It seems to me that a whitelist is the preferred solution to the problem of
displaying too many classes that an item belongs to.  Any blacklist solution
is going to need revision as new classes are added to Wikidata.  Any
preference data is going to have problems with different languages and
cultures.  Any solution based on specificity is going to have problems with
classes like big city Q1549591.  Any solution that solely depends on whether
the class has a language-specific Wikipedia page also will have problems with
big city.

It may be that in many cases a combination of a whitelist that is not
language/culture specific combined with only showing classes that have a
language-specific Wikipedia page will work well enough.



peter



On 11/27/2015 07:41 AM, Markus Krötzsch wrote:
> Hi James,
[...]

> 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
>> "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 statements which are true, but misleading if read without qualifiers.
>>
>>
>> What *is* needed though, is a view on whether trying to tailor what is
>> shown in infoboxes is an appropriate reason to alter statement rankings.
>>
>> It would be good to get a view on this.
>>
>> The Spanish guys who stated doing this have temporarily put further
>> rank-changes on hold, for the issue to be discussed; but so far what
>> they have done has only just scratched the surface of what could be done
>> -- there are still a lot more cases of multiple values they would like
>> to tidy.
>>
>> So: is this the kind of thing that "preferred rank" is envisaged for ?
>>
>> Or, should some statements not be marked as less preferred than others,
>> if this is the only reason ?
>>
>>
>>     --  James.
>>
>>
>> _______________________________________________
>> 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