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 <[email protected] > 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 > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikidata > -- Innovimax SARL Consulting, Training & XML Development 9, impasse des Orteaux 75020 Paris Tel : +33 9 52 475787 Fax : +33 1 4356 1746 http://www.innovimax.fr RCS Paris 488.018.631 SARL au capital de 10.000 €
_______________________________________________ Wikidata mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata
