[Tagging] RFC: remove alphanumeric code visible in infoboxes at OSM Wiki linking to Wikidata
matkoniecz at tutanota.com
Tue Jan 19 21:20:00 UTC 2021
Jan 19, 2021, 19:34 by minh at nguyen.cincinnati.oh.us:
> Vào lúc 02:17 2021-01-19, Mateusz Konieczny via Tagging đã viết:
>> Can you find a replacement for mismatches mentioned in
>> And there is no value at all in linking "OpenStreetMap tag" Wikidata entries.
> Like OSM and its own tagging ontology, Wikidata is still a work in progress. The fact that something isn't represented now doesn't mean it can't represent it a minute from now. You've essentially identified a number of instances of mistaken or unrefined tagging. We know all about that in OSM! :-)
My claim is that
- (1) it is a fundamental issue, with very large part of supposed matches being useless
- (2) even if we fix mismatches this links would not be useful for infobox display
- (3) we are anyway missing people willing to fix this invalid links in OSM Wiki
though I see that you improved
https://www.wikidata.org/w/index.php?title=Q994972&action=history - thanks!
If you are interested I can generate big table with list of OSM values/keys
and description at OSM wiki and description of what was matched to them
at Wikidata. Blatantly wrong are nearly fixed, but many
dubious ones remain and I am not sure what should be done with them.
There are many like
linking https://www.wikidata.org/wiki/Q602300 <http://www.wikidata.org/wiki/Q602300war>
"war flag - variant of a national flag for use by the nation's military forces on land"
with mismatch "on land" from Wikidata and
"Military flags include war flags, naval flags, and flags representing specific military forces or units."
on OSM wiki
Keep it? But it is actively misleading, incorrect just enough to not be spotted by
someone who followed link but enough to cause confusion, especially by
someone using it for translating or understanding tag meaning.
Delete it? Then we would delete most of current matches. There are some exact matches
but it is fairly rare.
> If there's no exact match for amenity=toilets, one can be created as a replacement for Q813966 in the infobox and in the associated data item. The "OSM tag or key" external ID alone will likely protect that entity from deletion, based on Wikidata's notability guidelines. It isn't so outlandish to imagine hundreds of OSM keys and tags getting their own Wikidata items in the future for the same reason.
What would be the benefit over https://wiki.openstreetmap.org/wiki/Data_items
that are strict matches to OSM tags?
And putting there some relationships to Wikidata instances such as
- narrower than Q813966
- wider than Q602300 <http://www.wikidata.org/wiki/Q602300war>
- intersection of QX and QY
- sum of QA, QB, QC
- place where profession QT is practiced
- access of QZ is specified by this tag
- organization QP assigns this identifier
rather than current "this is sort-of related, not specified how"
Or maybe create missing wikidata items (create "permanent or long-term test"
for building=tent that would be subclass of https://www.wikidata.org/wiki/Q170544 etc)
But even if someone(s) will do this - is it actually useful to have prominent links
in infobox to display it?
> There's value in being able to model that more specific entity as a subclass of Q813966 , even if the concepts don't align exactly. For example, a sophisticated enough search engine could return amenity=toilet features to users who search for "toilet" or "restroom" in a hurry without wanting to fuss about semantics.
> More broadly, whenever you put two ontologies side by side, mismatches are inevitable, but that doesn't make it any less helpful to develop correspondences between ontologies. For example, the standard classification system for businesses in North America makes very different distinctions than OSM, some of them quite annoying, but developing a correspondence table like  has been essential for understanding OSM's coverage compared to the real world. Some OSM data consumers have also had to map OSM tags to non-OSM ontologies to make OSM data more readily consumable in renderers, routers, and search engines.
I agree that there are some possible uses, but I see no point of displaying it in the infoboxes
(that is why I am proposing removal from infobox rather without removal from data items)
> I think you've at least made a pretty good case that the Wikidata line in the infobox needs to be contextualized. For that matter, the wiki could use a Help:Infobox page that explains each of the sections in more detail.
What you mean by "contextualized"? (I am open to alternative proposals how to handle it,
but I am not sure what you mean here)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging