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

Joseph Eisenberg joseph.eisenberg at gmail.com
Tue Jan 19 20:21:07 UTC 2021


> Re: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.

I am perfectly happy if someone wants to run a bot that creates wikidata
items for every documented OpenStreetMap tag.

But in that case there is no need to have it added by humans, and no need
for humans to see the Q#### code, since the key=value would be enough.

I am strongly opposed to having this shown in the infobox as something that
needs to be added, because 95% of the time users are adding incorrect links
to somewhat-similar Wikidata concepts rather than creating a new wikidata
entry for the OpenStreetMap tag.

Managing these takes up a lot of work for wiki gardners such as Mateusz
Konieczny and myself, when as you say it could clearly be automated.

I suspect Mateusz Konieczny could create a bot to automatically add these
to the Data Items, if he has the time.


On Tue, Jan 19, 2021 at 10:37 AM Minh Nguyen <minh at nguyen.cincinnati.oh.us>
wrote:

> 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
>
>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20210119/b6dab577/attachment.htm>


More information about the Tagging mailing list