On Wed, Jul 8, 2015 at 3:07 AM, Gerard Meijssen <gerard.meijssen(a)gmail.com> wrote: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 08.07.2015 um 09:45 schrieb Gerard Meijssen: monitor for it 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 08.07.2015 um 13:11 schrieb Gerard Meijssen: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

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.

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(a)wikimedia.de> wrote: changing secondary name concrete _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 08.07.2015 um 14:32 schrieb Magnus Manske: non-unique when {{reflist}}? If aliases are not unique, you cannot use them to refer to properties.

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(a)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

they use a non-unique alias? Like using references without the

What you want is closer to a redirect than an alias, while an alias is closer to a disambiguation page.

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 ?

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.

2015-07-08 17:34 GMT+02:00 Daniel Kinzler &lt;daniel.kinzler(a)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.

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.

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 ;)

Il 08/07/2015 22:00, Daniel Kinzler ha scritto: 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. Yes! _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 09.07.2015 um 03:12 schrieb Ricordisamoa: {{#property:syntymäaika}} or 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). accessing right now, aliases of 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 09.07.2015 um 11:04 schrieb Gerard Meijssen: combination new 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 09.07.2015 um 11:21 schrieb Gerard Meijssen: a number and either show the can be 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

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: property is 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. on a 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). to be go away 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. an 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Hoi, The parser would understand it because it stored information. The

still the same property, the label it uses is now seen as a local

Daniel, there are many ways to solve this. The problem you face is based

misconception. Language are not meant for rigidity.

Expectting that you can has already been shown to be problematic. Consequently persisting on labels

always unique is a problem of your own choosing. A problem that will not

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.

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.

Am 09.07.2015 um 14:22 schrieb Thomas Douillard:> Substitution is a

mechanism in MediaWiki and would achive what Gerard > needs ... for example: > "{{subst:property_prime|date of birth}}" could be expanded and

> "{{#property:Pxxx}} <--date of birth-->" and everything would be stored

There is nothing wrong with that. If people on the client wikis think

sufficient, and the {{#property}} parser function does not need to support "named" access to properties, that would be fine with me. So far, I

it would be very annoying to be forced to rely on IDs when using

But if that is fine with everybody, that's fine with me - supporting only

there is much simpler than allowing access via labels or aliases.

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

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" &lt;lydia.pintscher(a)wikimedia.de <mailto:lydia.pintscher@wikimedia.de>> a écrit : On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL &lt;innovimax(a)gmail.com <mailto:innovimax@gmail.com>> wrote: ==> hence the of unicity 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(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata(a)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: property is 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. on a 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). to be go away 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. an 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(a)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 &lt;gerard.meijssen(a)gmail.com&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)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.

Am 11.07.2015 um 09:28 schrieb Gerard Meijssen: in by 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 11.07.2015 um 23:21 schrieb Gerard Meijssen: properties are by 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(a)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(a)gmail.com&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 12.07.2015 um 08:43 schrieb Gerard Meijssen: other. So but store 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 12.07.2015 um 12:52 schrieb Gerard Meijssen: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

:

Am 12.07.2015 um 15:31 schrieb Gerard Meijssen: Indeed. This is why I am asking questions. 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? whatever you the 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. 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. need to be This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything. 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. that not that at This point 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(a)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 &lt;jeblad(a)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 &lt;daniel.kinzler(a)wikimedia.de <mailto:daniel.kinzler@wikimedia.de>>: Am 12.07.2015 um 15:31 schrieb Gerard Meijssen: Indeed. This is why I am asking questions. 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? labels or whatever you internally you use the 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. description 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. and will need to be This is why we want to make aliases unique. If we have unique aliases, labels can change without breaking anything. 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. And sorry that not very much that at not scale. This point 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(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 13.07.2015 um 13:00 schrieb Ricordisamoa: 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.

Am 13.07.2015 um 15:40 schrieb Luca Martinelli: 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(a)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 &lt;daniel.kinzler(a)wikimedia.de&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)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 &lt;markus(a)semantic-mediawiki.org&gt; 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 >> &lt;daniel.kinzler(a)wikimedia.de&gt; 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(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikidata >> >> >> _______________________________________________ >> Wikidata mailing list >> Wikidata(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikidata >> > > > _______________________________________________ > Wikidata mailing list > Wikidata(a)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 &lt;jeblad(a)gmail.com&gt; wrote: _______________________________________________ Wikidata mailing list Wikidata(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

No we should not make the aliases unique, the reason aliases are

No we should not make the aliases unique, the reason aliases are

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.

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.

Am 13.07.2015 um 13:00 schrieb Ricordisamoa: 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Am 13.07.2015 um 17:22 schrieb Gerard Meijssen: 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. 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. names" as witha text Sure, for display, that's fine. For widgets on wikidata, too. We were dicussing readability of wikitext, though. 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(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata

Hiding behind Lydia is not graceful.

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.

On Wed, Jul 8, 2015 at 3:07 AM, Gerard Meijssen &lt;gerard.meijssen(a)gmail.com&gt; wrote: 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?

we can add parenthetical disambiguators