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