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_ran... 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.
@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 j.heald@ucl.ac.uk:
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_ran... 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
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_ran...
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
@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 markus@semantic-mediawiki.org:
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_ran...
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
On 27.11.2015 17:05, Tobias Schönberg wrote:
@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.
Unfortunately, this is not sufficient for census number selections, since the most recent number might be less accurate than another somewhat-recent number, which is therefore considered "preferred". I have no idea how to come up with a reasonable SPARQL query to evaluate this situation.
Similarly, ignoring the instance-of statements that are historic if other statements may have no times associated whatsoever, and picking the most recent instance-of statement if all of them have times associated would require an amount of computation that you really don't want to encode in SPARQL. Feel free to prove me wrong by posting the SPARQL query here, but I think it won't be feasible. SPARQL is not a programming language to implement arbitrarily complex selection rules in. The current rank-based system, in spite of its necessary limitations, is in fact highly effective for solving a huge number of such issues in a pragmatic way. You may need to use the exact data for many applications (we completely agree there), but ranks will always be of great use to keep the rest of your query as simple as possible.
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.
Yes, it seems we need to let the use of references evolve a little more until such things will be feasible and lead to good coverage.
If that doesn't solve it we could at least think about language specific rank-overrides.
Storing ranks per language will not be feasible or desirable. I think the solutions I gave can go a long way. In the end, any language-specific way to define the classes you want to display/hide will do. For example, a SPARQL query for all super classes that have an article in a given Wikipedia is rather easy (querying for the most specific such superclasses is another matter of course ...).
Markus
2015-11-27 16:41 GMT+01:00 Markus Krötzsch <markus@semantic-mediawiki.org mailto:markus@semantic-mediawiki.org>:
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 "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 <mailto:Wikidata@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikidata _______________________________________________ Wikidata mailing list Wikidata@lists.wikimedia.org <mailto: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
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_ran...
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
Hoi, A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred. Thanks, GerardM
On 28 November 2015 at 06:12, Peter F. Patel-Schneider < pfpschneider@gmail.com> wrote:
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_ran...
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
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
Nemo
Why have instance of item and instance of superclass of that item? If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
Nemo
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
Hoi, Many of such baggage is legacy of Wikipedia. There is no point in storing that a city is in any specific place or of a specific size by making it what it is. It is all implied. The category:Scottish city can be implied from what administrative entity it is part of and from defining a city in whatever way. For instance Zwaag has "city rights" and nowadays it is not even a municipality. It however may be known as a "city" by having appropriate properties.
We should cut down on baggage if only to improve our "quality". Thanks, GerardM
On 29 November 2015 at 18:56, Joe Filceolaire filceolaire@gmail.com wrote:
Why have instance of item and instance of superclass of that item? If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
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
If we look at Glasgow, https://www.wikidata.org/wiki/Q4093
the values for P31 in question are:
Q515 -- city Q15060255 -- council area Q7309443 -- registration county Q202435 -- lieutenancy area of Scotland Q21457810 -- Scottish district (1975 to 1996)
Each of those statuses is different and independent (even in a purely Scottish context): none of them implies any of the others, none of them is implied by any of the others.
So, in this case, I don't see that "city of Scotland" would help at all.
-- James.
On 29/11/2015 17:56, Joe Filceolaire wrote:
Why have instance of item and instance of superclass of that item? If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
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
Hoi, Most of these could be / should be qualifiers. Several are historic and no longer valid. Thanks, GerardM
On 29 November 2015 at 23:42, James Heald j.heald@ucl.ac.uk wrote:
If we look at Glasgow, https://www.wikidata.org/wiki/Q4093
the values for P31 in question are:
Q515 -- city Q15060255 -- council area Q7309443 -- registration county Q202435 -- lieutenancy area of Scotland Q21457810 -- Scottish district (1975 to 1996)
Each of those statuses is different and independent (even in a purely Scottish context): none of them implies any of the others, none of them is implied by any of the others.
So, in this case, I don't see that "city of Scotland" would help at all.
-- James.
On 29/11/2015 17:56, Joe Filceolaire wrote:
Why have instance of item and instance of superclass of that item? If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
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
Thanks Gerard, but which ones do you think could be qualifiers? And qualifiers of what?
As a default position, I tend to be against hiding information in qualifiers when it is an actual fact about the item, because it makes the fact harder to extract and to use -- eg it's harder (and slower) to include in a recursive query. So as I rule, I prefer to use qualifiers to indicate the sense in which something is true, or any limits on its truth, rather than as a place to store primary facts.
In terms of currency, all of the statuses have current relevance (though some may be more significant than others), apart from Q21457810.
But even for historical facts, it makes queries for those historical facts trickier if they can't be retrieved using the wdt:... form of properties -- or rather (in fact, worse) if the wdt:... query *appears* to work, and retrieves some values, but is in fact silently not returning all of them.
-- James.
On 30/11/2015 04:40, Gerard Meijssen wrote:
Hoi, Most of these could be / should be qualifiers. Several are historic and no longer valid. Thanks, GerardM
On 29 November 2015 at 23:42, James Heald j.heald@ucl.ac.uk wrote:
If we look at Glasgow, https://www.wikidata.org/wiki/Q4093
the values for P31 in question are:
Q515 -- city Q15060255 -- council area Q7309443 -- registration county Q202435 -- lieutenancy area of Scotland Q21457810 -- Scottish district (1975 to 1996)
Each of those statuses is different and independent (even in a purely Scottish context): none of them implies any of the others, none of them is implied by any of the others.
So, in this case, I don't see that "city of Scotland" would help at all.
-- James.
On 29/11/2015 17:56, Joe Filceolaire wrote:
Why have instance of item and instance of superclass of that item? If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
Nemo
Years ago I made somebody a classification into ten or so "subjects" that might correspond to the sections of a magazine: movies, music, TV, sports, business, etc.
The person who wound up in the most categories was not the Austrian polymath, but Alyssa Milano who not only acts but dances and sings and is involved with charity and has a medical condition, etc.
As also mentioned, cities are also a source of trouble because there are lots of "places where X happens" or "places that contain Y" -- they might not do that in Georgia but they certainly do X and have Y in Atlanta so big cities get a pile of uninformative types.
The funny thing is that once you start building an actual application over some actual problem domain, these problems mostly dry up and blow away -- unless it is (1) celebrity gossip, (2) Wikidata's service to Wikipedia, or (3) building editing interfaces like the one for Wikidata,
There is a strong danger in (3) that you build CycL,a platform to develop Cyc with ,and then Cyc and CycL coevolve to the point where they can't imagine throwing out Cyc and knocking out something simple with CycL -- at that point the software is programming you.
On Mon, Nov 30, 2015 at 3:46 AM, James Heald j.heald@ucl.ac.uk wrote:
Thanks Gerard, but which ones do you think could be qualifiers? And qualifiers of what?
As a default position, I tend to be against hiding information in qualifiers when it is an actual fact about the item, because it makes the fact harder to extract and to use -- eg it's harder (and slower) to include in a recursive query. So as I rule, I prefer to use qualifiers to indicate the sense in which something is true, or any limits on its truth, rather than as a place to store primary facts.
In terms of currency, all of the statuses have current relevance (though some may be more significant than others), apart from Q21457810.
But even for historical facts, it makes queries for those historical facts trickier if they can't be retrieved using the wdt:... form of properties -- or rather (in fact, worse) if the wdt:... query *appears* to work, and retrieves some values, but is in fact silently not returning all of them.
-- James.
On 30/11/2015 04:40, Gerard Meijssen wrote:
Hoi, Most of these could be / should be qualifiers. Several are historic and no longer valid. Thanks, GerardM
On 29 November 2015 at 23:42, James Heald j.heald@ucl.ac.uk wrote:
If we look at Glasgow,
https://www.wikidata.org/wiki/Q4093
the values for P31 in question are:
Q515 -- city Q15060255 -- council area Q7309443 -- registration county Q202435 -- lieutenancy area of Scotland Q21457810 -- Scottish district (1975 to 1996)
Each of those statuses is different and independent (even in a purely Scottish context): none of them implies any of the others, none of them is implied by any of the others.
So, in this case, I don't see that "city of Scotland" would help at all.
-- James.
On 29/11/2015 17:56, Joe Filceolaire wrote:
Why have instance of item and instance of superclass of that item?
If Glasgow is instance of : city of Scotland and City of Scotland is subclass of : city Then we should not have Glasgow instance of : city
This principle should cut down a lot of these extra 'instances '
Joe
On Sat, 28 Nov 2015 15:51 Federico Leva (Nemo) nemowiki@gmail.com wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of
inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
Nemo
Wikidata mailing list Wikidata@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata
On 28.11.2015 16:51, Federico Leva (Nemo) wrote:
Gerard Meijssen, 28/11/2015 07:05:
A big city is what? A city with more than a given number of inhabitants? If so it is redundant because it can be inferred.
Criteria might be defined by local law and/or require some administrative act. That's how it works in Italy, for instance.
German actually has a noun "Großstadt" ("big city"), which has a fixed meaning to be a city with at least 100,000 inhabitants. The noun is now widely used as a native expression in everyday German, unlike the descriptive English translation "big city" (which feels to English speakers like "große Stadt" would feel to German speakers). It is an example of a concept that natively exists in some languages but not in others.
The important clarification to Gerard's reply is that this is not a case of an over-specific Wikipedia category that somehow became a Wikidata class. Rather, it is a concept that is natural to some languages and not to others. It's a challenge for Wikidata to deal with this, clearly. Nevertheless, from my point of view, a classification that integrates concepts from many cultures/languages is preferable over many disjointed classifications that are perfectly aligned with one particular culture/language.
Markus