Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

[Tobias Schönberg]

@James
As you mention yourself using ranks is a very limiting approach, and I
think that we shouldn't modify the data to help the queries, but try to
make the queries more intelligent. - Once confliciting, and time-dependent
statements are added to each item, the return values of simple queries will
be huge lists, or chunks of the data-tree. - So I think even the infoboxes
have to make some decisions on how they wan't to deal with the complexity,
and those decisions might not be the same in every language community. - I
also think we need to communicate this more that something like "Mayor of
Barcelona" might get 1 results now, but is actually bad-practice and in
Wikidata's future will likely return 100s of values.

-Tobias

2015-11-27 15:58 GMT+01:00 James Heald :

> Some items have quite a lot of "instance of" statements, connecting them
> to quite a few different classes.
>
> For example, Frankfurt is currently an instance of seven different classes,
> https://www.wikidata.org/wiki/Q1794
>
> and Glasgow is currently an instance of five different classes:
> https://www.wikidata.org/wiki/Q4093
>
> This can produce quite a pile-up of descriptions in the
> description/subtitle section of an infobox -- for example, as on the
> Spanish page for Frankfurt at
> https://es.wikipedia.org/wiki/Fr%C3%A1ncfort_del_Meno
> in the section between the infobox title and the picture.
>
>
> Question:
>
> Is it an appropriate use of ranking, to choose a few of the values to
> display, and set those values to be "preferred rank" ?
>
> It would be useful to have wider input, as to whether it is a good thing
> as to whether this is done widely.
>
> Discussions are open at
>
> https://www.wikidata.org/wiki/Wikidata:Project_chat#Preferred_and_normal_rank
> and
> https://www.wikidata.org/wiki/Wikidata:Bistro#Rang_pr.C3.A9f.C3.A9r.C3.A9
>
> -- but these have so far been inconclusive, and have got slightly taken
> over by questions such as
>
> * how well terms really do map from one language to another --
> near-equivalences that may be near enough for sitelinks may be jarring or
> insufficient when presented boldly up-front in an infobox.
>
> (For example, the French translation "ville" is rather unspecific, and
> perhaps inadequate in what it conveys, compared to "city" in English or
> "ciudad" in Spanish; "town" in English (which might have over 100,000
> inhabitants) doesn't necessarily match "bourg" in French or "Kleinstadt" in
> German).
>
> * whether different-language wikis may seek different degrees of
> generalisation or specificity in such sub-title areas, depending on how
> "close" the subject is to that wiki.
>
> (For readers in some languages, some fine distinctions may be highly
> relevant and familiar, whereas for other language groups that level of
> detail may be undesirably obscure).
>
>
> There is also the question of the effect of promoting some values to
> "preferred rank" for the visibility of other values in SPARQL -- in
> particular when so queries are written assuming they can get away with
> using just the simple "truthy" wdt:... form of properties.
>
> However, making eg the value "city" preferred for Glasgow means that it
> will no longer be returned in searches for its other values, if these have
> been written using "wdt:..." -- so it will now be missed in a simple-level
> query for "council areas", the current top-level administrative
> subdivisions of Scotland, or for historically-based "registration counties"
> -- and this problem will become more pronounced if the practice becomes
> more widespread of making some values "preferred" (and so other values
> invisible, at least for queries using wdt:...).
>
> From a SPARQL point of view, what would actually be very helpful would to
> add a (new) fourth rank -- "misleading without qualifier", below "normal"
> but above "deprecated" -- for statements that *are* true (with the
> qualifiers), but could be misleading without them
> * for example, for a town that was the county town of a shire once, but
> hasn't been for two centuries
> * or for an administrative area that is partly located in one higher-level
> division, and partly in another -- this is very valuable information to be
> able to note, but it's important to be able to exclude it from being all
> included in a recursive search for the places in one (but not the other) of
> that higher-level division.
>
> The statements shouldn't be marked "deprecated", because they are true
> (unlike a widely-given but incorrect date of birth, for example).  At the
> moment one can sort of work round the issue, if one can find another
> statement to make "preferred", so that the qualified statement becomes
> invisible to a simple search without qualifiers.  However, if "preferred"
> status is going to be used just to select things to show in infoboxes, it
> becomes very desirable that "wdt:..." searches should retrieve things at
> normal rank as well -- creating a need for a new rank for statement

Re: [Wikidata] Preferred rank -- choices for infoboxes, versus SPARQL

[Tobias Schönberg]

@Markus, James:
In my opinion it is better to make the query ask for the most recent
population number. People just need to start using time-qualifiers for
things like census-report numbers.

And the other issue is one of standardized vocabulary and that is always a
sourcing problem in my opinion. A query could say "get the
instance-of-statement" that has a supporting source from the Spanish
Geographic Society. Then the infobox would only include standardized
vocabulary by that organization. But I aknowledge that large parts of the
world are not covered by standardized vocabulary organizations.

If that doesn't solve it we could at least think about language specific
rank-overrides.

-Tobias


2015-11-27 16:41 GMT+01:00 Markus Krötzsch :

> Hi James,
>
> I would immediately agree to the following measures to alleviate your
> problem:
>
> (1) If some instance-of statements are historic (i.e., no longer valid),
> then one should make the current ones "preferred" and leave the historic
> ones "normal", just like for, e.g., population numbers. This would get rid
> of the rather inappropriate "Free imperial city" label for Frankfurt.
>
> (2) If some classes are redundant, they could be removed (e.g., if we
> already have "Big city" we do not need "city"). However, community might
> decide to prefer the direct use of a main class (such as "Human"), even if
> redundant.
>
> The other issues you mention are more tricky. Especially issues of
> translation/cultural specificity. The most specific classes are not always
> the ones that all languages would want to see, e.g., if the concept of the
> class is not known in that language.
>
> Possible options for solving your problem:
>
> * Make a whitelist of classes you want to show at all in the template, and
> default to "city" if none of them occurs.
> * Make a blacklist of classes you want to hide.
> * Instead of blacklist or whitelist, show only classes that have a
> Wikipedia page in your language; default to "city" if there are none.
> * Try to generalise overly specific classes (change "big city" to "city"
> etc.). I don't know if there is a good programmatic approach for this, or
> if you would have to make a substitution list or something, which would not
> be very maintainable.
> * Do not use instance-of information like this in the infobox. It might
> sound radical, but I am not sure if "instance of" is really working very
> well for labelling things in the way you expect. Instance-of can refer to
> many orthogonal properties of an object, in essentially random order, while
> a label should probably focus on certain aspects only.
>
> For obvious reasons, ranks of statements cannot be used to record
> language-specific preferences.
>
> Cheers,
>
> Markus
>
>
> On 27.11.2015 15:58, James Heald wrote:
>
>> Some items have quite a lot of "instance of" statements, connecting them
>> to quite a few different classes.
>>
>> For example, Frankfurt is currently an instance of seven different
>> classes,
>>  https://www.wikidata.org/wiki/Q1794
>>
>> and Glasgow is currently an instance of five different classes:
>>  https://www.wikidata.org/wiki/Q4093
>>
>> This can produce quite a pile-up of descriptions in the
>> description/subtitle section of an infobox -- for example, as on the
>> Spanish page for Frankfurt at
>>  https://es.wikipedia.org/wiki/Fr%C3%A1ncfort_del_Meno
>> in the section between the infobox title and the picture.
>>
>>
>> Question:
>>
>> Is it an appropriate use of ranking, to choose a few of the values to
>> display, and set those values to be "preferred rank" ?
>>
>> It would be useful to have wider input, as to whether it is a good thing
>> as to whether this is done widely.
>>
>> Discussions are open at
>>
>> https://www.wikidata.org/wiki/Wikidata:Project_chat#Preferred_and_normal_rank
>>
>> and
>> https://www.wikidata.org/wiki/Wikidata:Bistro#Rang_pr.C3.A9f.C3.A9r.C3.A9
>>
>> -- but these have so far been inconclusive, and have got slightly taken
>> over by questions such as
>>
>> * how well terms really do map from one language to another --
>> near-equivalences that may be near enough for sitelinks may be jarring
>> or insufficient when presented boldly up-front in an infobox.
>>
>> (For example, the French translation "ville" is rather unspecific, and
>> perhaps inadequate in what it conveys, compared to "city" in English or
>> "ciudad" in Spanish; "town" in English (which might have over 100,000
>> inhabitants) doesn't necessarily match "bourg" in French or "Kleinstadt"
>> in German).
>>
>> * whether different-language wikis may seek different degrees of
>> generalisation or specificity in such sub-title areas, depending on how
>> "close" the subject is to that wiki.
>>
>> (For readers in some languages, some fine distinctions may be highly
>> relevant and familiar, whereas for other language groups that level of
>> detail may be undesirably obscure).
>>
>>
>> There is also the question of the effect of promoting some values to
>

[Wikidata] Wikimania submission deadline approaching

[Tobias Schönberg]

Hi all!

Friendly reminder: Please visit this page and submit your discussions,
posters, or training session before the 20th March 2016:

https://wikimania2016.wikimedia.org/wiki/Submissions

-Tobias

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

Re: [Wikidata] Wikidata property for items about software

[Tobias Schönberg]

@Loic

You might have already found the answer, but you can request for an
item to be deleted here:

https://www.wikidata.org/wiki/Wikidata:Requests_for_deletions

I don't know if we have any good automatically updating tables of
properties, but there is at least an attempt to curate the software
properties here:

https://www.wikidata.org/wiki/Wikidata:WikiProject_Informatics

-Tobias

2016-07-13 15:54 GMT+02:00 Loic Dachary :
> Hi,
>
> I created "Wikidata property for items about software" 
> https://www.wikidata.org/wiki/Q25857383 modeled after "Wikidata property for 
> items about works" https://www.wikidata.org/wiki/Q18618644. It is my 
> understanding that it will automagically display all properties that are an 
> instance of "Wikidata property for items about software" in the "Software" 
> part (which does not exist yet) of 
> https://www.wikidata.org/wiki/Wikidata:List_of_properties/all
>
> There also is an existing "Wikidata property for software" 
> https://www.wikidata.org/wiki/Q21126229 which seems identical but worded 
> slightly differently. I realize creating a new item with an identical purpose 
> was a mistake but I don't know how to remove this new item. And I don't 
> understand why properties that are instance of "Wikidata property for 
> software" do not show in 
> https://www.wikidata.org/wiki/Wikidata:List_of_properties/all.
>
> I would very much appreciate any advice you may have on this topic :-)
>
> Cheers
>
> --
> Loïc Dachary, Artisan Logiciel Libre
>
> ___
> 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] wikiconvention & wikidata: thanks and a bug report

[Tobias Schönberg]

Hi Loic!

That is of course unfortunate that it didn't work as planned. Maybe if we
can get more people signed up for Wikiprojects it would make it easier to
get more specialised sessions organised. Or even plan separate events.
Especially for free software it might also make sense to have a workshop
and booth at open source conferences. The data from Wikidata could be very
useful for example to the freedesktop initiative, so there would be a lot
of synergies.

-tobias

Am 21.08.2016 7:07 nachm. schrieb "Loic Dachary" :

> Hi,
>
> A short mail to report a bug in the organization of the wikidata workshop
> held today during the wikiconvention in Paris[1]. Weeks in advance I
> convinced a few people to attend so that we can work on our topic of
> interest: Software and Free Software in particular[2]. There is no better
> context than being surrounded by seasoned wikidata contributors to improve
> and contribute at the same time. The description was appealing:
>
> "After a one hour training, we will create groups according to the desire
> of the participants: contribute, discover and install useful gadgets..."
>
> When the audience was asked for their preferences, I raised my hand and
> happily declared "Contributing to the Software and FLOSS projects !". Much
> to my surprise this was quickly dismissed: "we're only going to learn about
> tools, we create groups to use and learn about tools, not to work on a
> specific project". My interest for the Software project is known to both
> Harmonia Amanda and Ash_Crow, to the extent that I discussed with them my
> intent to recruit people to participate in the workshop for that particular
> topic[3], well in advance. The focus of our interest was also made clear in
> the participant list[4].
>
> Of course the rebuttal was not enough to discourage us from contributing
> to wikidata :-) We found another room and did useful work together, just
> without the pleasure of being part of the group.
>
> When facing such a minor disappointment, I suppose there is not much cause
> for concern. But I thought it would be useful to report what appears to be
> a glitch in the organization so that it can be fixed. This is not a
> pleasant thing to write or read, but what would be life without a few
> mistakes ?
>
> In conclusion I would like to thank everyone for a wonderful first
> experience, specially Harmonia Amanda and Ash_Crow who do a tremendous work
> with wikidata.
>
> Cheers
>
> [1] https://meta.wikimedia.org/wiki/WikiConvention_
> francophone/2016/Programme/Atelier_de_formation_%C3%A0_Wikidata
> [2] https://www.wikidata.org/wiki/Wikidata:WikiProject_
> Informatics/Software https://www.wikidata.org/wiki/Wikidata:WikiProject_
> Informatics/FLOSS
> [3] 15 july 2016  Ash_Crow: pour https://meta.wikimedia.org/
> wiki/WikiConvention_francophone/2016/Programme/
> Atelier_de_formation_%C3%A0_Wikidata nous serons au moins trois avec pour
> centre d'intérêt https://www.wikidata.org/wiki/Wikidata:WikiProject_
> Informatics/FLOSS et https://www.wikidata.org/wiki/Wikidata:WikiProject_
> Informatics/Software . J'espère convaincre deux autres personnes mais
> c'est pas gagné ... l'attrait des vacances...
> [4] https://meta.wikimedia.org/wiki/WikiConvention_
> francophone/2016/Programme/Atelier_de_formation_%C3%A0_
> Wikidata#Participants_int.C3.A9ress.C3.A9s_.28inscrivez-
> vous_ci-dessous_et_posez_d.C3.A8s_.C3.A0_pr.C3.A9sent_vos_
> questions_.C3.A0_l.27organisateur_de_la_session.29
> --
> Loïc Dachary, Artisan Logiciel Libre
>
> ___
> 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] wikiconvention & wikidata: thanks and a bug report

[Tobias Schönberg]

The informatics Wikiproject was started to combine software and hardware in
one project. That was mainly done because of the low number of participants
and to avoid dispersing the discussions on too many pages. I am very happy
that Loic is putting so much work into software and I think that
Wikiproject Software could just move up in the namespace (as opposed to
being a subpage of Informatics).

I hope we can have more discussions on the WikiProject pages in general,
because they are a vital part of how the community works and interacts.

-Tobias

2016-08-26 14:58 GMT+02:00 Jane Darnell :

> Great, and thanks for your work! I suggest not placing the project behind
> a link like "Informatics" but just make a basic project for "Software"
> though. Someone else can go create a project for "Computers" and the
> Informatics page can be updated accordingly. The easiest thing would be to
> start copying some of the stuff from the old English Wikiprojects
> directory. They may be largely unused, but those pages can still be reused
> to build basic how-to-model pages on Wikidata.
>
> On Fri, Aug 26, 2016 at 8:25 AM, Loic Dachary  wrote:
>
>> Hi Jane,
>>
>> On 26/08/2016 14:01, Jane Darnell wrote:
>> > Hi Loic,
>> > I recently noticed that the history of software is severely
>> underrepresented on Wikidata and there is very little interlinking going on
>> at all, while many items are missing P31. I do think it would be useful to
>> create a Wikidata: page to list the various types of
>> software (OS, languages, development environments) and model how to use
>> properties to flesh out such items. I suspect there are several properties
>> that need to be created, such as "Principal developer" or something like
>> that.
>>
>> You're right ! That's what https://www.wikidata.org/wiki/
>> Wikidata:WikiProject_Informatics/FLOSS and https://www.wikidata.org/wiki/
>> Wikidata:WikiProject_Informatics/Software are about, but it's quite
>> recent.
>>
>> > I agree however that for a low-threshold Wikidata meetup, the most
>> important thing is to share basic gadgets and knowledge, because there is
>> so much still to be done on outreach in all languages. I noticed for
>> example that Listeria was blocked on Portuguese Wikipedia due to objections
>> in the labelling showing up in list headers. This shows how the basic
>> interface is still such a mystery to so many communities, probably because
>> the basic interface is still so incomplete in those languages.
>>
>> That makes perfect sense. My bug report was not about the scope of the
>> workshop. It was more about the contradiction between the workshop
>> description and what happened, the way communication was handled overall
>> and the fact that it lead to a situation that is counterproductive and
>> generally unpleasant for the people involved. It's easy to fix and I'm sure
>> things will be better next time :-)
>>
>> Cheers
>>
>> > Jane
>> >
>> > On Fri, Aug 26, 2016 at 7:27 AM, Loic Dachary > > wrote:
>> >
>> > Hi Sylvain,
>> >
>> > On 26/08/2016 11:43, Sylvain Boissel wrote:
>> > >
>> > >
>> > > 2016-08-21 19:06 GMT+02:00 Loic Dachary >   l...@dachary.org>>>:
>> > >
>> > > When the audience was asked for their preferences, I raised
>> my hand and happily declared "Contributing to the Software and FLOSS
>> projects !". Much to my surprise this was quickly dismissed: "we're only
>> going to learn about tools, we create groups to use and learn about tools,
>> not to work on a specific project". My interest for the Software project is
>> known to both Harmonia Amanda and Ash_Crow, to the extent that I discussed
>> with them my intent to recruit people to participate in the workshop for
>> that particular topic[3], well in advance.
>> > >
>> > > And I answered you weeks ago that I plan to organize a fully
>> dedicated workshop on this topic later this year, involving local free
>> software organizations like Parinux or Framasoft.
>> >
>> > I remember that, excellent initiative :-) I'm not sure how it
>> explains what happened during the wikiconvention though.
>> >
>> > I was connected to #wikidata-fr today and read a conversation on
>> this topic, involving you and Harmonia Amanda (which I will not quote here
>> because I assume this is not a good behavior to quote from channels that
>> are not logged). The general tone was unfriendly and made me feel unwanted
>> as a contributor. It also made me realize that my efforts to bring more
>> French people / organizations to wikidata were mocked and unappreciated.
>> >
>> > As a volunteer I value good relationships even more than technical
>> contributions. For this reason I will distance myself from the wikidata
>> French community. I hope to return in the future when a more welcoming
>> context has been established.
>> >
>> > Cheers
>> >
>> > --
>> > Loïc Dachary, Artisan Logiciel Libre
>> >
>> 

[Wikidata] Query fails with hy labels

[Tobias Schönberg]

This query does not work with Armenian labels, but works with en. Is that a
bug?

https://query.wikidata.org/#%23%20Given%20names%20of%20all%20people%20born%20in%20Armenia%2C%20on%20Wikidata%0A%23defaultView%3ABubbleChart%0ASELECT%20%3FgivenName%20%3FgivenNameLabel%20%3Fcount%0AWHERE%0A%7B%0A%20%20%7B%0A%20%20%20%20SELECT%20%3FgivenName%20%28count%28%3Fitem%29%20as%20%3Fcount%29%0A%20%20%20%20WHERE%20%7B%0A%20%20%20%20%20%20%3Fitem%20wdt%3AP19%20%3Fplace%20.%0A%20%20%20%20%20%20%3Fplace%20wdt%3AP17%20wd%3AQ399%20.%0A%20%20%20%20%20%20%3Fitem%20wdt%3AP735%20%3FgivenName%20.%0A%20%20%20%20%7D%0A%20%20%20%20GROUP%20BY%20%3FgivenName%0A%20%20%7D%0A%20%20SERVICE%20wikibase%3Alabel%20%7B%20bd%3AserviceParam%20wikibase%3Alanguage%20%22hy%22%20%7D%0A%7D%0AORDER%20BY%20DESC%28%3Fcount%29
___
Wikidata mailing list
Wikidata@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata

Re: [Wikidata] Query fails with hy labels

[Tobias Schönberg]

Thank you both! Tonight I tried again and now it works.

2016-09-01 8:23 GMT+02:00 Bináris :

>
>
> 2016-09-01 7:38 GMT+02:00 Tobias Schönberg :
>
>> This query does not work with Armenian labels, but works with en. Is that
>> a bug?
>>
>
> Works fine for me. Firefox, Win7. Have you tried in different browsers?
>
> ___
> 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] Languages in Wikidata4Wiktionary

[Tobias Schönberg]

An example using the second suggestion:

If I would like to query all L-items that contain a combination of letters
and limit those results by getting the Q-items of the language and limit
those, to those that have Latin influences.

In my imagination this would work better using the second suggestion. Also
the flexibility of "what is a language" and "what is a dialect" would seem
easier if we can attach statements to the UserLanguageCode or the Q-item of
the language.

-Tobias

2017-04-06 18:51 GMT+02:00 Denny Vrandečić :

> The current spec of the data model states that an L-Item has a lemma, a
> language, and several forms, and the forms in turn have representations.
>
> https://www.mediawiki.org/wiki/Extension:WikibaseLexeme/Data_Model
>
> The language is a Q-Item, the lemma and the representations are
> Multilingual Texts. Multilingual texts are sets of pairs of strings and
> UserLanguageCodes.
>
> My question is about the relation between representing a language as a
> Q-Item and as a UserLanguageCode.
>
> A previous proposal treated lemmas and representations as raw strings,
> with the language pointing to the Q-Item being the only language
> information. This now is gone, and the lemma and representation carry their
> own language information.
>
> How do they interact? The language set referencable through Q-Items is
> much larger than the set of languages with a UserLanguageCode, and indeed,
> the intention was to allow for every language to be representable in
> Wikidata, not only those with a UserLanguageCode.
>
> I sense quite a problem here.
>
> I see two possible ways to resolve this:
> - return to the original model and use strings instead of Multilingual
> texts (with all the negative implications for variants)
> - use Q-Items instead of UserLanguageCodes for Multilingual texts (which
> would be quite a migration)
>
> I don't think restricting Wiktionary4Wikidata support to the list of
> languages with a UserLanguageCode is a viable solution, which would happen
> if we implement the data model as currently suggested, if I understand it
> correctly.
>
> Cheers,
> Denny
>
>
> ___
> 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