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.html
On 10 July 2015 at 17:35, Gerard Meijssen <[email protected]> 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 <[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
>>
>
>
_______________________________________________
Wikidata mailing list
[email protected]
https://lists.wikimedia.org/mailman/listinfo/wikidata
