[Wikidata] Re: web reference

[Thomas Douillard]

There might be a misunderstanding here. The "admin" in question are not the
administrators in the wiki / mediawiki sense, those elected by the
contributor’s community, but the admin at the system level.

Those who administrates the website and the machine, the WMF staff, might
perform the procedures that Google proposes to gain access to this Google
console.

Le lun. 31 juil. 2023 à 16:25, Luca Martinelli [Sannita] <
martinellil...@gmail.com> a écrit :

> Il giorno lun 31 lug 2023 alle ore 16:15 Marie-Claude Lemaire
>  ha scritto:
> >  a wikidata admin has access to the webmaster, when can I hope it will
> be done
>
> No. They don't. They don't have access to that kind of function. It
> was wrong information that was given to you.
>
> If you want Google to update your data, follow Platonides' advice and
> use the button "Lancer la demande de suppresion" from
> https://support.google.com/websearch/answer/9673730?hl=fr to request
> Google to delete "Marie-Claude Mallet-Lemaire".
>
> L.
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/2WWCER3XOCA4SRO7SKDAZBCL3BZ37R7W/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/O3SMKCJVJAIC5PPRJXXEDFHU2KPI22Q5/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: web reference

[Thomas Douillard]

It seem to need that the WMF or WMDE follow some protocol with Google to
authenticate them to Google :
https://support.google.com/webmasters/answer/9008080?hl=en#choose_method

Not sure this will be very fast in the middle of the summer if they wish to
do this, if they have not done it yet.


Le dim. 30 juil. 2023 à 21:28, Simon Gelfand  a écrit :

> That is not correct. If a wikidata admin has access to the webmaster tools
> of wikidata.org they can request a re-crawl or remove the url.
>
> https://support.google.com/webmasters/answer/7041154?hl=en
>
> On Sun, 30 Jul 2023 at 22:12 Luca Martinelli [Sannita] <
> martinellil...@gmail.com> wrote:
>
>> Il giorno dom 30 lug 2023 alle ore 21:04 Simon Gelfand
>>  ha scritto:
>> > Actually with webmaster tools it can be done by Wikidata - question is
>> who has access to the webmaster tools of wikidata.org
>>
>> No, Simon, it cannot be done the way you're suggesting. Please, don't
>> share wrong info, we cannot do a single thing about Google indexing,
>> except waiting for it to be updated or suggesting Ms Lemaire to take
>> action herself and require Google to remove those results.
>>
>> L.
>> ___
>> Wikidata mailing list -- wikidata@lists.wikimedia.org
>> Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/JBJMVROAXD6MLLGAICCESLO7GMN2C6DC/
>> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>>
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/HNR5Z2SSXUPA6RYD3TOGGDAWR7VOI5QG/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/DLFLVR53FFRGFG3TFECSEBUMABYFKORX/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: web reference

[Thomas Douillard]

Google is a huge company with automated process. The robot that takes the
information up to date will soon reach your page and update, but as simple
users just as you and not insiders there is not much possibility to reach
them and order them to speed things up. As they index the whole web it can
take some time I guess, there is a massive quantity of data to reach up. I
guess they also prioritize places with a lot of views to visit more
frequently, your Wikidata page is probably not visited or updated very much
compared to much more visited websites, so it’s not up in their automated
pile of work.

Le ven. 28 juil. 2023 à 18:43, Marie-Claude Lemaire  a
écrit :

> I do not know how to ask google to suppress the information Marie-Cladue
> Mallet-Lemaire https://www.wikidata.org/wiki/Q89127676 if you know how to
> do it.
>
> Le 28 juil. 2023 à 18:36, Thomas Douillard  a
> écrit :
>
> Wikidata contributors were probably not aware of those wishes. It’s an
> open project anyone can contribute to, and do their best.
>
> Those data can be used because someone insert some fact in Wikidata with
> one of the articles you wrote as a reference. Wikidata internally use your
> datas on this page to reference you as author of the reference.
>
> Datas about awards are typically used to build statistics about gender
> biais on awards, for example see
> https://dl.acm.org/doi/fullHtml/10.1145/3479986.3479992 for such a study
> using Wikidata data.
>
> Le ven. 28 juil. 2023 à 18:24, Marie-Claude Lemaire 
> a écrit :
>
>> No I do not understand that people publish informations against my wishes
>>
>> > Le 28 juil. 2023 à 17:59, Luca Martinelli [Sannita] <
>> martinellil...@gmail.com> a écrit :
>> >
>> > Il giorno ven 28 lug 2023 alle ore 17:52 Marie-Claude Lemaire
>> >  ha scritto:
>> >>
>> >> I am Marie-Claude Lemaire particle physicist( french) and known in
>> particle physics as Marie-Claude Lemaire
>> https://inspirehep.net/authors/1000606. I do not want that Marie-Claude
>> Mallet-Lemaire appears in google chrome.
>> >> My french identity card is Marie-Claude Lemaire , my CEA card is
>> Marie-Claude Lemaire. I am a woman an definitively want that Marie-Claude
>> Mallet-Lemaire disappears from Google Chrome;
>> >> The best way is to suppress wikidata as it against my wishes to appear
>> in it.
>> >
>> > As people have already explained, the problem on Wikidata has been
>> > fixed. We have no control over Google or the way they show
>> > information.
>> >
>> > You can either wait until Google updates their own information, or ask
>> > Google for a correction of the data.
>> >
>> > Please, understand that we did all that we could have done in this
>> > particular situation, and that all that goes beyond it we cannot do.
>> >
>> > Cheers,
>> >
>> > L.
>> > ___
>> > Wikidata mailing list -- wikidata@lists.wikimedia.org
>> > Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/2QVVPPU5VJT7R76CKKGAGXLOGM452CJR/
>> > To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>> ___
>> Wikidata mailing list -- wikidata@lists.wikimedia.org
>> Public archives at
>> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/P2TVPQYLZ2DYF7ZHOTLPNKBLNWFEDQKM/
>> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>>
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/KJM2ARMGDW5KPWT325GXPVDOIXMH254W/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
>
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/4CLLQWQGNLSZ4OV23B2KE6ZJH73SRYCO/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/JTQDZPXAWWUGNPULGQUJA7UPEKYL444X/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: web reference

[Thomas Douillard]

Wikidata contributors were probably not aware of those wishes. It’s an open
project anyone can contribute to, and do their best.

Those data can be used because someone insert some fact in Wikidata with
one of the articles you wrote as a reference. Wikidata internally use your
datas on this page to reference you as author of the reference.

Datas about awards are typically used to build statistics about gender
biais on awards, for example see
https://dl.acm.org/doi/fullHtml/10.1145/3479986.3479992 for such a study
using Wikidata data.

Le ven. 28 juil. 2023 à 18:24, Marie-Claude Lemaire  a
écrit :

> No I do not understand that people publish informations against my wishes
>
> > Le 28 juil. 2023 à 17:59, Luca Martinelli [Sannita] <
> martinellil...@gmail.com> a écrit :
> >
> > Il giorno ven 28 lug 2023 alle ore 17:52 Marie-Claude Lemaire
> >  ha scritto:
> >>
> >> I am Marie-Claude Lemaire particle physicist( french) and known in
> particle physics as Marie-Claude Lemaire
> https://inspirehep.net/authors/1000606. I do not want that Marie-Claude
> Mallet-Lemaire appears in google chrome.
> >> My french identity card is Marie-Claude Lemaire , my CEA card is
> Marie-Claude Lemaire. I am a woman an definitively want that Marie-Claude
> Mallet-Lemaire disappears from Google Chrome;
> >> The best way is to suppress wikidata as it against my wishes to appear
> in it.
> >
> > As people have already explained, the problem on Wikidata has been
> > fixed. We have no control over Google or the way they show
> > information.
> >
> > You can either wait until Google updates their own information, or ask
> > Google for a correction of the data.
> >
> > Please, understand that we did all that we could have done in this
> > particular situation, and that all that goes beyond it we cannot do.
> >
> > Cheers,
> >
> > L.
> > ___
> > Wikidata mailing list -- wikidata@lists.wikimedia.org
> > Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/2QVVPPU5VJT7R76CKKGAGXLOGM452CJR/
> > To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/P2TVPQYLZ2DYF7ZHOTLPNKBLNWFEDQKM/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/KJM2ARMGDW5KPWT325GXPVDOIXMH254W/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: web reference

[Thomas Douillard]

A little off topic but I’m curious. I assumed that the datas were shown as
the structured data knowledge graph but it appears they are not and the
page is shown as first result by Google. I don’t think I have ever seen a
Wikidata first result from a Google request ! I don’t even recall that a
Wikidata item page result in a regular request. I assume there are few
links to Wikidata page on the web …

Does that happen often ? What links Wikidata page so that they are on the
top results sometimes ?

Le ven. 28 juil. 2023 à 12:44,  a écrit :

> I have checked and it looks like the wikidata item has now been updated to
> reflect the name "Marie-Claude Lemaire".
>
> However, it still appears in Google because Google has not re-indexed the
> page yet. For this you just have to wait, as it's unknown how long it will
> take and Google does not respond to user requests for re-indexing.
> Hopefully it will not take long.
>
> Cheers,
> Marielle
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> Public archives at
> https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/X66CENEWDEN43AZL336HKFXWQCI3SI5H/
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/725TURHI6EPS4HC653EH7LQEAMIP3EJE/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: WEB references

[Thomas Douillard]

There is a reference for the statement, this page :
https://www.sfpnet.fr/8-mars-journee-internationale-des-droits-des-femmes
but indeed this seems to be a "prix de spécialité de la SPF" which does not
seem to be the Joliot-Curie price.
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
Public archives at 
https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/message/XX5TTBDUGE5GJ7TOOKMHV2RCSKXS3VOI/
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: Transitivity ... how far do we go? It depends.

[Thomas Douillard]

Question about this property : can it be applied to a non transitive
property ?

We could have two « friend of » properties, one transitive, « the friend of
my friend is mine », one not.
If I then say, « what belongs to me belong to my friend »
* in the transitive version it belongs also to the friend of my friend
* can it be applied to the non transitive friendship ? This could mean that
it just belongs to the friends with explicit statement I guess.

I agree that « if A is an instance of B » and « B is a subclass of C » then
« A is an instance of C » getting something weird as a result is a powerful
tool to find consistency issues in the ontology.

The « Classification » gadget takes advantage of this, cf.
https://www.wikidata.org/wiki/Special:MyLanguage/Wikidata:Tools/Enhance_user_interface#Classification.js

It shows a few classes in the class hierarchy an items belongs to and this
item is supposed to be an instance of. If « Albert Einstein is a taxon »
seems weird, the user can click to report a bug in the ontology on the
ontology project talk page.

Le dim. 22 mai 2022 à 17:42, Thad Guidry  a écrit :

> Hi Thomas,
>
> Yes, your example is the kind of use case.  And disagreements often come
> up with the  "then C is a part of B".
>
> And I've found that many times the classification problems where "wait a
> second, this is not actually quite true, and the right class in the
> hierarchy I'm thinking of" ... will typically be resolved, and
> consensus more easily agreed by all parties when the class is either:
> A. made more abstract for the benefit of all, but saving that...
> B. make a new class, more broader, and less disagreeable by all parties
>
> It's just a simple data modeling problem oftentimes, but where "transitive
> over" seems to expose them.
> I see it more about getting consensus and the "it depends" seemed
> oftentimes easily solved with a different broader class used or created and
> applied.
>
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/
>
>
> On Sun, May 22, 2022 at 8:25 AM Thomas Douillard <
> thomas.douill...@gmail.com> wrote:
>
>> Sounds not uninteresting, but without the context of the discussion it’s
>> hard to understand what the problem actually is. Could include more details
>> ?
>>
>> I googled a bit and found that a « transitive over » usecase could be
>> If
>> * researcher Livingstone « explores » Egypt
>> * Egypt is a part of Africa
>> then we can conclude that researcher livingstone explores Africa
>>
>> This would mean that the « explore » property would be transitive over «
>> part of ».
>> An example of this could be of course « instance of » who is of course
>> transitive over « subclass of ».
>>
>> Yet « subclass of » is of course a transitive property by itself. If all
>> mammals are animals (so ''mammal subclass of animal')' and all animals are
>> organism ''animal subclass of living organism'', then of course all mammals
>> are living organisms.
>>
>> As for transitivity of « part of » of course if A is a part of B and C is
>> a part of A, then C is a part of B. The thing is that someone that studies,
>> say a lineage of cell of some kind of animal could not necessarily
>> considering to study the animal itself, so « studies » could not be
>> considered to be transitive over « part of ».
>>
>> What exact reasoning problem do you have in mind ?
>>
>> Le sam. 21 mai 2022 à 17:56, Thad Guidry  a écrit :
>>
>>> I wanted to share my reply to a recent Telegraph conversation:
>>>
>>> Thad Guidry, [5/21/2022 10:22 AM]
>>> [In reply to Nikki]
>>> Agree somewhat, however in the case of P31 we already have P6609 that
>>> describes the general SKOS/OWL "transitive over" and we added the
>>> value-type constraint https://www.wikidata.org/wiki/Q21510865 to be
>>> transitive property https://www.wikidata.org/wiki/Q18647515
>>>
>>> But that was not the case with P279 ... where instead we stated that
>>> P279 itself is an instance of transitive property ... which is what
>>> probably confuses folks.
>>>
>>> [[wikilinksbot]], [5/21/2022 10:22 AM]
>>> P31 (https://www.wikidata.org/entity/P31) – instance of
>>> P6609 (https://www.wikidata.org/entity/P6609) – value hierarchy property
>>> P279 (https://www.wikidata.org/entity/P279) – subclass of
>>>
>>> Thad Guidry, [5/21/2022 10:26 AM]
>>> So P279 is a https://www.wikidata.org/wiki/Q18647515 and P31 is not.
>>>
>>> [[wikilinksbot]], [5/21/2022 10:26 AM]
>>> P279 (https://www.wikidata

[Wikidata] Re: Transitivity ... how far do we go? It depends.

[Thomas Douillard]

Sounds not uninteresting, but without the context of the discussion it’s
hard to understand what the problem actually is. Could include more details
?

I googled a bit and found that a « transitive over » usecase could be
If
* researcher Livingstone « explores » Egypt
* Egypt is a part of Africa
then we can conclude that researcher livingstone explores Africa

This would mean that the « explore » property would be transitive over «
part of ».
An example of this could be of course « instance of » who is of course
transitive over « subclass of ».

Yet « subclass of » is of course a transitive property by itself. If all
mammals are animals (so ''mammal subclass of animal')' and all animals are
organism ''animal subclass of living organism'', then of course all mammals
are living organisms.

As for transitivity of « part of » of course if A is a part of B and C is a
part of A, then C is a part of B. The thing is that someone that studies,
say a lineage of cell of some kind of animal could not necessarily
considering to study the animal itself, so « studies » could not be
considered to be transitive over « part of ».

What exact reasoning problem do you have in mind ?

Le sam. 21 mai 2022 à 17:56, Thad Guidry  a écrit :

> I wanted to share my reply to a recent Telegraph conversation:
>
> Thad Guidry, [5/21/2022 10:22 AM]
> [In reply to Nikki]
> Agree somewhat, however in the case of P31 we already have P6609 that
> describes the general SKOS/OWL "transitive over" and we added the
> value-type constraint https://www.wikidata.org/wiki/Q21510865 to be
> transitive property https://www.wikidata.org/wiki/Q18647515
>
> But that was not the case with P279 ... where instead we stated that P279
> itself is an instance of transitive property ... which is what probably
> confuses folks.
>
> [[wikilinksbot]], [5/21/2022 10:22 AM]
> P31 (https://www.wikidata.org/entity/P31) – instance of
> P6609 (https://www.wikidata.org/entity/P6609) – value hierarchy property
> P279 (https://www.wikidata.org/entity/P279) – subclass of
>
> Thad Guidry, [5/21/2022 10:26 AM]
> So P279 is a https://www.wikidata.org/wiki/Q18647515 and P31 is not.
>
> [[wikilinksbot]], [5/21/2022 10:26 AM]
> P279 (https://www.wikidata.org/entity/P279) – subclass of
> P31 (https://www.wikidata.org/entity/P31) – instance of
>
> Thad Guidry, [5/21/2022 10:29 AM]
> Details here:  https://www.w3.org/TR/owl-ref/#TransitiveProperty-def
>
> Thad Guidry, [5/21/2022 10:38 AM]
> So... (lolol)  through transitivity once an item becomes an instance
> of a class... then it automatically inherits all properties of that
> class... but only and strong ONLY WHEN it is considered an instance of a
> class... and not before.
>
> Reasoners, interpreters (external, custom code, institutions, etc.) might
> apply transitivity "slightly" differently for different contexts, and might
> bucket some items prematurely to be considered an instance of a class ...
> but generally, the old adage is that of the above paragraph... only once it
> is considered an instance of.
>
> The problem as often seen in Wikidata is that sometimes higher classes are
> currently not abstract enough sometimes to fulfill broader roles... *and
> hence... a broader higher class oftentimes just needs to be created to make
> things in the hierarchy a bit more sensical.*
>
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: Redirected entities

[Thomas Douillard]

The sparql query :
 select ?redirect ?target {
   ?redirect owl:sameAs ?target .
 }
is very close to timeout but still works with the public wikidata query
service :
https://query.wikidata.org/#select%20%3Fredirect%20%3Ftarget%20%7B%0A%20%20%3Fredirect%20owl%3AsameAs%20%3Ftarget%20.%0A%7D

Le ven. 17 déc. 2021 à 15:53, Kapps Augustin Norbert Justin via Wikidata <
wikidata@lists.wikimedia.org> a écrit :

> Hi Lydia,
>
>
> Thank you for your answer, it is exactly what I was looking for!
>
>
> Do you know if it is possible to download the entire "list of redirects"?
>
> Are there some dumps available?
>
>
> Best,
>
>
> Augustin
> --
> *De :* Lydia Pintscher 
> *Envoyé :* vendredi 17 décembre 2021 15:25:42
> *À :* Discussion list for the Wikidata project
> *Cc :* Kapps Augustin Norbert Justin
> *Objet :* Re: [Wikidata] Redirected entities
>
> Hi Augustin,
>
> Yes, there are redirected entities in Wikidata. This is done when an
> editor merges two Items for the same concept. This is done for example
> when someone accidentally creates a duplicate because they didn't find
> the existing Item for the concept.
> Here are some examples of redirects and their targets:
> https://www.wikidata.org/wiki/Special:ListRedirects
>
>
> Cheers
> Lydia
>
> On Mon, Dec 13, 2021 at 5:21 PM Kapps Augustin Norbert Justin via
> Wikidata  wrote:
> >
> > Dear all,
> >
> > I am currently working on the wiki data knowledge graph to compute the
> article's embeddings.
> >
> > My question is the following: are some entities of the graph redirected?
> And if yes: how can I redirect these nodes, are there some redirection
> tables?
> >
> > Cheers,
> >
> > Augustin
> >
> > ___
> > Wikidata mailing list -- wikidata@lists.wikimedia.org
> > To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
>
>
> --
> 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/029/42207.
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: Help make this Property Query faster

[Thomas Douillard]

Wikidata has a huge number of labels in a high number of languages.
Is it be possible that indexing strategies based on the language of the
string literal a good thing ? It’s an RDF choice to encode the language in
the literal, it might not be the better choice for performance indeed.
But a query planner/rewriter should be able to detect a pattern like «
filter lang() = "en" » to take advantage of such an index ?

Retrieving label is important in general and do this efficiently might be a
something that makes a difference …

Le ven. 5 nov. 2021 à 11:55, David Causse  a écrit :

> Hi Thad,
>
> I looked at this query and I have nothing to add to what was suggested
> already to make it run faster.
> I think the main issue is the size of the intermediate results that have
> to have the language filter applied, sadly almost every time that a FILTER
> is being used on a string literal blazegraph might have to fetch its
> representation from its lexicon which incur a huge slowdown.
> Regarding indices and ordering I believe the right indices are being used
> otherwize the query would certainly time out, I doubt it can filter all
> english labels before joining them to the property labels.
>
> The criterion ?prop wdt:P31/wdt:P279* wd:Q18616576 does indeed seem
> useless to me and is pulling a couple false positives[1] into the join
> (totally harmless regarding query perf but should perhaps be cleaned up
> from wikidata?).
>
> So filtering & fetching the textual data is indeed what makes this query
> slow. I tried various combinations but could not come up with reasonable &
> stable sub-second response times. Fetching the textual data (possibly
> lazily) from another service might help but this certainly is a consequent
> rewrite of the client relying on this query.
>
> Caching is definitely going to help especially if this data is not subject
> to rapid/frequent changes, the WDQS infrastructure has a caching layer but
> retention might not be long enough to be useful for this particular tool.
> The json output seems indeed quite big (almost 5Mb), while not
> enormous it's still consequent and if this data is relatively stable there
> might be value in refreshing it on purpose (daily as you suggest) and
> making it available on a static storage.
>
> Another note about response times, you may see varying response times from
> the query service and the reasons might be one of the following:
> - it's cached on the query service caching layer (generally sub 100ms
> response time)
> - the server the query hits is heavily loaded
> - the server the query hits is an old generation (we have 2 different
> kinds of hardware setup in the cluster at the moment and might explain some
> of the variance you see).
>
> Hope it helps a bit,
>
> Regards,
>
> David.
>
>
> 1: https://w.wiki/4Lae
>
> On Wed, Nov 3, 2021 at 11:39 PM Thad Guidry  wrote:
>
>> Thanks Kingsley, Thomas, Jeff,
>>
>> From what I see the live query never is sub second and that's likely
>> because of 2 things:
>>   1. indexing not prioritizing this kind of query and aligning it (which
>> David Causse might know if that could be changed), essentially its metadata
>> about Wikidata (it's available properties).
>>   2. it's 2.2 MB of data
>>
>> I think that Yi Liu's Wikidata Property Explorer service then might want
>> to instead cache the results for 24 hours for the best of both worlds.
>>
>> To be fair, the raw amount of data requested seems to be approximately
>> 2.2 MB and so probably should be locally cached by his tool for some
>> determined time (like 24 hours).
>>
>> Thad
>> https://www.linkedin.com/in/thadguidry/
>> https://calendly.com/thadguidry/
>>
>> ___
>> Wikidata mailing list -- wikidata@lists.wikimedia.org
>> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>>
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

[Wikidata] Re: Help make this Property Query faster

[Thomas Douillard]

You can drop the « (wdt:P31/(wdt:P279*)) wd:Q18616576; » part, it’s
useless.
« ?prop wikibase:propertyType ?type. » is enough : https://w.wiki/4Kmp
and it’s fast.

What seem to be really expensive is the label part, just adding the label
(alone) at least triples or quadruples the query time, this takes us from
less than a seconds to 3/4 seconds

https://w.wiki/4Kms

https://w.wiki/4Kmv


Le ven. 29 oct. 2021 à 16:12, Thad Guidry  a écrit :

> Hi David and team,
>
> In Yi Liu's tool, Wikidata Property Explorer, I noticed that the query
> performance could be better ideally.  Currently the query takes about 9
> seconds and I'm asking if there might be anything to help reduce that
> considerably?  Refactoring query for optimization, backend changes,
> anything you can think of Davd?
>
> SELECT DISTINCT ?prop ?label ?desc ?type (GROUP_CONCAT(DISTINCT ?alias;
> SEPARATOR = " | ") AS ?aliases) WHERE {
>   ?prop (wdt:P31/(wdt:P279*)) wd:Q18616576;
> wikibase:propertyType ?type.
>   OPTIONAL {
> ?prop rdfs:label ?label.
> FILTER((LANG(?label)) = "en")
>   }
>   OPTIONAL {
> ?prop schema:description ?desc.
> FILTER((LANG(?desc)) = "en")
>   }
>   OPTIONAL {
> ?prop skos:altLabel ?alias.
> FILTER((LANG(?alias)) = "en")
>   }
> }
> GROUP BY ?prop ?label ?desc ?type
>
> Thad
> https://www.linkedin.com/in/thadguidry/
> https://calendly.com/thadguidry/
> ___
> Wikidata mailing list -- wikidata@lists.wikimedia.org
> To unsubscribe send an email to wikidata-le...@lists.wikimedia.org
>
___
Wikidata mailing list -- wikidata@lists.wikimedia.org
To unsubscribe send an email to wikidata-le...@lists.wikimedia.org

Re: [Wikidata] SPARQL examples page not displaying properly latest examples ?

[Thomas Douillard]

It’s probably linked indeed as, as far as I know, the HTML page is parsed,
not the initial wikitext.

Le mar. 8 oct. 2019 à 10:51, Thomas Francart  a
écrit :

> Hello
>
> I recently contributed to an example SPARQL query in the example page (
> https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries/examples#Display_the_class_tree_under_a_known_class_(subclass_of)
> )
>
> It is not displayed properly and it seems that this page is broken as none
> of the latest examples in the page is displayed, starting with this one :
> https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/queries/examples#Human_settlements_without_an_article_in_any_language_version_of_Wikipedia
>
> Hypothesis : I suspect this is due to the high number of the same
> "Template:SPARQL" used in that same page.
>
> Is this a known issue ? any way to fix this ?
>
> Also, I can't find this query example in the query interface, when
> searching for it. How/when is the query interface updated with the example
> page ? is it related to the display problem in the page itself ?
>
> Cheers
> Thomas
>
> --
>
> *Thomas Francart* -* SPARNA*
> Web de *données* | Architecture de l'*information* | Accès aux
> *connaissances*
> blog : blog.sparna.fr, site : sparna.fr, linkedin :
> fr.linkedin.com/in/thomasfrancart
> tel :  +33 (0)6.71.11.25.97, skype : francartthomas
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Nobel Prizes and consensus in Wikidata

[Thomas Douillard]

Hi, I participated into the edits that ended up with this mess, so I plead
guilty /o\.

I’d say the problem is that we don’t really have a model at all. At best,
there is some WikiProject that try to impose some rules they decided, with
the notion of concensus decided by the people of the project. Some
WikiProjects exists for some domains but are inactive and/or inefficient to
impose rules. Apart from that there is constraints, that are decided by the
sums of individual edits, for example, and occasionally discussions on
project chat or other venue like the french «bistro». In my experience RfCs
on the model does not usually reach a conclusion. In this case there is a
WikiProject Award, that sets up some rule : https://www.wikidata.org , but
… I’m not sure how those rules came up and the rationale behind it are not
explained.

Le sam. 28 sept. 2019 à 13:00, Andy Mabbett  a
écrit :

> On Fri, 27 Sep 2019 at 20:34, Aidan Hogan  wrote:
>
>
> > In summary, of the six types of Nobel prizes, three different properties
> > are used in five different combinations
>
> > I am more interested in the general problem of the
> > lack of consensus that such a case exhibits.
>
> Has there been any attempt to resolve this through discussion on-wiki?
> Failure to agree a consensus is a much more serious issue than a "we
> have yet to attempt to reach consensus" scenario.
>
> Have you attempted to make edits to align the items concerned, only to
> find them reverted? An active dispute (edit war) over how to model
> data is a much more serious issue than a "we have yet to attempt to
> reach consensus" scenario.
>
> In either case, links or preferably diffs would help.
>
> > What processes (be they social, technical, or some combination thereof)
> > are currently in place to reach consensus in these cases in Wikidata?
>
> On-wiki discussion, usually on a project page, sometimes on project chat.
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Dead or alive ? Probably dead

[Thomas Douillard]

We have also other properties on Wikidata to refine partial knowledge about
the chronology of a life :
https://www.wikidata.org/wiki/Property:P1317 – floruit
https://www.wikidata.org/wiki/Property:P2032 /
https://www.wikidata.org/wiki/Property:P2031 — floruit begin and end
that may overlap with https://www.wikidata.org/wiki/Property:P1319
https://www.wikidata.org/wiki/Property:P1326

I found myself sometimes using a century precision date for somebody we
don’t really have information about the date of death but know it lived on
some century.


Le ven. 20 sept. 2019 à 00:25, Olaf Simons 
a écrit :

> On FactGrid we created two properties for this (maybe clever, maybe daft):
> P290 and P291 for estimates (or for knowledge) of an earliest and latest
> point in the life span. The necessity is here that we have loads of people
> with just a single data point like "studied in Jena in 1776" or "appeared
> on a list of voters in 1849". If that is all you know, you do actually know
> that the person is likely to have a birth date some 17 (or in the voters
> case at least 21) years before.
>
> If a person is only once mentioned as retired that stretches the P290 date
> to some 60 years before and so on - you qualify the estimate accordingly.
>
> I have no idea whether this is a good move on our site since we are not
> really that advanced in running the more intriguing SPARQL searches.
>
> Olaf
>
>
>
>
> > Fabrizio Carrai  hat am 19. September 2019
> um 22:13 geschrieben:
> >
> >
> > So, the question is if it would be fine and ethic to set the "Date of
> > death" to "unknown" on the base of an old date of birth.
> > And about the biography of living persons, I found this [1]
> >
> > Deceased persons, corporations, or groups of personsRecently dead or
> > probably dead
> > Anyone born within the past 115 years (on or after 19 September 1904) is
> > covered by this policy unless a reliable source has confirmed their
> death.
> > Generally, this policy does not apply to material concerning people who
> are
> > confirmed dead by reliable sources. The only exception would be for
> people
> > who have recently died, in which case the policy can extend for an
> > indeterminate period beyond the date of death—six months, one year, two
> > years at the outside. Such extensions would apply particularly to
> > contentious or questionable material about the dead that has implications
> > for their living relatives and friends, such as in the case of a possible
> > suicide or a particularly gruesome crime. *Even absent confirmation of
> > death, for the purposes of this policy anyone born more than 115 years
> ago
> > is presumed dead* *unless* reliable sources confirm the person to have
> been
> > living within the past two years. If the date of birth is unknown,
> editors
> > should use reasonable judgement to infer—from dates of events noted in
> the
> > article—if it is plausible that the person was born within the last 115
> > years and is therefore covered by this policy.
> >
> > This would support the set of "Date of death" to "unknown" on the base of
> > the "Date of birth". It remains hard to verify typo errors, but we are
> > doing our best to verify the data of the several wikiprojects.
> >
> > The property set would become effective if done in mass by a bot or
> similar.
> >
> > By the way, I would extend be period to 122 years [2]
> >
> > FabC
> >
> > [1]
> >
> https://en.wikipedia.org/wiki/Wikipedia:Biographies_of_living_persons#Deceased_persons,_corporations,_or_groups_of_persons
> > [2] https://en.wikipedia.org/wiki/Oldest_people
> >
> > Il giorno gio 19 set 2019 alle ore 21:29 Andy Mabbett <
> > a...@pigsonthewing.org.uk> ha scritto:
> >
> > > On Sat, 7 Sep 2019 at 07:53, Fabrizio Carrai <
> fabrizio.car...@gmail.com>
> > > wrote:
> > >
> > > > I found athletes with the "Date of born" but with NO "date of death".
> > > > So a query on the age show me athletes up to 149 years old.
> > > > Since the oldest know person was 122, what about to set "date of
> > > > death = unknown value" for all the persons resulting older such age ?
> > >
> > > Yes, but check that the date of birth isn't a typo (i.e. 1875 instead
> > > of 1975; or 1894 instead of 1984).
> > >
> > > Showing a living person as being dead would be a serious breach of the
> > > BLP policy.
> > >
> > > --
> > > Andy Mabbett
> > > @pigsonthewing
> > > http://pigsonthewing.org.uk
> > >
> > > ___
> > > Wikidata mailing list
> > > Wikidata@lists.wikimedia.org
> > > https://lists.wikimedia.org/mailman/listinfo/wikidata
> > >
> >
> >
> > --
> > *Fabrizio*
> > ___
> > Wikidata mailing list
> > Wikidata@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikidata
>
> Dr. Olaf Simons
> Forschungszentrum Gotha der Universität Erfurt
> Schloss Friedenstein, Pagenhaus
> 99867 Gotha
>
> Büro: +49-361-737-1722
> Mobil: +49-179-5196880
>
> Privat: Hauptmarkt 17b/ 

Re: [Wikidata] Lexical datas and automated learning – where it is answered to « I don’t believe in Wikidata senses developpment »

[Thomas Douillard]

A link to the discussions about language barriers for reference :
https://www.wikidata.org/wiki/Wikidata:Language_barriers_input

We could try to add an item « automatic annotation of discussions using
Wikidata datas and learning algorithms, and an interface in discussion to
enrich Wikidata datas thanks to user inputs
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Lexical datas and automated learning – where it is answered to « I don’t believe in Wikidata senses developpment »

[Thomas Douillard]

Indeed machine translation is really hard, but assistance into translation
is a more reachable goal. Focus on the terms before translate whole stuffs,
suggest meaning for terms, for example. Or suggest completion while
translating stuffs. And as there is already datas to feed in in the
Mediawiki ecosystem as translation of stuffs, take Wikidata translated
pages for example. This is not a huge dataset and there is tons of
untranslated things, so it may be something that eventually makes a
difference, translating things make translation easier which could motivate
people.

Le ven. 20 sept. 2019 à 16:42, Nicolas VIGNERON 
a écrit :

> Hi all,
>
> As a reminder, for ideas of tool, there is
> https://www.wikidata.org/wiki/Wikidata:Lexicographical_data/Ideas_of_tools
> (feel free to add your own ideas or to take an idea to make a tool)
>
> Machine translation is a very hard and complex subject, and anyway, it
> needs a large set of data. It's still a good goal for the future but right
> now, we should focus on tool increasing and improving the data.
>
> Cheers, ~nicolas
>
> Le ven. 20 sept. 2019 à 16:34, Thomas Douillard <
> thomas.douill...@gmail.com> a écrit :
>
>>
>> Oh, one obvious usecase that comes to my mind, after reading a
>> discussion like this one
>> <https://www.wikidata.org/w/index.php?title=Wikidata_talk:Lexicographical_data=16175375=1016446701=1015669722=source#Reminder:_your_input_needed_about_integration_of_Lexemes_in_Wiktionaries>
>> this reminds that we are a multilingual community that could hugely benefit
>> from some help in multilingual discussions. So if we can eat our own dog
>> food … it’s for the better. It could indeed help for the funding as if I
>> recall there was a recent community call for need to help cross language
>> barriers. Wikitools to translate pages in a wiki, or cross wikis, could
>> probably benefit from sense annotation and translation suggestions thanks
>> to Wikidata datas …
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Lexical datas and automated learning – where it is answered to « I don’t believe in Wikidata senses developpment »

[Thomas Douillard]

Oh, one obvious usecase that comes to my mind, after reading a discussion
like this one

this reminds that we are a multilingual community that could hugely benefit
from some help in multilingual discussions. So if we can eat our own dog
food … it’s for the better. It could indeed help for the funding as if I
recall there was a recent community call for need to help cross language
barriers. Wikitools to translate pages in a wiki, or cross wikis, could
probably benefit from sense annotation and translation suggestions thanks
to Wikidata datas …
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Lexical datas and automated learning – where it is answered to « I don’t believe in Wikidata senses developpment »

[Thomas Douillard]

This is very interesting and definitely relevant to my interrogation.

Finance aside, it may be worth trying to define more in depth what would be
a workflow, and usecases. For people to validate datas, they have to want
it … Why would they want it ? It’s not enough to just build a random tool
and hope it will be used. I find myself often testing tools proposed in the
Wikidata Weekly, actually it rarely occurs that it become something I use
very often.

We’re on a Wikimedia project, one of the purpose shared by people in it is
to build an encyclopedy … One cool goal would be a tool that for example
analyse the text produced by people and suggests wikilinks. People could
then give feedback by saying to the tool « yes, this is indeed the meaning
of this word in my text » to validate the output, or « yes, this is indeed
a cool wikilink ». Just a thought.

On this example, those techs would be used to analyse the produced text and
make suggestions. It could be made through an open API that receive
(wiki)text, returns annotated wikitext, and recieve feedback from users
through the client UI, eventually writing posiive feedback into Wikidata if
it’s missing.

Such a service would be reusable for all kind of usecases. Another could
be, for example, analysis of commons semi-structured descriptions to
suggests values for depicts claims.

Le ven. 20 sept. 2019 à 14:22, Houcemeddine A. Turki <
turkiabdelwa...@hotmail.fr> a écrit :

> Dear all,
> I thank you for your efforts. To know more about word embedding and
> semantic similarity, please refer to the survey of our research group about
> the issue available at
> https://www.sciencedirect.com/science/article/pii/S0952197619301745. If
> you would like that we work on using these techniques to enrich
> Lexicographical Data on Wikidata, we will be honoured to do this. However,
> we will face two main problems. The first one is absolutely funding and the
> second one is that we need people to validate the information returned by
> these two techniques and adjust it if needed.
> Yours Sincerely,
> Houcemeddine Turki (he/him)
> Medical Student, Faculty of Medicine of Sfax, University of Sfax, Tunisia
> Undergraduate Researcher, UR12SP36
> GLAM, Research and Education Coordinator, Wikimedia TN User Group
> Member, Wiki Project Med
> Member, WikiIndaba Steering Committee
> Member, Wikimedia and Library User Group Steering Committee
> Co-Founder, WikiLingua Maghreb
> ____
> +21629499418
>
>
>  Message d'origine 
> De : Thomas Douillard 
> Date : 2019/09/20 12:08 (GMT+01:00)
> À : "Discussion list for the Wikidata project." <
> wikidata@lists.wikimedia.org>
> Objet : [Wikidata] Lexical datas and automated learning – where it is
> answered to « I don’t believe in Wikidata senses developpment »
>
>
> I recently read the french sentence « Je ne crois pas au développement
> des sens. » — translation : I don’t believes senses with develop much
> (following links in a Wikidata Weekly summary, the slides on a french
> meeting about Wikidata lexicographical datas). I believe in it, (regardless
> of the arguments exposed in the slides), and I write this email to try to
> explain why.
>
> I’m curious to know if there is already some work on the automated
> discovering of lexicographical datas / senses thanks to the help of
> Wikidata items.
>
> There is tools for automated tagging of terms with the corresponding
> Wikidata item, that appeared on this mailing list and/or on the wikidata
> weekly summaries.
> There is also methods that can discover senses into texts using only the
> terms with no reference to any external « sense » like
> https://towardsdatascience.com/word-embedding-with-word2vec-and-fasttext-a209c1d3e12c
> and can discriminate several usages of the same word according to the
> context.
>
> Wikidata lexicographical datas and Wikibase items could close the loop
> between the 2 methods and allow us to semi automatically build tools that
> annotate texts with Wikidata items it there is something relevant in
> Wikidata, but if there is nono try to suggest to add datas on Wikidata,
> wether it’s a missing item or a missing sense for the term.
>
> It may even be possible to store word embeddings generated by word2vec
> methods into Wikidata senses.
>
> In conclusion, I think Wikidata senses will be used because they allow to
> close a gap. It does not depends only on a strong involvement in a
> volunteer traditional lexicographic community. If reasearchers of the
> language community dives into this and develop algorithms and easy to use
> tools to share there lexicographical datas in Wikidata, there could be a
> very positive feedback loop where numerous data ends to be added on
> Wikidata, where the store datas hel

[Wikidata] Lexical datas and automated learning – where it is answered to « I don’t believe in Wikidata senses developpment »

[Thomas Douillard]

I recently read the french sentence « Je ne crois pas au développement des
sens. » — translation : I don’t believes senses with develop much
(following links in a Wikidata Weekly summary, the slides on a french
meeting about Wikidata lexicographical datas). I believe in it, (regardless
of the arguments exposed in the slides), and I write this email to try to
explain why.

I’m curious to know if there is already some work on the automated
discovering of lexicographical datas / senses thanks to the help of
Wikidata items.

There is tools for automated tagging of terms with the corresponding
Wikidata item, that appeared on this mailing list and/or on the wikidata
weekly summaries.
There is also methods that can discover senses into texts using only the
terms with no reference to any external « sense » like
https://towardsdatascience.com/word-embedding-with-word2vec-and-fasttext-a209c1d3e12c
and can discriminate several usages of the same word according to the
context.

Wikidata lexicographical datas and Wikibase items could close the loop
between the 2 methods and allow us to semi automatically build tools that
annotate texts with Wikidata items it there is something relevant in
Wikidata, but if there is nono try to suggest to add datas on Wikidata,
wether it’s a missing item or a missing sense for the term.

It may even be possible to store word embeddings generated by word2vec
methods into Wikidata senses.

In conclusion, I think Wikidata senses will be used because they allow to
close a gap. It does not depends only on a strong involvement in a
volunteer traditional lexicographic community. If reasearchers of the
language community dives into this and develop algorithms and easy to use
tools to share there lexicographical datas in Wikidata, there could be a
very positive feedback loop where numerous data ends to be added on
Wikidata, where the store datas helps the algorithm to enrich text
annotations, for example, and missing datas are semi automatically added
thanks to user feedback.

This is all just wishful thinking, but I thought this deserved to be
shared, hopefully this will launch at list a thread of ideas/comment in
here :)

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

Re: [Wikidata] SPARQL search for Wikipedia Link

[Thomas Douillard]

Is it what you need ?


Le mar. 17 sept. 2019 à 22:03, Olaf Simons 
a écrit :

> Hi,
>
> I am trying to bring some light into this query:
>
> https://w.wiki/8Xv
>
> Many of the listings have no labels in any language - is there a simple
> way to get the Wikipedia-title in whatever wp with the q-Number?
>
> cheers
> Olaf
>
>
>
> Dr. Olaf Simons
> Forschungszentrum Gotha der Universität Erfurt
> Schloss Friedenstein, Pagenhaus
> 99867 Gotha
>
> Büro: +49-361-737-1722
> Mobil: +49-179-5196880
>
> Privat: Hauptmarkt 17b/ 99867 Gotha
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Dead or alive ? Probably dead

[Thomas Douillard]

We have already a qualifier for this kind of stuffs, I think : P887
 this is a bit of a corner
case because it’s not the value that is computed here but the existence of
a value, but I think it will do. We just need an item for this, something
such as « most likely dead because born long before » should do the trick.

Le sam. 7 sept. 2019 à 09:14, Federico Leva (Nemo)  a
écrit :

> Fabrizio Carrai, 07/09/19 09:53:
> > Since the oldest know person was 122, what about to set "date of death =
> > unknown value" for all the persons resulting older such age ?
>
> It seems to me a sensible thing to do. It's good you asked because it's
> better to avoid the risk of conflicting mass changes.
>
> I wounder if we need a qualifier to allow identifying this as an
> inferred piece of data: do people sometimes state "unknown value" when
> someone is known to be dead, but we don't know when they did? I would
> place a date of death with a precision of a decade or century in such a
> case, but I've not checked what's the frequency of such qualifiers yet.
>
> Federico
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] "Wikidata item" link to be moved in the menu column on Wikimedia projects

[Thomas Douillard]

Comparing to something very similar, the user interface of structured
metadatas associated to a file in commons, it seems to be far less visible
and accessible. Considering the Wikidata datas are possibly used in the
article, Wikidata is not « any » other project.

However it’s true that we put links to the datas in the infoboxes
themselves and the « edit links » link in the interwiki section so this
might not be a real issue.

Le jeu. 8 août 2019 à 11:47, Léa Lacroix  a
écrit :

> Hello all,
>
> Currently and since the Wikimedia projects pages and Wikidata items have
> been connected, the link "Wikidata item" appears on the menu column of the
> Wikimedia wikis, in the section "Tools".
>
> However, many editors from various projects told us that it would make
> more sense to have the link in the "In other projects" section, since
> Wikidata is one of the Wikimedia projects and the Wikidata item link
> doesn’t really belong to the list of special pages.
>
> This is why we are going to change the position of the link, on August
> 22nd for all Wikipedias and August 21st for all the other projects. After
> this date, *you will find the "Wikidata item" link in the "In other
> projects" section* of all Wikimedia projects.
>
> In some cases, for example on help and meta pages, the section may contain
> two links to Wikidata, for example on en:Help:Contents
>  where there will be the
> "Wikidata" link (linking to d:Help:Contents
> ) and the "Wikidata item"
> link (linking to d:Q914807 ).
>
> If you want to know more about the previous discussions or mention a bug
> or an issue, please add a comment to the related Phabricator task
> .
> Cheers,
> --
> Léa Lacroix
> Project Manager Community Communication 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/029/42207.
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Authority control and Wikidata

[Thomas Douillard]

That's by design, since identifiers on Wikidata are not some kind of
> top-down process where ever single actor's responsibility is defined
> from the beginning.
>
> This doesn't preclude good things from happening, as we've seen with LOC:
>
> https://blogs.loc.gov/thesignal/2019/05/integrating-wikidata-at-the-library-of-congress/
>

I know that, but indeed that does not preclude deeper collaboration and
synchronisation of Wikidata datas and other resources, and that’s the
status of those potential collaboration and their maturity/workflow I’m
interested in. Liking is useful of course but things happens also on
Wikidata like data curation, duplicates entry identification on the
external database working with their identifiers if it occurs that the same
Wikidata item has two identifiers (for example :
https://www.wikidata.org/wiki/Q539#P1015 has two values at the post time).
I’m interested to know if this potential is exploited by some workflow
authority control organisation by a periodic review/report of comparison of
their datas against Wikidata community differences. And conversely if we
imported datas from a datasource, if the changes made on the original live
data source are reflected on the Wikidata datas.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

[Wikidata] Authority control and Wikidata

[Thomas Douillard]

Hi all, I find it hard to know what are the connections between Wikidata
and authority control organizations and big live databases.

We got plenty of property that maps entities to external datas in Wikidata,
but information about their freshness and the deepness of the collaboration
between community and the organisations is harder to find.

There is a degree of collaboration, which come from « community does all
the work,  maintenance and synchronisation, updates on Wikidata are not
reflected on the database » to « the organisation fully collaborate and
maintains a two way synchronization of the mapping and data from Wikidata
(meaning, corrections on Wikidata are reflected on the database and the
other way around) ».

Do we know where we are on the scale for the major authorities ? Pages like
https://en.wikipedia.org/wiki/Wikipedia_talk:Authority_control/VIAF seems
to be a little dead, which suggest the collaboration which VIAF seems a
little dead right now. Did I miss anything ?
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] What's wrong in Italy ?

[Thomas Douillard]

> I'm a bit puzzled by a ranking with at preference in an "instance of"
but...

It’s indeed an interesting point. The problem in the country domain is that
there is a lot of evolution into the regime of a state, a state can be
sovereign at some point in history then become a part of a bigger state
losing its sovereignty. If we assume a kind of continuity of a state across
this status change, we have to use ranks to select the last valid value.
There may not be items for all the regime of a state in history, and a
practical choice could be to store the information in the « instance of »
statements with date qualifiers.

In this case I assume however it’s just a practical way to circumvene the
complexity or even inexistence of our ontology on countries. I would in
most case would have noted that « sovereign state » is a subclass of «
country ». If you want to include countries of all kind and don’t miss any,
you’d have to use a construction like
> ?country wdt:P31/wdt:P279* wd:Q6256.

The problem with this is that there is many subclasses of « wd:Q6256 »
(country) :
https://tools.wmflabs.org/wikidata-todo/tree.html?lang=fr=Q6256=279 so
this might include some unwanted « countries ». It would be interesting to
check what the differences are, to see which one is best or if some
subclasses of country should not be.

There for example a subclass of « wd:Q6256 » that is « former countries »,
so this query would include former entities.

My opinion on these is that if we choose a scheme where there are classes
or former entities, the best would be to have the counterpart « today’s
country » (with label (country) and a superclass for both, « country
(either former or not ) ») to avoid having the « former country » class be
a subclass of «today’s country».

Another question, why is not « sovereign state » as the sole class not
enough for this query ? Or only the state recognized by the United Nations
(I don’t know if/how we model this) ?



Le mar. 7 mai 2019 à 23:51, Fabrizio Carrai  a
écrit :

> Thank you Nicolas!
> I found the same situation for other countries like France (Q142) and
> Germany (Q183), maybe in many others. I'm a bit puzzled by a ranking with
> at preference in an "instance of" but...
> Is there a way to extend the query to all the values of the property ?
>
> Fabrizio
>
> Il giorno mar 7 mag 2019 alle ore 22:54 Nicolas VIGNERON <
> vigneron.nico...@gmail.com> ha scritto:
>
>> Hi,
>>
>> This query only search for "country" (Q6256) but Italy, like many other
>> items, has a preferred ranking on the value "sovereign state" (Q3624078),
>> so by default, Italy doesn't appears as a country (which is strange but not
>> totally illogical "country" is a quite broad term).
>>
>> Cheers, ~nicolas
>>
>> Le mar. 7 mai 2019 à 22:11, Fabrizio Carrai 
>> a écrit :
>>
>>> Can anybody explain why Italy is not shown in the results of the
>>> "Wikidata Query Service" example "Continents, countries, regions and
>>> capitals" [1] ?
>>> I suppose because Italy is belonging to two different continents (Europe
>>> and Africa). If this is the case I'm not able to fix the query.
>>>
>>> Thanks
>>>
>>> --
>>> *Fabrizio*
>>>
>>>
>>> *[1]
>>> 

Re: [Wikidata] Weekly Summary #361

[Thomas Douillard]

I played a bit with OpenTapioca, and trying to annotate a « nature briefing
» newsletter I found something weird : « Nature » is mapped not to the
scientific publication entity, but first to this weird item :
https://www.wikidata.org/wiki/Q57439158 . Seems to originate from Orchid
and looks like a bug from an automated tool.

Le mar. 23 avr. 2019 à 16:10, Léa Lacroix  a
écrit :

> *Here's your quick overview of what has been happening around Wikidata
> over the last week.*
>
> Events 
>
>- Past: Editathon Where iNaturalist meets Wiki
>
> ,
>on April 16th in Meise, Belgium
>- Upcoming: Wikidata meetup in Argentina
>, April 25th
>- Upcoming; Wikidata workshop in Pardubice
>,
>Czech Republic
>
> Press, articles, blog posts
> 
>
>- Association of Research Libraries White Paper on Wikidata:
>Opportunities and Recommendations
>
> 
>- Open-sourcing PyTorch-BigGraph for faster embeddings of extremely
>large graphs
>
> 
>and the example of Wikidata, on AI Facebook blog
>- OpenTapioca : Lightweight Entity Linking
>for Wikidata (paper by Antonin Delpeuch
>)
>- Update on the Factgrid project with Wikibase and GND
> by Olaf Simons
>
> Other Noteworthy Stuff
>
>- Plenty of documentation pages have been translated into Spanish: Wikidata
>in one page
>, Query
>Service in one page
>
> ,
>a new data model example based on Marie Curie
>
> ,
>and the flyer "Wikidata for developers"
>
> .
>Thanks a lot to Mlemusrojas
> and the Wikidata
>group in Argentina
>!
>- Depicts statements were due to arrive on Commons on April 23rd
>
> 
>- The Wikimedia URL Shortener
> is live and
>now included in the Query Service to create short links to queries or
>direct results (announcement
>
>)
>- Reminder: the application phase for the WikidataCon is open until
>April 29th : if
>you want to attend to the conference, don't forget to participate!
>- Wikidata Sign Languages Browser
>
>- You can help by training ORES, the machine learning system, to
>better judge if edits are good or bad. We need another 7000 edits
>judged 
>
> Did you know?
>
>- Newest properties
>:
>   - General datatypes: number of sentences
>   , Football Money
>   League rank 
>   - External identifiers: National Wrestling Hall of Fame wrestler ID
>   , MassBank Accession
>   ID , CNV-SP ID
>   , GruCultura ID
>   , CEMDP ID
>   , NGMDb Prod ID
>   , MESH Concept ID
>   , PRELIB organization
>   ID 
>- New property proposals
>
> 
>to review:
>   - General datatypes: supported metadata
>   
> ,
>   expansion
>   

[Wikidata] Fwd: Querying Wikidata

[Thomas Douillard]

I think there is a higher probability of answer on the dedicated mailng
list, so I take the freedom to transfer the message (originally posted on
the sematic web mailing list)

-- Forwarded message -
From: Jean-Claude Moissinac 
Date: lun. 7 janv. 2019 à 11:04
Subject: Querying Wikidata
To: semantic-web 


Hello,

Is there a good mean to query the sparql wdqs service of wikidata?
I've tried some python code to do it, with relative success.
Success, because some requests gives the expected result.
Relative, because the same query sometimes gives an empty response either
from my code or directly in the WDQS interface, where it's possible to see
that a sparql query sometimes gives an empty response, sometimes the
expected reponse without message or status to know that the response is
erroneous.
(demo is difficult, because it seems to depend of the load of the wdqs
service)
I've found the following info:
*
https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Query_limits,
which suggest a possible error HTTP code 429, which I never receive
* https://phabricator.wikimedia.org/T179879, which suggest a possible
connexion with OAuth, but such possibility is never documented in the
official documentation

None of them gives a practical method to get a response and trust it.

Have you some advices?
(comment: this question is relative to the post
https://onsem.wp.imt.fr/2019/01/06/paris-musees-and-wikidata-establishing-links/
)


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

Re: [Wikidata] Wikidata considered unable to support hierarchical search in Structured Data for Commons

[Thomas Douillard]

There is already stuffs to handle this kind of « mutex » on Wikidata :
"disjoint union of", see for example in usage on htps://
www.wikidata.org/wiki/Q180323 . The statements are used on the talk page by
templates that uses them to generate queries to find instances that violate
the mutex : https://www.wikidata.org/wiki/Talk:Q180323 (for example This
query

, that does not find anything unsurprisingly because I don’t expect to find
a lot of vertebra instances on Wikidata :) )

Le sam. 20 oct. 2018 à 12:09, Thad Guidry  a écrit :

> Hi All,
>
> Just to address what Markus was hinting at with inference rules. Both
> positive and negative rules could be stored.  Back in the Freebase days, we
> had those and were called "mutex's".  We used them for "type incompatible"
> hints to users and stored those "type incompatible" mutex rules in the
> knowledge graph. (Freebase being a Type based system along with having
> Properties under each Type)
>
> Such as:  ORGANIZATION != SPORT
>
> You actually have all those type incompatible mutexs in the Freebase dumps
> handed to you where you could start there.  The biggest one was called "Big
> Momma Mutex".
> Here is an archived email thread to give further context:
> https://freebase.markmail.org/thread/z5o7nlnb62n5t22o
>
> Anyways, the point is that those rules worked well for us in Freebase and
> I can see rules also working wonders in various ways in Wikidata as well.
> Maybe its just a mutex at each class ? Where multiple statements could
> hold rules ?
>
> Thad
> +ThadGuidry 
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata + Wikipedia outreach

[Thomas Douillard]

For the record,  tagging has noting to do with the « part of » properties
as defined by Help:Basic Membership Properties whatsoever. Please don’t
confuse genericity with lack of precision and Giant Mess …

2018-01-04 17:10 GMT+01:00 Thad Guidry :

>
> "relatedness" or "tagging" is typically handled generically in Wikidata
> through the use of "part of" and "has part" properties.
> They work terrifically well to apply some generic classification needs
> such as those of the Black Lunch Table efforts.
>
> So, an alternative to the current modeling could be...
>
> Are they only persons ?  if so, mark them as "participant of" ->
> "Q28781198" Black Lunch Table
> Are the topics needing some "tagging" for classification sometimes more
> than persons ?  if so, mark them as "part of" -> "Q28781198" Black Lunch
> Table
>
> -Thad
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] RDF: All vs Truthy

[Thomas Douillard]

In the RDF dump, used by the query service, totally. See
https://www.mediawiki.org/wiki/Wikibase/Indexing/RDF_Dump_Format . In the
json dump, all these is encoded by a "mainsnak" attribute and a
"qualifiers" one : https://www.mediawiki.org/wiki/Wikibase/DataModel/JSON

2017-12-03 15:34 GMT+01:00 Laura Morales :

> > If you want to know when, why, where, etc, you have to
> > check the qualified "full" statements.
>
> All these qualifiers are encoded as additional triples in "all", correct?
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] RDF: All vs Truthy

[Thomas Douillard]

« Ranking » is a Wikibase feature to deal with this. If one of the
statement is ranked « preferred », typically the one valid at present time,
then it will be the only one present in a typical query result or in an
infobox extraction.

2017-12-03 14:49 GMT+01:00 Imre Samu :

> >All=contains not only the Truthy ones, but also the ones with qualifiers
>
> imho:  Sometimes Qualifiers is very important for multiple values  (
>  like "Start time","End time","point in time", ... )
> for example:   Russia https://www.wikidata.org/wiki/Q159  :  Russia -
> P38:"currency"
> has 2 "statements" both with qualifiers:
>
> * Russian ruble -  ( start time: 1992 )
> * Soviet ruble  - (end time: September 1993 )
>
> My Question:
> in this case - what is the "Truthy=simple" result for
>  Russia-P38:"currency" ?
>
>
> Regards,
>  Imre
>
>
>
> 2017-12-03 7:54 GMT+01:00 Fariz Darari :
>
>> Truthy=simple, direct, only Subject-Predicate-Object structure
>>
>> For example: wd:Q76127 wdt:P26 wd:Q468519 (= Sukarno hasSpouse Fatmawati)
>>
>> All=contains not only the Truthy ones, but also the ones with qualifiers
>> (= how long was the marriage? when did the marriage happen?), references
>> (sources to support the claim), and preferences (in case of multiple
>> values, one might be preferred -- think of multiple birth dates of some
>> people).
>>
>> -fariz
>>
>> Regards,
>> Fariz
>>
>> On Sun, Dec 3, 2017 at 1:49 PM, Laura Morales  wrote:
>>
>>> Can somebody please explain (in simple terms) what's the difference
>>> between "all" and "truthy" RDF dumps? I've read the explanation available
>>> on the wiki [1] but I still don't get it.
>>> If I'm just a user of the data, because I want to retrieve information
>>> about a particular item and link items with other graphs... what am I
>>> missing/leaving-out by using "truthy" instead of "all"?
>>> A practical example would be appreciated since it will clarify things, I
>>> suppose.
>>>
>>> [1] https://www.wikidata.org/wiki/Wikidata:Database_download#RDF_dumps
>>>
>>> ___
>>> Wikidata mailing list
>>> Wikidata@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>>
>>
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] An answer to Lydia Pintscher regarding its considerations on Wikidata and CC-0

[Thomas Douillard]

> you might enumerate the position of each occurrence of a word in Harry
Potter, that's all pure facts after all. But publishing an extensive set of
that kind of factual statements would let anyone rebuild this books.

This is just a representation of the artwork. And the artwork is protected
as a creative work. So you can’t do that without violating database right
(I guess a court won’t buy the argument « but this was not the ebook of
Harry Potter, this was the zipfile of an ebook of Harry Potter.) You can’t
« hack » the law that way as it has been robust ehough to protect numerical
and paper versions of book withou a sustantial change, an editor don’t have
to protect the little endian as well as the big endian version of the file
:). What is not protected is the idea : you can make a story about a
sorcerer school.

What is a work of the spirit is defined by the law, in france :
http://www.bnf.fr/fr/professionnels/principes_droit_auteur.html A criteria,
relevant in databases is « originality »
*: another author would not make the same work. In pure factual facts, like
a lot of stuffs, a list of work ever published by a specific editor, any
author would do the same list eventually. Only the specific presentation of
the data can apply as « droit d’auteur ». However databases obey a specific
law that aims to protect an organisation that uses a « substancial » amout
of resources to build a specific dataset. An example is the french organism
IGN https://www.wikidata.org/wiki/Special:EntityPage/Q1665102
 who recolted,
updated and publisshed detailed geographic maps of france. Such an editor
is allowed to disallow the extraction of a « substancial » amount of datas
from his dataset … this last 15 years from the point the editor stops
unpdating the data. *

2017-11-30 13:38 GMT+01:00 mathieu stumpf guntz <
psychosl...@culture-libre.org>:

>
>
> Le 30/11/2017 à 10:14, John Erling Blad a écrit :
>
> A single property licensing scheme would allow storage of data, it might
> or might not allow reuse of the licensed data together with other data.
> Remember that all entries in the servers might be part of an mashup with
> all other entries.
>
> That's a very interesting point. Does anyone know a clear extensive report
> of what is legal or not regarding massive import of data extracted from
> some source?
>
> Indeed, if there was really no limit in using "factual statement" data,
> that would be a huge loophole in copyright. For example you might enumerate
> the position of each occurrence of a word in Harry Potter, that's all pure
> facts after all. But publishing an extensive set of that kind of factual
> statements would let anyone rebuild this books.
>
> The same might happen with an extensive extraction of data stored
> initially in Wikipedia under CC-by-sa, and imported in Wikidata. There is
> already the ArticlePlaceholder[1] extension which is a first step in
> generating whole complete prosodic encyclopaedic article, which then should
> be logically be publishable under CC0. Thus the concerns of license
> laundering.
>
> Not having a way to track sources and their corresponding licenses doesn't
> make automagically disappear that there are licenses issues in the first
> place. An integrating license tracking system should enable to detect
> possible infractions in remixes. Users should be informed that what they
> are trying to mix is legally authorized by the miscellaneous ultimate
> sources from which Wikidata gathered them, or not. Until some solid legal
> report point in this direction, it's not accurate to pretend unilaterally
> that they can do whatever they want regardless of sources from which
> Wikidata gathered them in the first place even if it's a massive import of
> a differently licensed source.
>
> [1] https://www.mediawiki.org/wiki/Extension:ArticlePlaceholder
>
>
>
> On Thu, Nov 30, 2017 at 9:55 AM, John Erling Blad 
> wrote:
>
>> Please keep this civil and on topic!
>>
>> Licensing was discussed in the start of the project, as in start of
>> developing code for the project, and as I recall it the arguments for CC0
>> was valid and sound. That was long before Danny started working for Google.
>>
>> As I recall it was mention during first week of the project (first week
>> of april), and the duscussion reemerged during first week of development.
>> That must have been week 4 or 5 (first week of may), as the delivery of the
>> laptoppen was delayed. I was against CC0 as I expected problems with reuse
>> og external data. The arguments for CC0 convinced me.
>>
>> And yes, Denny argued for CC0 AS did Daniel and I believe Jeroen and Jens
>> did too.
>>
>> Argument is pretty simple: Part A has some data A and claim license A.
>> Part B has some data B and claim license B. Both license A and  license B
>> are sticky, this later data C that use an aggregation of A and B must
>> satisfy both license A and license B. That is 

Re: [Wikidata] Deletion nomination of Template:Cite Q on English Wikipedia

[Thomas Douillard]

If my experience in correct, this would not stop anything. There are
usually very basic arguments about data duplication and data reuse, ease of
maintenance and so on, stuffs that should be on an introduction about
Wikidata and Wikipedia.

But this won’t be enough and some people will push stuff more and more and
demand more and more stuffs, and don’t care about those arguments. « Fake
News » are in the air, and the Truth is not stopping them. Improvements in
watchlist integration, edition on the client wiki and so on are stuffs
which resulted of those discussion. There was a war on frwiki to slow down
Wikidata infobox deployment enough to lead deployment that will need
decades.

And in the end, I’m afraid this will not be enough because some people have
a problem with the very idea of using data external of « their » wiki, a
sensation of loosing control and will try to react by any mean, a fear to
collaborate with foreigners …

2017-09-20 13:14 GMT+02:00 Lydia Pintscher <lydia.pintsc...@wikimedia.de>:

> On Wed, Sep 20, 2017 at 1:03 PM, Thomas Douillard
> <thomas.douill...@gmail.com> wrote:
> > I don’t know what you disagree with but personally I investd a lot of
> time
> > in those discussions in frwiki, and I keep a lot of bitterness over the
> > process. This seems like a wierdly very very similar redux of those
> > discussions with the exact same arguments, and I’m done with all this.
> I’m
> > also done with the « it’s not the use by itself who is the problem it’s
> the
> > advocacy » who is very close to the one of conspiracy theory (a group of
> > outsider want to steal the control of your wiki and invade it) who is a
> > serious attack on the good faith of everyone borderline to push
> everything
> > on fire. Enough with this.
>
> Since this is indeed the same discussions over and over again would it
> maybe be helpful to create a central page that lines out our thinking
> and arguments about them so you can point there instead of doing this
> over and over again?
>
>
> 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/029/42207.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Deletion nomination of Template:Cite Q on English Wikipedia

[Thomas Douillard]

I don’t know what you disagree with but personally I investd a lot of time
in those discussions in frwiki, and I keep a lot of bitterness over the
process. This seems like a wierdly very very similar redux of those
discussions with the exact same arguments, and I’m done with all this. I’m
also done with the « it’s not the use by itself who is the problem it’s the
advocacy » who is very close to the one of conspiracy theory (a group of
outsider want to steal the control of your wiki and invade it) who is a
serious attack on the good faith of everyone borderline to push everything
on fire. Enough with this.

2017-09-20 11:41 GMT+02:00 Yaroslav Blanter :

> No, I actually disagree. There is a number of English Wikipedia users who
> advocate banning Wikidata completely (I mean, not banning it as a project,
> but banning any direct interaction with Wikidata). Some of them are
> reasonable, some of them are not reasonable. Some of their arguments have
> merit, other arguments do not (for instance, one argument frequently
> repeated is that everything what shows up on a Wikipedia page should be in
> the code of the page - whereas it is not true already for many years for
> pages using complex templates such as railway lines etc). If we just ignore
> this, they open an RfC at some point and ban Wikidata. Also, discussing
> arguments help to convince those who are sane that at least something from
> Wikidata can be eventually used. There are of course always people who are
> centered on the Default Language Wikipedia and do not care about other
> projects, but completely ignoring the argument would not help here.
>
> Cheers
> Yaroslav
>
> On Wed, Sep 20, 2017 at 11:29 AM, Jane Darnell  wrote:
>
>> Yes the hostility is so general that it is pointless to try to discuss
>> anything with those anti-WD people at this point. We can better disregard
>> such discussions and focus on ways to help any Wikipedia editors who are
>> eager to tap into WD resources, such as enabling people to easily add high
>> quality references to Wikipedia in cases of articles that currently have
>> zero references, for example. I think that was the original idea behind the
>> cite-Q thing before the implementation got completely derailed, wasn't it?
>> The main question in this type of situation, namely where Wikidata has
>> something truly useful that Wikipedia lacks, is how to indicate this to
>> potential editor/readers at the Wikipedia-level? Maybe some sort of basic
>> gadget that indicates the number of statements in the associated item?
>>
>> On Wed, Sep 20, 2017 at 11:01 AM, Yaroslav Blanter 
>> wrote:
>>
>>> There is also a more general and very useful discussion of the same
>>> issues at this page
>>>
>>> https://en.wikipedia.org/wiki/Wikipedia_talk:Wikidata/2017_S
>>> tate_of_affairs
>>>
>>> (check recent edits, last 5 days or so).
>>>
>>> Since it is not related to any decision-making (at least not yet) I
>>> would expect it is easier to comment there, though some editors are really
>>> hostile (I was at some point labeled as a "part of Wikidata crowd" in a
>>> negative sense and had to point out that I have 15 times as many edits on
>>> the English Wikipedia than the editor who was attacking me).
>>>
>>> Cheers
>>> Yaroslav
>>>
>>> On Wed, Sep 20, 2017 at 10:03 AM, Jane Darnell 
>>> wrote:
>>>
 Yes Yaroslav, I totally agree with you (and don't worry, I wouldn't
 dream of commenting there). On the other hand, this is extremely relevant
 for the Wikidata mailing list and I am really grateful to Dario for posting
 about it, because I had no idea. I stopped following that "2017 state of
 affairs" thing when it first got ugly back in January. I suggest that in
 cases where (as Dario suggests) highly structured and superior data from
 Wikidata *could* be used in Wikipedia, that we create some sort of property
 to indicate this on Wikidata, along the lines of the P31->Q17362920 we use
 to show that a certain Wikipedia has a pending merge problem. If the
 information is ever used on that Wikipedia (either with or without that
 "Cite-Q" template) then the property for that specific Wikipedia should be
 removed. Ideally this property could be used as a qualifier at the
 statement level (so e.g. for paintings, a statement on a collection
 property for a painting that it was stolen and rediscovered, or on a
 significant event property that it was restored and reattributed, or that
 it was owned by the Hitler museum and stored it the depot in Linz during
 WWII, etc).

 On Wed, Sep 20, 2017 at 8:58 AM, Yaroslav Blanter 
 wrote:

> Thanks Dario.
>
> May I please add that whereas the deletion discussion is of course
> open to everyone, a sudden influx of users who are not regular editors of
> the English Wikipedia will be looked at extremely 

Re: [Wikidata] Explaining Wikidata

[Thomas Douillard]

To be pedantic, not everything is an item. There is entities who are not
items and the non-entity datatype are not.

> What's not possible is to have sets or clusters of items, and to give
properties to such sets and clusters. This is somehow related to the book
topic.

This is something I’d definitely miss in Wikidata : the lack of explicit
data model that defines implicit values for instances of classes …
Considering th ecomplexity involved, this means that the software is no
help at all to the editor, this is why such a mail is definitely not
surprising. There is ongoing wiki discussion, on
https://www.wikidata.org/wiki/Wikidata:WikiProject_Reasoning especially,
but it’s stalled due to lack of inputs and/or manpower unfortunately.

One other less ambitious approach would be to define a javascript gadget
specialized for bibliographical datas that take the user by the hand in the
mess. Of course that means that we agree on a datamodel, we identifies
usecases and so on.

Tom

2017-05-17 17:17 GMT+02:00 Andrea Zanni :

> [Sorry for cross-posting. I just sent this mail to the Wikicite mailing
> list, but I thought it could be of interest also here. Moreover, the
> community here could provide some important insight to better explain
> wikidata to "newbies" and set the right path for a meaningful conference.]
>
>
> Dear all,
> sorry for the messy email, but I'd like to to express a small concern I
> have regarding the awesome Wikicite conference we'll have in few days.
>
> My main point is that Wikidata is *complex*.
> It's not just the data model (which is not easy, per se), but the whole
> idea behind wikidata, the policies, the community, the workflow, the tools,
> and the whole helo of vagueness that sorrounds it.
>
> My favourite example about this is this little story:
> https://en.wikipedia.org/wiki/Blind_men_and_an_elephant
> (which was actually a very good metaphor used by my professors introducing
> the Information Science course...)
>
> Different people with different background work with data in different
> manners: the word "data" (as "information") means anything and its
> contrary, so we must be careful. You know better than me that everyone
> projects her own dreams and delusions upon Wikidata, so we must work
> towards a good understanding at the beginning, to avoid the painful and
> time-consuming job of making people un-learn things they think they know.
> This was quite evident especially last year, when a lot of librarians and
> wikimedians were in the same room, and everyone knew many things about
> metadata and their metadata model: librarians had difficulties grasping
> things about Wikibase, Wikidata, policies and communities, and wikimedians
> about bibliographic models and complexities.
>
> We spent at least 30 minutes explaining Wikidata from the beginning, also
> adding some "color" about strategies, policies and community.
>
> I'll try to make examples.
>
> * we need to explain that in Wikidata (and Wikibase) everything is an
> *item*. Everything. Every items has properties, values, qualifiers. What's
> not possible is to have sets or clusters of items, and to give properties
> to such sets and clusters. This is somehow related to the book topic.
>
> * we need to explain that there are at least 2 different possible
> strategies: create few general properties and many specific items,
> or create many specific properties and less general items. Wikidata chose
> the former.
>
> * we need to explain the "scaffolding principle", meaning that we don't
> need to put *all the info in all the items*. We need to create and organize
> items that are *queriable*, in such a way that I can make a query that get
> all the data and details I need, scattered among different items. If the
> items in questions are built "on top of each other", this is doable. It is
> actually very important to understand this, because people get confused
> about how many things to say inside one item. This principle (and the
> former) was explained to me by Tobias1984, and helped me a lot in my
> understanding of Wikidata.
>
> I think that this kind of insight is crucial for working with Wikidata in
> a meaningful way, because wikidata offers *one product*, with *one data
> model*, and it simply impossible to adapt and stretch the Complexity Of The
> World to Wikidata without loss of information.
> I'm sure many of you know this perfectly, but other people maybe don't, or
> at least they will struggle with it.
> We all come from different backgrounds and are emotionally very attached
> to our models and our crucial pieces of information we don't want to lose:
> in this sensse, Wikidata is much more a "negotiation" than Wikipedia,
> because Wikipedia is not structured and llows for much more messiness.
>
> Every model and decision we will make will be a trade-off, and I think
> it's worth trying to save time and effort trying to establish these
> boundaries at the beginning.
> Of course, 

Re: [Wikidata] Wikimania 2017

[Thomas Douillard]

Not a mature idea but definitely something we all have to figure out : how
(if we should) to integrate the different "groupification" methods on
Wikimedia:
* (unformal) classes item on Wikidata
* categories on wikipedias, common cats
* list articles
* ... (?)

This raised a number on issued that never could really be socially properly
solved on Wikidata and Wikipedias, the overall picture remains unclear.

On the other hand there is relationship between all those objects, some
categories maps to classes and to lists, some categories maps to a
property/value pair, some lists articles maps to categories. There is tools
to define queries from lists article, Reasonator is an exampe. Maybe we
need a comprehensive review and search for a consistent model and/or a plan
that could be discussed with community to gain a consensus that would led
to involvement an action from the different communities  ?
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Wikidata ontology

[Thomas Douillard]

> Same entity can be treated both as class and individual

This is valid for OWL as well.

2017-01-05 22:21 GMT+01:00 Stas Malyshev :

> Hi!
>
> > The best you can get in terms of "downloading the wikidata ontology"
> would be to
> > download all properties and all the items representing classes. We
> currently
> > don't have a separate dump for these. Also, do not expect this to be a
> concise
> > or consistent model that can be used for reasoning. You are bound to find
> > contradictions and lose ends.
>
> Also, Wikidata Toolkit (https://github.com/Wikidata/Wikidata-Toolkit)
> can be used to generate something like taxonomy - see e.g.
> http://tools.wmflabs.org/wikidata-exports/rdf/exports/
> 20160801/dump_download.html
>
> But one has to be careful with it as Wikidata may not (and frequently
> does not) follow assumptions that are true for proper OWL models - there
> are no limits on what can be considered a class, a subclass, an
> instance, etc. Same entity can be treated both as class and individual,
> and there may be some weird structures, including even outright errors
> such as cycles in subclass graph, etc. And, of course, it changes all
> the time :)
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] External link Twitter --> Wikidata

[Thomas Douillard]

Hi, I'm afraid this is the wrong place to talk about this.

We're incompetent on this list to talk about this as it's wikipedias and
their community matter to discuss on how Wikidata datas are used. There is
documentation indeed on how to modify Wikidata for contributors :
https://www.wikidata.org/wiki/Help:Contents especially the
https://www.wikidata.org/wiki/Wikidata:Tours are interesting on basis on
how to edit Wikidata for beginners.

2016-10-09 13:34 GMT+02:00 Brill Lyle :

> So I have been noticing that Twitter links often found in the External
> link section is starting to move to Wikidata on English Wikipedia.
> {{Twitter}} template is used much like with {{Authority control}}
>
> Was there consensus or discussion about this before it's implementation? I
> am hoping there is also really good documentation so Wikipedia editors know
> how to create and/or edit this value.
>
> Apologies if I didn't see this mentioned or addressed previously.
>
> - Erika
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Greater than 400 char limit for Wikidata string data types

[Thomas Douillard]

Probably a silly question but ... did you all consider creating a datatype
for molecue representation ? This seem to be a very similar usecase than
mathematica formula. Essentially we're not dealing with a raw string but a
representation of molecule formulas, with its own encoding ...

Changing the limit seem to be a poor workaround to a dedicated datatype -
nobody seems to have found a relevant usecase and it seem to me that we're
essentially abusing strings for storing blobs ...

2016-10-08 11:33 GMT+02:00 Egon Willighagen :

>
>
> On Sat, Oct 8, 2016 at 11:28 AM, Lydia Pintscher <
> lydia.pintsc...@wikimedia.de> wrote:
>
>> On Sat, Oct 8, 2016 at 11:23 AM, Egon Willighagen
>>  wrote:
>> > Ah, those numbers are for https://www.wikidata.org/wiki/Property:P234
>> ...
>>
>> External identifier then. Cool. And for string like in
>> https://www.wikidata.org/wiki/Property:P233? Sebastian's initial email
>
> says 1500 to 2000. Is this still a good number after this discussion?
>>
>
> Yes, that would cover more than 99.9% of all InChIs in PubChem. (See
> Sebastian's reply earlier in this thread.)
>
> Egon
>
> --
> E.L. Willighagen
> Department of Bioinformatics - BiGCaT
> Maastricht University (http://www.bigcat.unimaas.nl/)
> Homepage: http://egonw.github.com/
> LinkedIn: http://se.linkedin.com/in/egonw
> Blog: http://chem-bla-ics.blogspot.com/
> PubList: http://www.citeulike.org/user/egonw/tag/papers
> ORCID: -0001-7542-0286
> ImpactStory: https://impactstory.org/u/egonwillighagen
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] (Ab)use of "deprecated"

[Thomas Douillard]

People may build representation in their mind, but first there is no
guarantee that they all have the same representations which will lead to
endless conflicts on incompatibilities. But mostly : there already is a
reference interpretation.

This is not high level, this is very very low level and has an impact
everywhere on Wikidata, basically. This should not be conflictual as we
have a reference interpretation, a Markus and a Denny who should be
authoritative on the question, and we can explain and point to pointers
such as this thread. This is just the time to highlight this as community
begins to ask itself about such questions - this might not be the case
earlier as community used less the data and was not really seriously
considering all this.

This is probably not to late either, as if wikidata is beginning to be used
we can probably roll back without to much trouble. Consider the problems we
could face if german do not share the same interpretation as french and as
a result the infoboxes displays wrong datas ... We need such agreement, and
we have strong arguments to show people the right path.

2016-08-14 17:25 GMT+02:00 Gerard Meijssen <gerard.meijs...@gmail.com>:

> Hoi,
> It is even more base. It is about the understanding of the data. When
> people are to understand the data and have no help, they will build
> constructs in their mind and not consider at all any high level conceptual
> considerations.
>
> I do not care too much about the "conceptual heritage of the Wikidata
> creators", they stand on the shoulders of giants as well. What I care about
> is the purpose of Wikidata. What it is there for and I repeat myself when I
> state that interoperability is secondary. The primary purpose of Wikidata
> is realised when said interoperability has an effect on the data in a
> qualitative way. So far it is far removed from the content in Wikidata
> itself and consequently the point has not been shown except abstractly.
>
> So far we have been on a path where the work developed elsewhere was
> considered to be of a lesser value. It is why the Freebase import is a
> fiasco.
> Thanks,
>GerardM
>
> On 14 August 2016 at 17:01, Thomas Douillard <thomas.douill...@gmail.com>
> wrote:
>
>> More seriously maybe :
>>
>> I guess you mention tool because you argue that the correct
>> interpretation of datas is given by the tools and humans. I think it's
>> totally wrong in this case. First because it's a (very small) minimal set
>> of requirements that Wikibase (not Wikidata) was built on, and those set is
>> present since the very first conceptual data model of Wikidata. It's always
>> been public and present in the conceptual description and determined the
>> help pages if you bother read them. It's the framework that guided our
>> decisions more or less explicitely, and this is relatively well understood
>> from our core community. It just need to be spread on to the more distant
>> Wikimedia user circles that are less into Wikidata. This should not be a
>> problem. Things are very different with properties which community is able
>> to create, delete and use as it wishes.
>>
>> Another POV on this : this is one of Wikidata's pillars. The conceptual
>> heritage of WIkidata creators.
>>
>> 2016-08-14 15:14 GMT+02:00 Gerard Meijssen <gerard.meijs...@gmail.com>:
>>
>>> Hoi,
>>> Markus it is very much a matter of perspective and we do not all see
>>> things in the same way. For me the re-usability of Wikidata is very much
>>> secondary. Important but secondary. The primary goal of Wikidata is to
>>> provide a data storage for Wikimedia projects. The problem that I see is
>>> that much effort has gone in secondary goals largely at the cost of the
>>> primary perspective.
>>>
>>> For an editor of Wikidata Wikidata is hardly usable. It is very much
>>> because of tools like Reasonator that I can understand the data that is in
>>> Wikidata. It is also for this reason that "deprecation" will evolve away
>>> from you. It is wonderful that all these high level approaches exist but
>>> the problem is that it does not consider the effects on people editing
>>> Wikidata. SPARQL is now good enough to replace WDQ but the problem is that
>>> the tools build upon WDQ are not converted and SPARQL does not bring the
>>> easy use that I and others are accustomed to. There is no replacement for
>>> much of the functionality.
>>>
>>> We do agree that the architecture of Wikidata has to be stable but so
>>> does its tooling and this is where we fail and consequently see a
>>> divergence. In the past 

Re: [Wikidata] (Ab)use of "deprecated"

[Thomas Douillard]

More seriously maybe :

I guess you mention tool because you argue that the correct interpretation
of datas is given by the tools and humans. I think it's totally wrong in
this case. First because it's a (very small) minimal set of requirements
that Wikibase (not Wikidata) was built on, and those set is present since
the very first conceptual data model of Wikidata. It's always been public
and present in the conceptual description and determined the help pages if
you bother read them. It's the framework that guided our decisions more or
less explicitely, and this is relatively well understood from our core
community. It just need to be spread on to the more distant Wikimedia user
circles that are less into Wikidata. This should not be a problem. Things
are very different with properties which community is able to create,
delete and use as it wishes.

Another POV on this : this is one of Wikidata's pillars. The conceptual
heritage of WIkidata creators.

2016-08-14 15:14 GMT+02:00 Gerard Meijssen :

> Hoi,
> Markus it is very much a matter of perspective and we do not all see
> things in the same way. For me the re-usability of Wikidata is very much
> secondary. Important but secondary. The primary goal of Wikidata is to
> provide a data storage for Wikimedia projects. The problem that I see is
> that much effort has gone in secondary goals largely at the cost of the
> primary perspective.
>
> For an editor of Wikidata Wikidata is hardly usable. It is very much
> because of tools like Reasonator that I can understand the data that is in
> Wikidata. It is also for this reason that "deprecation" will evolve away
> from you. It is wonderful that all these high level approaches exist but
> the problem is that it does not consider the effects on people editing
> Wikidata. SPARQL is now good enough to replace WDQ but the problem is that
> the tools build upon WDQ are not converted and SPARQL does not bring the
> easy use that I and others are accustomed to. There is no replacement for
> much of the functionality.
>
> We do agree that the architecture of Wikidata has to be stable but so does
> its tooling and this is where we fail and consequently see a divergence. In
> the past I asked you for tools and I supported additional funding on the
> promise of support for tooling. So far I have noticed that the quality of
> the engine has improved but I have not seen improvements in or the tooling
> that makes use of the SPARQL engine.
>
> For me all the attention to top level concerns have been at the cost of
> supporting people who actually enter the data. I do not see a strategy to
> converge Wikidata and Wikipedia editing and I have made the argument why
> this is vital for our quality repeatedly.
>
> So as you want to preserve top level integrity do consider tooling and do
> consider what it is we aim for.
> Thanks,
>GerardM
>
> On 14 August 2016 at 14:26, Markus Kroetzsch  de> wrote:
>
>> On 12.08.2016 17:24, Jean-Luc Léger wrote:
>>
>>> On 2016-08-11 22:29, Markus Kroetzsch wrote:
>>>
>>> On 11.08.2016 18:45, Andra Waagmeester wrote:
>>>
>>> On Thu, Aug 11, 2016 at 4:15 PM, Markus Kroetzsch
>>> >> 
>>> >>
>>> >>
>>> wrote:
>>>
>>>
>>> has a statement "population: 20,086 (point in time: 2011)"
>>> that is
>>> confirmed by a reference. Nevertheless, the statement is
>>> marked as
>>> "deprecated". This would mean that the statement "the
>>> popluation was
>>> 20,086 in 2011" is wrong. As far as I can tell, this is not
>>> the case.
>>>
>>>
>>> I wouldn't say that with a deprecated rank, that statement is
>>> "wrong". I
>>> consider de term deprecated to indicate that a given statement
>>> is no
>>> longer valid in the context of a given resource (reference). I
>>> agree, in
>>> this specific case the use of the deprecated rank is wrong,
>>> since no
>>> references are given to that specific statement.
>>> Nevertheless, I think it is possible to have disagreeing
>>> resources on an
>>> identical statement, where two identical statements exists, one
>>> with
>>> rank "deprecated" and one with rank "normal". It is up to the
>>> user to
>>> decide which source s/he trusts.
>>>
>>>
>>> The status "deprecated" is part of the claim of the statement. The
>>> reference is supposed to support this claim, which in this case is
>>> also the claim that it is deprecated. The status is not meant to
>>> deprecate a reference (not saying that this is never useful,
>>> potentially, but you can only use it in one way, and it seems much
>>> more practical if 

Re: [Wikidata] (Ab)use of "deprecated"

[Thomas Douillard]

Sorry but I hardly see how this answer could come up into current
discussion. Please start another thread ;)

2016-08-14 15:14 GMT+02:00 Gerard Meijssen :

> Hoi,
> Markus it is very much a matter of perspective and we do not all see
> things in the same way. For me the re-usability of Wikidata is very much
> secondary. Important but secondary. The primary goal of Wikidata is to
> provide a data storage for Wikimedia projects. The problem that I see is
> that much effort has gone in secondary goals largely at the cost of the
> primary perspective.
>
> For an editor of Wikidata Wikidata is hardly usable. It is very much
> because of tools like Reasonator that I can understand the data that is in
> Wikidata. It is also for this reason that "deprecation" will evolve away
> from you. It is wonderful that all these high level approaches exist but
> the problem is that it does not consider the effects on people editing
> Wikidata. SPARQL is now good enough to replace WDQ but the problem is that
> the tools build upon WDQ are not converted and SPARQL does not bring the
> easy use that I and others are accustomed to. There is no replacement for
> much of the functionality.
>
> We do agree that the architecture of Wikidata has to be stable but so does
> its tooling and this is where we fail and consequently see a divergence. In
> the past I asked you for tools and I supported additional funding on the
> promise of support for tooling. So far I have noticed that the quality of
> the engine has improved but I have not seen improvements in or the tooling
> that makes use of the SPARQL engine.
>
> For me all the attention to top level concerns have been at the cost of
> supporting people who actually enter the data. I do not see a strategy to
> converge Wikidata and Wikipedia editing and I have made the argument why
> this is vital for our quality repeatedly.
>
> So as you want to preserve top level integrity do consider tooling and do
> consider what it is we aim for.
> Thanks,
>GerardM
>
> On 14 August 2016 at 14:26, Markus Kroetzsch  de> wrote:
>
>> On 12.08.2016 17:24, Jean-Luc Léger wrote:
>>
>>> On 2016-08-11 22:29, Markus Kroetzsch wrote:
>>>
>>> On 11.08.2016 18:45, Andra Waagmeester wrote:
>>>
>>> On Thu, Aug 11, 2016 at 4:15 PM, Markus Kroetzsch
>>> >> 
>>> >>
>>> >>
>>> wrote:
>>>
>>>
>>> has a statement "population: 20,086 (point in time: 2011)"
>>> that is
>>> confirmed by a reference. Nevertheless, the statement is
>>> marked as
>>> "deprecated". This would mean that the statement "the
>>> popluation was
>>> 20,086 in 2011" is wrong. As far as I can tell, this is not
>>> the case.
>>>
>>>
>>> I wouldn't say that with a deprecated rank, that statement is
>>> "wrong". I
>>> consider de term deprecated to indicate that a given statement
>>> is no
>>> longer valid in the context of a given resource (reference). I
>>> agree, in
>>> this specific case the use of the deprecated rank is wrong,
>>> since no
>>> references are given to that specific statement.
>>> Nevertheless, I think it is possible to have disagreeing
>>> resources on an
>>> identical statement, where two identical statements exists, one
>>> with
>>> rank "deprecated" and one with rank "normal". It is up to the
>>> user to
>>> decide which source s/he trusts.
>>>
>>>
>>> The status "deprecated" is part of the claim of the statement. The
>>> reference is supposed to support this claim, which in this case is
>>> also the claim that it is deprecated. The status is not meant to
>>> deprecate a reference (not saying that this is never useful,
>>> potentially, but you can only use it in one way, and it seems much
>>> more practical if deprecated statements get references that explain
>>> why they are deprecated).
>>>
>>>
>>> Yes. I think a complete deprecated statement should look like this :
>>>
>>> Rank: Deprecated
>>> Value: 
>>> Qualifier: P2241:reason for deprecation + 
>>>
>>> References
>>> * P248:Stated in (or any other property for a reference)   --> a
>>> reference where the value is true (explaining why we added it)
>>>   Value: 
>>>   + any additional qualifiers
>>> * P1310:statement disputed by  --> a
>>> reference explaining why the claim is deprecated
>>>   Value: 
>>>   + any additional qualifiers
>>>
>>
>> I am afraid that this is not a good approach, and it will lead to
>> problems in the future. The status "deprecated" refers to the *complete
>> claim, including all qualifiers*. So if you add a qualifier P2241, it would
>> also be 

Re: [Wikidata] Grammatical display of units

[Thomas Douillard]

My two cents : this is a job to do in conjunction with structured
wiktionary, who will be able to deal with lexical entities.

We however have some properties here and there to deal with such languages
issues to deal with this inside Wikidata, female form of occupation name
for example, but the logic to deal with those datas is coded in the clients
like the infoboxes.

Coding this inside Wikidata would still require a step that is far from
reach imho : code a per language language grammatical model that would
select some lexical forms considering the context ... Not that easy to do.
What would be really cool eventually is for us to code those rules in a
structured way. One open question would be "how the software would know
thoses rules and which one to use in which context".

I'd suggest to do this as a javascript gadget as a first step to better
understand what those rule may look like, where the main units are
hardcoded, and to leave the logic code in this gadget.

2016-07-29 9:19 GMT+02:00 Stas Malyshev :

> Hi!
>
> > You mean the MediaWiki message processing code? This would probably be
>
> Yes, exactly.
>
> > powerful enough for units as well, but it works based on message strings
> > that look a bit like MW template calls. Someone has to enter such
> > strings for all units (and languages). This would be doable but the
> > added power comes at the price of more difficult editing of such message
> > strings instead of plain labels.
>
> True. OTOH, we already have non-plain strings in the database - e.g.
> math formulae - so that would be another example of such strings. It's
> not ideal but would be a start, and maybe we can have some gadgets later
> to deal with it :)
>
> >> Oh yes :) Russian is one, but I'm sure there are others.
> >>
> >
> > Forgive my ignorance; I was not able to read the example you gave there.
>
> Sorry, it's hard to give examples in foreign languages that would be
> comprehensible :) The gist of it is that Russian, as many other
> inflected languages, changes nouns by grammatical case, and uses
> different cases for different number of items (i.e. 1, 2,  and 5 will
> use three different cases). Labels are of course in singular nominative
> case, which is wrong for many numbers.
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Software API : {{P:part of}} or {{P:API}} ?

[Thomas Douillard]

There is two things : API specs, and services that can implement that
specs.

Which property links something to the class of stuffs that represents its
properties ? "Instance of", a pretty natural way in computing :) The spec
is a set of property its implementations fulfills ... Problem solved :)
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata-tech] MathML is dead, long live MathML

[Thomas Douillard]

Hi, One concrete usecase is the formula datatype for properties on
Wikidata. We are discussing the semantics issues here : what means the
operators of the formula, what means the variables ? An immediate way, in
Wikidata, is to
In the item for a geometric figure, for example a square, how to model that
a square can be defined in the euclidian space by the geometric coordinates
of points, we could create the item for a point class in Wikidata, give a
name of a point (pretty much usual mathematical or programming work) and to
link that variable name to an item for the semantics/corresponding type.
Same for the operators.

Last, in the question you raised on "modelling maths versus modeling domain
model formula" I'd say that in Wikidata the scope is basically unlimited,
contrary to a regular scientific publication who takes place in a context
that may be more or less non formally explicited, we can fill the gap
beetween more formal aspects of logical or inference rules used by the
scientist, the mathematical framework (euclidian space, non euclidian
space, logical framework, axioms ... we pretty much have items for all of
this and can create new one if that's structurally needed for a usecase)
and the formula. Time is less of an issue because the work is reusable and
cumulative, there is no deadline. There is only a need to leave the door
open to do that work for someone to be able to do it at his/her convenance.

Of course it's a lot of work, but there is no pressure. I'm not sure how
MathML relates to this however.

2016-04-08 0:51 GMT+02:00 Paul Topping :

> Peter just posted a follow up response, largely commenting on my response:
> https://www.peterkrautzberger.org/0187/.
>
> First, I suspect the reason his post doesn't get as much discussion as
> he'd like is because his blog doesn't accept comments. I can understand why
> he doesn't enable comments on his personal blog but why not post it
> somewhere that DOES accept comments?
>
> He says that most of the discussion has been private. That is not the way
> to change a standard or replace it by a new one. By all means have your
> private conversations but don't expect others to agree with any conclusions
> reached in them. The result of good ideas expressed in private conversation
> should be to introduce them into public conversation. Instead, his post
> treated MathML's failure as a fait accompli. Perhaps it is but only in the
> narrow scope of it being ignored by browser makers.
>
> He feels that many things I said in my reply were more about expressing my
> own ideas. I'll cop to that. I felt that was needed to indicate that there
> are other points of view and other ideas. His solutions may not be the
> right ones. Let's open up the discussion.
>
> Can we identify specific topics worthy of addressing and discuss them? I
> tried to hint at some possible directions in my reply, which is why it
> veered into some of my own ideas. I would love for this to be a
> constructive discussion. Instead of discussing whether MathML is a failed
> standard, I would like to see real, open discussion on solutions to various
> problems. Any takers?
>
> Paul
>
> > -Original Message-
> > From: Paul Topping [mailto:pa...@dessci.com]
> > Sent: Thursday, April 07, 2016 2:02 PM
> > To: Daniel Kinzler ; Moritz Schubotz  > berlin.de>; www-m...@w3.org; Peter Krautzberger
> > 
> > Cc: Wikimedia developers ; wikidata-tech
> > 
> > Subject: RE: MathML is dead, long live MathML
> >
> > I have no problem with that but are some of these lists members-only? I
> was
> > told when I replied that my message would be reviewed by the moderator as
> > I wasn't a member. Perhaps that was the W3C list.
> >
> > Paul
> >
> > > -Original Message-
> > > From: Daniel Kinzler [mailto:dan...@brightbyte.de]
> > > Sent: Thursday, April 07, 2016 11:06 AM
> > > To: Moritz Schubotz ; www-m...@w3.org; Peter
> > > Krautzberger 
> > > Cc: Wikimedia developers ;
> wikidata-tech
> > > 
> > > Subject: Re: MathML is dead, long live MathML
> > >
> > > Am 07.04.2016 um 20:00 schrieb Moritz Schubotz:
> > > > Hi Daniel,
> > > >
> > > > Ok. Let's discuss!
> > >
> > > Great! But let's keep the discussion in one place. I made a mess by
> > > cross-posting this to two lists, now it's three, it seems. Can we
> agree on
> > >  as the venue of discussion? At least
> for
> > the
> > > discussion of MathML in the context of Wikimedia, that would be the
> best
> > > place,
> > > I think.
> > >
> > > -- daniel
> > >
> > >
>
> ___
> Wikidata-tech mailing list
> Wikidata-tech@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata-tech
>

Re: [Wikidata] Bachelor's thesis on ArticlePlaceholder

[Thomas Douillard]

>One of the main goals of the ArticlePlaceholder is getting more editors
for the projects in question. We need to be very careful not to encourage
them to create articles which are then deleted 5 minutes later. If this
would happen to me as an editor I'd be extremely miffed because you just
asked me to do exactly that 5 minutes earlier.

Sorry, I meant "not showing the create article button when the article is
presumed not notable" ? If it should be very clear that when the button is
shown, there is an incent to create the article, if the button is not shown
it's very clear that we are just showing datas. There could be a button
"edit Wikidata" instead.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Bachelor's thesis on ArticlePlaceholder

[Thomas Douillard]

I think not doing anything at all when the item is presumed not notable is
a bad thing, especially when we have datas. We should be able to at least
generate a description in those cases, maybe in a popup way.

Why not, just not showing the "create" button instead ?

2016-04-03 16:27 GMT+02:00 John Erling Blad :

> Just read through the doc, and found some important points. I post each
> one in a separate mail.
>
> > Since it is hard to decide which content is actually notable, the items
> appear-
> > ing in the search should be limited to the ones having at least one
> statements
> > and two sitelinks to the same project (like Wikipedia or Wikivoyage).
>
> This is a good baseline, but figuring out what is notable locally is a bit
> more involved. A language is used in a local area, and within that area
> some items are more important just because they reside within the area.
> This is quite noticeable in the differences between nnwiki and nowiki which
> both basically covers "Norway". Also items that somehow relates to the
> local area or language is more noticeable than those outside those areas.
> By traversing upwords in the claims using the "part of" property it is
> possible to build a priority on the area involved. It is possible to
> traverse "nationality" and a few other properties.
>
> Things directly noticeable like an area enclosed in an area using the
> language is somewhat easy to identify, but things that are noticeable by
> association with another noticeable thing is not. Like a Danish slave ship
> operated by a Norwegian firm, the ship is thus noticeable in nowiki. I
> would say that all things linked as an item from other noticeable things
> should be included. Some would perhaps say that "items with second order
> relevance should be included".
>
>
> On Sat, Apr 2, 2016 at 11:09 PM, Luis Villa  wrote:
>
>> On Sat, Apr 2, 2016, 4:34 AM Lucie Kaffee 
>> wrote:
>>
>>> I wrote my Bachelor's thesis on "Generating Article Placeholders from
>>> Wikidata for Wikipedia: Increasing Access to Free and Open Knowledge". The
>>> thesis summarizes a lot of the work done on the ArticlePlaceholder
>>> extension ( https://www.mediawiki.org/wiki/Extension:ArticlePlaceholder
>>> )
>>>
>>> I uploaded the thesis to commons under a CC-BY-SA license- you can find
>>> it at
>>> https://commons.wikimedia.org/wiki/File:Generating_Article_Placeholders_from_Wikidata_for_Wikipedia_-_Increasing_Access_to_Free_and_Open_Knowledge.pdf
>>>
>>> I continue working on the extension and aim to deploy it to the first
>>> Wikipedias, that are interested, in the next months.
>>>
>>> I am happy to answer questions related to the extension!
>>>
>>
>> Great work on something that I *believe *has a lot of promise - thanks!
>> I really think this approach has a lot of promise to help take back some
>> readership from Google, and potentially in the long-run drive more new
>> editors as well. (I know that was part of the theory of LSJbot, though I
>> don't know if anyone has actually a/b tested that.)
>>
>> I was somewhat surprised to not see data collection discussed in Section
>> 8.10 - are there plans to do that? I would have expected to see a/b testing
>> discussed as part of the deployment methodology, so that it could be
>> compared both to the current baseline and also to similar approaches (like
>> the ones you survey in Section 3).
>>
>> Thanks again for the hard work here-
>>
>> Luis
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] from Freebase to Wikidata: the great migration

[Thomas Douillard]

Congrats everybody.

Now that we're at it, I'll highlight a usability problem I have with the
primary source tool : it reloads the page every time we approve something,
which can take a lot of times for heavy pages, and is really a blocker to
approve a large number of claims :)

2016-02-18 15:59 GMT+01:00 Lydia Pintscher :

> Hey everyone :)
>
> Thomas, Denny, Sebastian, Thomas, and I have published a paper which was
> accepted for the industry track at WWW 2016. It covers the migration from
> Freebase to Wikidata. You can now read it here:
> http://research.google.com/pubs/archive/44818.pdf
>
> 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/029/42207.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] [Wiki-research-l] Quality issues

[Thomas Douillard]

First they ignore you, then they fight you ... :)

and eventually evrebody wins !

2015-11-21 13:56 GMT+01:00 Markus Krötzsch :

> On 21.11.2015 12:21, Jane Darnell wrote:
>
>> +1
>> I think many Wikipedians are control freaks who like to think their
>> articles are the endpoint in any internet search on their article
>> subjects. We really need to suppress the idea that the data they have
>> curated so painstakingly over the years is less valuable because it is
>> not on Wikidata or disagrees with data on Wikidata in some way. We can
>> and should let these people continue to thrive on Wikipedia without
>> pressuring them to look at their data on Wikidata, which might confuse
>> and overwhelm them. They figured out Wikipedia at some point and
>> presumably some of them have figured out Commons. In future they may
>> figure out Wikidata, but that will be on their own terms and in their
>> own individual way.
>>
>>
> Yes, one can also understand the point of view of many seasoned
> Wikipedians. Because of the popularity of the platform, large parts of
> their daily work consist in defending "their" content against all kinds of
> absurd ideas and changes for the worse. Rather than writing new, better
> content, their main work is in rejecting content that is worse. They
> therefore are spending a lot of time on talk pages, having debates with
> people whom most of us would simply ignore on the Internet, but which they
> cannot ignore if they want to protect what has been achieved already. Doing
> this is hard work, since Wikipedia rejects the notion of personal standing
> or seniority as a basis for "trusting" someone to be right -- every puny
> battle of opinions has to be fought out on the talk page. The only thing to
> allude to is some abstract notion of "quality" -- and a complex system of
> policies and processes.
>
> This tough work hardens people and gives them a negative bias towards
> change, especially towards process changes that might lead to reduced
> control. They worry (not unreasonably!) that Wikidata does not have this
> community of gate keepers that can fend off the irrational and the
> misguided. They also worry that they themselves may not have enough time to
> take on this task, watching yet another site in addition to what they
> already do in their Wikipedias.
>
> Conversely, people on Wikidata are (not unreasonably!) frustrated when
> being met with the same distrust as the average Internet freak that
> Wikipedians are fighting off on a daily basis, rather than being accepted
> as members of the Wikimedia community who are working towards the same goal.
>
> Considering all this, it is amazing what has been achieved already :-)
>
> Markus
>
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] qwery.me - simpler queries for wikidata

[Thomas Douillard]

Nice :) removing all the boilerplate and using labels, all I could dreamed
of :)

2015-11-11 1:09 GMT+01:00 Paul Sonnentag :

> Hey,
>
> A week ago I started working on a project which tries to make it simpler
> to query wikidata.
> It's still in a very early stage of development but I would like to hear
> your feedback, especially if you haven't used SPARQL, because you found it
> too complicated to get started with.
>
> qwery.me
>
> My approach was it to simplify SPARQL as much as possible without loosing
> too much of its power. Basically you can just write statements and the ids
> are autocompleted. Currently there are still a lot of features missing like
> data literals, filters and group by which i want to implement eventually.
>
> So please tell me, is something like that usefull to you? Is it simple
> enough?
>
> Cheers,
> Paul
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Data model explanation and protection

[Thomas Douillard]

There is a proposal for some kind of class disjointness :
https://www.wikidata.org/wiki/Wikidata:Property_proposal/Generic#subclass
this is here for a while now, maybe a few more supporters would speed up
the process :)

I think a proposal for "DisjointWith" was rejected a long time ago. But
another one could pass.

2015-11-10 13:27 GMT+01:00 Markus Krötzsch :

> On 29.10.2015 05:41, Benjamin Good wrote:
>
>> For what its worth, I tend to agree with Peter here.  It makes sense to
>> me to add constraints akin to 'disjoint with' at the class level.
>>
>
> +1 for having this. This does not preclude to have an additional mechanism
> on the instance level if needed to augment the main thing, but the classes
> are an easier way to start.
>
> This can also help with detecting other issues that are unrelated to
> merging. For instance, nothing should be an event and an airplane at the
> same time.
>
> We need a common approach on how to deal with ambiguous Wikipedia
> articles. One option would be to create an "auxiliary" item that is not
> linked to Wikipedia in such a case, but that is used to represent some
> aspects of the "main" item that would otherwise be incompatible.
>
> Benjamin is right that these issues are not specific to the bio domain.
> It's rather the opposite: the bio domain is one of the domains that is
> advanced enough to notice these problems ...
>
> The
>> problem I see is that we don't exactly have classes here as the term is
>> used elsewhere.  I guess in wikidata, a 'class' is any entity that
>> happens to be used in a subclassOf claim ?
>>
>
> In this case, one can leave this to the user: two items that are specified
> to be disjoint classes are classes.
>
> In the Wikidata Taxonomy Browser, we consider items as classes if one of
> the following is true:
> (1) they have a "subclass of" statement
> (2) they are the target of a "subclass of" statement
> (3) they are the target of an "instance of" statement
>
> We then (mostly) ignore the classes that do not have own instances or own
> subclasses (the "leafs" in the taxonomy), since these are very many:
> * The above criterion leads to over 200,000 class items.
> * Only about 20,000 of them have instances or subclasses.
>
>
>> Another way forward could be to do this using properties rather than
>> classes.  I think this could allow use to use the constraint-checking
>> infrastructure that is already in place?  You could add a constraint on
>> a property that it is 'incompatible with' another property.  In the
>> protein/gene case we could pragmatically use Property:P351 (entrez gene
>> id), incompatible with Property:P352 (uniprot gene id).  More
>> semantically, we could use 'encoded by' incompatible-with 'encodes' or
>> 'genomic start'
>>
>
> I think the constraint checking infrastructure should be able to handle
> both approaches equally well. If "disjoint with" is a statement, one could
> even check this constraint in SPARQL (possibly further restricting to query
> only for constraint violations in a particular domain).
>
> Cheers,
>
> Markus
>
>
>> On Wed, Oct 28, 2015 at 5:08 PM, Peter F. Patel-Schneider
>>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

[Thomas Douillard]

> Blazegraph for example looks like does not
handle them out of the box

As Wikidata is an Open Wiki, I think we can't avoid the query engine having
to deal with cycles from time to times. I can't imagine the Wikidata query
engine having troubles with cycles. It must be robust.

2015-10-24 1:50 GMT+02:00 Stas Malyshev :

> Hi!
>
> > least one Wikipedia) are considered to refer to equivalent classes on
> > Wikidata, which could be expressed by a small subclass-of cycle. For
>
> We can do it, but I'd rather we didn't. The reason is that it would
> require engine that queries such data (e.g. SPARQL engine) to be
> comfortable with cycles in property paths (especially ones with + and
> *), and not every one is (Blazegraph for example looks like does not
> handle them out of the box). It can be dealt with, I assume, but why
> create trouble for ourselves?
>
> > We also have/had cycles involving instance-of, which is definitely an
> > error. ;-)
>
> Right. So I think we need to mark properties that should not form cycles
> with
> https://www.wikidata.org/wiki/Q18647519 (asymmetric property) and have
> constraints checking scripts/bots find out such cases and alert about them.
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Announcing Wikidata Taxonomy Browser (beta)

[Thomas Douillard]

Integration is the purpose of templates like Q' with Reasonator or P' and
Item Documentation
, I don't know if they are actually use. Templates like Query have a
limited success however

2015-10-23 11:16 GMT+02:00 Gerard Meijssen :

> Hoi,
> The problem with tools like this is that they get a moment attention.
> Particularly when they are stand alone, not integrated, they will lose
> interest.
>
> Would it be an option to host this tool on Labs?
> Thanks,
>  GerardM
>
> On 22 October 2015 at 21:27, Markus Kroetzsch <
> markus.kroetz...@tu-dresden.de> wrote:
>
>> On 22.10.2015 19:29, Dario Taraborelli wrote:
>>
>>> I’m constantly getting 500 errors.
>>>
>>>
>> I also observed short outages in the past, and I sometimes had to run a
>> request twice to get an answer. It seems that the hosting on bitbucket is
>> not very reliable. At the moment, this is still a first preview of the tool
>> without everything set up as it should be. The tool should certainly move
>> to Wikimedia labs in the future.
>>
>> Markus
>>
>>
>>
>> --
>> Markus Kroetzsch
>> Faculty of Computer Science
>> Technische Universität Dresden
>> +49 351 463 38486
>> http://korrekt.org/
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

2015-10-19 4:44 GMT+02:00 Emw :

> This problem is especially acute in chemistry on Wikidata, where chemical
> elements use "*instance of *chemical element*" *even though it has been
> established that chemical compounds should not use "*instance of*
> chemical compound" [
>


As we discussed many times, it's natural to model "chemical element" as
"type of substance" or "type of atom" depending on the definintion you
take. But no question elements are either subclass of substance of subclass
of atom however. It's a natural case of metamodeling, similarly to the "car
model" example. And no, using instance of has not be proven to be incorrect
at all.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

Consistency and well foundedness. It's acutally pretty confortable that the
basic object we're classyfing are concrete stuffs. The diary of Ann Franck
as a Work is more an abstract object. This ensure that we always indeed are
trying to class concrete object at the base of the classification system.
Classes and higher order classes are then always at some level : one for
classes as they are collections of concrete objects or events, two for car
models or chemical elements as they are classes of classes of objects or
events, and so on.

This avoids to have some questions to be asked about "will my class will
have instance" "oh shit, in fact we have articles on the concrete objects
after all, what will we do ?"

Let's do be right the first time on the basic principle we uses.
https://www.wikidata.org/wiki/Help:Classification simplifies overall things
because we use a regular and consistent scheme across the vasts domain of
application Wikidata is a database for. Read the "Metaclass" article,
follow the citations of the sources of it, you'll see that this is a widely
accepted scheme actually. For a reason(s) :)

2015-10-19 19:58 GMT+02:00 Stas Malyshev :

> Hi!
>
> > Similarly the "Diary of Anne Frank" is an instance of a memoir or a
> > literary work but is a subclass of book (because there are lots of
> > physical books with that name). Literary works have authors and
> > publishers. Books have numbers of pages and printers and physical
> locations.
>
> I'm not sure I understand this. What is the difference between "instance
> of memoir" and "subclass of book"? You could literally argue with the
> same words that it is also "subclass of memoir" and again since very
> rarely any specific physical book is notable enough (maybe excluding
> things like first Gutenberg Bible, etc.) we would have virtually no
> instances of book at all. I do not think people think that way - if you
> ask somebody is "Diary of Anne Frank" an example of a book or a class I
> think most people would say it's an example of a book and not a class.
> Unless we plan to seek out and record every printed physical copy of
> that book, I don't see any practical reason to describe it as a class.
> This class - and hundreds of thousands of other book titles, maybe with
> rare exceptions of the Gutenberg Bible, etc. - would never have any
> instances. So my question is - what is the use of modeling something as
> a class if there won't be ever any instances of the class modeled?
>
> --
> Stas Malyshev
> smalys...@wikimedia.org
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

Oops, I meant https://www.wikidata.org/wiki/Help:Classification of course.
We made the page translatable even if it's not an accepted policy, at least
it's well founded and solid.

2015-10-17 17:06 GMT+02:00 Gerard Meijssen <gerard.meijs...@gmail.com>:

> Hoi,
> So in order to understand all this and participate it is necessary to
> submit to the FRENCH Wikipedia.. Why not Thai ?
>
> The mind boggles
> Thanks,
>   GerardM
>
> On 17 October 2015 at 16:42, Thomas Douillard <thomas.douill...@gmail.com>
> wrote:
>
>> You're right, I tend to think having a metaclass for types of deaseases
>> would be useful, really.
>>
>> Please submit your suggestions and correction on
>> https://fr.wikipedia.org/w/index.php?search=Help%3AClassification=Sp%C3%A9cial%3ARecherche=Lire
>> :) There is an opened RfC on adopting such basic classification basic
>> principles things as an help page :
>> https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Adopt_Help:Classification_as_an_official_help_page
>>
>> 2015-10-17 16:25 GMT+02:00 Peter F. Patel-Schneider <
>> pfpschnei...@gmail.com>:
>>
>>> On 10/17/2015 12:55 AM, Thomas Douillard wrote:
>>> >> I was a bit surprised to see class reasoning used on diseases.
>>> >
>>> > I was not aware of that, do you have links ?
>>>
>>> See slide 38 of
>>> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial
>>>
>>> >> I was a bit surprised to see class reasoning used on diseases.
>>> >> This depends on a particular modelling methodology.
>>> >
>>> > It's not surprising as the meaning of properties is community defined
>>> (or sub
>>> > community defined) so any community can use reasoning technology they
>>> want to
>>> > use as which is consistent with the intended meaning of properties. As
>>> > Wikidata do only stores statements anyone can use reasoning
>>> technologies on
>>> > top of this that are community accepted. The drawback of this approach
>>> have
>>> > been discussed on another thread some days ago : it could become
>>> tricky to
>>> > understand for a simple user the path that lead to a statement
>>> addition and we
>>> > have to be careful to always provide informations on which bot added
>>> inferred
>>> > statements with that reasoning technology or rule from which data.
>>>
>>> What is the community-defined meaning of subclass of and diseases then?
>>>
>>> Here is what I see in Wikidata.
>>>
>>> https://www.wikidata.org/wiki/Q128581 breast cancer
>>> has a
>>> https://www.wikidata.org/wiki/Property:P279 subclass of
>>> link to both
>>> https://www.wikidata.org/wiki/Q12136 disease
>>> and
>>> https://www.wikidata.org/wiki/Q18556617 thoracic cancer
>>>
>>> https://www.wikidata.org/wiki/Property:P279 subclass of
>>> is linked via
>>> https://www.wikidata.org/wiki/Property:P1628 equivalent property
>>> to
>>> http://www.w3.org/2000/01/rdf-schema#subClassOf
>>> which is the subclass relationship between classes.
>>>
>>> https://www.wikidata.org/wiki/Property:P279 subclass of
>>> has English description
>>> all of these items are instances of those items; this item is a class of
>>> that
>>> item. Not to be confused with Property:P31 (instance of).
>>> which is rather confusing, but appears to be gloss of the RDFS meaning of
>>> http://www.w3.org/2000/01/rdf-schema#subClassOf
>>>
>>> Someone looking at all this is thus lead to believe that
>>> https://www.wikidata.org/wiki/Property:P279 subclass of
>>> is the same as the RDFS meaning of
>>> http://www.w3.org/2000/01/rdf-schema#subClassOf
>>>
>>> So diseases are classes.  They then have instances.  They can be
>>> reasoned with
>>> using techniques borrowed from RDFS.
>>>
>>> This is a particular modelling methodology.  It has its benefits.  It
>>> requires
>>> a certain view of disease and diseases.  The particular instantiation of
>>> this
>>> modelling methodology, where there is a redundant link to the top of the
>>> disease hierarchy and that top loops back to itself, has its own
>>> benefits and
>>> drawbacks.
>>>
>>>
>>> A bigger problem than the one you state, I think, is how outsiders can
>>> determine that this modelling methodology is in place and und

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

Yes, in the pizza example Emw showed, the definition of "food" is
important. If what I ate this morning is a food, then pizza is a subclass
of food. This is consistent with the first sentence of
https://fr.wikipedia.org/wiki/Nourriture of frwiki. And the fact that
"pizza" is an instance of food is a mistake, unfortunately a pretty common
one on Wikidata. We should write a query to find all such examples where an
item is both an instance and a subclass of the same class.

Now pizza is clearly a type of meal it could be relevant in a food
classification and could be very well be an instance of it, as it's a
preparation common people used to put whatever they can put on it,
similarly to https://www.wikidata.org/wiki/Q12486


2015-10-18 18:31 GMT+02:00 Thad Guidry :

> The main problem is that Instance Of is not being used properly sometimes.
> In general, wrong classifications across Wikidata lead to weird assumptions.
>
> Better documentation, and even helper rules to help prevent wrong
> classifications is what is needed and its forthcoming.
>
> Lydia has mentioned that these kinds of problems will eventually become
> less and less as the Roadmap features eventually land into production.
>
> I am looking forward to next year, and the year after, to see the quality
> improve.
>
> Thad
> +ThadGuidry 
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

I tried this to know whether there was items who are both instance of a
subclass of human and intance of human, unfortunately the query timeouts :/
https://query.wikidata.org/#prefix%20wdt%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fprop%2Fdirect%2F%3E%0Aprefix%20entity%3A%20%3Chttp%3A%2F%2Fwww.wikidata.org%2Fentity%2F%3E%0ASELECT%20%3Fitem%20WHERE%20{%0A%20%20%3Fitem%20wdt%3AP31%20%3Fsub0%20.%0A%20%20%3Fsub0%20%28wdt%3AP279%29*%20entity%3AQ5%20.%0A%20%20%3Fitem%20%28wdt%3AP279%29*%20%3Fsub0%20.%0A}

2015-10-18 19:34 GMT+02:00 Thomas Douillard <thomas.douill...@gmail.com>:

> Yes, in the pizza example Emw showed, the definition of "food" is
> important. If what I ate this morning is a food, then pizza is a subclass
> of food. This is consistent with the first sentence of
> https://fr.wikipedia.org/wiki/Nourriture of frwiki. And the fact that
> "pizza" is an instance of food is a mistake, unfortunately a pretty common
> one on Wikidata. We should write a query to find all such examples where an
> item is both an instance and a subclass of the same class.
>
> Now pizza is clearly a type of meal it could be relevant in a food
> classification and could be very well be an instance of it, as it's a
> preparation common people used to put whatever they can put on it,
> similarly to https://www.wikidata.org/wiki/Q12486
>
>
> 2015-10-18 18:31 GMT+02:00 Thad Guidry <thadgui...@gmail.com>:
>
>> The main problem is that Instance Of is not being used properly
>> sometimes. In general, wrong classifications across Wikidata lead to weird
>> assumptions.
>>
>> Better documentation, and even helper rules to help prevent wrong
>> classifications is what is needed and its forthcoming.
>>
>> Lydia has mentioned that these kinds of problems will eventually become
>> less and less as the Roadmap features eventually land into production.
>>
>> I am looking forward to next year, and the year after, to see the quality
>> improve.
>>
>> Thad
>> +ThadGuidry <https://www.google.com/+ThadGuidry>
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] An Ambitious Wikidata Tutorial

[Thomas Douillard]

> I was a bit surprised to see class reasoning used on diseases.

I was not aware of that, do you have links ?

> I was a bit surprised to see class reasoning used on diseases.
This depends on a particular modelling methodology.

It's not surprising as the meaning of properties is community defined (or
sub community defined) so any community can use reasoning technology they
want to use as which is consistent with the intended meaning of properties.
As Wikidata do only stores statements anyone can use reasoning technologies
on top of this that are community accepted. The drawback of this approach
have been discussed on another thread some days ago : it could become
tricky to understand for a simple user the path that lead to a statement
addition and we have to be careful to always provide informations on which
bot added inferred statements with that reasoning technology or rule from
which data.

I however noticed in heated recent debates that some users on frwiki were
sensible to the argument that Wikidata only does store statements. This
kind of users feared that Wikidata would induce an alignment of semantics
of words and items to the enwiki semantic, They believes in the linguistic
hypothesis that words in a language carry some kind of language dependant
meaning on their own and feared some kind of "cultural contagion" by some
kind of mechanism where the specific meaning of english word would
contaminate the french word. It has of course been said many time that
Wikidata was not focused on words and linguistic but on definitions mainly,
and that one definition equals one item, that wikidata was the sum of all
knowledge, but the argument that finally seemed to be effective was the one
that Wikidata do only store statements and do not einforce constraint. It
seems to be effective to convince them that Wikidata is indeed POV agnostic.

2015-10-16 19:14 GMT+02:00 Peter F. Patel-Schneider 
:

> It's very pleasant to hear from someone else who thinks of Wikidata as a
> knowledge base (or at least hopes that Wikidata can be considered as a
> knowledge base).  Did you get any pushback on this or on your stated
> Wikidata
> goal of structuring the sum of all human knowledge?
>
> Did you get any pushback on your section on classification in Wikidata?  It
> seems to me that some of that is rather controversial in the Wikidata
> community.  I was a bit surprised to see class reasoning used on diseases.
> This depends on a particular modelling methodology.
>
> peter
>
>
> On 10/12/2015 11:47 AM, Emw wrote:
> > Hi all,
> >
> > On Saturday, I facilitated a workshop at the U.S. National Archives
> entitled
> > "An Ambitious Wikidata Tutorial" as part of WikiConference USA 2015.
> >
> > Slides are available at:
> > http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial
> >
> https://commons.wikimedia.org/wiki/File:An_Ambitious_Wikidata_Tutorial.pdf
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] diseases as classes in Wikidata - was Re: An Ambitious Wikidata Tutorial

[Thomas Douillard]

You're right, I tend to think having a metaclass for types of deaseases
would be useful, really.

Please submit your suggestions and correction on
https://fr.wikipedia.org/w/index.php?search=Help%3AClassification=Sp%C3%A9cial%3ARecherche=Lire
:) There is an opened RfC on adopting such basic classification basic
principles things as an help page :
https://www.wikidata.org/wiki/Wikidata:Requests_for_comment/Adopt_Help:Classification_as_an_official_help_page

2015-10-17 16:25 GMT+02:00 Peter F. Patel-Schneider <pfpschnei...@gmail.com>
:

> On 10/17/2015 12:55 AM, Thomas Douillard wrote:
> >> I was a bit surprised to see class reasoning used on diseases.
> >
> > I was not aware of that, do you have links ?
>
> See slide 38 of
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial
>
> >> I was a bit surprised to see class reasoning used on diseases.
> >> This depends on a particular modelling methodology.
> >
> > It's not surprising as the meaning of properties is community defined
> (or sub
> > community defined) so any community can use reasoning technology they
> want to
> > use as which is consistent with the intended meaning of properties. As
> > Wikidata do only stores statements anyone can use reasoning technologies
> on
> > top of this that are community accepted. The drawback of this approach
> have
> > been discussed on another thread some days ago : it could become tricky
> to
> > understand for a simple user the path that lead to a statement addition
> and we
> > have to be careful to always provide informations on which bot added
> inferred
> > statements with that reasoning technology or rule from which data.
>
> What is the community-defined meaning of subclass of and diseases then?
>
> Here is what I see in Wikidata.
>
> https://www.wikidata.org/wiki/Q128581 breast cancer
> has a
> https://www.wikidata.org/wiki/Property:P279 subclass of
> link to both
> https://www.wikidata.org/wiki/Q12136 disease
> and
> https://www.wikidata.org/wiki/Q18556617 thoracic cancer
>
> https://www.wikidata.org/wiki/Property:P279 subclass of
> is linked via
> https://www.wikidata.org/wiki/Property:P1628 equivalent property
> to
> http://www.w3.org/2000/01/rdf-schema#subClassOf
> which is the subclass relationship between classes.
>
> https://www.wikidata.org/wiki/Property:P279 subclass of
> has English description
> all of these items are instances of those items; this item is a class of
> that
> item. Not to be confused with Property:P31 (instance of).
> which is rather confusing, but appears to be gloss of the RDFS meaning of
> http://www.w3.org/2000/01/rdf-schema#subClassOf
>
> Someone looking at all this is thus lead to believe that
> https://www.wikidata.org/wiki/Property:P279 subclass of
> is the same as the RDFS meaning of
> http://www.w3.org/2000/01/rdf-schema#subClassOf
>
> So diseases are classes.  They then have instances.  They can be reasoned
> with
> using techniques borrowed from RDFS.
>
> This is a particular modelling methodology.  It has its benefits.  It
> requires
> a certain view of disease and diseases.  The particular instantiation of
> this
> modelling methodology, where there is a redundant link to the top of the
> disease hierarchy and that top loops back to itself, has its own benefits
> and
> drawbacks.
>
>
> A bigger problem than the one you state, I think, is how outsiders can
> determine that this modelling methodology is in place and understand it
> adequately to effectively use the information or to contribute more
> information.  There is nothing on the discussion pages for the various
> diseases that I looked at.
>
>
> The modelling methodology used here is useful in many other places,
> including
> human occupations, creative work genres, cuisines, and sports.   Is
> Wikidata
> uniform in applying this methodology?  If this is not the case, then how is
> the use of this methodology signalled?
>
> > I however noticed in heated recent debates that some users on frwiki were
> > sensible to the argument that Wikidata only does store statements. This
> kind
> > of users feared that Wikidata would induce an alignment of semantics of
> words
> > and items to the enwiki semantic, They believes in the linguistic
> hypothesis
> > that words in a language carry some kind of language dependant meaning on
> > their own and feared some kind of "cultural contagion" by some kind of
> > mechanism where the specific meaning of english word would contaminate
> the
> > french word. It has of course been said many time that Wikidata was not
> > focused on words and linguistic but on definitions 

Re: [Wikidata] An Ambitious Wikidata Tutorial

[Thomas Douillard]

Great that you could make a presentation.

A remark however of what I could read : "instance of" IS NOT transitive.

2015-10-12 20:47 GMT+02:00 Emw :

> Hi all,
>
> On Saturday, I facilitated a workshop at the U.S. National Archives
> entitled "An Ambitious Wikidata Tutorial" as part of WikiConference USA
> 2015.
>
> Slides are available at:
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial
> https://commons.wikimedia.org/wiki/File:An_Ambitious_Wikidata_Tutorial.pdf
>
> The demo of Wikidata's new SPARQL endpoint at https://query.wikidata.org/
> was the most exciting part of the workshop for me, and caught the
> audience's attention too [1].  Stas Malyshev et al., thank you for
> developing Wikidata Query Service -- it's an incredibly awesome tool!
>
> I've added the query we used to the list of examples at
> https://www.mediawiki.org/wiki/Wikibase/Indexing/SPARQL_Query_Examples#Politicians_who_died_of_cancer_.28of_any_type.29
> .
>
> We also:
>
>- Live-edited the item about Nobel laureate Barbara McClintock [2]
>
>- Saw how Wikidata is used in Histropedia [3]
>
>- Discussed *instance of* (P31), *subclass of* (P279), and *part of*
>(P361) and how to avoid "bad smells" [4]
>
>- Learned about the RDF/OWL exports and how to explore them locally
>with Protege [5]
>
>- Talked about modeling causation on Wikidata, in the context of the
>American Civil War [6]
>
>- Covered Wikidata vocabulary, the Wikidata API, where to find things,
>unit quantity properties (e.g. area, length, GDP per capita), etc.
>
> I'd estimate we had 30 to 40 attendees.
>
> Later the same day, Katie (Aude) presented on integrating Wikidata into
> Wikipedia through Lua.  Elvira (Emitraka) also presented on how the Gene
> Wiki project has been enhancing Wikidata with items about genes, items
> about diseases, and their causal connection -- and how the Gene Wiki group
> is working to make corresponding infoboxes on Wikipedia more relevant to
> the layperson.  Both talks were well-attended and excellent.
>
> Cheers,
> Eric
> https://www.wikidata.org/wiki/User:Emw
>
> 1.  SPARQL on Wikidata.  Slides 39 - 43.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#39
>
> 2.  Barbara McClintock live edit.  Slide 18.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#18
>
> 3.  Histropedia.  Slide 22.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#22
>
> 4.  Avoiding bad smells in classification.  Slide 35.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#35
>
> 5.  How to explore Wikidata RDF/OWL dumps locally.  Slides 44 - 48.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#44
> 6.  Causation on Wikidata.  Slides 49 - 51.
> http://www.slideshare.net/_Emw/an-ambitious-wikidata-tutorial#50
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

[Thomas Douillard]

> Some did, I think. :) Anything that doesn't create a recentchanges entry
is "hiding that it happened".

Then I'd say the alternatives are either
1) no inferences at all
2) find a solution for inferences to show up on recent changes on related
items

Of course if we want to have inferences 1 is not really an option :) and if
two is possible, and I don't see why it should not be, then this solves the
(not) hiding problem.

2015-09-29 8:24 GMT+02:00 Federico Leva (Nemo) :

> Peter F. Patel-Schneider, 28/09/2015 22:27:
>
>> >I'm aguing against making such inference part of wikibase/wikidata core
>>> >functionality, and hiding it's working ("magic").
>>> >
>>> >However, I very much hope for a whole ecosystem of tools that apply and
>>> use such
>>> >inference, and make the results obvious to users, both integrated with
>>> >wikidata.org and outside.
>>>
>>
>> Has anyone argued for performing inference and then hiding that it
>> happened?
>>
>
> Some did, I think. :) Anything that doesn't create a recentchanges entry
> is "hiding that it happened".
>
> Nemo
>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

[Thomas Douillard]

No it's not, because of the "undoing" problem. A user can't delete a
statement assuming this will be enough as he will not be explicit that the
statement is bot added and implied by other statements, as opposed as a
statement explicitely inferred by Wikibase and marked explicitely as such
in the UI. If Wikibase tracks the root explicit statements used to make the
inference, they could be exposed in the UI as well to tell the user what he
might have to do to correct the mistake (closer to or) at the actual root.

Actually, instead of making stuffs explicit, it make stuffs hidden into
complex workflows, so imho this goes in the oposite direction to the
intended one.

2015-09-29 10:07 GMT+02:00 Andrew Gray <andrew.g...@dunelm.org.uk>:

> On 29 September 2015 at 08:39, Thomas Douillard <
> thomas.douill...@gmail.com> wrote:
>
>> > Some did, I think. :) Anything that doesn't create a recentchanges
>> entry is "hiding that it happened".
>>
>> Then I'd say the alternatives are either
>> 1) no inferences at all
>> 2) find a solution for inferences to show up on recent changes on related
>> items
>>
>> Of course if we want to have inferences 1 is not really an option :) and
>> if two is possible, and I don't see why it should not be, then this solves
>> the (not) hiding problem.
>>
>
> Isn't option #2 effectively the same (to the end-user) as having someone
> build a bot to fill in all the inferences as soon as one part is created?
> It's just making it faster and more robust...
>
> Andrew.
>
> --
> - Andrew Gray
>   andrew.g...@dunelm.org.uk
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

[Thomas Douillard]

Time available and priorities of the devteam is something entirely
different :)

Just to add a thought and be complete, I must add that we focused the
discussion on bots, but that's missing
that there is not only bots but also manual and semi automated work (with
magnus' tools typically) involved : removing a statement can trigger a
constraint on symmetry, that another will resolve by re-adding the
statement you just removed. This might trigger community issue as well.

2015-09-29 17:01 GMT+02:00 Daniel Kinzler <daniel.kinz...@wikimedia.de>:

> Am 29.09.2015 um 11:05 schrieb Thomas Douillard:
> > No it's not, because of the "undoing" problem. A user can't delete a
> statement
> > assuming this will be enough as he will not be explicit that the
> statement is
> > bot added and implied by other statements, as opposed as a statement
> explicitely
> > inferred by Wikibase and marked explicitely as such in the UI. If
> Wikibase
> > tracks the root explicit statements used to make the inference, they
> could be
> > exposed in the UI as well to tell the user what he might have to do to
> correct
> > the mistake (closer to or) at the actual root.
>
> I agree: if we had built in inference done Just Right (tm), with everything
> editable and visible in all the right places, that would be great. But this
> would add a lot of complexity to the system, and would take a lot of
> resources
> to implement. It would also diverge quite a bit from the classic idea of a
> wiki,
> potentially cause community issues.
>
> The approach using bots was never ideal, but is still hugely successful on
> wikipedia. The same seems to be the case here. Also don't underestimate
> the fact
> that the community has a lot of experience with bots, but is generally very
> skeptical against automatic content (even just including information from
> wikidata on wikipedia pages).
>
> So, while bots are not ideal, and a better solution is conceivable, I
> think bots
> as the optimal solution for the moment. We should not ignore the issues
> that
> exist with bots, and we should not lose sight of other options. But I
> think we
> should focus development on more urgent things, like a better system for
> source
> references, or unit conversion, or better tools for constraints, or for
> re-use
> on wikipedia.
>
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

[Thomas Douillard]

An example that just happened a few minutes ago : I did this kind of edits
because the claims are wrong :
https://www.wikidata.org/w/index.php?title=Q12191=254099391=254099376
I think I already did this in the past. After a chat with Yamaha5, it
appears he added this to complete a symmetric relations, which means if I
just remove the claim in this item they are likely to come back. But it
might be a chain of works : maybe a robot had imported this from some
Wikipedia, then Yamaha completed the symmetric relation. If I remove the
symmetric claims, the robot might reimport them, so ... with or without
inferrences and magic, we will have to trace the origin of the problem to
solve it once and for all.

2015-09-28 16:43 GMT+02:00 Thomas Douillard <thomas.douill...@gmail.com>:

> >
> (*) This follows the principle of "magic is bad, let people edit". Allowing
> inconsistencies means we can detect errors by finding such inconsistencies.
> Automatically enforcing consistency may lead to errors propagating out of
> view
> of the curation process. The QA process on wikis is centered around edits,
> so
> every change should be an edit. Using a bot to fill in missing "reverse"
> links
> follows this idea. The fact that you found an issue with the data because
> you
> saw a bot do an edit is an example of this principle working nicely.
>
> That might prove to become a worser nightmare than the magic one ... It's
> seems like refusing any kind of automation because it might surprise people
> for the sake of exhausting them to let them do a lot of manual work.
>
> 2015-09-28 16:23 GMT+02:00 Daniel Kinzler <daniel.kinz...@wikimedia.de>:
>
>> Am 27.09.2015 um 21:19 schrieb Thad Guidry:
>> > Both Sides ?  Wikidata has a true graph representation like FB ?
>> didn't know
>> > that.  Can you show me the other side your referring too ?
>>
>> "Both sides" probably means that "sister city" is a reflexive property,
>> so if
>> item A refers to item B as a sister city, item B should also refer to
>> item A as
>> a sister city. This is not automatic, and it was a conscious design
>> decision to
>> not make it automatic(*).
>>
>> What do you mean by "true graph representation"? Wikidata internally uses
>> JSON
>> structures to represent items, and items reference each other, forming a
>> graph.
>> We have a linked data interface for traversing the graph[1]. We also have
>> an RDF
>> mapping with a SPARQL endpoint[2] that allows queries against that graph.
>>
>> -- daniel
>>
>>
>> [1]
>> https://www.wikidata.org/wiki/Wikidata:Data_access#Linked_Data_interface
>> [2] https://www.wikidata.org/wiki/Wikidata:Data_access#SPARQL_endpoints
>>
>> (*) This follows the principle of "magic is bad, let people edit".
>> Allowing
>> inconsistencies means we can detect errors by finding such
>> inconsistencies.
>> Automatically enforcing consistency may lead to errors propagating out of
>> view
>> of the curation process. The QA process on wikis is centered around
>> edits, so
>> every change should be an edit. Using a bot to fill in missing "reverse"
>> links
>> follows this idea. The fact that you found an issue with the data because
>> you
>> saw a bot do an edit is an example of this principle working nicely.
>>
>>
>> --
>> Daniel Kinzler
>> Senior Software Developer
>>
>> Wikimedia Deutschland
>> Gesellschaft zur Förderung Freien Wissens e.V.
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Italian Wikipedia imports gone haywire ?

[Thomas Douillard]

Bots are actually much more opaque that could be explicit inference rules
(we don't have the source code of Krbot for example). It seems my problem
originated in lsjbot who created articles on nlwiki, which were imported on
Wikidata, then other statements were created ... this is actually hard to
maintain and the origin of datas is traceable, but not that easily. For the
user, a bot work is as opaque as Wikidata work, if not more opaque as the
Rules could be transparent and Wikibase could provide explanation and trace
itself the origin of datas and of inferences.

2015-09-28 17:12 GMT+02:00 Daniel Kinzler <daniel.kinz...@wikimedia.de>:

> Am 28.09.2015 um 16:43 schrieb Thomas Douillard:
> > Daniel Wrote:
> >> (*) This follows the principle of "magic is bad, let people edit".
> Allowing
> >> inconsistencies means we can detect errors by finding such
> inconsistencies.
> >> Automatically enforcing consistency may lead to errors propagating out
> of view
> >> of the curation process. The QA process on wikis is centered around
> edits, so
> >> every change should be an edit. Using a bot to fill in missing
> "reverse" links
> >> follows this idea. The fact that you found an issue with the data
> because you
> >> saw a bot do an edit is an example of this principle working nicely.
> >
> > That might prove to become a worser nightmare than the magic one ...
> It's seems
> > like refusing any kind of automation because it might surprise people
> for the
> > sake of exhausting them to let them do a lot of manual work.
>
> I'm not arguing against "any" kind of automation. I'm arguing against
> "invisible" automation baked into the backend software. We(*) very much
> encourage "visible" automation under community control like bots and other
> (semi-)automatic import tools like WiDaR.
>
> -- daniel
>
>
> (*) I'm part of the wikidata developer team, not an active member of the
> community. I'm primarily speaking for myself here, from my personal
> experience
> as a wikipedia and common admin. I know from past discussions that "bots
> over
> magic" is considered Best Practice among the dev team, and I believe it's
> also
> the approach preferred by the Wikidata community, but I cannot speak for
> them.
>
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Units are live! \o/

[Thomas Douillard]

On the other hand the users, especially on some specific domains, are
probably the one who knows how the uncertainty data are used and
represented in their field and could give good inputs of what they would
need, both on the UI and on the technical side. With discussion on a
project tracker we may have a big bias on computer-tecchi members on the
community.

2015-09-21 12:40 GMT+02:00 Daniel Kinzler :

> Am 21.09.2015 um 12:08 schrieb Andy Mabbett:
> > Focussing such a discussion in Phabricator is a bad thing
> > .
> > To my mind, discussion of how Wikdiata represents statements should be
> > conducted on Wikidata; Phabricator should be used for discussion of
> > how, in coding terms, to enact the consensus at Wikidata.
>
> As long as we can agree on one place, it's fine with me. I was pointing to
> Phabricator because the discussion about deriving uncertainty intervals
> from the
> dignificant digits of decimal notation has been going on there for some
> weeks
> and months already.
>
> Also, the issue does seem rather technical to me. It's a question of how to
> interpret the decimal (and scientific) notation of measured quantities when
> parsing user input.
>
> --
> Daniel Kinzler
> Senior Software Developer
>
> Wikimedia Deutschland
> Gesellschaft zur Förderung Freien Wissens e.V.
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Fwd: Internationalisation of people names

[Thomas Douillard]

Seems like a must read for
https://www.wikidata.org/wiki/Wikidata:WikiProject_Names :)

2015-09-18 16:09 GMT+02:00 Federico Leva (Nemo) :

> Given the recent discussions on how to deal with person names in Wikidata
> (e.g. how many properties to use, how to handle scripts, automatic vs.
> manual labels/aliases/descriptions...) and the importance username display
> has in MediaWiki (e.g. gendered namespaces, log system restructure since
> 1.19, ...), it may be useful for someone to read this thesis and summarise
> it to our benefit. :)
>
> http://ulir.ul.ie/handle/10344/3450
>
> «If a system does not possess the ability to capture, store, and retrieve
> people names, according to their cultural requirements, it is less likely
> to be acceptable on the international market. Internationalisation of
> people names could reduce the probability of a person’s name being lost in
> a system, avoiding frustration, saving time, and possibly money. This study
> attempts to determine the extent to which the human name can be
> internationalised, based upon published anthroponymic data for 148 locales,
> by categorising them into eleven distinctly autonomous parts: definite
> article, common title, honorific title, nickname, by-name, particle,
> forename, patronymic or matronymic, surname, community name, and
> generational marker. This paper provides an evaluation of the effectiveness
> of internationalising people names; examining the challenges of terminology
> conflicts, the impact of subjectivity whilst pigeonholing personyms, and
> the consequences of decisions made. It has demonstrated that the cultural
> variety of human names can be expressed with the Locale Data Mark-up
> Language for 74% of the world’s countries. This study, which spans 1,919
> anthroponymic syntactic structures, has also established, through the use
> of a unique form of encoding, that the extent to which the human name can
> be internationalised is 96.31% of the data published by Plassard (1996) and
> Interpol (2006). Software developers, localisation engineers, and database
> administrators may benefit from this paper, through recognition of this
> problem and understanding the potential gains from accurately handling
> people names within a system. The outcome of this study opens up
> opportunities for future research into cultural name mapping that may
> further enhance the Common Locale Data Repository.»
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Naming projects

[Thomas Douillard]

I think that we don't have to invoke PC every time we're talking of a not
so happy choice of name.

(I can't help answering but this will be my last message on this topic)
Le 14 sept. 2015 10:53, "Magnus Manske"  a
écrit :

> So I'll name my next tool "George" or "Bush". No wait, he killed even more
> people.
>
> PC has its limits, you know...
>
>
> On Sun, Sep 13, 2015 at 11:23 PM John Erling Blad 
> wrote:
>
>> Please do not name projects "listeria", or use any other names of
>> diseases that has killed people. Thank you for taking this into
>> consideration next time.
>>
>> John
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Naming projects

[Thomas Douillard]

On the other side it's not necessarily a good thing not to be enough ... I
must admit I'm disturbed by this name when I read it. But I like the tool.
We had arguments on whether or not using it on frwiki, I'm surprised this
has not been raised as a bad faith argument against its usage, actually. I
wonder if this could have been an uncountious influencer for community ...
Le 14 sept. 2015 05:48, "Gerard Meijssen"  a
écrit :

> Hoi,
> Sorry but its name is a pun as well as named after a bacterium. I do think
> we can be overly concerned with feelings, it is not necessarily a good
> thing.
> Thanks,
> GerardM
>
> On 14 September 2015 at 00:23, John Erling Blad  wrote:
>
>> Please do not name projects "listeria", or use any other names of
>> diseases that has killed people. Thank you for taking this into
>> consideration next time.
>>
>> John
>>
>> ___
>> Wikidata mailing list
>> Wikidata@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikidata
>>
>>
>
> ___
> Wikidata mailing list
> Wikidata@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikidata
>
>
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Properties for family relationships in Wikidata

[Thomas Douillard]

Another example where things might get complicated is the common office -
head of office problem.

For example in french governments, ministries change all the time in scopes
depending on the president and the prime minister.

We can have one Minister of veterants and of slipper, with it
corresponding minister, that will become minister on slippers and panties
on the next one.

While it's pretty sure there will be a minister of foreign affairs, hence
it's pretty clear that there will be an item for the corresponding minister.

So a contributor can face problems like do I use the construction

* Michel Michu office held: minister of: slippers
* Michel Michu office held: minister of slipper
* Michel Michu office held: minister of: ministry of slipper

Do I create the item for the ministry of slippers ? for the minister as an
office ?

I think inferences could help him by stating all these are more or less a
way to say the same thing, and help the query writing at the same time.


2015-08-17 14:47 GMT+02:00 Markus Kroetzsch markus.kroetz...@tu-dresden.de
:

 Hi Andrew,

 I am very interested in this, especially in the second aspect (how to
 handle symmetry). There are many cases where we have two or more ways to
 say the same thing on Wikidata (symmetric properties are only one case). It
 would be useful to draw these inferences so that they can used for queries
 and maybe also in the UI.

 This can also help to solve some of the other problems you mention: for
 those who would like to have properties son and daughter, one could
 infer their values automatically from other statements, without editors
 having to maintain this data at all.

 A possible way to maintain these statements on wiki would be to use a
 special reference to encode that they have been inferred (and from what).
 This would make it possible to maintain them automatically without the
 problem of human editors ending up wrestling with bots ;-) Moreover, it
 would not require any change in the software on which Wikidata is running.

 For the cases you mentioned, I don't think that there is a problem with
 too many inferred statements. There are surely cases where it would not be
 practical (in the current system) to store inferred data, but family
 relationships are usually not problematic. In fact, they are very useful to
 human readers.

 Of course, the community needs to fully control what is inferred, and this
 has to be done in-wiki. We already have symmetry information in
 constraints, but for useful inference we might have to be stricter. The
 current constraints also cover some not-so-strict cases where exceptions
 are likely (e.g., most people have only one gender, but this is not a
 strong rule; on the other hand, one is always the child of one's mother by
 definition).

 One also has to be careful with qualifiers etc. For example, the start end
 end of a spouse statement should be copied to its symmetric version, but
 there might also be qualifiers that should not be copied like this. I would
 like to work on a proposal for how to specify such things. It would be good
 to coordinate there.

 A first step (even before adding any statement to Wikidata) could be to
 add inferred information to the query services and RDF exports. This will
 make it easier to solve part of the problem first without having too many
 discussions in parallel.

 Best regards,

 Markus



 On 17.08.2015 13:29, Andrew Gray wrote:

 Hi all,

 I've recently been thinking about how we handle family/genealogical
 relationships in Wikidata - this is, potentially, a really valuable
 source of information for researchers to have available in a
 structured form, especially now we're bringing together so many
 biographical databases.

 We currently have the following properties to link people together:

 * spouses (P26) and cohabitants (P451) - not gendered
 * parents (P22/P25) and step-parents (P43/P44) - gendered
 * siblings (P7/P9) - gendered
 * children (P40) - not gendered (and oddly no step-children?)
 * a generic related to (P1038) for more distant relationships

 There's two big things that jump out here.

 ** First, gender. Parents are split by gender while children are not
 (we have mother/father not son/daughter). Siblings are likewise
 gendered, and spouses are not. These are all very early properties -
 does anyone remember how we got this way?

 This makes for some odd results. For example, if we want to using our
 data to identify all the male-line *descendants* of a person, we have
 to do some complicated inference from [P40 + target is male]. However,
 to identify all the male-line *ancestors*, we can just run back up the
 P22 chain. It feels quite strange to have this difference, and I
 wonder if we should standardise one way or the other - split P40 or
 merge the others.

 In some ways, merging seems more elegant. We do have fairly good
 gender metadata (and getting better all the time!), so we can still do
 gender-specific relationship searches 

Re: [Wikidata] Descriptions

[Thomas Douillard]

 I am just one Wikidatan but it would be great if others could also keep
Wikidata in mind while browsing Wikipedia. Can we publish this gadget in
all languages on Wikidata? Maybe we should create a project on Wikidata
called Wikipedia?

I totally agree, people don't really realize yet that Wikidata is not
really another project but another aspect of the same project. An example
is the data quality question (I had to answer this one more time today with
enwiki chemist bot owner), «is data quality of Wikidata enough for
Wikipedia»). The question disappear when you realize data quality of both
projects is essentially the same after the data migration step, and that a
more coordinated effort on local communities means better quality for
everything …

Of course as Wikidata is not full featured yet (chemists needs units for
their numbers) this can mitigate the discourse a lot, but it becomes more
and more credible as development progress.

2015-08-20 9:22 GMT+02:00 Jane Darnell jane...@gmail.com:

 Thanks for your work including ULAN descriptions! I agree they are great.
 As for Monte's earlier response to Magnus's comment about people vs other
 stuff, I think that Monte's sample effort proves how much headway we have
 achieved on person-items and this is excellent to read. I am a big fan of
 enabling the crowd, and have been having fun with Magnus latest gadget that
 shows me the auto-description, which is of course most challenging when
 that is blank (no instance of property). I spent fifteen minutes trying
 on this one and couldn't think of anything better than machine:
 https://en.wikipedia.org/wiki/Banknote_counter

 I am just one Wikidatan but it would be great if others could also keep
 Wikidata in mind while browsing Wikipedia. Can we publish this gadget in
 all languages on Wikidata? Maybe we should create a project on Wikidata
 called Wikipedia?

 On Thu, Aug 20, 2015 at 8:59 AM, Vladimir Alexiev 
 vladimir.alex...@ontotext.com wrote:

  The case is made often that descriptions as they exist are evil. They
 are atrocious
  Why do we not get rid of all that rubbish. [and replace with]
  Automated descriptions … can easily be improved upon in two ways ..

 I agree in general, except for items that don’t have much data, e.g.
 person’s life years,
 (Or have too much data that can’t be selected easily, e.g. 10 occupations
 but only 1 is really notable).
 For people: I mostly copy the description from Getty ULAN: that’s very
 good, even if the life years are unknown (thus set too wide, or missing).

 So my point is, there should also be an algorithm to decide whether to
 replace the manual description.

 Why people invest time in writing “rubbish”: because there’s no worse
 description than a missing description.
 Most everything should have an EN description, to allow a user to
 understand what that is, esp in an auto-complete list.
 Even a very bad description usually allows that.



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



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


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

Re: [Wikidata] Descriptions

[Thomas Douillard]

I also started a lua module on frwiki in the same spirit for on wiki
without gadgets description generation:
https://fr.wikipedia.org/wiki/Module:Description . It's used in the Lien
Wikidata template, but it's unclear wether or not Wikipedians in frwiki
will catch the bait :)
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

 No we should not make the aliases unique, the reason aliases are
useful is because they are _not_ unique.

They are still usefil if they are not unique because search is fuzzy : if
you search “whatever” you'll see both “wathever one” AND “whatever2” in the
results …


2015-07-13 16:01 GMT+02:00 John Erling Blad jeb...@gmail.com:

 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
 daniel.kinz...@wikimedia.de 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@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikidata

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

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

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

Hehe, to be fair with this argument you would have to provide a concensus
that people want aliases in templates :) That's also probably five people
on a bugtracker :)

2015-07-13 17:38 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de:

 Am 13.07.2015 um 17:22 schrieb Gerard Meijssen:
  Hoi,
  Either you accept the consensus or you don't.

 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.

  Hiding behind Lydia is not graceful.

 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.

  How often is it necessary to indicate that you CAN show localised
 names as
  long as they are the labels used in Wikidata and as long as they come
 witha text
  we have the needed functionality.

 Sure, for display, that's fine. For widgets on wikidata, too.
 We were dicussing readability of wikitext, though.

  It is just not the solution you have been looking for is it.. BUT it does
  satisfy our and Lydia's needs. Wonderful right?

 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@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikidata

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

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

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 lydia.pintsc...@wikimedia.de a
écrit :

 On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL innovi...@gmail.com
 wrote:
  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

 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

 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@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikidata

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

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

Yep  /o\ Getting used to my new phone

Not a problem was corrected into our problem in French, which is pretty
bad.
 Le 10 juil. 2015 17:56, Ricordisamoa ricordisa...@openmailbox.org a
écrit :

  OT: French spelling checker?

 Il 10/07/2015 16:56, Thomas Douillard ha scritto:


 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 lydia.pintsc...@wikimedia.de
 a écrit :

 On Fri, Jul 10, 2015 at 12:00 AM, Innovimax SARL innovi...@gmail.com
 wrote:
  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

 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

 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@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikidata



 ___
 Wikidata mailing 
 listWikidata@lists.wikimedia.orghttps://lists.wikimedia.org/mailman/listinfo/wikidata



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


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

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

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.

If the label is ambiguous and cannot be substituted, then instead of subst
with a Pid, it may also possible to substitute with an error span
explaining it's ambiguous and suggesting the alternative properties ...

2015-07-08 16:52 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de:

 Am 08.07.2015 um 16:43 schrieb Thad Guidry:
  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 ?

 That's not a feature request, that's how it is designewd to work, and has
 been
 working for a long time. The change under discussion is allowing aliases
 here,
 in addition to labels.

 --
 Daniel Kinzler
 Senior Software Developer

 Wikimedia Deutschland
 Gesellschaft zur Förderung Freien Wissens e.V.

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

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

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

2015-07-08 17:34 GMT+02:00 Daniel Kinzler daniel.kinz...@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.
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] property label/alias uniqueness

[Thomas Douillard]

 The idea was readability and internationalization.

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

2015-07-08 22:00 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de:

 Am 08.07.2015 um 18:45 schrieb Thomas Douillard:
  2015-07-08 17:34 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de
  mailto:daniel.kinz...@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.

 Not if the old name is kept as an alias. Which seems the easier and more
 streight forward solution to me.

  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.

 Splitting will always be a problem. Some usages will end up having the
 wrong
 P-id or name or label or alias or whatever.

  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.

 The idea was readability and internationalization.

 If there is consensus to not use human readable property names for
 accessing
 data, and solely rely on IDs instead, we could indeed stop all this right
 now,
 and just drop the uniqueness constraint for labels as well as for aliases
 of
 properties.

 You are right that changing the name of a property shouldn't be as easy as
 it
 currently is. There should at least be a warning.


 --
 Daniel Kinzler
 Senior Software Developer

 Wikimedia Deutschland
 Gesellschaft zur Förderung Freien Wissens e.V.

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

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

Re: [Wikidata] New Wikidata maps

[Thomas Douillard]

What impress me is that we see france pretty well in nearly all the maps
... It's the only contry that is on so much maps. Is this a bug or is
France the real center of the world ?

2015-06-25 21:07 GMT+02:00 Info WorldUniversity 
i...@worlduniversityandschool.org:

 Markus,

 Great and thanks!

 Cheers,
 Info (Scott)


 On Thu, Jun 25, 2015 at 6:31 AM, Markus Kroetzsch 
 markus.kroetz...@tu-dresden.de wrote:

 Hi all,

 inspired by the recent works of Adam, I have now recreated the Wikidata
 maps that Denny made some years ago:

 https://ddll.inf.tu-dresden.de/web/Wikidata/Maps-06-2015/en

 There are some interesting observations to be made there, and in any case
 the images are quite pretty.

 The code is available online as one of the Wikidata Toolkit examples [1]
 for anyone who wants to create more/different maps. Building all of the
 maps takes about half an hour on my laptop, once the dump is downloaded.

 Cheers,

 Markus

 [1]
 https://github.com/Wikidata/Wikidata-Toolkit/tree/master/wdtk-examples

 --
 Markus Kroetzsch
 Faculty of Computer Science
 Technische Universität Dresden
 +49 351 463 38486
 http://korrekt.org/

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




 --

 - Scott MacLeod - Founder  President

 - http://worlduniversityandschool.org

 - 415 480 4577

 - PO Box 442, (86 Ridgecrest Road), Canyon, CA 94516

 - World University and School - like Wikipedia with best STEM-centric
 OpenCourseWare - incorporated as a nonprofit university and school in
 California, and is a U.S. 501 (c) (3) tax-exempt educational organization,
 both effective April 2010.


 World University and School is sending you this because of your interest
 in free, online, higher education. If you don't want to receive these,
 please reply with 'unsubscribe' in the body of the email, leaving the
 subject line intact. Thank you.

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


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

Re: [Wikidata] Lists of things as entities in Wikidata

[Thomas Douillard]

We can create as many specialized classes as we want. That lists are more
specific than classes is not a fatality.

I think having a list about instances of a concept proves the concept is
useful, so that the class is something that could exists. Moreother if we
manually mark an item as an instance of such a class, in only one statement
we add a lot of informations and maybe a few properties could be
automatically added by a bot.

2015-06-15 18:09 GMT+02:00 Romaine Wiki romaine.w...@gmail.com:

 Also the list entity has a function. The function of *instance of* is to
 identify what a page is about. A database is built on consistency, the list
 entity does do that for lists. A list is a very special type of a subject
 in comparison to other articles. It isn't linked through topic type
 properties. By using a list entity this kind of items are identified as
 such. Likewise for dps, categories, templates, etc.

 Romaine

 2015-06-15 17:53 GMT+02:00 Benjamin Good ben.mcgee.g...@gmail.com:

 This is an important question.  There are apparently 196,839 known list
 items based on a query for instanceOf Wikipedia list item
 (CLAIM[31:13406463])

 http://tools.wmflabs.org/autolist/autolist1.html?q=CLAIM%5B31%3A13406463%5D

 I tend to agree with Thad that these kinds of items aren't really what we
 want filling in WikiData.  In fact replacing them with the ability to
 generate them automatically based on queries is a primary use case for
 wikidata.  But just deleting them doesn't entirely make sense either
 because they are key signposts into things that ought to be brought into
 wikidata properly.  The items in these lists clearly matter..

 Ideally we could generate a bot that would examine each of these lists
 and identify the unifying properties that should be added to the items
 within the list that would enable the list to be reproduced by a query.

 I disagree that this reasoning suggests deleting items about categories
 and disambiguation pages. - both of these clearly have functions in
 wikidata.  I'm not sure what the function of a list entity is.


 On Mon, Jun 15, 2015 at 8:47 AM, Federico Leva (Nemo) nemow...@gmail.com
  wrote:

 By this reasoning we should also delete items about categories or
 disambiguation pages.

 Thad Guidry, 15/06/2015 17:21:

 Ex. List of tallest buildings in Wuhan -
 https://www.wikidata.org/wiki/Q6642364


 What's the issue here? The item doesn't actually contain any list, there
 is no duplication or information clumped together.

 Nemo


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



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



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


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

Re: [Wikidata] weekly summary #159

[Thomas Douillard]

I think we should have items and use Wikidata ! (Hem, here is where I get
flamed /o\)

2015-05-27 15:44 GMT+02:00 Magnus Manske magnusman...@googlemail.com:



 On Wed, May 27, 2015 at 2:40 PM Lydia Pintscher 
 lydia.pintsc...@wikimedia.de wrote:

 On Wed, May 27, 2015 at 3:38 PM, Magnus Manske
 magnusman...@googlemail.com wrote:
  Actually they can. All it needs is a little JSON file somewhere on the
 web
  that has one or multiple entries. Manual is on the directory page.

 Uh nice. Then maybe the best way is to get rid of the external
 tools page and replace it with a link to the directory?


 I *think* we could even host the JSON in a [[Wikidata:]] page, and add the
 URL as ?title=XYZaction=raw. Didn't try though.




 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@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikidata


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


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

Re: [Wikidata-l] Wikidata for Wiktionary

[Thomas Douillard]

I don't get this, is this really a technical issue or just an interface one
? It can be pretty clear to users that the semantic entity pages are very
different from lexical entities in the same instance just by tweaking the
UI. Or with separate instances this can be confusing as well if not well
done.

Is this a community issue ? Different project, different communities,
different site ? I really don't like it as it tends to make several groups
who can have difficulties to talk to each other and go on the other site. I
think as Wikidata community is already constituted and tends to try to grow
and advocate for the project, considering its central situation in the
ecosystem and that community tends to learn how to make interproject social
links, it would be beneficial imho to continue to grow and to learn from
here. There is strong connections between words and senses.

I think in that global scheme, one or several instance is a mostly
technical detail that is not really important and that both solutions can
accommodate to distinct (or not) pages or distinct (or not) communities.

2015-05-08 11:15 GMT+02:00 Bene* benestar.wikime...@gmail.com:

 Hi

  I do not think a separate Wikibase instance would be needed to provide
 the data for Wiktionary. I think this can and should be done on Wikidata.
 But as said by Milos and pointed out by Gerard, lexical knowledge does
 indeed require a different data schema. This is why the proposal introduces
 new entity types for lexemes, forms, and senses. The data model is mostly
 based on lexical ontologies that we surveyed, like LEMON and others.


 I think a separate Wikibase installation would be much better than adding
 lexical knowledge on Wikidata. Wikidata is about things in the first place
 and Wiktionary is about words etc. So having a Wikibase installation only
 for Wiktionary makes more sense in my opinion as that is the same plan we
 currently have for Commons/Wikiquote etc. It would still be connected to
 Wikidata in ways like accepting items from Wikidata as values in statements
 and having access to their data. However, we should separate lexical
 knowledge and Wikidata also wiki-wise.

 Best regards,
 Bene


 ___
 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

[Thomas Douillard]

Yes, that's what they are for, but wikidata is far from beeing complete,
and if there is no label in your language, showing next to the original
name a transliteration in your language could prove useful. I can very well
imagine situations where it is unclear on how to say a Chinese name, for
example. Putting a label in french can somewhat be a hard task, for example.


2015-05-01 11:04 GMT+02:00 Bene* benestar.wikime...@gmail.com:

  Hi,

 this is what the monolingual text datatype is for. The labels however are
 multilingual and should provide users in all languages an idea how the name
 is said.

 Best regards
 Bene


 Am 01.05.2015 um 07:14 schrieb Gerard Meijssen:

 Hoi,
 It is still a bad idea. An official name exists only in one language.
 Thanks,
  GerardM

 On 30 April 2015 at 18:50, Thomas Douillard thomas.douill...@gmail.com
 wrote:

  I meant add automatically the transliteration, not replace the name.

  This is a good candidate : we know for sure the source and the target
 language (the one of the user) so a good choice for transliteration method
 is always possible, and we don't pretend it should be the way to say orally
 the name in the target language. It's just a transliteration of the
 official name.



 2015-04-30 15:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

   Hoi,
  It does not quality anything. It is plain wrong.
  Thanks,
   GerardM

 On 30 April 2015 at 15:06, Joe Filceolaire filceola...@gmail.com
 wrote:

 Exactly. The official name  property always has the name in the
 original script. But we can and should have the transliteration in a
 qualifier.

 Joe
   On 30 Apr 2015 06:13, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

   Hoi,
  We transliterate every name from one script to the other.
 Transliteration the official name is exactly the one you should not
 transliterate.. What is left after transliteration is not official.
  Thanks,
GerardM

 On 29 April 2015 at 18:54, Thomas Douillard 
 thomas.douill...@gmail.com wrote:

  It's always possible to transliterate the official name
 https://www.wikidata.org/wiki/Property:P1448property. Of course
 this should be done by a gadget, or we may have to find a special 
 treatment
 for the ''name'' properties.

 2015-04-28 23:06 GMT+02:00 Joe Filceolaire filceola...@gmail.com:

 I agree up to a point. Transliteration is not appropriate for labels
 for all items.  There are however a few categories of items for which
 transliterated labels are appropriate. For example :
 * English labels for villages and towns
 * English labels for people
 *English labels for bands and albums
 I'm sure there are  others that could use this too.

 Joe
   On 27 Apr 2015 18:09, Leon Liesener leon.liese...@wikipedia.de
 wrote:

 The problem with ISO is that it's a standard for
 language-independent
 transliteration to Latin script. Since labels on Wikidata are
 language-dependent, making use of ISO does not make sense really. If
 you use ISO for Russian names in Cyrillic script, the label you get
 is
 not in English. It's still in Russian but transliterated to Latin
 script. ISO thus would only fit as an alias for the Russian
 interface
 language, if at all.

 2015-04-26 22:39 GMT+02:00 Gerard Meijssen 
 gerard.meijs...@gmail.com:
  Hoi,
  grin ISO is a reliable source; it is THE standard /grin
 Wikipedia is
  definitely not a standard by its own admission.
  Thanks,
  GerardM
 
  On 26 April 2015 at 22:37, Yaroslav M. Blanter pute...@mccme.ru
 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



 ___
 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

[Thomas Douillard]

I'll all with you, on this, unfortunately only a few people reads IPA
currently :(. I don't, for example.

2015-05-02 15:19 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 When the point is to express how an official name is to be pronounced, IPA
 is in order not a text in another script.
 Thanks,
  GerardM

 On 1 May 2015 at 11:04, Bene* benestar.wikime...@gmail.com wrote:

  Hi,

 this is what the monolingual text datatype is for. The labels however are
 multilingual and should provide users in all languages an idea how the name
 is said.

 Best regards
 Bene


 Am 01.05.2015 um 07:14 schrieb Gerard Meijssen:

 Hoi,
 It is still a bad idea. An official name exists only in one language.
 Thanks,
  GerardM

 On 30 April 2015 at 18:50, Thomas Douillard thomas.douill...@gmail.com
 wrote:

  I meant add automatically the transliteration, not replace the name.

  This is a good candidate : we know for sure the source and the target
 language (the one of the user) so a good choice for transliteration method
 is always possible, and we don't pretend it should be the way to say orally
 the name in the target language. It's just a transliteration of the
 official name.



 2015-04-30 15:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

   Hoi,
  It does not quality anything. It is plain wrong.
  Thanks,
   GerardM

 On 30 April 2015 at 15:06, Joe Filceolaire filceola...@gmail.com
 wrote:

 Exactly. The official name  property always has the name in the
 original script. But we can and should have the transliteration in a
 qualifier.

 Joe
   On 30 Apr 2015 06:13, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

   Hoi,
  We transliterate every name from one script to the other.
 Transliteration the official name is exactly the one you should not
 transliterate.. What is left after transliteration is not official.
  Thanks,
GerardM

 On 29 April 2015 at 18:54, Thomas Douillard 
 thomas.douill...@gmail.com wrote:

  It's always possible to transliterate the official name
 https://www.wikidata.org/wiki/Property:P1448property. Of course
 this should be done by a gadget, or we may have to find a special 
 treatment
 for the ''name'' properties.

 2015-04-28 23:06 GMT+02:00 Joe Filceolaire filceola...@gmail.com:

 I agree up to a point. Transliteration is not appropriate for
 labels for all items.  There are however a few categories of items for
 which transliterated labels are appropriate. For example :
 * English labels for villages and towns
 * English labels for people
 *English labels for bands and albums
 I'm sure there are  others that could use this too.

 Joe
   On 27 Apr 2015 18:09, Leon Liesener leon.liese...@wikipedia.de
 wrote:

 The problem with ISO is that it's a standard for
 language-independent
 transliteration to Latin script. Since labels on Wikidata are
 language-dependent, making use of ISO does not make sense really.
 If
 you use ISO for Russian names in Cyrillic script, the label you
 get is
 not in English. It's still in Russian but transliterated to Latin
 script. ISO thus would only fit as an alias for the Russian
 interface
 language, if at all.

 2015-04-26 22:39 GMT+02:00 Gerard Meijssen 
 gerard.meijs...@gmail.com:
  Hoi,
  grin ISO is a reliable source; it is THE standard /grin
 Wikipedia is
  definitely not a standard by its own admission.
  Thanks,
  GerardM
 
  On 26 April 2015 at 22:37, Yaroslav M. Blanter pute...@mccme.ru
 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



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



 ___
 Wikidata

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

[Thomas Douillard]

I think it would be nice if the *official name* property could have a
special treatment in the UI. Something like the way you plan to sort out
ids out of the rest of the statements :) But I have no idea.

It's an important things, the name the local people gives to a place or a
thing, it may be on road signs for example. It's kind of the Main Name.

2015-05-02 11:54 GMT+02:00 Daniel Kinzler daniel.kinz...@wikimedia.de:

 Am 02.05.2015 um 11:32 schrieb Thomas Douillard:
  Yes, that's what they are for, but wikidata is far from beeing complete,
 and if
  there is no label in your language, showing next to the original name a
  transliteration in your language could prove useful. I can very well
 imagine
  situations where it is unclear on how to say a Chinese name, for example.
  Putting a label in french can somewhat be a hard task, for example.

 Automatic transliteration is already implemented and used. You will notice
 if
 you set your user language to sr-el for instance (Serbian using latin
 alphabet).
 However:

 * Transliteration is currently only supported between a handful of language
 variants, like the different scripts for Serbian, and various variants of
 Chinese.

 * Transliteration (and language fallback in general) is only applied inside
 statements, not for editable labels, descriptions and aliases at the top
 of the
 page. It's unclear hoe language fallback should interact with editing.

 * Transliteration (and language fallback in general) may not work
 correctly in
 qualifiers and references at the moment.

 So, the general mechanism is already there, the question is just how to
 improve
 an apply it. It seems to me that we could use transliteration support for
 more
 languages, and that we should figure out a way to apply it to the main
 label
 and description shown at the top of the page.


 --
 Daniel Kinzler
 Senior Software Developer

 Wikimedia Deutschland
 Gesellschaft zur Förderung Freien Wissens e.V.

 ___
 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

[Thomas Douillard]

...

I did not say automatically translate into my on language everybody should
speak as I'm the only True One in the Universe and everybody should bow and
learn and pray I'll treat them well and talk in my own language otherwise
bad things will happen,

I said transliterate in the main users language, the same reason we
translate the UI,, the help pages, the Wikipedia articles and so on.

2015-05-01 16:40 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 A name in a script that does not make sense to you is a standard to what?
 Do not put yourself at the centre of the galaxy... It is a few years ago,
 that it was proven earth did not centre the sun and the sun is only a spec
 in our galaxy.
 Thanks,
  GerardM

 On 1 May 2015 at 11:00, Thomas Douillard thomas.douill...@gmail.com
 wrote:

 An official name in an alphabet I don't understand does not give me any
 useful information, not even an idea of how it is said.

 It may be the only information we have for sur of some item. I say it's a
 good idea to give the official name in the original language together with
 a transliteration in the user language. I don't understand how it could be
 a bad idea.

 2015-05-01 7:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 It is still a bad idea. An official name exists only in one language.
 Thanks,
  GerardM

 On 30 April 2015 at 18:50, Thomas Douillard thomas.douill...@gmail.com
 wrote:

 I meant add automatically the transliteration, not replace the name.

 This is a good candidate : we know for sure the source and the target
 language (the one of the user) so a good choice for transliteration method
 is always possible, and we don't pretend it should be the way to say orally
 the name in the target language. It's just a transliteration of the
 official name.



 2015-04-30 15:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 It does not quality anything. It is plain wrong.
 Thanks,
  GerardM

 On 30 April 2015 at 15:06, Joe Filceolaire filceola...@gmail.com
 wrote:

 Exactly. The official name  property always has the name in the
 original script. But we can and should have the transliteration in a
 qualifier.

 Joe
 On 30 Apr 2015 06:13, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

 Hoi,
 We transliterate every name from one script to the other.
 Transliteration the official name is exactly the one you should not
 transliterate.. What is left after transliteration is not official.
 Thanks,
   GerardM

 On 29 April 2015 at 18:54, Thomas Douillard 
 thomas.douill...@gmail.com wrote:

 It's always possible to transliterate the official name
 https://www.wikidata.org/wiki/Property:P1448property. Of course
 this should be done by a gadget, or we may have to find a special 
 treatment
 for the ''name'' properties.

 2015-04-28 23:06 GMT+02:00 Joe Filceolaire filceola...@gmail.com:

 I agree up to a point. Transliteration is not appropriate for
 labels for all items.  There are however a few categories of items for
 which transliterated labels are appropriate. For example :
 * English labels for villages and towns
 * English labels for people
 *English labels for bands and albums
 I'm sure there are  others that could use this too.

 Joe
 On 27 Apr 2015 18:09, Leon Liesener leon.liese...@wikipedia.de
 wrote:

 The problem with ISO is that it's a standard for
 language-independent
 transliteration to Latin script. Since labels on Wikidata are
 language-dependent, making use of ISO does not make sense really.
 If
 you use ISO for Russian names in Cyrillic script, the label you
 get is
 not in English. It's still in Russian but transliterated to Latin
 script. ISO thus would only fit as an alias for the Russian
 interface
 language, if at all.

 2015-04-26 22:39 GMT+02:00 Gerard Meijssen 
 gerard.meijs...@gmail.com:
  Hoi,
  grin ISO is a reliable source; it is THE standard /grin
 Wikipedia is
  definitely not a standard by its own admission.
  Thanks,
  GerardM
 
  On 26 April 2015 at 22:37, Yaroslav M. Blanter 
 pute...@mccme.ru 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

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

[Thomas Douillard]

I can't add more than I already did, I think, so I'll rest my case. A part
of the work in Wikidata is building the database and guessing what could be
unidentified items there only is informations in a language we don't
understand or an alphabet we can't read. And there is no label in our
language, and we want to put some. In that case, any information is useful.
Or we plan a trip in the country in question and we want to have an idea of
how to say the name in the language, or ...
___
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

[Thomas Douillard]

You really don't read what I write or is it me who speaks so badly I can't
make myself understood ? I'm beginning to wonder ... :)

2015-05-01 19:47 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 You rest your case Fine. You do not address the point that an official
 name is exactly that. It is the name as used by authorities. Typically it
 is what is used in registers, in passports. You do not have those for your
 convenience in any language. It does not matter what you can read or not.
 What matters is that you can accept is that it is not about you and your
 understanding. For this it is not relevant.

 When you want to make a trip to another country you look for the label for
 your item.
 Thanks,
  GerardM

 On 1 May 2015 at 19:19, Thomas Douillard thomas.douill...@gmail.com
 wrote:

 I can't add more than I already did, I think, so I'll rest my case. A
 part of the work in Wikidata is building the database and guessing what
 could be unidentified items there only is informations in a language we
 don't understand or an alphabet we can't read. And there is no label in our
 language, and we want to put some. In that case, any information is useful.
 Or we plan a trip in the country in question and we want to have an idea of
 how to say the name in the language, or ...

 ___
 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

[Thomas Douillard]

An official name in an alphabet I don't understand does not give me any
useful information, not even an idea of how it is said.

It may be the only information we have for sur of some item. I say it's a
good idea to give the official name in the original language together with
a transliteration in the user language. I don't understand how it could be
a bad idea.

2015-05-01 7:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 It is still a bad idea. An official name exists only in one language.
 Thanks,
  GerardM

 On 30 April 2015 at 18:50, Thomas Douillard thomas.douill...@gmail.com
 wrote:

 I meant add automatically the transliteration, not replace the name.

 This is a good candidate : we know for sure the source and the target
 language (the one of the user) so a good choice for transliteration method
 is always possible, and we don't pretend it should be the way to say orally
 the name in the target language. It's just a transliteration of the
 official name.



 2015-04-30 15:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 It does not quality anything. It is plain wrong.
 Thanks,
  GerardM

 On 30 April 2015 at 15:06, Joe Filceolaire filceola...@gmail.com
 wrote:

 Exactly. The official name  property always has the name in the
 original script. But we can and should have the transliteration in a
 qualifier.

 Joe
 On 30 Apr 2015 06:13, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

 Hoi,
 We transliterate every name from one script to the other.
 Transliteration the official name is exactly the one you should not
 transliterate.. What is left after transliteration is not official.
 Thanks,
   GerardM

 On 29 April 2015 at 18:54, Thomas Douillard 
 thomas.douill...@gmail.com wrote:

 It's always possible to transliterate the official name
 https://www.wikidata.org/wiki/Property:P1448property. Of course
 this should be done by a gadget, or we may have to find a special 
 treatment
 for the ''name'' properties.

 2015-04-28 23:06 GMT+02:00 Joe Filceolaire filceola...@gmail.com:

 I agree up to a point. Transliteration is not appropriate for labels
 for all items.  There are however a few categories of items for which
 transliterated labels are appropriate. For example :
 * English labels for villages and towns
 * English labels for people
 *English labels for bands and albums
 I'm sure there are  others that could use this too.

 Joe
 On 27 Apr 2015 18:09, Leon Liesener leon.liese...@wikipedia.de
 wrote:

 The problem with ISO is that it's a standard for
 language-independent
 transliteration to Latin script. Since labels on Wikidata are
 language-dependent, making use of ISO does not make sense really. If
 you use ISO for Russian names in Cyrillic script, the label you get
 is
 not in English. It's still in Russian but transliterated to Latin
 script. ISO thus would only fit as an alias for the Russian
 interface
 language, if at all.

 2015-04-26 22:39 GMT+02:00 Gerard Meijssen 
 gerard.meijs...@gmail.com:
  Hoi,
  grin ISO is a reliable source; it is THE standard /grin
 Wikipedia is
  definitely not a standard by its own admission.
  Thanks,
  GerardM
 
  On 26 April 2015 at 22:37, Yaroslav M. Blanter pute...@mccme.ru
 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



 ___
 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

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

[Thomas Douillard]

I meant add automatically the transliteration, not replace the name.

This is a good candidate : we know for sure the source and the target
language (the one of the user) so a good choice for transliteration method
is always possible, and we don't pretend it should be the way to say orally
the name in the target language. It's just a transliteration of the
official name.



2015-04-30 15:14 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com:

 Hoi,
 It does not quality anything. It is plain wrong.
 Thanks,
  GerardM

 On 30 April 2015 at 15:06, Joe Filceolaire filceola...@gmail.com wrote:

 Exactly. The official name  property always has the name in the
 original script. But we can and should have the transliteration in a
 qualifier.

 Joe
 On 30 Apr 2015 06:13, Gerard Meijssen gerard.meijs...@gmail.com
 wrote:

 Hoi,
 We transliterate every name from one script to the other.
 Transliteration the official name is exactly the one you should not
 transliterate.. What is left after transliteration is not official.
 Thanks,
   GerardM

 On 29 April 2015 at 18:54, Thomas Douillard thomas.douill...@gmail.com
 wrote:

 It's always possible to transliterate the official name
 https://www.wikidata.org/wiki/Property:P1448property. Of course this
 should be done by a gadget, or we may have to find a special treatment for
 the ''name'' properties.

 2015-04-28 23:06 GMT+02:00 Joe Filceolaire filceola...@gmail.com:

 I agree up to a point. Transliteration is not appropriate for labels
 for all items.  There are however a few categories of items for which
 transliterated labels are appropriate. For example :
 * English labels for villages and towns
 * English labels for people
 *English labels for bands and albums
 I'm sure there are  others that could use this too.

 Joe
 On 27 Apr 2015 18:09, Leon Liesener leon.liese...@wikipedia.de
 wrote:

 The problem with ISO is that it's a standard for language-independent
 transliteration to Latin script. Since labels on Wikidata are
 language-dependent, making use of ISO does not make sense really. If
 you use ISO for Russian names in Cyrillic script, the label you get is
 not in English. It's still in Russian but transliterated to Latin
 script. ISO thus would only fit as an alias for the Russian interface
 language, if at all.

 2015-04-26 22:39 GMT+02:00 Gerard Meijssen gerard.meijs...@gmail.com
 :
  Hoi,
  grin ISO is a reliable source; it is THE standard /grin
 Wikipedia is
  definitely not a standard by its own admission.
  Thanks,
  GerardM
 
  On 26 April 2015 at 22:37, Yaroslav M. Blanter pute...@mccme.ru
 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



 ___
 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


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

Re: [Wikidata-l] Number of planets in the solar system

[Thomas Douillard]

It may not be practical, but it is still possible ;) classes like
''astronomic corp that was thought to be a planet in 1850'' are an option
:)

2015-04-30 13:51 GMT+02:00 Andrew Gray andrew.g...@dunelm.org.uk:

 On 30 April 2015 at 12:37, Thomas Douillard thomas.douill...@gmail.com
 wrote:
  Infovarius even complicated the problem, he put the number of known
  planets at some time with a qualifier for validity :)

 Just to throw a real spanner in the works: for a lot of the nineteenth
 century the number varied widely. The eighth planet was discovered
 in 1801, and is what we'd now think of as the asteroid or dwarf planet
 Ceres; the real eighth planet, Neptune, wasn't discovered until
 1851.

 Newly discovered asteroids were thought of as 'planets' for some time
 (I have an 1843 schoolbook somewhere that confidently tells children
 there were eleven planets...) until by about 1850, it became clear
 that having twenty or so very small planets with more discovered every
 year was confusing, and the meaning of the word shifted. There was no
 formal agreement (as was the case in 2006) so no specific end date.

 The moral of this story is probably that trying to express complex
 things in Wikidata is not always practical :-)

 --
 - Andrew Gray
   andrew.g...@dunelm.org.uk

 ___
 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] Number of planets in the solar system

[Thomas Douillard]

Actually, like it is, there is no *number of planets* property, there is a
class of planet (solar system planet) together with a *number of instances*
property. This might save us : we can have two item :
* solar system planet (old style definition) and
* solar system planet (new style definition)
 This might just put the problem in another place though :) although this
might not change the correctness of statements like *solar system*  has
part *solar system planet* (old style) :)


Pluto can still be an old style definition planet, and maybe solar system
planet
 is a subclass of *solar system planet* (old style)

Thinking about it, classes are naturally a good way to deal with
definitions.

2015-04-29 19:35 GMT+02:00 Markus Krötzsch mar...@semantic-mediawiki.org:

 Hi,

 General case first: Many statements depend on time and have an end date
 (e.g., population numbers). The general approach there is to (1) have a
 qualifier that clarifies the restricted temporal validity and (2) make the
 current statement preferred. So your idea with the ranks was a good
 starting point, but it should be normal and preferred instead of
 deprecated and normal. And infovarius was also right in this sense to
 use a temporal quantifier. Note that more than one statement can be
 preferred if more than one is current (this could be relevant, e.g., for
 the classes that Pluto is/was an instance of).


 However, this answer is only about the general pattern of dealing with
 things that changed over time, and the intended use of ranks in this case.
 Things might be different here. It's a special case in that it was not so
 much the world that changed but the definition, so the real question is
 what our property number of planets really means:

 (1) Number of planets at a given time (given as a qualifier), based on
 the definition of planet adopted at this time
 (2) Number of planets according to the definition that was used when the
 property was introduced
 (3) Number of planets according to the definition that is current right
 now

 (3) is problematic since it means that the meaning of the property would
 change over time, and statements that were true will become false. I would
 strongly discourage this. But both (1) and (2) are possible. If one wants
 to use (1) then *every* statement with this property must have some time
 qualifier -- otherwise it will not make any sense since one would not know
 which definition is meant.

 In case (2), the number of planets of our solar system is 8, and nothing
 else. It has never been 9 *according to the definition of planet used by
 this property*. So if this interpretation is adopted, then the statement
 with value 9 should really at best be there in a deprecated form, not in a
 temporal form. It could make sense to keep a deprecated form to warn other
 users that this should not be reintroduced.

 One could also add more options, e.g., one could have a qualifier that
 specifies the definition of planet that is used. This would be a bit like
 (1) but instead of time one would now always need to specify a definition,
 and the statements would not be temporal at all (the number would always
 remain 9 according to the old definition). One could still use preferred
 to mark the statement that is based on the most common definition.

 The world is beautifully complicated, isn't it? I'll leave it to you
 experts to discuss what makes sense here here :-)

 Best regards,

 Markus


 On 29.04.2015 18:05, Thomas Douillard wrote:

 Hi, a small question about qualifiers and ranks.

 It is well known that the number of planets changed in 2006. Or did it ?
 Of course, Pluto is still here, it's just its status that changed. The
 definition of planets changed in 2006.

 This imply that (imho), the statement  the number of planets in the
 solar system in 9 should be deprecated. But infovarius did not agree
 with me and changed the rank of the claim back to normal and put an end
 date. I still think it should be deprecated, but it raise me a question:
 How are we supposed (if we are) to express an information about a
 deprecation ? Should we include something about the deprecation in the
 sources ? Should we have a qualifier ''deprecation date'' ?

 https://www.wikidata.org/wiki/Q17362350


 ___
 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] Number of planets in the solar system

[Thomas Douillard]

Hi, a small question about qualifiers and ranks.

It is well known that the number of planets changed in 2006. Or did it ? Of
course, Pluto is still here, it's just its status that changed. The
definition of planets changed in 2006.

This imply that (imho), the statement  the number of planets in the solar
system in 9 should be deprecated. But infovarius did not agree with me and
changed the rank of the claim back to normal and put an end date. I still
think it should be deprecated, but it raise me a question: How are we
supposed (if we are) to express an information about a deprecation ? Should
we include something about the deprecation in the sources ? Should we have
a qualifier ''deprecation date'' ?

https://www.wikidata.org/wiki/Q17362350
___
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 smalys...@wikimedia.org:

 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] 176k items matched to OSM (Re: OpenStreetMap + Wikidata)

[Thomas Douillard]

There is Wikidata The Game for this :) Semi automatic tool with a community
around ...

2015-04-23 16:22 GMT+02:00 Edward Betts edw...@4angle.com:

 James Heald j.he...@ucl.ac.uk wrote:
  The post last autumn said you had 176,000 items matched to OSM, a very
 large
  proportion of which (at least at that time) had no P31 instance of, but
  you had been able to deduce this from Wikipedia.
 
  Would it be possible to start loading Wikidata with that information --
 ie
  complete the P31's that were missing?

 The code that generates the mappings uses Wikipedia categories, and it
 makes
 some mistakes. Take beaches for example:

 http://edwardbetts.com/osm-wikidata/2015-04-18/match_results/Beaches.html

 Some of the Wikidata items are about a beach, some about a settlement next
 to
 a beach. All of them are in within a beaches category on Wikipedia. It
 would
 be wrong to say that a settle with a beach is an instance of a beach.

 For this reason it probably doesn't make sense to add 'instance of'
 statements
 automatically.
 --
 Edward.

 ___
 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] items about data model concepts

[Thomas Douillard]

OK, I did not think it might confuse users, the label needs to be changed.

It's of course not intended to use in statements which have no value, it's
just an attempt to express wikibase data model in Wikidata.
https://www.wikidata.org/wiki/Q16354757 is not Wikibase Data model :)

I changed the label to ensure users would not confuse the items with
 the real values ...

2015-04-22 21:52 GMT+02:00 Markus Krötzsch mar...@semantic-mediawiki.org:

 Hi Thomas,

 On 22.04.2015 20:06, Thomas Douillard wrote:

 Hi, there is items about Wikibase data model in Wikidata (created by me,
 but not only)

 If I understand correctly, they could be cited in the semantic web as
 https://www.wikidata.org/entity/Q19798647


 No value is exactly that: not a value. It should not be confused with a
 (definite) value that is used with claims (as the item description seems to
 suggest). The reason why we introduced no value was to be able to say
 this without resorting to a special value to represent this.

 You can also find some rationale about this in our article Wikidata: a
 free collaborative knowledgebase (see
 https://ddll.inf.tu-dresden.de/web/Article4002/en). Basically, the main
 point is that, if you are querying for two people with a common child, you
 wouldn't want to get pairs of people who both have novalue as a value for
 child. The same is true for some value (sometimes referred to as
 unknown value) -- again, if this would be a definite special value, and
 be treated like a value in queries, it would lead to wrong results.

 Cheers,

 Markus


 (If they are kept /o\)

 Tom²


 ___
 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] items about data model concepts

[Thomas Douillard]

Hehe, we should picture this idea in help page :)
https://www.wikidata.org/entity/Q1061035
https://www.wikidata.org/wiki/Q1061035 is not a pipe.

2015-04-23 9:50 GMT+02:00 Stas Malyshev smalys...@wikimedia.org:

 Hi!

  OK, I did not think it might confuse users, the label needs to be
 changed.

 Yes, I think it should made clear that it should not be used for actual
 values.

  It's of course not intended to use in statements which have no value,
  it's just an attempt to express wikibase data model in Wikidata.
  https://www.wikidata.org/wiki/Q16354757 is not Wikibase Data model :)

 Which reminds me of https://www.wikidata.org/wiki/Q1061035 ...

 --
 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] items about data model concepts

[Thomas Douillard]

Don't use Q19798647 The item is just a description of the concept ! on
Wikidata, there is a way to set an unknow value to a claim.

here is how to set this special value on a claim in the UI, in french : to
https://commons.wikimedia.org/wiki/File:Wikidata_pas_de_valeur.png

You must click to the little blue icon on the left of the label.

2015-04-23 11:46 GMT+02:00 Jane Darnell jane...@gmail.com:

 So the intention is to use Q19798647 as a random place holder specifically
 for Wikibase entities without a value, but not as a no value placeholder
 for a person? I think it is useful in the way you describe it, but I am
 curious how you would model the source B saying that X had no child

 On Thu, Apr 23, 2015 at 11:37 AM, Lydia Pintscher 
 lydia.pintsc...@wikimedia.de wrote:

 On Thu, Apr 23, 2015 at 11:33 AM, Gerard Meijssen
 gerard.meijs...@gmail.com wrote:
  Hoi,
  Sorry for being dense.. What is wrong with there being no value ?
 Having a
  no value is imho understanding only a complication of saying
 nothing...
  Why not say nothing in the first place ?

 It is important for cases like the following for example: Source A
 says X had a child and source B says X had no child.


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