Re: [Wikidata-l] [Wikimedia-l] Google rankings and mobile phone support`

[Gerard Meijssen]

Hoi Pine,
Thanks for the link to the test tool.  I find that the one project
dearest to my heart is doing poorly . It seems that our projects
themselves are fairing much better than what the news led me to believe..

The point of it all is that mobile phones need to be well supported. It is
good that we are working strongly on improving our mobile presence and the
software and the group of readers they represent are becoming main-stream
as time progresses.
Thanks,
  GerardM

On 27 April 2015 at 08:41, Pine W  wrote:

> Hi Gerard,
>
> Yes, I saw this news as well.
>
> Check out these results:
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikipedia.org
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=en.wikipedia.org
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=commons.wikimedia.org
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimediafoundation.org
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=www.wikimedia.org
>
>
> https://www.google.com/webmasters/tools/mobile-friendly/?url=blog.wikimedia.org
>
> It looks like most but not all Wikimedia sites pass Google's test.
>
> Personally I hope we invest heavily in Mobile Web in the next annual plan.
> I would like to see growth in mobile readership and growth in mobile
> contributions, and year-over-year growth in combined desktop and mobile
> readership and contributions.
>
> Thanks,
>
> Pine
>
> *This is an Encyclopedia* 
>
>
>
>
>
>
> *One gateway to the wide garden of knowledge, where lies The deep rock of
> our past, in which we must delve The well of our future,The clear water we
> must leave untainted for those who come after us,The fertile earth, in
> which truth may grow in bright places, tended by many hands,And the broad
> fall of sunshine, warming our first steps toward knowing how much we do not
> know.*
>
> *—Catherine Munro*
>
> On Sun, Apr 26, 2015 at 11:24 PM, Gerard Meijssen <
> gerard.meijs...@gmail.com
> > wrote:
>
> > Hoi,
> >
> > It is all over the news. Google will push mobile phone support by
> changing
> > its ranking algorithm. A website that does not support mobiles well will
> > suffer the consequences. Several sources like /. indicate that Wikipedia
> > has a problem.
> >
> > I am anxious to learn what we are going to do.
> >
> > From my perspective this is not a time of endless deliberations; we have
> > done that, we have been there. Mobile is where we grow. It seems to me a
> no
> > brainer that we will move lock stock and barrel to a more mobile friendly
> > environment.
> >
> > Thanks.
> >  GerardM
> >
> >
> >
> http://ultimategerardm.blogspot.nl/2015/04/google-thank-you-for-pushing-mobile.html
> > ___
> > Wikimedia-l mailing list, guidelines at:
> > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> > wikimedi...@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> > 
> ___
> Wikimedia-l mailing list, guidelines at:
> https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines
> wikimedi...@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
> 
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Gerard Meijssen]

Hoi,
There are different transliterations per language pair.

When you include Wikidata in the mix; Wikidata should in my opinion support
the transliteration from Russian to English according to ISO for its label.
Anything else including whatever Wikipedia likes may be an alias.

Your point about confusion is the same as with standard metrics. Napoleon
did us a service by moving to the metric system, It is sad that he did not
conquer Britain so that we are now stuck with something that confuses the
hell out of me when we have to deal with whatever you lot have..
Thanks,
 GerardM


On 27 April 2015 at 07:09, Stas Malyshev  wrote:

> Hi!
>
> > My point is that it is not a given that we should follow any WIkipedia
> > for anything. Also the point of romanisation of Russian is not for the
> > benefit of Russian speakers, it is for the speakers of English.
>
> Same people may speak more than one language. And for English speakers,
> letters like š or č are not the most familiar either. Moreover, mismatch
> between Wikipedia and Wikidata would only confuse people - is Shchedrin
> and Ščedrin the same last name or different one? How does one look up
> for it? I think departing from commonly used way would just add
> confusion and not really help people, neither experienced nor new.
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Stas Malyshev]

Hi!

>  ISO is a reliable source; it is THE standard  Wikipedia is
> definitely not a standard by its own admission.

No, it's *a* standard (or, rather, two of them). There are 11 of them
overall listed just on Wiki, and there might be more too. And of those,
ISO not the most commonly used and looks alien to both Russian and
English speakers, why insist on it?
-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Stas Malyshev]

Hi!

> My point is that it is not a given that we should follow any WIkipedia
> for anything. Also the point of romanisation of Russian is not for the
> benefit of Russian speakers, it is for the speakers of English.

Same people may speak more than one language. And for English speakers,
letters like š or č are not the most familiar either. Moreover, mismatch
between Wikipedia and Wikidata would only confuse people - is Shchedrin
and Ščedrin the same last name or different one? How does one look up
for it? I think departing from commonly used way would just add
confusion and not really help people, neither experienced nor new.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Gerard Meijssen]

Hoi,
A fine position statement ... but what is your argument ? WHY
Thanks,
 GerardM

On 26 April 2015 at 23:15, Joe Filceolaire  wrote:

> When we use auto transliteration to generate English labels then I think
> we should follow the practice of the English Wikipedia with other
> transliterations demoted to aliases.
>
> Similarly auto generated German labels should follow the transliteration
> practices in the German wikipedia.
>
> When we use an auto transliteration bot to generate qualifier statements
> with transliteration of values in "birth name" statements (and other name
> statements ) then we just need a separate property for each transliteration
> scheme and make sure the bot uses the appropriate property for each
> qualifier statement. We can have lots of transliteration qualifier
> statements for each value  (plus statements for IPA and for a pronunciation
> recording ).
>
> Joe
> On 26 Apr 2015 21:40, "Gerard Meijssen"  wrote:
>
>> Hoi,
>>  ISO is a reliable source; it is THE standard  Wikipedia is
>> definitely not a standard by its own admission.
>> Thanks,
>> GerardM
>>
>> On 26 April 2015 at 22:37, Yaroslav M. Blanter  wrote:
>>
>>> On 2015-04-26 22:33, Gerard Meijssen wrote:
>>>
 Hoi
 My point is that it is not a given that we should follow any WIkipedia
 for anything. Also the point of romanisation of Russian is not for the
 benefit of Russian speakers, it is for the speakers of English.
 Thanks,
   GerardM


>>> On one hand, yes.
>>>
>>> On the other hand, no reliable source uses ISO. When NYT writes about a
>>> Russian person, they do not use ISO, they use what the English Wikipedia
>>> uses or smth similar. In my passport, they do not use ISO (fortunately),
>>> why should then ISO be used on Wikidata in an entry about me?
>>>
>>>
>>> Cheers
>>> Yaroslav
>>>
>>> ___
>>> Wikidata-l mailing list
>>> Wikidata-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>>
>>
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Joe Filceolaire]

When we use auto transliteration to generate English labels then I think we
should follow the practice of the English Wikipedia with other
transliterations demoted to aliases.

Similarly auto generated German labels should follow the transliteration
practices in the German wikipedia.

When we use an auto transliteration bot to generate qualifier statements
with transliteration of values in "birth name" statements (and other name
statements ) then we just need a separate property for each transliteration
scheme and make sure the bot uses the appropriate property for each
qualifier statement. We can have lots of transliteration qualifier
statements for each value  (plus statements for IPA and for a pronunciation
recording ).

Joe
On 26 Apr 2015 21:40, "Gerard Meijssen"  wrote:

> Hoi,
>  ISO is a reliable source; it is THE standard  Wikipedia is
> definitely not a standard by its own admission.
> Thanks,
> GerardM
>
> On 26 April 2015 at 22:37, Yaroslav M. Blanter  wrote:
>
>> On 2015-04-26 22:33, Gerard Meijssen wrote:
>>
>>> Hoi
>>> My point is that it is not a given that we should follow any WIkipedia
>>> for anything. Also the point of romanisation of Russian is not for the
>>> benefit of Russian speakers, it is for the speakers of English.
>>> Thanks,
>>>   GerardM
>>>
>>>
>> On one hand, yes.
>>
>> On the other hand, no reliable source uses ISO. When NYT writes about a
>> Russian person, they do not use ISO, they use what the English Wikipedia
>> uses or smth similar. In my passport, they do not use ISO (fortunately),
>> why should then ISO be used on Wikidata in an entry about me?
>>
>>
>> Cheers
>> Yaroslav
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Gerard Meijssen]

Hoi,
As you know I am not a fan at all about these special values. I can follow
logic but do not need to agree.

When "novalue" is not to be seen as a value. What is the point.. The point
is to state there is no value right ? .. and that makes it of value. Right
ahum, I admit it is confusing but is that not the point.  ?

It is similar to a lot of referenced statements that when you check them
are NOT what is stated at all.
Thanks,
GerardM

On 26 April 2015 at 22:37, Markus Krötzsch 
wrote:

> On 26.04.2015 22:28, Gerard Meijssen wrote:
>
>> Hoi,
>> It is a matter of perspective. From my perspective a value exists or
>> not. Depending on that I may want to process. When you state novalue
>> there is a value of novalue and that is not the same as there not being
>> a value in the first place.
>>
>
> Ah, I see. I think any query interface should allow you to find both:
> things with a novalue-claim and things with no claim at all. You can then
> pick your perspective on these two things as you like.
>
> However, it would be an error to treat "novalue" as a kind of "some
> value", and it would be an even bigger error to treat "novalue" as a
> specific value (that can be equal to other such values). For example, a WDQ
> tree query should never go through "novalue" (and not even through a
> "somevalue" a.k.a. "unknownvalue"), as I am sure you will agree.
>
> Cheers,
>
>
> Markus
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Gerard Meijssen]

Hoi,
 ISO is a reliable source; it is THE standard  Wikipedia is
definitely not a standard by its own admission.
Thanks,
GerardM

On 26 April 2015 at 22:37, Yaroslav M. Blanter  wrote:

> On 2015-04-26 22:33, Gerard Meijssen wrote:
>
>> Hoi
>> My point is that it is not a given that we should follow any WIkipedia
>> for anything. Also the point of romanisation of Russian is not for the
>> benefit of Russian speakers, it is for the speakers of English.
>> Thanks,
>>   GerardM
>>
>>
> On one hand, yes.
>
> On the other hand, no reliable source uses ISO. When NYT writes about a
> Russian person, they do not use ISO, they use what the English Wikipedia
> uses or smth similar. In my passport, they do not use ISO (fortunately),
> why should then ISO be used on Wikidata in an entry about me?
>
>
> Cheers
> Yaroslav
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Markus Krötzsch]

On 26.04.2015 22:28, Gerard Meijssen wrote:

Hoi,
It is a matter of perspective. From my perspective a value exists or
not. Depending on that I may want to process. When you state novalue
there is a value of novalue and that is not the same as there not being
a value in the first place.


Ah, I see. I think any query interface should allow you to find both: 
things with a novalue-claim and things with no claim at all. You can 
then pick your perspective on these two things as you like.


However, it would be an error to treat "novalue" as a kind of "some 
value", and it would be an even bigger error to treat "novalue" as a 
specific value (that can be equal to other such values). For example, a 
WDQ tree query should never go through "novalue" (and not even through a 
"somevalue" a.k.a. "unknownvalue"), as I am sure you will agree.


Cheers,

Markus


___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Yaroslav M. Blanter]

On 2015-04-26 22:33, Gerard Meijssen wrote:

Hoi
My point is that it is not a given that we should follow any WIkipedia
for anything. Also the point of romanisation of Russian is not for the
benefit of Russian speakers, it is for the speakers of English.
Thanks,
  GerardM



On one hand, yes.

On the other hand, no reliable source uses ISO. When NYT writes about a 
Russian person, they do not use ISO, they use what the English Wikipedia 
uses or smth similar. In my passport, they do not use ISO (fortunately), 
why should then ISO be used on Wikidata in an entry about me?


Cheers
Yaroslav

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Gerard Meijssen]

Hoi
My point is that it is not a given that we should follow any WIkipedia for
anything. Also the point of romanisation of Russian is not for the benefit
of Russian speakers, it is for the speakers of English.
Thanks,
  GerardM

On 26 April 2015 at 22:30, Yaroslav M. Blanter  wrote:

> On 2015-04-26 22:26, Gerard Meijssen wrote:
>
>> Hoi,
>> Let us be clear that what whatever Wikipedia does is for that
>> Wikipedia to decide. It does not follow automatically that it must be
>> the label for that language..
>> Thanks,
>>  GerardM
>>
>>
> This is fine with me, but using ISO is really really weird for any Russian
> speaker. And I would like to see any reason why a romanization chosen for
> English labels on Wikidata should be deliberately different from English
> Wikipedia.
>
>
> Cheers
> Yaroslav
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Yaroslav M. Blanter]

On 2015-04-26 22:26, Gerard Meijssen wrote:

Hoi,
Let us be clear that what whatever Wikipedia does is for that
Wikipedia to decide. It does not follow automatically that it must be
the label for that language..
Thanks,
 GerardM



This is fine with me, but using ISO is really really weird for any 
Russian speaker. And I would like to see any reason why a romanization 
chosen for English labels on Wikidata should be deliberately different 
from English Wikipedia.


Cheers
Yaroslav

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Gerard Meijssen]

Hoi,
It is a matter of perspective. From my perspective a value exists or not.
Depending on that I may want to process. When you state novalue there is a
value of novalue and that is not the same as there not being a value in the
first place.
Thanks,
GerardM

On 26 April 2015 at 22:25, Markus Krötzsch 
wrote:

> On 26.04.2015 22:16, Gerard Meijssen wrote:
>
>> Hoi,
>> I regularly query for for instance claim[31] ie any instance of
>> whatever... I would also query for the existence of a date of death in a
>> similar way. for me a claim with a "whatever it is that says that there
>> is no value" would be a positive result and I would not consider it for
>> any processing.
>>
>
> Not sure what you are trying to say here. Do you think there is a problem
> in how Wikidata Query is treating novalue? I am sure this can be fixed if
> it is the case. But I am not the right person to answer this.
>
> Markus
>
>
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] Auto-transliteration of names of humans

[Gerard Meijssen]

Hoi,
Let us be clear that what whatever Wikipedia does is for that Wikipedia to
decide. It does not follow automatically that it must be the label for that
language..
Thanks,
 GerardM

On 26 April 2015 at 14:22, Yaroslav M. Blanter  wrote:

> On 2015-04-23 01:21, Stas Malyshev wrote:
>
>> Hi!
>>
>>  Careful, this is one of the most debated and dramatic style issues after
>>> citation format!
>>> Actual transliteration should clearly follow scientific/ISO standards
>>> https://en.wikipedia.org/wiki/Scientific_transliteration_of_Cyrillic .
>>>
>>
>> Well, "scientific/ISO standards" is in this case at least three
>> different standards, and 11 standards if you include commonly used ones
>> :) E.g. see: https://en.wikipedia.org/wiki/Romanization_of_Russian
>>
>>  However the labels and aliases are in languages like "it" and "fr", so
>>> they're supposedly translations rather than mere transliterations. This
>>> makes things more complex.
>>>
>>
>> Yes. I see that the bot is setting language labels for entities, so for
>> this both language-specific transliterations and common usage can be
>> important. Which for Russian for example can be quite crazy,
>> https://www.wikidata.org/wiki/Q187349's last name is "Ватсон" but
>> https://www.wikidata.org/wiki/Q1187613's is "Уотсон". And I have no idea
>> what is the correct romanization of
>> https://www.wikidata.org/wiki/Q4105300's name.
>>
>
> This is what we commonly use at the English Wikipedia for romanization of
> Russian:
>
> https://en.wikipedia.org/wiki/Wikipedia:Romanization_of_Russian
>
> It was already noted that the Russian Wikipedia uses the reverse order for
> names (Dostoyevsky, Fyodor Mikhaylovich), whereas there is no reason to use
> this order on Wikidata. The reasonable options should be either "Fyodor
> Dostoyevsky" or (less preferable to me) "Fyodor Mikhaylovich Dostoyevsky".
>
> Cheers
> Yaroslav
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Markus Krötzsch]

On 26.04.2015 22:16, Gerard Meijssen wrote:

Hoi,
I regularly query for for instance claim[31] ie any instance of
whatever... I would also query for the existence of a date of death in a
similar way. for me a claim with a "whatever it is that says that there
is no value" would be a positive result and I would not consider it for
any processing.


Not sure what you are trying to say here. Do you think there is a 
problem in how Wikidata Query is treating novalue? I am sure this can be 
fixed if it is the case. But I am not the right person to answer this.


Markus



___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Gerard Meijssen]

Hoi,
I regularly query for for instance claim[31] ie any instance of whatever...
I would also query for the existence of a date of death in a similar way.
for me a claim with a "whatever it is that says that there is no value"
would be a positive result and I would not consider it for any processing.

It is fine that RDF does whatever, it is not what we use on a day to day
basis with Wikidata. Consequently what RDF does has no practical
implication for me.
Thanks,
   GerardM

On 26 April 2015 at 19:54, Markus Krötzsch 
wrote:

> Quick reply to Denny and Gerard:
>
> @Denny: I think it makes sense to treat qualifiers under a closed-world
> semantics. That is: what is not there can safely be assumed to be false. In
> this I agree with Gerard. OTOH, I don't think it hurts very much to add
> them anyway.
>
> @Gerard: Please note that the use of novalue in qualifiers does not have
> any negative effects on tools that rely on the value not being there. We do
> not encode "novalue" as a special value, so tools that search for some
> arbitrary value will never find novalues (on any level: statement,
> qualifier, reference). So, overall, it is not such a big deal if people add
> novalue qualifiers in some places. Only tool developers who create own
> query services (not based on our RDF exports) must be aware that it would
> not be a good idea to treat "novalue" like a value internally. But that's a
> very small and rather competent group :-)
>
>
> Anyway, even if we generally agree that "not stated" means "not true" on
> the level of qualifiers, there could be cases where the explicit "novalue"
> could be valuable as documentation for other human users.
>
> Regards,
>
> Markus
>
> On 26.04.2015 00:52, Denny Vrandečić wrote:
>
>> Actually I think that having "no value" for the end date qualifier
>> probably means that it has not ended yet. There is no other way to
>> express whether this information is currently merely incomplete (i.e. it
>> has ended, but no one bothered to fill it in) or not (i.e. it has not
>> ended yet). This is pretty much the same use case as for normal claims.
>>
>> Other qualifiers I could imagine where an explicit "no value" would make
>> sense is P678, I guess.
>>
>> In references it might make sense to state explicitly that the source
>> does not have an issue number or an ISSN, etc., in order for example to
>> allow cleanup of references and to mark the cases where a reference does
>> not have a given value from those cases where it is merely incomplete.
>>
>> I don't have superstrong arguments as you see (I would have much
>> stronger arguments for "unknown value"), but I would prefer not to
>> forbid "no value" in those cases explicitly, because it might be useful
>> and it is already there.
>>
>> [1] https://www.wikidata.org/wiki/Special:WhatLinksHere/Q18615010
>>
>> On Thu, Apr 23, 2015 at 1:27 PM, Stas Malyshev > > wrote:
>>
>> Hi!
>>
>> I was lately looking into the use of novalue in wikidata, specifically
>> in qualifiers and references. While use of novalue in property values
>> is
>> pretty clear for me, not sure it is as useful in qualifiers and refs.
>>
>> Example:
>>
>> https://www.wikidata.org/wiki/Q62#P6
>>
>> As we can see, Edwin Mah Lee is the mayor of San Francisco, with end
>> date set to "novalue". I wonder how useful is this - most entries like
>> this just omit end date, and if we query this in SPARQL, for example,
>> we
>> would do something like "FILTER NOT EXISTS (?statement q:P582
>> ?enddate)". Inconsistently having novalues there makes it harder to
>> process both visually (instead of just looking for one having no end
>> date we need to look for either no end date or end date with specific
>> "novalue") and automatically. And in overwhelming majority of cases I
>> feel "novalue" and absence of value model exactly the same fact - it
>> is
>> a current event, etc. Is there any useful case for using novalue
>> there?
>>
>> Another example: https://www.wikidata.org/wiki/Q2866#P569
>>
>> Here we have reference with "stated in":"no value". I don't think I
>> understand what it means - not stated anywhere? How would we know to
>> make such claim? Is a lie? Why would we keep confirmed lies in the
>> data?
>> Does not have confirmed source that we know of? Many things do, why
>> would we have "stated in" in this particular case?
>> Summarily, it is unclear for me that novalue in references is ever
>> useful.
>>
>> To quantify this, we do not have a lot of such things: on the partial
>> dump I'm working with for WDQS (which contains at least half of the
>> DB)
>> there are 14 novalue refs and 13 properties using novalue as
>> qualifier,
>> leader being P582 with 200+ uses, and overall 422 uses. So volume-wise
>> it's not a big deal but I'd like to figure out what's the right thing
>> to
>> do here and establish some 

Re: [Wikidata-l] novalue in qualifiers or references

[Markus Krötzsch]

Quick reply to Denny and Gerard:

@Denny: I think it makes sense to treat qualifiers under a closed-world 
semantics. That is: what is not there can safely be assumed to be false. 
In this I agree with Gerard. OTOH, I don't think it hurts very much to 
add them anyway.


@Gerard: Please note that the use of novalue in qualifiers does not have 
any negative effects on tools that rely on the value not being there. We 
do not encode "novalue" as a special value, so tools that search for 
some arbitrary value will never find novalues (on any level: statement, 
qualifier, reference). So, overall, it is not such a big deal if people 
add novalue qualifiers in some places. Only tool developers who create 
own query services (not based on our RDF exports) must be aware that it 
would not be a good idea to treat "novalue" like a value internally. But 
that's a very small and rather competent group :-)



Anyway, even if we generally agree that "not stated" means "not true" on 
the level of qualifiers, there could be cases where the explicit 
"novalue" could be valuable as documentation for other human users.


Regards,

Markus

On 26.04.2015 00:52, Denny Vrandečić wrote:

Actually I think that having "no value" for the end date qualifier
probably means that it has not ended yet. There is no other way to
express whether this information is currently merely incomplete (i.e. it
has ended, but no one bothered to fill it in) or not (i.e. it has not
ended yet). This is pretty much the same use case as for normal claims.

Other qualifiers I could imagine where an explicit "no value" would make
sense is P678, I guess.

In references it might make sense to state explicitly that the source
does not have an issue number or an ISSN, etc., in order for example to
allow cleanup of references and to mark the cases where a reference does
not have a given value from those cases where it is merely incomplete.

I don't have superstrong arguments as you see (I would have much
stronger arguments for "unknown value"), but I would prefer not to
forbid "no value" in those cases explicitly, because it might be useful
and it is already there.

[1] https://www.wikidata.org/wiki/Special:WhatLinksHere/Q18615010

On Thu, Apr 23, 2015 at 1:27 PM, Stas Malyshev mailto:smalys...@wikimedia.org>> wrote:

Hi!

I was lately looking into the use of novalue in wikidata, specifically
in qualifiers and references. While use of novalue in property values is
pretty clear for me, not sure it is as useful in qualifiers and refs.

Example:

https://www.wikidata.org/wiki/Q62#P6

As we can see, Edwin Mah Lee is the mayor of San Francisco, with end
date set to "novalue". I wonder how useful is this - most entries like
this just omit end date, and if we query this in SPARQL, for example, we
would do something like "FILTER NOT EXISTS (?statement q:P582
?enddate)". Inconsistently having novalues there makes it harder to
process both visually (instead of just looking for one having no end
date we need to look for either no end date or end date with specific
"novalue") and automatically. And in overwhelming majority of cases I
feel "novalue" and absence of value model exactly the same fact - it is
a current event, etc. Is there any useful case for using novalue there?

Another example: https://www.wikidata.org/wiki/Q2866#P569

Here we have reference with "stated in":"no value". I don't think I
understand what it means - not stated anywhere? How would we know to
make such claim? Is a lie? Why would we keep confirmed lies in the data?
Does not have confirmed source that we know of? Many things do, why
would we have "stated in" in this particular case?
Summarily, it is unclear for me that novalue in references is ever
useful.

To quantify this, we do not have a lot of such things: on the partial
dump I'm working with for WDQS (which contains at least half of the DB)
there are 14 novalue refs and 13 properties using novalue as qualifier,
leader being P582 with 200+ uses, and overall 422 uses. So volume-wise
it's not a big deal but I'd like to figure out what's the right thing to
do here and establish some guidelines.

Thanks,
--
Stas Malyshev
smalys...@wikimedia.org 

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org 
https://lists.wikimedia.org/mailman/listinfo/wikidata-l




___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l




___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

[Wikidata-l] weekly summary #155

[Lydia Pintscher]

Hey folks :)

Here's your summary of what's been happening around Wikidata over the past
week. Enjoy!

Discussions

   - RfC: Opting out of Global sysops 2
   


Events /Press/Blogs


   - Wikidata emerges as central element of GLAM-WIKI 2015
   

   - ongoing: Coding DaVinci 

Other Noteworthy Stuff

   - The question that started Wikidata has finally been answered!
   
   Thank you Markus! ;-)
   - Wikimedia Sverige adapted two brochures about Wikidata, one for GLAMs
   
   and one for researchers
   .
   - Bene* has been working on making Wikidata work nicely on mobile. You
   can check the current status on a demo system
   

   .
   - Amir could use your help with automatic transliteration of human names
   
   - Commons-WD : a tool to
   edit Wikidata based on a Commons category
   - Various improvements to the Primary Sources Tool
    including:
  - Edits made with it will now say so in the edit summary
  - It now uses the URL blacklist
  

  to not suggest low-quality references
  - Caching issues were fixed

Did you know?

   - Newest properties: Kiev street code
   , blood type
   , Perry Index
   , input set
   , SSR Name ID
   , SSR WrittenForm ID
   , INPN Code
   , Nasjonalbiblioteket
   photographer ID , distribution
   map , anti-virus alias
   , HathiTrust id
   , common name
   , Global Anabaptist
   Mennonite Encyclopedia Online identifier
   , Swedish district code
   , investigated by
   , US Federal Election
   Commission identifier
, PSS-archi
   ID , Gaoloumi ID
   , draft pick number
   , GrassBase ID
   , electorate
   , owner of
   , Roud Folk Song Index
   , IPI Code
   , ISWC
   
   - There are a number of user boxes
    you can add to your
   user page to indicate interests and which wiki projects you belong to.

Development

   - On Tuesday, we are deploying usage tracking (no arbitrary access yet)
   to Dutch Wikipedia and French Wikisource, and subscription tracking on
   Wikidata. There should be no noticeable changes for users. These are
   necessary steps towards enabling arbitrary access in clients.
   - Worked on making language fallback work in the suggester (when adding
   a new statement or searching for an item)
   - More work on RDF output and the query service
   - Added Special:RedirectEntity for redirecting items
   - Investigated and working to fix JS bug on items with “invalid” values (
   phabricator:92975 )
   - Did work towards having entity ids in revision histories and in diffs
   linked with their label (like on watchlists or in the recentchanges)

You can see all open bugs related to Wikidata here
.
Monthly Tasks

   - Hack on one of these
   .
   - Help fix these items
   

Re: [Wikidata-l] Auto-transliteration of names of humans

[Yaroslav M. Blanter]

On 2015-04-23 01:21, Stas Malyshev wrote:

Hi!

Careful, this is one of the most debated and dramatic style issues 
after

citation format!
Actual transliteration should clearly follow scientific/ISO standards
https://en.wikipedia.org/wiki/Scientific_transliteration_of_Cyrillic .


Well, "scientific/ISO standards" is in this case at least three
different standards, and 11 standards if you include commonly used ones
:) E.g. see: https://en.wikipedia.org/wiki/Romanization_of_Russian


However the labels and aliases are in languages like "it" and "fr", so
they're supposedly translations rather than mere transliterations. 
This

makes things more complex.


Yes. I see that the bot is setting language labels for entities, so for
this both language-specific transliterations and common usage can be
important. Which for Russian for example can be quite crazy,
https://www.wikidata.org/wiki/Q187349's last name is "Ватсон" but
https://www.wikidata.org/wiki/Q1187613's is "Уотсон". And I have no 
idea

what is the correct romanization of
https://www.wikidata.org/wiki/Q4105300's name.


This is what we commonly use at the English Wikipedia for romanization 
of Russian:


https://en.wikipedia.org/wiki/Wikipedia:Romanization_of_Russian

It was already noted that the Russian Wikipedia uses the reverse order 
for names (Dostoyevsky, Fyodor Mikhaylovich), whereas there is no reason 
to use this order on Wikidata. The reasonable options should be either 
"Fyodor Dostoyevsky" or (less preferable to me) "Fyodor Mikhaylovich 
Dostoyevsky".


Cheers
Yaroslav

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[André Costa]

Could you not add the last active date as a qualifier to the somevalue
death date?

In general uncertainty in dates are not so easily entered. Born 1969 or
1970 cannot be entered as 1969 with uncertainty decade since that becomes
1960s (at least that is what is shown to readers) so the only legit way of
entering it is 20th century (bringing the uncertainty from 2 to 100 years).

In general being able to model dates as between X and Y (as for numbers)
would be nice.

Um.. sorry for the sidetrack from somevalue which sidetracked from the
novalue discussion.

/André

--
André Costa
GLAM-tekniker
Wikimedia Sverige
On 26 Apr 2015 10:23, "Thomas Douillard"  wrote:

> For the unknown date case, I also used some imprecise dates in the past,
> if you set  date withe a precision of the century around the last time it
> wa known active for example, you get something semantically correct and
> that is probably esaier to handle in queries (athough the way to handle
> imprecise or overlapping dates interval in date comparison for the query
> engine is probably not known yet :) I'm curious to know)
>
> 2015-04-26 9:29 GMT+02:00 Stas Malyshev :
>
>> Hi!
>>
>> > It would make sense to have a bot run and add dates of novalue for dob
>> > dod where we know that people must be dead.
>>
>> That would actually be opposite of what we want, since novalue would
>> mean they were not born and are not dead. I think you meant "unknown"
>> for date of death, in which case it does make sense.
>>
>> --
>> Stas Malyshev
>> smalys...@wikimedia.org
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Thomas Douillard]

For the unknown date case, I also used some imprecise dates in the past, if
you set  date withe a precision of the century around the last time it wa
known active for example, you get something semantically correct and that
is probably esaier to handle in queries (athough the way to handle
imprecise or overlapping dates interval in date comparison for the query
engine is probably not known yet :) I'm curious to know)

2015-04-26 9:29 GMT+02:00 Stas Malyshev :

> Hi!
>
> > It would make sense to have a bot run and add dates of novalue for dob
> > dod where we know that people must be dead.
>
> That would actually be opposite of what we want, since novalue would
> mean they were not born and are not dead. I think you meant "unknown"
> for date of death, in which case it does make sense.
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata-l mailing list
> Wikidata-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Stas Malyshev]

Hi!

> It would make sense to have a bot run and add dates of novalue for dob
> dod where we know that people must be dead.

That would actually be opposite of what we want, since novalue would
mean they were not born and are not dead. I think you meant "unknown"
for date of death, in which case it does make sense.

-- 
Stas Malyshev
smalys...@wikimedia.org

___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l

Re: [Wikidata-l] novalue in qualifiers or references

[Gerard Meijssen]

Hoi,
It would make sense to have a bot run and add dates of novalue for dob dod
where we know that people must be dead.
Thanks,
GerardM

On 26 April 2015 at 08:54, Gerard Meijssen 
wrote:

> Hoi,
> There are two ways of doing that.. You can assume given average age and
> date of birth in what century someone died. This is something you can
> specify or you can state that the date of death as unknown. Now that IS a
> valid way of doing this. However it does not mean that 17th centrury people
> did not die. It is therefore relatively useless.
> Thanks,
>   GerardM
>
> On 26 April 2015 at 08:42, Jane Darnell  wrote:
>
>> What about people who were born in the 18th-century? We know they are
>> dead, but their death is not recorded and we only know when they were last
>> active. How do you set that end date?
>>
>> On Sun, Apr 26, 2015 at 8:36 AM, Stas Malyshev 
>> wrote:
>>
>>> Hi!
>>>
>>> > Actually I think that having "no value" for the end date qualifier
>>> > probably means that it has not ended yet. There is no other way to
>>>
>>> But that's what no end date also means, in 99% cases where there's start
>>> date and no end date. Let's see https://www.wikidata.org/wiki/Q30#P35 -
>>> does it say that we have no idea if Barack Obama is still the US
>>> president (same for P6) and nobody bothered to check? I don't think so.
>>> I mean, maybe that was the original idea, but are we going to go and fix
>>> all start/end pairs now and add novalues to them? Are people editing
>>> Wikidata even aware this is what they should be doing - in case it is
>>> what they should be doing?
>>> I think in this case the common usage and the intent of the editor would
>>> be in 99% of cases that start date and no end date means current event
>>> and not "we have no idea if it's still current or not". At least for
>>> something like P582. I admit, for some others the meaning may be
>>> different - i.e., if there's neither P580 nor P582 then the above
>>> reasoning does not apply. But then we by default assume it's current
>>> (unless it has P585) so the outcome is essentially the same.
>>>
>>> > Other qualifiers I could imagine where an explicit "no value" would
>>> make
>>> > sense is P678, I guess.
>>>
>>> OK, here I don't know much about what it means, so I just accept your
>>> point.
>>>
>>> > In references it might make sense to state explicitly that the source
>>> > does not have an issue number or an ISSN, etc., in order for example to
>>> > allow cleanup of references and to mark the cases where a reference
>>> does
>>> > not have a given value from those cases where it is merely incomplete.
>>>
>>> Here though again the same as above - usually when you add something
>>> that is expected to have issue number but it's not there, it's either
>>> somevalue (means, we don't know what the issue is, but it was an issue)
>>> or somehow it's the exception and it has no issue. Only actual usage of
>>> novalue I found in refs so far was confused usage of refs instead of
>>> qualifiers (pretty soon - ~couple of weeks - we'll have full recent dump
>>> loaded in the lab machine and we could answer this with real certainty,
>>> right now it's like 80% certainty :).
>>>
>>> > I don't have superstrong arguments as you see (I would have much
>>> > stronger arguments for "unknown value"), but I would prefer not to
>>> > forbid "no value" in those cases explicitly, because it might be useful
>>> > and it is already there.
>>>
>>> For qualifiers, I can see now there might be cases where it is useful,
>>> still not on references. But I think maybe not forbidding as such but
>>> having the guideline on what is considered the Right Thing and then if
>>> there's an exception than the editors can use their own judgement.
>>>
>>> --
>>> Stas Malyshev
>>> smalys...@wikimedia.org
>>>
>>> ___
>>> Wikidata-l mailing list
>>> Wikidata-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>>
>>
>>
>> ___
>> Wikidata-l mailing list
>> Wikidata-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata-l
>>
>>
>
___
Wikidata-l mailing list
Wikidata-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l