[Tagging] RFC: remove alphanumeric code visible in infoboxes at OSM Wiki linking to Wikidata

Minh Nguyen minh at nguyen.cincinnati.oh.us
Tue Jan 19 18:34:55 UTC 2021


Vào lúc 02:17 2021-01-19, Mateusz Konieczny via Tagging đã viết:
> 
> 
> 
> Jan 19, 2021, 11:10 by dieterdreist at gmail.com:
> 
>     Am Di., 19. Jan. 2021 um 11:09 Uhr schrieb Mateusz Konieczny via
>     Tagging <tagging at openstreetmap.org
>     <mailto:tagging at openstreetmap.org>>:
> 
> 
>         And if we would want exact matches then nearly all wikidata
>         matches would be removed.
> 
> 
> 
>     not removed, replaced.
> 
> Can you find a replacement for mismatches mentioned in
> https://lists.openstreetmap.org/pipermail/tagging/2021-January/058733.html 
> <https://lists.openstreetmap.org/pipermail/tagging/2021-January/058733.html>
> and
> https://lists.openstreetmap.org/pipermail/tagging/2021-January/058735.html 
> <https://lists.openstreetmap.org/pipermail/tagging/2021-January/058735.html>
> ?
> 
> 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! :-)

Wikidata is open to modeling overlapping concepts with similar names as 
separate entities. For example, it's possible for a place to be 
represented by as many as six different entities. [1] There's a separate 
item for an MUTCD stop sign versus a stop sign in general, a nice 
parallel to OSM's traffic_sign=stop versus traffic_sign=US:R1-1. [2]

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.

There's value in being able to model that more specific entity as a 
subclass of Q813966 [3], 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 [4] 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 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.

[1] 
https://lists.openstreetmap.org/pipermail/talk-us/2021-January/020810.html
[2] https://www.wikidata.org/wiki/Q97329852
[3] https://www.wikidata.org/wiki/Property:P279
[4] https://wiki.openstreetmap.org/wiki/NAICS

-- 
minh at nguyen.cincinnati.oh.us




More information about the Tagging mailing list