Hey folks :)
Right now the property parser function on Wikipedia and other clients only works with the label of the property. People are asking us to make it also work with aliases. In order to do that labels and aliases need to be unique across properties. There are unfortunately a number of properties where the label and aliases are not unique. Those need to be fixed before we can enable the feature. Bene has created a page that lists all properties that need to have their aliases changed: https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a look at this and fix some that'd be much appreciated.
Cheers Lydia
Fixed for many items. Seems time to update that pages.
Also I tried to fix it for these two, but it seems that as multiple languages have an issue of double aliases/labels, the software prevents me from saving both pages. https://www.wikidata.org/wiki/Property:P1451 https://www.wikidata.org/wiki/Property:P1546
I solved it by deleting the second one, changing the first one and restoring the second one again.
Romaine
2015-07-08 1:27 GMT+02:00 Lydia Pintscher lydia.pintscher@wikimedia.de:
Hey folks :)
Right now the property parser function on Wikipedia and other clients only works with the label of the property. People are asking us to make it also work with aliases. In order to do that labels and aliases need to be unique across properties. There are unfortunately a number of properties where the label and aliases are not unique. Those need to be fixed before we can enable the feature. Bene has created a page that lists all properties that need to have their aliases changed: https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a look at this and fix some that'd be much appreciated.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On Wed, Jul 8, 2015 at 2:39 AM, Romaine Wiki romaine.wiki@gmail.com wrote:
Fixed for many items. Seems time to update that pages.
It should be updating regularly. Bene: Can you check if it still does?
Cheers Lydia
Hoi, It is not realistic from a language perspective to ask for labels to be unique. Thanks, GerardM
On 8 July 2015 at 01:27, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
Hey folks :)
Right now the property parser function on Wikipedia and other clients only works with the label of the property. People are asking us to make it also work with aliases. In order to do that labels and aliases need to be unique across properties. There are unfortunately a number of properties where the label and aliases are not unique. Those need to be fixed before we can enable the feature. Bene has created a page that lists all properties that need to have their aliases changed: https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a look at this and fix some that'd be much appreciated.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On Wed, Jul 8, 2015 at 3:07 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is not realistic from a language perspective to ask for labels to be unique.
For items I totally agree. And that's not happening. But for properties I'd hope that would be possible. Do you have cases where it is not?
Cheers Lydia
Hoi, Given that we only support 280+ languages, I am fairly certain that this restriction will bite us. I strongly urge you to allow for it but monitor for it and see what can be done. Thanks, GerardM
On 8 July 2015 at 03:42, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
On Wed, Jul 8, 2015 at 3:07 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is not realistic from a language perspective to ask for labels to be unique.
For items I totally agree. And that's not happening. But for properties I'd hope that would be possible. Do you have cases where it is not?
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 09:45 schrieb Gerard Meijssen:
Hoi, Given that we only support 280+ languages, I am fairly certain that this restriction will bite us. I strongly urge you to allow for it but monitor for it and see what can be done.
Property labels are unique per language, not globally. They always have been. Properties can be accessed by their name (label) in wikitext, so they have to be unique.
We now want to make it possibel to also access properties by their alias (otherwise, changing a property label will break all pages that have been using it). This requires property aliases to also be unique per language.
Hoi, I did appreciate that we are talking per language. When properties are to be unique and you do this for computing reasons and do not accept that languages are not their for your convenience, you will hit problems.
My question, you have always known that Wikidata is multi language.. What research did you do to establish that you CAN make this requirement in the first place?
Technically there is no problem disambiguating. People are really good understanding what a property means based on context. Machines do not care for labels (really).. Thanks, GerardM
On 8 July 2015 at 10:27, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 09:45 schrieb Gerard Meijssen:
Hoi, Given that we only support 280+ languages, I am fairly certain that this restriction will bite us. I strongly urge you to allow for it but
monitor for it
and see what can be done.
Property labels are unique per language, not globally. They always have been. Properties can be accessed by their name (label) in wikitext, so they have to be unique.
We now want to make it possibel to also access properties by their alias (otherwise, changing a property label will break all pages that have been using it). This requires property aliases to also be unique per language.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 13:11 schrieb Gerard Meijssen:
Technically there is no problem disambiguating. People are really good understanding what a property means based on context. Machines do not care for labels (really)..
For items, that is exactly hgow it is. For properties however, that is not the case.
Consider {{#property:date of birth}}. That's much more readable than {{#property:P569}}, right? That's why properties can be *addressed* by their label, when transcluding data into wikitext. Properties have unique *names* by which they can be *used*, not just labels for display, like items do.
The problem we have is that you cannot change a propertie's label, because you would break usage in {{#property}} calls. Unless you keep the old label as an alias. Which can only work if the alias is unique, too.
We will get clashes between different ontologies, can't see how we can avoid that. Our label should be unique, but not aliases. We use aliases as a way to access something that we later must disambiguate. We should not have a uniqueness constraint on aliases, it simply makes no sense.
On Wed, Jul 8, 2015 at 1:23 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 13:11 schrieb Gerard Meijssen:
Technically there is no problem disambiguating. People are really good understanding what a property means based on context. Machines do not care for labels (really)..
For items, that is exactly hgow it is. For properties however, that is not the case.
Consider {{#property:date of birth}}. That's much more readable than {{#property:P569}}, right? That's why properties can be *addressed* by their label, when transcluding data into wikitext. Properties have unique *names* by which they can be *used*, not just labels for display, like items do.
The problem we have is that you cannot change a propertie's label, because you would break usage in {{#property}} calls. Unless you keep the old label as an alias. Which can only work if the alias is unique, too.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Another way to formulate this is that "The labels are our name for the property and we can force them to be unique, while the aliases are other peoples names for similar properties and as we can't control them they won't be unique."
On Wed, Jul 8, 2015 at 1:43 PM, John Erling Blad jeblad@gmail.com wrote:
We will get clashes between different ontologies, can't see how we can avoid that. Our label should be unique, but not aliases. We use aliases as a way to access something that we later must disambiguate. We should not have a uniqueness constraint on aliases, it simply makes no sense.
On Wed, Jul 8, 2015 at 1:23 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 13:11 schrieb Gerard Meijssen:
Technically there is no problem disambiguating. People are really good understanding what a property means based on context. Machines do not care for labels (really)..
For items, that is exactly hgow it is. For properties however, that is not the case.
Consider {{#property:date of birth}}. That's much more readable than {{#property:P569}}, right? That's why properties can be *addressed* by their label, when transcluding data into wikitext. Properties have unique *names* by which they can be *used*, not just labels for display, like items do.
The problem we have is that you cannot change a propertie's label, because you would break usage in {{#property}} calls. Unless you keep the old label as an alias. Which can only work if the alias is unique, too.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 13:43 schrieb John Erling Blad:
We will get clashes between different ontologies, can't see how we can avoid that. Our label should be unique, but not aliases. We use aliases as a way to access something that we later must disambiguate. We should not have a uniqueness constraint on aliases, it simply makes no sense.
That's what we had. The problem is: you can't change the label without changing all references to it, then. IF properites can also be addressed by their aliases, it's simple to change the primary name (label), or add a secondary name (alias).
What kind of clash with another ontology do you mean? Can you give a concrete example?
What you describe is the problem that arise from preferred label vs alternate label, and that "our" labels are used as preferred labels while the aliases are used as alternate label. The first is sort of correct while the last is not correct. Create a new alternate label that can be used for unique lookup.
What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.
For an example of an ontology; assume you want aliases for DCterms and we have properties height, width, length. Then those three properties would all have the alias "DCterms extent". We are actually planning to create properties for height, width and length, it is only me that want extent.
On Wed, Jul 8, 2015 at 1:54 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 13:43 schrieb John Erling Blad:
We will get clashes between different ontologies, can't see how we can avoid that. Our label should be unique, but not aliases. We use aliases as a way to access something that we later must disambiguate. We should not have a uniqueness constraint on aliases, it simply makes no sense.
That's what we had. The problem is: you can't change the label without changing all references to it, then. IF properites can also be addressed by their aliases, it's simple to change the primary name (label), or add a secondary name (alias).
What kind of clash with another ontology do you mean? Can you give a concrete example?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Silly question: Why not leave the system as it is (allowing for non-unique aliases), but do some (reasonable) cleanup, then warn Wikipedia editors when they use a non-unique alias? Like using references without the {{reflist}}?
On Wed, Jul 8, 2015 at 1:13 PM John Erling Blad jeblad@gmail.com wrote:
What you describe is the problem that arise from preferred label vs alternate label, and that "our" labels are used as preferred labels while the aliases are used as alternate label. The first is sort of correct while the last is not correct. Create a new alternate label that can be used for unique lookup.
What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.
For an example of an ontology; assume you want aliases for DCterms and we have properties height, width, length. Then those three properties would all have the alias "DCterms extent". We are actually planning to create properties for height, width and length, it is only me that want extent.
On Wed, Jul 8, 2015 at 1:54 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 13:43 schrieb John Erling Blad:
We will get clashes between different ontologies, can't see how we can avoid that. Our label should be unique, but not aliases. We use aliases as a way to access something that we later must disambiguate. We should not have a uniqueness constraint on aliases, it simply makes no sense.
That's what we had. The problem is: you can't change the label without
changing
all references to it, then. IF properites can also be addressed by their aliases, it's simple to change the primary name (label), or add a
secondary name
(alias).
What kind of clash with another ontology do you mean? Can you give a
concrete
example?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 14:32 schrieb Magnus Manske:
Silly question: Why not leave the system as it is (allowing for non-unique aliases), but do some (reasonable) cleanup, then warn Wikipedia editors when they use a non-unique alias? Like using references without the {{reflist}}?
If aliases are not unique, you cannot use them to refer to properties. If you cannot refer to properties by alias, then you cannot change the labels of properties without breaking all usages.
On Wed, Jul 8, 2015 at 3:18 PM Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 14:32 schrieb Magnus Manske:
Silly question: Why not leave the system as it is (allowing for
non-unique
aliases), but do some (reasonable) cleanup, then warn Wikipedia editors
when
they use a non-unique alias? Like using references without the
{{reflist}}?
If aliases are not unique, you cannot use them to refer to properties.
You can, if they are unique. For the few that would conflict, the user would see an error, prompting him to chose a different alias. People adapt quickly to this.
If you
cannot refer to properties by alias, then you cannot change the labels of properties without breaking all usages.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 16:57 schrieb Magnus Manske:
If aliases are not unique, you cannot use them to refer to properties.You can, if they are unique.
That's exactly what I said :)
For the few that would conflict, the user would see an error, prompting him to chose a different alias. People adapt quickly to this.
That's exactly what we did, but had to revert, to allow people to clean up existing conflicts. Which is what Lydia's original mail was about.
On 8 July 2015 at 13:32, Magnus Manske magnusmanske@googlemail.com wrote:
Silly question: Why not leave the system as it is (allowing for non-unique aliases), but do some (reasonable) cleanup, then warn Wikipedia editors
when
they use a non-unique alias? Like using references without the
{{reflist}}?
I like this approach a lot - presumably we already have such errors if you use an alias that doesn't exist, or try to invoke a non-existent P number?
However, there's one possible problem that I can see - someone creating duplicate aliases at a later date on Wikidata, and causing errors to pop up across Wikipedia as a result. (When added they were fine, but now they're ambiguous.) The editor might not realise this, and the first anyone knows is when the client wikis complain...
A.
-- - Andrew Gray andrew.gray@dunelm.org.uk
Hoi, Why do you think Wikipedia is an issue? Why do you think that the label should not be overridden to something that makes sense in the context? Thanks, GerardM
On 9 July 2015 at 10:29, Andrew Gray andrew.gray@dunelm.org.uk wrote:
On 8 July 2015 at 13:32, Magnus Manske magnusmanske@googlemail.com wrote:
Silly question: Why not leave the system as it is (allowing for
non-unique
aliases), but do some (reasonable) cleanup, then warn Wikipedia editors
when
they use a non-unique alias? Like using references without the
{{reflist}}?
I like this approach a lot - presumably we already have such errors if you use an alias that doesn't exist, or try to invoke a non-existent P number?
However, there's one possible problem that I can see - someone creating duplicate aliases at a later date on Wikidata, and causing errors to pop up across Wikipedia as a result. (When added they were fine, but now they're ambiguous.) The editor might not realise this, and the first anyone knows is when the client wikis complain...
A.
--
- Andrew Gray
andrew.gray@dunelm.org.uk
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 14:13 schrieb John Erling Blad:
What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.
Yes. The semantics of labels on properties is indeed different from labels on items, and always has been. Property labels are defined to be unique names. Extending the uniqueness to aliases allows them, to qact as redirects, which allow use to "rename" or "move" properties (that is, change their label).
Using (unique) aliases for this seems the simplest solution. Introducing another kind-of-aliases would be confusing in the UI as well as in the data model, and wopuld require a lot more code, which is nearly exactly the same as for aliases.
I don't follow your example with the DC vocabulary. For the height, width and length properties, why would one want an alias that is the same for all of them? What would that be useful for?
Daniel Kinzler says " Consider {{#property:date of birth}}. That's much more readable than {{#property:P569}}, right? "
Yes, it is more readable, but is it really all worth the effort ?
Perhaps allow input with the {{#property:P569}} but then after page is saved... Computer Magic Happens Here ... the tag then looks like {{#property:P569|date of birth}}
It magically inserts the label as well ... to support the feature request of having readable properties ?
Or is the feature request to actually allow input that looks like {{#property:date of birth}} so that folks do not even have to remember numbers or lookup the mapping ?
Thad +ThadGuidry https://www.google.com/+ThadGuidry
On Wed, Jul 8, 2015 at 9:21 AM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 14:13 schrieb John Erling Blad:
What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.
Yes. The semantics of labels on properties is indeed different from labels on items, and always has been. Property labels are defined to be unique names. Extending the uniqueness to aliases allows them, to qact as redirects, which allow use to "rename" or "move" properties (that is, change their label).
Using (unique) aliases for this seems the simplest solution. Introducing another kind-of-aliases would be confusing in the UI as well as in the data model, and wopuld require a lot more code, which is nearly exactly the same as for aliases.
I don't follow your example with the DC vocabulary. For the height, width and length properties, why would one want an alias that is the same for all of them? What would that be useful for?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 16:43 schrieb Thad Guidry:
Or is the feature request to actually allow input that looks like {{#property:date of birth}} so that folks do not even have to remember numbers or lookup the mapping ?
That's not a feature request, that's how it is designewd to work, and has been working for a long time. The change under discussion is allowing aliases here, in addition to labels.
I already said that on project chat, but the discussion is going on here as well, so ...
Is it possible to give to the parser function a substitution semantics ? If a name or an alias is replaced by a Pid on the first expansion, maybe be a html comment on the original string used to find the property for human readers, this would solve the label unstability problem.
If the label is ambiguous and cannot be substituted, then instead of subst with a Pid, it may also possible to substitute with an error span explaining it's ambiguous and suggesting the alternative properties ...
2015-07-08 16:52 GMT+02:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
Am 08.07.2015 um 16:43 schrieb Thad Guidry:
Or is the feature request to actually allow input that looks like {{#property:date of birth}} so that folks do not even have to remember
numbers
or lookup the mapping ?
That's not a feature request, that's how it is designewd to work, and has been working for a long time. The change under discussion is allowing aliases here, in addition to labels.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 17:14 schrieb Thomas Douillard:
I already said that on project chat, but the discussion is going on here as well, so ...
Is it possible to give to the parser function a substitution semantics ? If a name or an alias is replaced by a Pid on the first expansion, maybe be a html comment on the original string used to find the property for human readers, this would solve the label unstability problem.
I think it might be possible, but not easy, and potentially very confusing. Why would you prefer that solution?
2015-07-08 17:34 GMT+02:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
I think it might be possible, but not easy, and potentially very confusing. Why would you prefer that solution?
Because of the property renaming problem. If unfortunately a property is renamed and someone used the label in a parser function call, then this might break templates. This might happen if a property is split, and we don't keep the alias on both resulting properties of the splitting because of the uniqueness of aliases constraint.
Of course if the property is split there might need more drastic changes in the clients and templates, but relying on labels for stability when we have stable Pids to rely on seems like a half-baked solution to me. Especially when renaming is so easy in the UI.
Am 08.07.2015 um 18:45 schrieb Thomas Douillard:
2015-07-08 17:34 GMT+02:00 Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de>: I think it might be possible, but not easy, and potentially very confusing. Why would you prefer that solution?
Because of the property renaming problem. If unfortunately a property is renamed and someone used the label in a parser function call, then this might break templates.
Not if the old name is kept as an alias. Which seems the easier and more streight forward solution to me.
This might happen if a property is split, and we don't keep the alias on both resulting properties of the splitting because of the uniqueness of aliases constraint.
Splitting will always be a problem. Some usages will end up having the wrong P-id or name or label or alias or whatever.
Of course if the property is split there might need more drastic changes in the clients and templates, but relying on labels for stability when we have stable Pids to rely on seems like a half-baked solution to me. Especially when renaming is so easy in the UI.
The idea was readability and internationalization.
If there is consensus to not use human readable property names for accessing data, and solely rely on IDs instead, we could indeed stop all this right now, and just drop the uniqueness constraint for labels as well as for aliases of properties.
You are right that changing the name of a property shouldn't be as easy as it currently is. There should at least be a warning.
The idea was readability and internationalization.
This is achievable by keeping as a comment the label or alias the user used in the first place. I think for intl it's better to be able to share templates beetween projects ;)
2015-07-08 22:00 GMT+02:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
Am 08.07.2015 um 18:45 schrieb Thomas Douillard:
2015-07-08 17:34 GMT+02:00 Daniel Kinzler <daniel.kinzler@wikimedia.de mailto:daniel.kinzler@wikimedia.de>: I think it might be possible, but not easy, and potentially very
confusing. Why
would you prefer that solution?Because of the property renaming problem. If unfortunately a property is
renamed
and someone used the label in a parser function call, then this might
break
templates.
Not if the old name is kept as an alias. Which seems the easier and more streight forward solution to me.
This might happen if a property is split, and we don't keep the alias on both resulting properties of the splitting because of the uniqueness
of
aliases constraint.
Splitting will always be a problem. Some usages will end up having the wrong P-id or name or label or alias or whatever.
Of course if the property is split there might need more drastic changes
in the
clients and templates, but relying on labels for stability when we have
stable
Pids to rely on seems like a half-baked solution to me. Especially when
renaming
is so easy in the UI.
The idea was readability and internationalization.
If there is consensus to not use human readable property names for accessing data, and solely rely on IDs instead, we could indeed stop all this right now, and just drop the uniqueness constraint for labels as well as for aliases of properties.
You are right that changing the name of a property shouldn't be as easy as it currently is. There should at least be a warning.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On Wed, Jul 8, 2015 at 5:11 PM, Thomas Douillard thomas.douillard@gmail.com wrote:
The idea was readability and internationalization.
This is achievable by keeping as a comment the label or alias the user used in the first place. I think for intl it's better to be able to share templates beetween projects ;)
I like that.
Helder
Il 08/07/2015 22:00, Daniel Kinzler ha scritto:
The idea was readability and internationalization.
Which one is more readable and internationalized, {{#property:syntymäaika}} or {{#property:P569}} ? The former makes reading and reusing templates from other wikis much harder.
If there is consensus to not use human readable property names for accessing data, and solely rely on IDs instead, we could indeed stop all this right now, and just drop the uniqueness constraint for labels as well as for aliases of properties.
Yes!
You are right that changing the name of a property shouldn't be as easy as it currently is. There should at least be a warning.
Hoi, YES !! It is almost certain that this will not consistently work for any and all languages and it will result in confusion at best. Relying on an ID is easily understood. Thanks, GerardM
On 9 July 2015 at 03:12, Ricordisamoa ricordisamoa@openmailbox.org wrote:
Il 08/07/2015 22:00, Daniel Kinzler ha scritto:
The idea was readability and internationalization.
Which one is more readable and internationalized, {{#property:syntymäaika}} or {{#property:P569}} ? The former makes reading and reusing templates from other wikis much harder.
If there is consensus to not use human readable property names for accessing data, and solely rely on IDs instead, we could indeed stop all this right now, and just drop the uniqueness constraint for labels as well as for aliases of properties.
Yes!
You are right that changing the name of a property shouldn't be as easy as it currently is. There should at least be a warning.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 09.07.2015 um 03:12 schrieb Ricordisamoa:
Il 08/07/2015 22:00, Daniel Kinzler ha scritto:
The idea was readability and internationalization.
Which one is more readable and internationalized, {{#property:syntymäaika}} or {{#property:P569}} ? The former makes reading and reusing templates from other wikis much harder.
Well, yea, localizing things always makes them harder to use by people who do not speak the respective language. I'd say the natural language name is still more readable, since there are probably more people who know what "syntymäaika" means than what "P569" means.
But I see your point, especially with regards to cross-wiki template use (if we ever get that).
If there is consensus to not use human readable property names for accessing data, and solely rely on IDs instead, we could indeed stop all this right now, and just drop the uniqueness constraint for labels as well as for aliases of properties.
Yes!
Can you point to a community decision/discussion regarding this? Is the sentiment the same across several languages?
If this feature is *really* not needed/wanted, we can of course drop it. Would save a lot of trouble. But I'd want to be rather sure about that. After all, even MediaWiki's magic words like #REDIRECT are localized.
On a related note: what about the "#property" bit. Should that be localized?...
Hoi, My understanding is that it is machines that need to uniquely know what a property stands for. People are quite capable understanding what a combination of a P and a Q mean. At that time there is no disambiguation. With proper descriptions it is not hard at all to choose the right property when a new statement is made.
So really what IS the issue? Thanks, GerardM
On 9 July 2015 at 10:59, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 03:12 schrieb Ricordisamoa:
Il 08/07/2015 22:00, Daniel Kinzler ha scritto:
The idea was readability and internationalization.
Which one is more readable and internationalized,
{{#property:syntymäaika}} or
{{#property:P569}} ? The former makes reading and reusing templates from other wikis much
harder.
Well, yea, localizing things always makes them harder to use by people who do not speak the respective language. I'd say the natural language name is still more readable, since there are probably more people who know what "syntymäaika" means than what "P569" means.
But I see your point, especially with regards to cross-wiki template use (if we ever get that).
If there is consensus to not use human readable property names for
accessing
data, and solely rely on IDs instead, we could indeed stop all this
right now,
and just drop the uniqueness constraint for labels as well as for
aliases of
properties.
Yes!
Can you point to a community decision/discussion regarding this? Is the sentiment the same across several languages?
If this feature is *really* not needed/wanted, we can of course drop it. Would save a lot of trouble. But I'd want to be rather sure about that. After all, even MediaWiki's magic words like #REDIRECT are localized.
On a related note: what about the "#property" bit. Should that be localized?...
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 09.07.2015 um 11:04 schrieb Gerard Meijssen:
Hoi, My understanding is that it is machines that need to uniquely know what a property stands for. People are quite capable understanding what a combination of a P and a Q mean. At that time there is no disambiguation. With proper descriptions it is not hard at all to choose the right property when a new statement is made.
That is not the use case under discussion.
The use case is accessing data from wikitext on the client wiki, using something like {{#property:date of birth}}. In order to do that, "date of birth" has to be unique.
For picking a property on wikidata, when creating statements, unique labels are not needed. That was never an issue, and never the subject of discussion.
Hoi, If that is the use case, not much changes. We are talking software. When a property is selected, the software does not need to show the property number and still store it. Nothing new here. It does not need to change the label either when Wikidata decides to change the label. A report may be produced to show the use of the old label... Again, nothing new here. It has been done and can be done again. Thanks, GerardM
On 9 July 2015 at 11:10, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 11:04 schrieb Gerard Meijssen:
Hoi, My understanding is that it is machines that need to uniquely know what a property stands for. People are quite capable understanding what a
combination
of a P and a Q mean. At that time there is no disambiguation. With proper descriptions it is not hard at all to choose the right property when a
new
statement is made.
That is not the use case under discussion.
The use case is accessing data from wikitext on the client wiki, using something like {{#property:date of birth}}. In order to do that, "date of birth" has to be unique.
For picking a property on wikidata, when creating statements, unique labels are not needed. That was never an issue, and never the subject of discussion.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 09.07.2015 um 11:21 schrieb Gerard Meijssen:
Hoi, If that is the use case, not much changes. We are talking software. When a property is selected, the software does not need to show the property number and still store it. Nothing new here. It does not need to change the label either when Wikidata decides to change the label. A report may be produced to show the use of the old label... Again, nothing new here. It has been done and can be done again.
So, the label changes. Later, the page that uses it on Wikipedia is edited. The parser looks at the #property tag, and sees a label that it no longer understands (how would it). The data transclusion is broken. Wouldn't it be nice if the transclusion could keep working? Unique aliases would do that.
Alternatively, we could do what Ricordisamoa suggests, and just put the P-ID into the wikitext. But then you couldn't easily see what {{#property:P1234}} means when looking at the wikitext. If people are OK with that - fine!
Or we could just do away with wikitext completely. Then we wouldn't have this problem. We'd use the ID internally, and the label for display and editing, just like we do on Wikidata. But I don't think that's going to happen any time soon.
-- daniel
Hoi, The parser would understand it because it stored information. The property is still the same property, the label it uses is now seen as a local overrride.
Daniel, there are many ways to solve this. The problem you face is based on a misconception. Language are not meant for rigidity. Expectting that you can has already been shown to be problematic. Consequently persisting on labels to be always unique is a problem of your own choosing. A problem that will not go away and is easiest solved now.
It is abundantly clear that you WILL use the requirement of Wikidata as an excuse when a language has no alternative. At that time it will be even more problematic to fix this issue. Not only because of the amount of data that may need conversion but also because assumption about Wikidata have grown even more fixed and rigid. Thanks GerardM
On 9 July 2015 at 11:42, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 11:21 schrieb Gerard Meijssen:
Hoi, If that is the use case, not much changes. We are talking software. When
a
property is selected, the software does not need to show the property
number and
still store it. Nothing new here. It does not need to change the label
either
when Wikidata decides to change the label. A report may be produced to
show the
use of the old label... Again, nothing new here. It has been done and
can be
done again.
So, the label changes. Later, the page that uses it on Wikipedia is edited. The parser looks at the #property tag, and sees a label that it no longer understands (how would it). The data transclusion is broken. Wouldn't it be nice if the transclusion could keep working? Unique aliases would do that.
Alternatively, we could do what Ricordisamoa suggests, and just put the P-ID into the wikitext. But then you couldn't easily see what {{#property:P1234}} means when looking at the wikitext. If people are OK with that - fine!
Or we could just do away with wikitext completely. Then we wouldn't have this problem. We'd use the ID internally, and the label for display and editing, just like we do on Wikidata. But I don't think that's going to happen any time soon.
-- daniel
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
* currently, property values can be accessed from wikitext using the property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
* if yes, should it be possible to change a property's label at all?
* if yes, should references to the old label break, or should they continue to work?
* if they should continue to work, should this be achieved by making the old label an alias?
* if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The property is still the same property, the label it uses is now seen as a local overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is based on a misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels to be always unique is a problem of your own choosing. A problem that will not go away and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as an excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
Daniel,
I'm worried you're trying to reinvent #REDIRECT I know it looks suboptimal the way it is, but it has proved working quite efficiently So what is clearly missing is a #REDIRECT for properties It would avoid breaking things It would avoid making labels unique (which could be a burden, if not really needed) It would allow the wikipedia to be able to detect that they are pointing to a REDIRECT and take their time to point to the last one
(because we know that some redirect are temporary and are deleted at some point : do you want to recreate this behaviour in the labels ?)
Regards,
Mohamed
On Thu, Jul 9, 2015 at 12:15 PM, Daniel Kinzler <daniel.kinzler@wikimedia.de
wrote:
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they
continue to work?
- if they should continue to work, should this be achieved by making the
old label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is based
on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels
to be
always unique is a problem of your own choosing. A problem that will not
go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as
an
excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 09.07.2015 um 12:32 schrieb Innovimax SARL:
Daniel,
I'm worried you're trying to reinvent #REDIRECT I know it looks suboptimal the way it is, but it has proved working quite efficiently So what is clearly missing is a #REDIRECT for properties
That would only work if properties had *one* label, and that label was used as the page title. But that is not the case: properties have one label per language, the P-ID is used as the page title.
Unless we want to manage all labels and aliases of a property as page titles (that redirect to the actual property page), the redirect mechanism won't work. Doing this would get quite messy, and introduce more complexity and new problems, I'm afraid.
You are correct that aliases that can be used as alternative names to address properties are conceptually very similar to redirects. But the technical mechanism doesn't quite fit. I can't see a feasible way to use the existing redirect mechanism to implement what we want.
Substitution is a standard mechanism in MediaWiki and would achive what Gerard needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and substituted to "{{#property:Pxxx}} <--date of birth-->" and everything would be stored in the Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that. Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
* currently, property values can be accessed from wikitext using the property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
* if yes, should it be possible to change a property's label at all?
* if yes, should references to the old label break, or should they continue to work?
* if they should continue to work, should this be achieved by making the old label an alias?
* if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is based
on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels
to be
always unique is a problem of your own choosing. A problem that will not
go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as an excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
This can also be described (and fixed) as a light-weight version problem. The clients templates and modules (probably also articles later on) are using an old surface form of the property label that existed at some previous time (the time when was last saved). When the client then tries to fetch the property value through use of the label it fails because the property label has a new version.
The proper solution would then be to allow lookup of property labels with a time constraint. Use of the time constraint would be hidden from the user, it would be added by the software. If a property label is used in a template/module, and the label has been changed at Wikidata between to revisions, then a warning can be given in the template/module's history. The new template/module will always use the last timestamp from the revision, it would be up to the user to fix those cases. If a template/module is fixed in the client then it will work even if the label is changed on the repo.
Only real cost would be an additional column for timestamps in the database table. A variation would be to make the lookup indirect through the revision table. Not sure if that would add anything useful.
On Thu, Jul 9, 2015 at 2:22 PM, Thomas Douillard thomas.douillard@gmail.com wrote:
Substitution is a standard mechanism in MediaWiki and would achive what Gerard needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and substituted to "{{#property:Pxxx}} <--date of birth-->" and everything would be stored in the Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that.
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they continue
to work?
- if they should continue to work, should this be achieved by making the old
label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The property is still the same property, the label it uses is now seen as a local overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is based on a misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels to be always unique is a problem of your own choosing. A problem that will not go away and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as an excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 09.07.2015 um 14:22 schrieb Thomas Douillard:> Substitution is a standard mechanism in MediaWiki and would achive what Gerard
needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and substituted to "{{#property:Pxxx}} <--date of birth-->" and everything would be stored in the Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that.
There is nothing wrong with that. If people on the client wikis think this is sufficient, and the {{#property}} parser function does not need to support "named" access to properties, that would be fine with me. So far, I assumed that it would be very annoying to be forced to rely on IDs when using {{#property}}. But if that is fine with everybody, that's fine with me - supporting only P-ids there is much simpler than allowing access via labels or aliases.
On Thu, Jul 9, 2015 at 10:39 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 14:22 schrieb Thomas Douillard:> Substitution is a standard mechanism in MediaWiki and would achive what Gerard
needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and substituted to "{{#property:Pxxx}} <--date of birth-->" and everything would be stored in the Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that.
There is nothing wrong with that. If people on the client wikis think this is sufficient, and the {{#property}} parser function does not need to support "named" access to properties, that would be fine with me. So far, I assumed that it would be very annoying to be forced to rely on IDs when using {{#property}}. But if that is fine with everybody, that's fine with me - supporting only P-ids there is much simpler than allowing access via labels or aliases.
Accessing only via the property's ID isn't enough. Folks, we want more usage of Wikidata on the Wikipedias and other sister projects. There'll be a few bullets we have to bite to make this happen. I am convinced this is one of them.
Cheers Lydia
Daniel, Gerard, Lydia, and Wikidatans,
Long interested here in a Creative Commons' licensed Universal Translator for all 7929+ languages (that is significantly CC Wikidata/Wikipedia- informed between all its 288 languages) and that is extensible, and especially with developing machine learning and voice etc., this Wikidata conversation is GREAT because aliases of properties can be coded for the unique multiplicity of connotations/denotations, almost infinitely, in any given word (or meme even, as replicating cultural unit), and then be recombined. In what ways can this discussion further anticipate a large translator for all of Wikipedia's 288 languages 5, 10, 20 + years ahead, I wonder, and with developing CC artificial intelligence? (Interspecies' communication and related coding systems? Genetics' link to language use? Brain neuron firing patterns to language use? Reflexivity and subjectivity questions of consciousness down the phylogenetic tree, etc? ...each a Q-item + ...all vis-a-vis CC AI?)
In what ways would a far-reaching and great Wikidata translator facilitate far greater usage of Wikipedia and its sister projects?
Thank you, Scott MacLeod
CC http://worlduniversityandschool.org/
On Thu, Jul 9, 2015 at 10:39 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 14:22 schrieb Thomas Douillard:> Substitution is a
standard
mechanism in MediaWiki and would achive what Gerard
needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and
substituted to
"{{#property:Pxxx}} <--date of birth-->" and everything would be stored
in the
Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that.
There is nothing wrong with that. If people on the client wikis think
this is
sufficient, and the {{#property}} parser function does not need to support "named" access to properties, that would be fine with me. So far, I
assumed that
it would be very annoying to be forced to rely on IDs when using
{{#property}}.
But if that is fine with everybody, that's fine with me - supporting only
P-ids
there is much simpler than allowing access via labels or aliases.
Accessing only via the property's ID isn't enough. Folks, we want more usage of Wikidata on the Wikipedias and other sister projects. There'll be a few bullets we have to bite to make this happen. I am convinced this is one of them.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
_______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Lydia,
If I'm not wront the substituion scenario covers your requirements
{{#property:Pxxx}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:MainLabelAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:UnambiuousAliasAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="unambiguous alias at subst time"}} {{#property:AmbiuousAliasAtSubsTime}} ==SUBST BY ==>{{ERROR}} ==> hence the editor can fix it
It looks like covering most of cases without adding extra burden of unicity and keeping existing mechanism
Mohamed
On Thu, Jul 9, 2015 at 10:50 PM, Lydia Pintscher < lydia.pintscher@wikimedia.de> wrote:
On Thu, Jul 9, 2015 at 10:39 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 09.07.2015 um 14:22 schrieb Thomas Douillard:> Substitution is a
standard
mechanism in MediaWiki and would achive what Gerard
needs ... for example: "{{subst:property_prime|date of birth}}" could be expanded and
substituted to
"{{#property:Pxxx}} <--date of birth-->" and everything would be
stored in the
Wikitext. What's wrong with this kind of solution exactly ? you did not elaborate on that.
There is nothing wrong with that. If people on the client wikis think
this is
sufficient, and the {{#property}} parser function does not need to
support
"named" access to properties, that would be fine with me. So far, I
assumed that
it would be very annoying to be forced to rely on IDs when using
{{#property}}.
But if that is fine with everybody, that's fine with me - supporting
only P-ids
there is much simpler than allowing access via labels or aliases.
Accessing only via the property's ID isn't enough. Folks, we want more usage of Wikidata on the Wikipedias and other sister projects. There'll be a few bullets we have to bite to make this happen. I am convinced this is one of them.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL innovimax@gmail.com wrote:
Lydia,
If I'm not wront the substituion scenario covers your requirements
{{#property:Pxxx}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:MainLabelAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:UnambiuousAliasAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="unambiguous alias at subst time"}} {{#property:AmbiuousAliasAtSubsTime}} ==SUBST BY ==>{{ERROR}} ==> hence the editor can fix it
It looks like covering most of cases without adding extra burden of unicity and keeping existing mechanism
I think the comment part is rather ugly and I'd expect more confusing for editors than it helps tbh. And substituting without the comment would help the first editor but none of the ones after him/her. So I'm not convinced this is a solution :/
Cheers Lydia
This is at the cost of renaming properties becoming a burden, si this overall increase the maintenance cost. Understanding the comment part on the other band is a matter of reading the d'oc, which is the l'East we can wait for coming from a template editor. If web think of users using for example visual editor then ... It's notre a problème as VE will do all the rendering and will translate into labels automagically. So ... Who are the users who actually need this ? Le 10 juil. 2015 00:14, "Lydia Pintscher" lydia.pintscher@wikimedia.de a écrit :
On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL innovimax@gmail.com wrote:
Lydia,
If I'm not wront the substituion scenario covers your requirements
{{#property:Pxxx}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:MainLabelAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:UnambiuousAliasAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="unambiguous alias at subst time"}} {{#property:AmbiuousAliasAtSubsTime}} ==SUBST BY ==>{{ERROR}} ==> hence
the
editor can fix it
It looks like covering most of cases without adding extra burden of
unicity
and keeping existing mechanism
I think the comment part is rather ugly and I'd expect more confusing for editors than it helps tbh. And substituting without the comment would help the first editor but none of the ones after him/her. So I'm not convinced this is a solution :/
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
OT: French spelling checker?
Il 10/07/2015 16:56, Thomas Douillard ha scritto:
This is at the cost of renaming properties becoming a burden, si this overall increase the maintenance cost. Understanding the comment part on the other band is a matter of reading the d'oc, which is the l'East we can wait for coming from a template editor. If web think of users using for example visual editor then ... It's notre a problème as VE will do all the rendering and will translate into labels automagically. So ... Who are the users who actually need this ?
Le 10 juil. 2015 00:14, "Lydia Pintscher" <lydia.pintscher@wikimedia.de mailto:lydia.pintscher@wikimedia.de> a écrit :
On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL <innovimax@gmail.com <mailto:innovimax@gmail.com>> wrote: > Lydia, > > If I'm not wront the substituion scenario covers your requirements > > {{#property:Pxxx}} ==SUBST BY > ==>{{#property:Pxxx|label="main label at the time of substitution"}} > {{#property:MainLabelAtSubsTime}} ==SUBST BY > ==>{{#property:Pxxx|label="main label at the time of substitution"}} > {{#property:UnambiuousAliasAtSubsTime}} ==SUBST BY > ==>{{#property:Pxxx|label="unambiguous alias at subst time"}} > {{#property:AmbiuousAliasAtSubsTime}} ==SUBST BY ==>{{ERROR}} ==> hence the > editor can fix it > > It looks like covering most of cases without adding extra burden of unicity > and keeping existing mechanism I think the comment part is rather ugly and I'd expect more confusing for editors than it helps tbh. And substituting without the comment would help the first editor but none of the ones after him/her. So I'm not convinced this is a solution :/ Cheers Lydia -- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de <http://www.wikimedia.de> Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985. _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Yep /o\ Getting used to my new phone
"Not a problem" was corrected into "our problem" in French, which is pretty bad. Le 10 juil. 2015 17:56, "Ricordisamoa" ricordisamoa@openmailbox.org a écrit :
OT: French spelling checker?
Il 10/07/2015 16:56, Thomas Douillard ha scritto:
This is at the cost of renaming properties becoming a burden, si this overall increase the maintenance cost. Understanding the comment part on the other band is a matter of reading the d'oc, which is the l'East we can wait for coming from a template editor. If web think of users using for example visual editor then ... It's notre a problème as VE will do all the rendering and will translate into labels automagically. So ... Who are the users who actually need this ? Le 10 juil. 2015 00:14, "Lydia Pintscher" lydia.pintscher@wikimedia.de a écrit :
On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL innovimax@gmail.com wrote:
Lydia,
If I'm not wront the substituion scenario covers your requirements
{{#property:Pxxx}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:MainLabelAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="main label at the time of substitution"}} {{#property:UnambiuousAliasAtSubsTime}} ==SUBST BY ==>{{#property:Pxxx|label="unambiguous alias at subst time"}} {{#property:AmbiuousAliasAtSubsTime}} ==SUBST BY ==>{{ERROR}} ==>
hence the
editor can fix it
It looks like covering most of cases without adding extra burden of
unicity
and keeping existing mechanism
I think the comment part is rather ugly and I'd expect more confusing for editors than it helps tbh. And substituting without the comment would help the first editor but none of the ones after him/her. So I'm not convinced this is a solution :/
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing listWikidata@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, I have been thinking about this. I think the current approach is wrong. I think it is the properties where Wikipedians rightfully want to be able to use a text as a label that fits their need. Restricting this is probably wrong.
It is in the Q values that we do NOT want editors to make a change, obviously. I intent to write more about this. Thanks, GerardM
On 9 July 2015 at 12:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they
continue to work?
- if they should continue to work, should this be achieved by making the
old label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is based
on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels
to be
always unique is a problem of your own choosing. A problem that will not
go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as
an
excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced in by assumptions from Wikidata. Thanks, GerardM
http://ultimategerardm.blogspot.nl/2015/07/wikidata-dont-fence-wikipedia-in....
On 10 July 2015 at 17:35, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I have been thinking about this. I think the current approach is wrong. I think it is the properties where Wikipedians rightfully want to be able to use a text as a label that fits their need. Restricting this is probably wrong.
It is in the Q values that we do NOT want editors to make a change, obviously. I intent to write more about this. Thanks, GerardM
On 9 July 2015 at 12:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they
continue to work?
- if they should continue to work, should this be achieved by making the
old label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is
based on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on labels
to be
always unique is a problem of your own choosing. A problem that will
not go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata as
an
excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hi. I understand your argument but I think there is an underlying incorrect assumption : template editors are actually ... Templates developers. Not regular editors. It's only a fraction of editors who actually touched a template in their life. (Maybe there is numbers somewhere)
With that in mind, the question become: will this change be any useful for those who already edited templates (my guess is barely) and for those who did never edited a template the same question can be asked. What stopped them until now, will Wikidata change anything to this, and lastly ... Will this feature have any influence at all ? I'm really dubious it's worth the trouble pictured like that. But I could be wrong. It would take more than a blogpost to convince me though ;) Le 11 juil. 2015 09:29, "Gerard Meijssen" gerard.meijssen@gmail.com a écrit :
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced in by assumptions from Wikidata. Thanks, GerardM
http://ultimategerardm.blogspot.nl/2015/07/wikidata-dont-fence-wikipedia-in....
On 10 July 2015 at 17:35, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I have been thinking about this. I think the current approach is wrong. I think it is the properties where Wikipedians rightfully want to be able to use a text as a label that fits their need. Restricting this is probably wrong.
It is in the Q values that we do NOT want editors to make a change, obviously. I intent to write more about this. Thanks, GerardM
On 9 July 2015 at 12:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they
continue to work?
- if they should continue to work, should this be achieved by making the
old label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is
based on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on
labels to be
always unique is a problem of your own choosing. A problem that will
not go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata
as an
excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, When a statement is used in a text, the same is true. Sometimes only the value is needed and sometimes an associated text is helpful. The notion that Wikidata insists on a set label is wrong for all the reasons given. Thanks, GerardM
On 11 July 2015 at 11:22, Thomas Douillard thomas.douillard@gmail.com wrote:
Hi. I understand your argument but I think there is an underlying incorrect assumption : template editors are actually ... Templates developers. Not regular editors. It's only a fraction of editors who actually touched a template in their life. (Maybe there is numbers somewhere)
With that in mind, the question become: will this change be any useful for those who already edited templates (my guess is barely) and for those who did never edited a template the same question can be asked. What stopped them until now, will Wikidata change anything to this, and lastly ... Will this feature have any influence at all ? I'm really dubious it's worth the trouble pictured like that. But I could be wrong. It would take more than a blogpost to convince me though ;) Le 11 juil. 2015 09:29, "Gerard Meijssen" gerard.meijssen@gmail.com a écrit :
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced in by assumptions from Wikidata. Thanks, GerardM
http://ultimategerardm.blogspot.nl/2015/07/wikidata-dont-fence-wikipedia-in....
On 10 July 2015 at 17:35, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, I have been thinking about this. I think the current approach is wrong. I think it is the properties where Wikipedians rightfully want to be able to use a text as a label that fits their need. Restricting this is probably wrong.
It is in the Q values that we do NOT want editors to make a change, obviously. I intent to write more about this. Thanks, GerardM
On 9 July 2015 at 12:15, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Before I reply to what you wrote Gerard, let me summarize the question we actually need to answer to go forward:
- currently, property values can be accessed from wikitext using the
property's (unique) label. Do we want to keep this? (the alternative is access via P-ids only)
if yes, should it be possible to change a property's label at all?
if yes, should references to the old label break, or should they
continue to work?
- if they should continue to work, should this be achieved by making
the old label an alias?
- if no, how should it be achieved, exactly?
Am 09.07.2015 um 11:54 schrieb Gerard Meijssen:
Hoi, The parser would understand it because it stored information. The
property is
still the same property, the label it uses is now seen as a local
overrride.
That would be a completely new system, and quite complicated. It would also introduce a host of new issues (such local overrides may conflict with new names, or other local overrides, for instance. Language fallback makes this even more fun. Not to mention that we currently don't have a good place to store this kind of information).
The current proposal is to store those overrides in wikidata, as aliases.
Daniel, there are many ways to solve this. The problem you face is
based on a
misconception. Language are not meant for rigidity.
Indeed. But names can be chosen to be unique. We do that all the time when naming pages. And when naming properties. Property names (labels) were always meant to be unique, this is nothing new. (For a while, there was a bug that allowed duplicate labels under *some* circumstances, sorry for that).
Expectting that you can has already been shown to be problematic. Consequently persisting on
labels to be
always unique is a problem of your own choosing. A problem that will
not go away
and is easiest solved now.
If we drop the requirement that properties should be accessible from wikitext via their name, then yes, that would be easy. If people can live with using P-Ids directly, that's fine with me.
It is abundantly clear that you WILL use the requirement of Wikidata
as an
excuse when a language has no alternative.
Excuse for what? From a programming perspective, making people use IDs is by far the simplest solution. It's easy enough for remove support for label based access to properties, if that support is not needed.
Allowing access from wikitext using non-unique names, THAT is not something I would want to support. I can't imagine how that would work at all.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 11.07.2015 um 09:28 schrieb Gerard Meijssen:
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced in by assumptions from Wikidata.
Your blog post seemsw to assume that the wikidata label will be displayed on wikipedia. That's not the case. We are discussing the use of localized property names (let's just stop calling them labels, it's misleading) for properties in the {{#property}} parser function, in order to retrieve the value. Only the value. So, is an ID better than a localized unique name? Both will only be visible in wikitext, and, in practice, only in wikitext in templates.
Your blog post states that labels cannot be changed once they are set. This is wrong. The can be changed. Currently, that will however break all wikitext (templates) that use that name to refer to the property. This is what we are trying to fix by allowing properties to be accessed by an alias. The downside is that this requires aliases to be unique.
I'm not sure how the number of languages is relevant at all. The name(s) of a property have to be unique per language. How many languages there are doesn't matter at all for this, since there can not be conflicts between languages.
In any case, *non* of this is at all visible to readers.
Forget aliases, it will only add to the overall mess. Labels should be versioned.
John
On Sat, Jul 11, 2015 at 10:20 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 11.07.2015 um 09:28 schrieb Gerard Meijssen:
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced in by assumptions from Wikidata.
Your blog post seemsw to assume that the wikidata label will be displayed on wikipedia. That's not the case. We are discussing the use of localized property names (let's just stop calling them labels, it's misleading) for properties in the {{#property}} parser function, in order to retrieve the value. Only the value. So, is an ID better than a localized unique name? Both will only be visible in wikitext, and, in practice, only in wikitext in templates.
Your blog post states that labels cannot be changed once they are set. This is wrong. The can be changed. Currently, that will however break all wikitext (templates) that use that name to refer to the property. This is what we are trying to fix by allowing properties to be accessed by an alias. The downside is that this requires aliases to be unique.
I'm not sure how the number of languages is relevant at all. The name(s) of a property have to be unique per language. How many languages there are doesn't matter at all for this, since there can not be conflicts between languages.
In any case, *non* of this is at all visible to readers.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, If none of this is visible to users, the whole point of names of properties are senseless. Why have them in the first place and prevent this whole issue by using the property identifier itself.
The number of languages is only relevant in so far that it is absolutely clear that you assume that you will have sensible property names in the first place. It is not smart to do so. It has been indicated that there are issues. Thanks, GerardM
On 11 July 2015 at 22:20, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 11.07.2015 um 09:28 schrieb Gerard Meijssen:
Hoi, I blogged about it. My argument is that Wikipedia should not be fenced
in by
assumptions from Wikidata.
Your blog post seemsw to assume that the wikidata label will be displayed on wikipedia. That's not the case. We are discussing the use of localized property names (let's just stop calling them labels, it's misleading) for properties in the {{#property}} parser function, in order to retrieve the value. Only the value. So, is an ID better than a localized unique name? Both will only be visible in wikitext, and, in practice, only in wikitext in templates.
Your blog post states that labels cannot be changed once they are set. This is wrong. The can be changed. Currently, that will however break all wikitext (templates) that use that name to refer to the property. This is what we are trying to fix by allowing properties to be accessed by an alias. The downside is that this requires aliases to be unique.
I'm not sure how the number of languages is relevant at all. The name(s) of a property have to be unique per language. How many languages there are doesn't matter at all for this, since there can not be conflicts between languages.
In any case, *non* of this is at all visible to readers.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 11.07.2015 um 23:21 schrieb Gerard Meijssen:
Hoi, If none of this is visible to users, the whole point of names of properties are senseless. Why have them in the first place and prevent this whole issue by using the property identifier itself.
So, being able to use a localized name to refer to a property in wikitext is not useful?
Hoi, The drawbacks are that you make assumptions about languages. Also having localised names prevents the copying of functionality from one to the other. So I would not use it, I would show a localised name and its desctription but store the property identifier. Text in this is a service not to be relied upon. Thanks, GerardM
On 12 July 2015 at 00:35, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 11.07.2015 um 23:21 schrieb Gerard Meijssen:
Hoi, If none of this is visible to users, the whole point of names of
properties are
senseless. Why have them in the first place and prevent this whole issue
by
using the property identifier itself.
So, being able to use a localized name to refer to a property in wikitext is not useful?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
I'm also of the opinion that this whole problem seems pretty easily solved by just using the PID numbers. If the only folk who will, in practice, make use of this functionality are template developers, it seems to me that they should be able to look up the PID numbers. I like the idea of using substitution to do the initial lookup for them.
While I think that being able to reference properties by name in Wikitext would be nice, I'm not convinced its currently worth it.
Thank you, Derric Atzrott
On Sun, Jul 12, 2015 at 2:43 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, The drawbacks are that you make assumptions about languages. Also having localised names prevents the copying of functionality from one to the other. So I would not use it, I would show a localised name and its desctription but store the property identifier. Text in this is a service not to be relied upon. Thanks, GerardM
On 12 July 2015 at 00:35, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 11.07.2015 um 23:21 schrieb Gerard Meijssen:
Hoi, If none of this is visible to users, the whole point of names of
properties are
senseless. Why have them in the first place and prevent this whole
issue by
using the property identifier itself.
So, being able to use a localized name to refer to a property in wikitext is not useful?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
I agree and find the whole idea to be just ridiculously overly ambitious for all the reasons Gerard has mentioned. In fact, I have to always click on both QIDs and the PIDs in Wikidata just to make sure I have the proper one, so why would I not do that from Wikipedia while developing a template? PID names may or may not be unique, but what has not even come up here is that their names are also the names of many QIDs. As more properties and items are added, this will only increase and the whole point of assigning numbers is to make life easier for everybody, including those languages that have not filled in the labels of QIDs and PIDs yet.
On Sun, Jul 12, 2015 at 10:37 AM, Derric Atzrott zellfaze@zellfaze.org wrote:
I'm also of the opinion that this whole problem seems pretty easily solved by just using the PID numbers. If the only folk who will, in practice, make use of this functionality are template developers, it seems to me that they should be able to look up the PID numbers. I like the idea of using substitution to do the initial lookup for them.
While I think that being able to reference properties by name in Wikitext would be nice, I'm not convinced its currently worth it.
Thank you, Derric Atzrott
On Sun, Jul 12, 2015 at 2:43 AM, Gerard Meijssen < gerard.meijssen@gmail.com> wrote:
Hoi, The drawbacks are that you make assumptions about languages. Also having localised names prevents the copying of functionality from one to the other. So I would not use it, I would show a localised name and its desctription but store the property identifier. Text in this is a service not to be relied upon. Thanks, GerardM
On 12 July 2015 at 00:35, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 11.07.2015 um 23:21 schrieb Gerard Meijssen:
Hoi, If none of this is visible to users, the whole point of names of
properties are
senseless. Why have them in the first place and prevent this whole
issue by
using the property identifier itself.
So, being able to use a localized name to refer to a property in wikitext is not useful?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 12.07.2015 um 08:43 schrieb Gerard Meijssen:
Hoi, The drawbacks are that you make assumptions about languages. Also having localised names prevents the copying of functionality from one to the other. So I would not use it, I would show a localised name and its desctription but store the property identifier. Text in this is a service not to be relied upon.
It seems like this argument would applied to all magic words used in wikitext, such as __NOTOC__ or #REDIRECT. These support localization, and many are localized. But I don't know how widely the localoized versions are used.
Would you say we should drop localization for magic words for the reasons given above (compatibility between wikis, mainly)?
Actually, the same argument also applies to the names of templates. Templates very often use other templates. Re-using such a construct on another wiki requires all the templates names to remain stable. Should we use english names, or better, numeric names, for all templates?
Oh, the same applies to namespaces, too - let's just use {{#ns:14}} everywhere instead of "Category" and its localized equivalents.
For magic words and namespaces, there is a mechanism that allows the english name to always work. So users can pick: use a portable name (english), or use a localized name. It's the same with property names: you can use the portable numeric ID, or a localized name. We are currently trying to deal with the issue that unlike namespaces and magic words, properties can be renamed.
Hoi, Sorry but this reaction is beneath you. Thanks, GerardM
On 12 July 2015 at 12:50, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 12.07.2015 um 08:43 schrieb Gerard Meijssen:
Hoi, The drawbacks are that you make assumptions about languages. Also having localised names prevents the copying of functionality from one to the
other. So
I would not use it, I would show a localised name and its desctription
but store
the property identifier. Text in this is a service not to be relied upon.
It seems like this argument would applied to all magic words used in wikitext, such as __NOTOC__ or #REDIRECT. These support localization, and many are localized. But I don't know how widely the localoized versions are used.
Would you say we should drop localization for magic words for the reasons given above (compatibility between wikis, mainly)?
Actually, the same argument also applies to the names of templates. Templates very often use other templates. Re-using such a construct on another wiki requires all the templates names to remain stable. Should we use english names, or better, numeric names, for all templates?
Oh, the same applies to namespaces, too - let's just use {{#ns:14}} everywhere instead of "Category" and its localized equivalents.
For magic words and namespaces, there is a mechanism that allows the english name to always work. So users can pick: use a portable name (english), or use a localized name. It's the same with property names: you can use the portable numeric ID, or a localized name. We are currently trying to deal with the issue that unlike namespaces and magic words, properties can be renamed.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 12.07.2015 um 12:52 schrieb Gerard Meijssen:
Hoi, Sorry but this reaction is beneath you.
Sorry for the annoyed tone. But I'm quite serious about the questions I asked.
We localize magic words, namespaces, and template names. These are not visible to users, the localization is done for conveniance of people editing wikitext. So why should we not do the same with property names? What's the difference?
And, if that localization gets in the way of portability as you argue, and is not relevant to the people who use these features, why don't we get rid of them?
I do think that allowing access via (optionaly!) localized names is useful. But if it's not wanted/needed, it's fine with me, it would save me quite a bit of work. But I think that we should be consistent about it.
Hoi, You do not get it. There are many properties. Consequently the scale of things is substantially different. It has been demonstrated that languages will have homonyms and consequently it is NOT a good idea to use labels or whatever you call them for properties. You can use them as long as internally you use the P-number. You can use a text as long as the combination of label and description is unique. This combination may be useful.
At the same time be aware that property labels will be wrong and will need to be changed at a later date. When this presents a problem for the comparison with external sources, it is tough. It is best to indicate this from the start.
The argument about what happens in MediaWiki is secondary. And sorry that not everyone cares or knows about that in your way. The point is very much that at the scale of thousands and thousands of properties it does not scale. This point has been made plenty of times by now. Thanks, GerardM
On 12 July 2015 at 15:08, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 12.07.2015 um 12:52 schrieb Gerard Meijssen:
Hoi, Sorry but this reaction is beneath you.
Sorry for the annoyed tone. But I'm quite serious about the questions I asked.
We localize magic words, namespaces, and template names. These are not visible to users, the localization is done for conveniance of people editing wikitext. So why should we not do the same with property names? What's the difference?
And, if that localization gets in the way of portability as you argue, and is not relevant to the people who use these features, why don't we get rid of them?
I do think that allowing access via (optionaly!) localized names is useful. But if it's not wanted/needed, it's fine with me, it would save me quite a bit of work. But I think that we should be consistent about it.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 12.07.2015 um 15:31 schrieb Gerard Meijssen:
Hoi, You do not get it.
Indeed. This is why I am asking questions.
There are many properties. Consequently the scale of things is substantially different.
There are far, far more templates than properties. And we use unique, localized names for templates. Why not for properties? And if we don't want this for properties, why do the same arguments not apply for template names?
It has been demonstrated that languages will have homonyms and consequently it is NOT a good idea to use labels or whatever you call them for properties. You can use them as long as internally you use the P-number.
Internally, we always use the P-number. Unless with "internally" you mean "in wikitext". This is the point under discussion: whether we want localized names for use in wikitext.
You can use a text as long as the combination of label and description is unique. This combination may be useful.
This is how we do it for items. This works quite well with a selector widget. It does not work inside wikitext - there, you either need a unique name, or rely on the plain ID.
For items, sitelinks act as a per-language unique name. For properties, we decided to require a unique label, since we can't use sitelinks there, and the number is low enough (a few thousand, compared to tens of millions of items) that ambuguities should be rare.
At the same time be aware that property labels will be wrong and will need to be changed at a later date.
This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything.
When this presents a problem for the comparison with external sources, it is tough. It is best to indicate this from the start.
Why would labels or aliases be used for comparison with external sources? Properties can be linked to external vocabularies via statements, just like we do it for items. Relying on labels for doing this would be asking for trouble.
The argument about what happens in MediaWiki is secondary. And sorry that not everyone cares or knows about that in your way. The point is very much that at the scale of thousands and thousands of properties it does not scale. This point has been made plenty of times by now.
Really? How and where? I only hear you asserting it, but I see no evidence. I see it scaling perfectly well on Wikidata. Property names already *are* unique, always have been. I know of no major problems with this. There are some issues with cultural differences and homonyms (e.g. the distinction between sex and gender, or the double meaning of "editor" in Portuguese), but these are relatively rare, and no worse than naming dicussions on Wikipedia.
I for one agree with Gerard that this is a problem.
John
søn. 12. jul. 2015, 18.08 skrev Daniel Kinzler <daniel.kinzler@wikimedia.de
:
Am 12.07.2015 um 15:31 schrieb Gerard Meijssen:
Hoi, You do not get it.
Indeed. This is why I am asking questions.
There are many properties. Consequently the scale of things is substantially different.
There are far, far more templates than properties. And we use unique, localized names for templates. Why not for properties? And if we don't want this for properties, why do the same arguments not apply for template names?
It has been demonstrated that languages will have homonyms and consequently it is NOT a good idea to use labels or
whatever you
call them for properties. You can use them as long as internally you use
the
P-number.
Internally, we always use the P-number. Unless with "internally" you mean "in wikitext". This is the point under discussion: whether we want localized names for use in wikitext.
You can use a text as long as the combination of label and description is unique. This combination may be useful.
This is how we do it for items. This works quite well with a selector widget. It does not work inside wikitext - there, you either need a unique name, or rely on the plain ID.
For items, sitelinks act as a per-language unique name. For properties, we decided to require a unique label, since we can't use sitelinks there, and the number is low enough (a few thousand, compared to tens of millions of items) that ambuguities should be rare.
At the same time be aware that property labels will be wrong and will
need to be
changed at a later date.
This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything.
When this presents a problem for the comparison with external sources, it is tough. It is best to indicate this from the
start.
Why would labels or aliases be used for comparison with external sources? Properties can be linked to external vocabularies via statements, just like we do it for items. Relying on labels for doing this would be asking for trouble.
The argument about what happens in MediaWiki is secondary. And sorry
that not
everyone cares or knows about that in your way. The point is very much
that at
the scale of thousands and thousands of properties it does not scale.
This point
has been made plenty of times by now.
Really? How and where? I only hear you asserting it, but I see no evidence. I see it scaling perfectly well on Wikidata. Property names already *are* unique, always have been. I know of no major problems with this. There are some issues with cultural differences and homonyms (e.g. the distinction between sex and gender, or the double meaning of "editor" in Portuguese), but these are relatively rare, and no worse than naming dicussions on Wikipedia.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Me too. On the point of Wikipedia templates, I would like to remind you that templates are a dramatically confusing mess on Wikipedia, and lots of those "unique, localized names" do not lend themselves to reuse, which is why we have so many doubles and why the translation extension hasn't been able to use them yet. Andy Mabbett has spent a lot of time and effort in trying to clean this up a bit on the English Wikipedia by merging and consolidating various popular templates, and I believe that properties are starting to move in the same direction. I certainly don't think we want to look at Wikipedia templates as an example of how to go about doing this.
On Mon, Jul 13, 2015 at 9:10 AM, John Erling Blad jeblad@gmail.com wrote:
I for one agree with Gerard that this is a problem.
John
søn. 12. jul. 2015, 18.08 skrev Daniel Kinzler < daniel.kinzler@wikimedia.de>:
Am 12.07.2015 um 15:31 schrieb Gerard Meijssen:
Hoi, You do not get it.
Indeed. This is why I am asking questions.
There are many properties. Consequently the scale of things is substantially different.
There are far, far more templates than properties. And we use unique, localized names for templates. Why not for properties? And if we don't want this for properties, why do the same arguments not apply for template names?
It has been demonstrated that languages will have homonyms and consequently it is NOT a good idea to use labels or
whatever you
call them for properties. You can use them as long as internally you
use the
P-number.
Internally, we always use the P-number. Unless with "internally" you mean "in wikitext". This is the point under discussion: whether we want localized names for use in wikitext.
You can use a text as long as the combination of label and description is unique. This combination may be useful.
This is how we do it for items. This works quite well with a selector widget. It does not work inside wikitext - there, you either need a unique name, or rely on the plain ID.
For items, sitelinks act as a per-language unique name. For properties, we decided to require a unique label, since we can't use sitelinks there, and the number is low enough (a few thousand, compared to tens of millions of items) that ambuguities should be rare.
At the same time be aware that property labels will be wrong and will
need to be
changed at a later date.
This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything.
When this presents a problem for the comparison with external sources, it is tough. It is best to indicate this from the
start.
Why would labels or aliases be used for comparison with external sources? Properties can be linked to external vocabularies via statements, just like we do it for items. Relying on labels for doing this would be asking for trouble.
The argument about what happens in MediaWiki is secondary. And sorry
that not
everyone cares or knows about that in your way. The point is very much
that at
the scale of thousands and thousands of properties it does not scale.
This point
has been made plenty of times by now.
Really? How and where? I only hear you asserting it, but I see no evidence. I see it scaling perfectly well on Wikidata. Property names already *are* unique, always have been. I know of no major problems with this. There are some issues with cultural differences and homonyms (e.g. the distinction between sex and gender, or the double meaning of "editor" in Portuguese), but these are relatively rare, and no worse than naming dicussions on Wikipedia.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
Il 13/07/2015 11:45, Jane Darnell ha scritto:
Me too. On the point of Wikipedia templates, I would like to remind you that templates are a dramatically confusing mess on Wikipedia, and lots of those "unique, localized names" do not lend themselves to reuse, which is why we have so many doubles and why the translation extension hasn't been able to use them yet. Andy Mabbett has spent a lot of time and effort in trying to clean this up a bit on the English Wikipedia by merging and consolidating various popular templates, and I believe that properties are starting to move in the same direction. I certainly don't think we want to look at Wikipedia templates as an example of how to go about doing this.
On Mon, Jul 13, 2015 at 9:10 AM, John Erling Blad <jeblad@gmail.com mailto:jeblad@gmail.com> wrote:
I for one agree with Gerard that this is a problem. John søn. 12. jul. 2015, 18.08 skrev Daniel Kinzler <daniel.kinzler@wikimedia.de <mailto:daniel.kinzler@wikimedia.de>>: Am 12.07.2015 um 15:31 schrieb Gerard Meijssen: > Hoi, > You do not get it. Indeed. This is why I am asking questions. > There are many properties. Consequently the scale of things > is substantially different. There are far, far more templates than properties. And we use unique, localized names for templates. Why not for properties? And if we don't want this for properties, why do the same arguments not apply for template names? > It has been demonstrated that languages will have > homonyms and consequently it is NOT a good idea to use labels or whatever you > call them for properties. You can use them as long as internally you use the > P-number. Internally, we always use the P-number. Unless with "internally" you mean "in wikitext". This is the point under discussion: whether we want localized names for use in wikitext. > You can use a text as long as the combination of label and description > is unique. This combination may be useful. This is how we do it for items. This works quite well with a selector widget. It does not work inside wikitext - there, you either need a unique name, or rely on the plain ID. For items, sitelinks act as a per-language unique name. For properties, we decided to require a unique label, since we can't use sitelinks there, and the number is low enough (a few thousand, compared to tens of millions of items) that ambuguities should be rare. > At the same time be aware that property labels will be wrong and will need to be > changed at a later date. This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything. > When this presents a problem for the comparison with > external sources, it is tough. It is best to indicate this from the start. Why would labels or aliases be used for comparison with external sources? Properties can be linked to external vocabularies via statements, just like we do it for items. Relying on labels for doing this would be asking for trouble. > The argument about what happens in MediaWiki is secondary. And sorry that not > everyone cares or knows about that in your way. The point is very much that at > the scale of thousands and thousands of properties it does not scale. This point > has been made plenty of times by now. Really? How and where? I only hear you asserting it, but I see no evidence. I see it scaling perfectly well on Wikidata. Property names already *are* unique, always have been. I know of no major problems with this. There are some issues with cultural differences and homonyms (e.g. the distinction between sex and gender, or the double meaning of "editor" in Portuguese), but these are relatively rare, and no worse than naming dicussions on Wikipedia. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V. _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
2015-07-13 15:24 GMT+02:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
Providing this possibility IMHO is a good thing. If it is possible to allow this kind of access to data without generating the End of the Universe, I'm all for it. Then it *will* be difficult to deal with all the problems, but I don't think this is a good reason NOT to try to implement it.
Am 13.07.2015 um 15:40 schrieb Luca Martinelli:
Providing this possibility IMHO is a good thing. If it is possible to allow this kind of access to data without generating the End of the Universe, I'm all for it. Then it *will* be difficult to deal with all the problems, but I don't think this is a good reason NOT to try to implement it.
Thank you :)
To clarify: This already *is* implemented in the software. There are just some conflicting aliases to be cleaned up before we can turn alias uniqueness on.
Basically, there is the conveniance of being able to use a localized name, against the the inconveniance of being forced to find unique labels and aliases.
Basically, the community has to pick one or the other: use P-number everywhere, or (optionally) use localized names, but be forced to find unique ones.
If Q then P, I suppose?
Thank you, Scott On Jul 13, 2015 8:43 AM, "Daniel Kinzler" daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 15:40 schrieb Luca Martinelli:
Providing this possibility IMHO is a good thing. If it is possible to allow this kind of access to data without generating the End of the Universe, I'm all for it. Then it *will* be difficult to deal with all the problems, but I don't think this is a good reason NOT to try to implement it.
Thank you :)
To clarify: This already *is* implemented in the software. There are just some conflicting aliases to be cleaned up before we can turn alias uniqueness on.
Basically, there is the conveniance of being able to use a localized name, against the the inconveniance of being forced to find unique labels and aliases.
Basically, the community has to pick one or the other: use P-number everywhere, or (optionally) use localized names, but be forced to find unique ones.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
A property function for versioned labels would look _exactly_ the same as today, but the request for the actual value would use the label and a timestamp. The timestamp would be the last revision of the template.
Look up books on distributed databases, and check out how they maintain consistency. In our case it is a simplified set up with a single master server with multiple clients that has read access to the server. In addition they have their own state that interfere with the master state.
We have a consistency problem (CAP theorem) because the clients don't update their state (the templates) according to changes on the server (the labels). One solution to this is to keep the last known version (a timestamp) to make it possible to continue using outdated information.
Another way to say this is that a change in the label leaves an invalid state at the clients, because the transaction ends prematurly. That is the templates are not updated, which they must be if the system lacks versioning.
Even another way to describe this is that the process running on the server and the clients lacks isolation, which again can be restored with versioning.
There are several consistency models that can be used, but I don't know if anyone includes something like the proposed "alias model".
CAP theorem is described in these two, but I havn't read them, sorry for that!
Brewer, Eric A.: Towards robust distributed systems (abstract), in: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7–
Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News (2002), vol. 33:pp. 51–59
On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch markus@semantic-mediawiki.org wrote:
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Another take on what happen with the labels.
You have a client that define some reference to data it gets from the server. The server then changes the valid reference to the data, and tells the client that the reference has changed. The client then says "fine" but does not update the reference to the data. To solve this (a) the master can provide an alternate lookup mechanism, or (b) the client must update the references, or (c) the client must provide the master with its old reference and a timestamp.
Wd-team wants to do (a) by making the aliases unique. That breaks some other use, basically they won't be aliases anymore, and people here on the list says "no".
I think nobody dare to do (b) because that imply rewriting the templates and modules. (The references to the data is in the messy templates, not some clean data structure.)
I want (c) but I think I'm perhaps the only one.
It is also possible to avoid the whole problem by using the P-ids, as they wont change.
On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad jeblad@gmail.com wrote:
A property function for versioned labels would look _exactly_ the same as today, but the request for the actual value would use the label and a timestamp. The timestamp would be the last revision of the template.
Look up books on distributed databases, and check out how they maintain consistency. In our case it is a simplified set up with a single master server with multiple clients that has read access to the server. In addition they have their own state that interfere with the master state.
We have a consistency problem (CAP theorem) because the clients don't update their state (the templates) according to changes on the server (the labels). One solution to this is to keep the last known version (a timestamp) to make it possible to continue using outdated information.
Another way to say this is that a change in the label leaves an invalid state at the clients, because the transaction ends prematurly. That is the templates are not updated, which they must be if the system lacks versioning.
Even another way to describe this is that the process running on the server and the clients lacks isolation, which again can be restored with versioning.
There are several consistency models that can be used, but I don't know if anyone includes something like the proposed "alias model".
CAP theorem is described in these two, but I havn't read them, sorry for that!
Brewer, Eric A.: Towards robust distributed systems (abstract), in: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7–
Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News (2002), vol. 33:pp. 51–59
On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch markus@semantic-mediawiki.org wrote:
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Actually I think we have a problem with all three points in the CAP theorem, so we should start coding for fault tolerance. Still this goes off-topic. I'm done with this thread.
On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad jeblad@gmail.com wrote:
A property function for versioned labels would look _exactly_ the same as today, but the request for the actual value would use the label and a timestamp. The timestamp would be the last revision of the template.
Look up books on distributed databases, and check out how they maintain consistency. In our case it is a simplified set up with a single master server with multiple clients that has read access to the server. In addition they have their own state that interfere with the master state.
We have a consistency problem (CAP theorem) because the clients don't update their state (the templates) according to changes on the server (the labels). One solution to this is to keep the last known version (a timestamp) to make it possible to continue using outdated information.
Another way to say this is that a change in the label leaves an invalid state at the clients, because the transaction ends prematurly. That is the templates are not updated, which they must be if the system lacks versioning.
Even another way to describe this is that the process running on the server and the clients lacks isolation, which again can be restored with versioning.
There are several consistency models that can be used, but I don't know if anyone includes something like the proposed "alias model".
CAP theorem is described in these two, but I havn't read them, sorry for that!
Brewer, Eric A.: Towards robust distributed systems (abstract), in: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7–
Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News (2002), vol. 33:pp. 51–59
On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch markus@semantic-mediawiki.org wrote:
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Thanks, John, for the explanation(s). I understand the idea. Essentially, the meaning of wikitext would then depend on when exactly a page is stored. The same content could have different meaning. That seems problematic to me ... But I guess we don't have to worry since it seems clear that this won't be implementable in MediaWiki as we know it today ;-) But thanks anyway -- it's an interesting concept, even if purely hypothetical right now.
Best regards,
Markus
On 13.07.2015 19:33, John Erling Blad wrote:
Actually I think we have a problem with all three points in the CAP theorem, so we should start coding for fault tolerance. Still this goes off-topic. I'm done with this thread.
On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad jeblad@gmail.com wrote:
A property function for versioned labels would look _exactly_ the same as today, but the request for the actual value would use the label and a timestamp. The timestamp would be the last revision of the template.
Look up books on distributed databases, and check out how they maintain consistency. In our case it is a simplified set up with a single master server with multiple clients that has read access to the server. In addition they have their own state that interfere with the master state.
We have a consistency problem (CAP theorem) because the clients don't update their state (the templates) according to changes on the server (the labels). One solution to this is to keep the last known version (a timestamp) to make it possible to continue using outdated information.
Another way to say this is that a change in the label leaves an invalid state at the clients, because the transaction ends prematurly. That is the templates are not updated, which they must be if the system lacks versioning.
Even another way to describe this is that the process running on the server and the clients lacks isolation, which again can be restored with versioning.
There are several consistency models that can be used, but I don't know if anyone includes something like the proposed "alias model".
CAP theorem is described in these two, but I havn't read them, sorry for that!
Brewer, Eric A.: Towards robust distributed systems (abstract), in: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7–
Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News (2002), vol. 33:pp. 51–59
On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch markus@semantic-mediawiki.org wrote:
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Agreed, that was a neat read John.
- It is not just experienced template coders who want to make use of
the parser function (This comes from discussions with several Wikipedians who want to try things but are not advanced enough for more than the property parser function.)
How easy is it to get the property ID?
Is it possible for us to make that easier to acquire? Perhaps add a button somewhere that says something like "Use this property in Wikitext" or somesuch. Using P numbers by themselves is not ideal, but I am still not convinced that there is another good way to do this and I think several people have made pretty reasonable arguments that aliases shouldn't be forced to be unique (though they often will be unique!).
I wish I had an idea for a solution myself. I feel bad giving an opinion without any input on how to fix the situation.
Thank you, Derric Atzrott
On Mon, Jul 13, 2015 at 2:46 PM, Markus Krötzsch < markus@semantic-mediawiki.org> wrote:
Thanks, John, for the explanation(s). I understand the idea. Essentially, the meaning of wikitext would then depend on when exactly a page is stored. The same content could have different meaning. That seems problematic to me ... But I guess we don't have to worry since it seems clear that this won't be implementable in MediaWiki as we know it today ;-) But thanks anyway -- it's an interesting concept, even if purely hypothetical right now.
Best regards,
Markus
On 13.07.2015 19:33, John Erling Blad wrote:
Actually I think we have a problem with all three points in the CAP theorem, so we should start coding for fault tolerance. Still this goes off-topic. I'm done with this thread.
On Mon, Jul 13, 2015 at 6:29 PM, John Erling Blad jeblad@gmail.com wrote:
A property function for versioned labels would look _exactly_ the same as today, but the request for the actual value would use the label and a timestamp. The timestamp would be the last revision of the template.
Look up books on distributed databases, and check out how they maintain consistency. In our case it is a simplified set up with a single master server with multiple clients that has read access to the server. In addition they have their own state that interfere with the master state.
We have a consistency problem (CAP theorem) because the clients don't update their state (the templates) according to changes on the server (the labels). One solution to this is to keep the last known version (a timestamp) to make it possible to continue using outdated information.
Another way to say this is that a change in the label leaves an invalid state at the clients, because the transaction ends prematurly. That is the templates are not updated, which they must be if the system lacks versioning.
Even another way to describe this is that the process running on the server and the clients lacks isolation, which again can be restored with versioning.
There are several consistency models that can be used, but I don't know if anyone includes something like the proposed "alias model".
CAP theorem is described in these two, but I havn't read them, sorry for that!
Brewer, Eric A.: Towards robust distributed systems (abstract), in: Proceedings of the nineteenth annual ACM symposium on Principles of distributed computing, PODC’00, ACM, New York, NY, USA, pp. 7–
Gilbert, Seth and Lynch, Nancy: Brewer’s conjecture and the feasibility of consistent, available, partition-tolerant web services. SIGACT News (2002), vol. 33:pp. 51–59
On Mon, Jul 13, 2015 at 4:21 PM, Markus Krötzsch markus@semantic-mediawiki.org wrote:
On 13.07.2015 16:01, John Erling Blad wrote:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
Following this thread for a while, I still have no idea what this solution is. Could you give an example of how the #property function in Wikitext will look for this proposal?
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
Citation needed ;-)
Markus
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
> > I agree too. > Also note that property IDs are language-neutral, unlike english > names > of > templates, magic words, etc. >
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
No we should not make the aliases unique, the reason aliases are
useful is because they are _not_ unique.
They are still usefil if they are not unique because search is fuzzy : if you search “whatever” you'll see both “wathever one” AND “whatever2” in the results …
2015-07-13 16:01 GMT+02:00 John Erling Blad jeblad@gmail.com:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
There are books on the topic, and also some dr thesis. I don't think we should create anything ad hoc for this. Go for a proven solution.
On Mon, Jul 13, 2015 at 3:24 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names
of
templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties
via
localized names, but if there is no demand for this possibility, and
it's a pain
to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique
aliases, so
property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 13.07.2015 um 16:27 schrieb Thomas Douillard:
No we should not make the aliases unique, the reason aliases are
useful is because they are _not_ unique.
They are still usefil if they are not unique because search is fuzzy : if you search “whatever” you'll see both “wathever one” AND “whatever2” in the results …
For search, they are still useful. For addressign things from wikitext, they do not work if they< are not unique.
Am 13.07.2015 um 16:01 schrieb John Erling Blad:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
We can do this once we have a mechanism in mediawiki that allows us to do this for templates ,etc. It's an extremely difficulat problem. So far nobody has been able to implement it, though it has been on the wishlist for a really long time.
A "timewarp" feature for everythign would be really cool, but it's FAR harder to implement. It would requrie a rewrite of quite a bit of MediaWiki.
You have versioning for templates, it is the last timestamp your labels should refer to. You don't have to regenerate a previous template, you just have to figure out which labels were valid at the time the template was last saved. That timestamp is one additional column in your labels table. That is your time warp machine. You don't need a time warp machine for everything, to use your example.
On Mon, Jul 13, 2015 at 4:43 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 16:01 schrieb John Erling Blad:
No we should not make the aliases unique, the reason aliases are useful is because they are _not_ unique. Add versioning to labels, that is the only real solution.
We can do this once we have a mechanism in mediawiki that allows us to do this for templates ,etc. It's an extremely difficulat problem. So far nobody has been able to implement it, though it has been on the wishlist for a really long time.
A "timewarp" feature for everythign would be really cool, but it's FAR harder to implement. It would requrie a rewrite of quite a bit of MediaWiki.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 13.07.2015 um 18:34 schrieb John Erling Blad:
You have versioning for templates, it is the last timestamp your labels should refer to. You don't have to regenerate a previous template, you just have to figure out which labels were valid at the time the template was last saved. That timestamp is one additional column in your labels table. That is your time warp machine. You don't need a time warp machine for everything, to use your example.
Works find until somebody renames or deletes a template, or oversights a revision, or there are multiple revisions with the same timestampt (yes, that is possible), etc. This has been tried, and it works ok-ish for the "normal" cases, and completely fails for edge cases, as far as I know: https://www.mediawiki.org/wiki/Extension:Memento
If you rename a template it still have the same history. If you delete a template, then I don't see how you would have a problem with content generated by that template. If someone oversights a revision, then the template is effectively edited and a new timestamp is given to the template. Whether two or more revisions have the same timestamp does not matter, whats important is that the master does not have conflicting labels on the same timestamp.
This is not about browsing the client on a past date, this is about "browsing" the labels on a past timestamp - and hopefully that should boil down to time resolution on the master(s), possibly with some time skew between the different database servers.
On Mon, Jul 13, 2015 at 6:51 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 18:34 schrieb John Erling Blad:
You have versioning for templates, it is the last timestamp your labels should refer to. You don't have to regenerate a previous template, you just have to figure out which labels were valid at the time the template was last saved. That timestamp is one additional column in your labels table. That is your time warp machine. You don't need a time warp machine for everything, to use your example.
Works find until somebody renames or deletes a template, or oversights a revision, or there are multiple revisions with the same timestampt (yes, that is possible), etc. This has been tried, and it works ok-ish for the "normal" cases, and completely fails for edge cases, as far as I know: https://www.mediawiki.org/wiki/Extension:Memento
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, Either you accept the consensus or you don't. Hiding behind Lydia is not graceful. How often is it necessary to indicate that you CAN show "localised names" as long as they are the labels used in Wikidata and as long as they come witha text we have the needed functionality.
It is just not the solution you have been looking for is it.. BUT it does satisfy our and Lydia's needs. Wonderful right? Thanks, GerardM
On 13 July 2015 at 15:24, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 13.07.2015 um 13:00 schrieb Ricordisamoa:
I agree too. Also note that property IDs are language-neutral, unlike english names of templates, magic words, etc.
As I said: if there is broad conseus to only use P-numbers to refer to properties, fine with me (note however that Lydia disagrees, and it's her decision). I like the idea of having the option of accessing properties via localized names, but if there is no demand for this possibility, and it's a pain to implement, I won't complain about dropping support for that.
But *if* we allow access to properties via localized unique labels (as we currently do), then we really *should* allow the same via unique aliases, so property labels can be chanegd without breaking stuff.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 13.07.2015 um 17:22 schrieb Gerard Meijssen:
Hoi, Either you accept the consensus or you don't.
Where is that consensus? Five people on a mailing list is hardly representative. Is there a "do not use labels to access properties" consensus across the client sites? I'd be happy to learn about it.
Hiding behind Lydia is not graceful.
I'm not hiding behind her, I'm aknowledging her prerogative as a product owner. I'd be out of line bypassing her on this.
How often is it necessary to indicate that you CAN show "localised names" as long as they are the labels used in Wikidata and as long as they come witha text we have the needed functionality.
Sure, for display, that's fine. For widgets on wikidata, too. We were dicussing readability of wikitext, though.
It is just not the solution you have been looking for is it.. BUT it does satisfy our and Lydia's needs. Wonderful right?
Using P-numbers in wikitext is not the solution I have been looking for?
If it's sufficient for the community, I'm happy with it. It means exactly zero work for me. It would allow me to throw out some not-so-pretty code. Yay!
I just don't take your word for it being sufficient for the community.
Hehe, to be fair with this argument you would have to provide a concensus that people want aliases in templates :) That's also probably five people on a bugtracker :)
2015-07-13 17:38 GMT+02:00 Daniel Kinzler daniel.kinzler@wikimedia.de:
Am 13.07.2015 um 17:22 schrieb Gerard Meijssen:
Hoi, Either you accept the consensus or you don't.
Where is that consensus? Five people on a mailing list is hardly representative. Is there a "do not use labels to access properties" consensus across the client sites? I'd be happy to learn about it.
Hiding behind Lydia is not graceful.
I'm not hiding behind her, I'm aknowledging her prerogative as a product owner. I'd be out of line bypassing her on this.
How often is it necessary to indicate that you CAN show "localised
names" as
long as they are the labels used in Wikidata and as long as they come
witha text
we have the needed functionality.
Sure, for display, that's fine. For widgets on wikidata, too. We were dicussing readability of wikitext, though.
It is just not the solution you have been looking for is it.. BUT it does satisfy our and Lydia's needs. Wonderful right?
Using P-numbers in wikitext is not the solution I have been looking for?
If it's sufficient for the community, I'm happy with it. It means exactly zero work for me. It would allow me to throw out some not-so-pretty code. Yay!
I just don't take your word for it being sufficient for the community.
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 13.07.2015 um 18:47 schrieb Thomas Douillard:
Hehe, to be fair with this argument you would have to provide a concensus that people want aliases in templates :) That's also probably five people on a bugtracker :)
True, but proper alias support is fixing a feature. Limiting access to P-numbers would be removing an existing feature.
Holy moly folks,
100 emails about this is slightly more than I expected...
On Mon, Jul 13, 2015 at 5:22 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hiding behind Lydia is not graceful.
Everyone who knows me should know that it is quite hard to physically hide behind me ;-) Seriously though. Daniel is right to defer this to me as in the end it is my call on the team. He was replying here as I'm officially on vacation for another 24h.
So here's the assumptions I am working with and why I think this is beneficial: * We do want more sister projects to make use of Wikidata data. * Right now one of several obstacles to more usage of Wikidata on sister projects is that it is simply too hard for most people - even technical ones. * Lua is great but poses a barrier to entry. The property parser function offers an easier alternative that more people can work with even if it is not as powerful as Lua. * People want to try and prototype with what Wikidata offers. The property parser function easily allows this. * Property IDs are posing a barrier to entry and understanding Wikidata. Natural language labels for the properties make this easier not just for the person who wrote the piece of wiki text but everyone else as well. * It is not just experienced template coders who want to make use of the parser function (This comes from discussions with several Wikipedians who want to try things but are not advanced enough for more than the property parser function.) * Editing infobox template code is hard! Wikidata should make editing them easier, not harder. Or at the very least not make the situation worse.
Based on all this I think we need to improve the parser function at least to some degree from what it is now.
Cheers Lydia
You asked for an example, end those are valid examples. It is even an example that use one of the most used ontologies on the net. Other examples from DCterms is coverage, which can be both temporal and spatial. We have a bunch of properties that can have an alias "DCterms coverage", a country for example or a year.
Use a separate list of "deferred labels", and put the existing label on that if someone tries to edit the defined (preferred) label. That list should be unique, as it should not be possible to save a new label that already exist on the list of deferred labels. At some future point in time it can be implemented some clean up routine, but I think it will take a long time before name clashes will be a real problem.
At some point I think we should seriously consider to use "SKOS Simple Knowledge Organization System Reference" http://www.w3.org/TR/skos-reference/
On Wed, Jul 8, 2015 at 4:21 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 14:13 schrieb John Erling Blad:
What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.
Yes. The semantics of labels on properties is indeed different from labels on items, and always has been. Property labels are defined to be unique names. Extending the uniqueness to aliases allows them, to qact as redirects, which allow use to "rename" or "move" properties (that is, change their label).
Using (unique) aliases for this seems the simplest solution. Introducing another kind-of-aliases would be confusing in the UI as well as in the data model, and wopuld require a lot more code, which is nearly exactly the same as for aliases.
I don't follow your example with the DC vocabulary. For the height, width and length properties, why would one want an alias that is the same for all of them? What would that be useful for?
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Am 08.07.2015 um 17:34 schrieb John Erling Blad:
You asked for an example, end those are valid examples. It is even an example that use one of the most used ontologies on the net. Other examples from DCterms is coverage, which can be both temporal and spatial. We have a bunch of properties that can have an alias "DCterms coverage", a country for example or a year.
For cross-linking properties with other vocabularies, we use P1628 "Equivalent Property", not aliases. I don't see how an alias would be useful for that. P1628 allows you to specify URIs, and it is itself marked as equivalent to owl:equivalentProperty, so it can be used directly by reasoners.
Use a separate list of "deferred labels", and put the existing label on that if someone tries to edit the defined (preferred) label. That list should be unique, as it should not be possible to save a new label that already exist on the list of deferred labels. At some future point in time it can be implemented some clean up routine, but I think it will take a long time before name clashes will be a real problem.
That's the idea, yes, we just call the deferred labels "aliases".
Sorry, but aliases are not deferred labels. We use an alias to disambiguate between properties.
I don't think we have anything that is equivalent to DCterms coverage,... At least I hope not!
An alias does not imply equivalence, not by a long shot.
On Wed, Jul 8, 2015 at 5:45 PM, Daniel Kinzler daniel.kinzler@wikimedia.de wrote:
Am 08.07.2015 um 17:34 schrieb John Erling Blad:
You asked for an example, end those are valid examples. It is even an example that use one of the most used ontologies on the net. Other examples from DCterms is coverage, which can be both temporal and spatial. We have a bunch of properties that can have an alias "DCterms coverage", a country for example or a year.
For cross-linking properties with other vocabularies, we use P1628 "Equivalent Property", not aliases. I don't see how an alias would be useful for that. P1628 allows you to specify URIs, and it is itself marked as equivalent to owl:equivalentProperty, so it can be used directly by reasoners.
Use a separate list of "deferred labels", and put the existing label on that if someone tries to edit the defined (preferred) label. That list should be unique, as it should not be possible to save a new label that already exist on the list of deferred labels. At some future point in time it can be implemented some clean up routine, but I think it will take a long time before name clashes will be a real problem.
That's the idea, yes, we just call the deferred labels "aliases".
-- Daniel Kinzler Senior Software Developer
Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 07/08/2015 03:42 AM, Lydia Pintscher wrote:
On Wed, Jul 8, 2015 at 3:07 AM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is not realistic from a language perspective to ask for labels to be unique.
For items I totally agree. And that's not happening. But for properties I'd hope that would be possible. Do you have cases where it is not?
Danish:
far/fader (father). https://en.wiktionary.org/wiki/fader#Danish
fader (godparent)
Alternative one could use the pattern 'fader (far)'? The 'fader' for 'far' is seldomly used though.
/Finn
On Tue, Jul 7, 2015 at 10:07 PM, Gerard Meijssen gerard.meijssen@gmail.com wrote:
Hoi, It is not realistic from a language perspective to ask for labels to be unique.
Indeed. For example, https://www.wikidata.org/wiki/Property:P123 en: publisher pt: editora
https://www.wikidata.org/wiki/Property:P98 en: editor pt: editor (male translation) pt: editora (female translation)
With unique aliases, I don't see how we could have both (valid/desirable) translations of "editor" in Portuguese.
Helder
Will there be a warning when critical aliases are being removed?
On Wed, 8 Jul 2015 09:28 Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
Hey folks :)
Right now the property parser function on Wikipedia and other clients only works with the label of the property. People are asking us to make it also work with aliases. In order to do that labels and aliases need to be unique across properties. There are unfortunately a number of properties where the label and aliases are not unique. Those need to be fixed before we can enable the feature. Bene has created a page that lists all properties that need to have their aliases changed: https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a look at this and fix some that'd be much appreciated.
Cheers Lydia
-- Lydia Pintscher - http://about.me/lydia.pintscher Product Manager for Wikidata
Wikimedia Deutschland e.V. Tempelhofer Ufer 23-24 10963 Berlin www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 8 July 2015 at 04:15, jayvdb@gmail.com wrote:
Will there be a warning when critical aliases are being removed?
There should be no need for this; we discussed previously* that we can add parenthetical disambiguators, as we do for Wikipedia article titles.
* I don't recall where; can someone remind me/ provide a link, please?
On 8 July 2015 at 09:05, Andy Mabbett andy@pigsonthewing.org.uk wrote:
we can add parenthetical disambiguators
It also seems that some of these properties should be merged.
Go Andy!
On Wed, Jul 8, 2015 at 10:11 AM, Andy Mabbett andy@pigsonthewing.org.uk wrote:
On 8 July 2015 at 09:05, Andy Mabbett andy@pigsonthewing.org.uk wrote:
we can add parenthetical disambiguators
It also seems that some of these properties should be merged.
-- Andy Mabbett @pigsonthewing http://pigsonthewing.org.uk
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 8 July 2015 at 00:27, Lydia Pintscher lydia.pintscher@wikimedia.de wrote:
Those need to be fixed before we can enable the feature.
There is a bug.
I have tried to make some changes to "en" aliases, but cannot save them, because there is a duplicate alias in some other language, which I cannot read.
If the speakers of those languages cannot edit in English, we may never resolve this!
I believed that #property with labels was never to be relied on. It seems that the effort to solve conflicts with aliases is not worth it.
Il 08/07/2015 01:27, Lydia Pintscher ha scritto:
Hey folks :)
Right now the property parser function on Wikipedia and other clients only works with the label of the property. People are asking us to make it also work with aliases. In order to do that labels and aliases need to be unique across properties. There are unfortunately a number of properties where the label and aliases are not unique. Those need to be fixed before we can enable the feature. Bene has created a page that lists all properties that need to have their aliases changed: https://tools.wmflabs.org/bene/alias-uniqueness/ If you could have a look at this and fix some that'd be much appreciated.
Cheers Lydia