[Tagging] RFC: remove alphanumeric code visible in infoboxes at OSM Wiki linking to Wikidata
matkoniecz at tutanota.com
Wed Jan 20 11:41:39 UTC 2021
That is quite long, feel free to reask me if I missed something where you expected my answer.
Jan 20, 2021, 10:05 by minh at nguyen.cincinnati.oh.us:
> Vào lúc 13:20 2021-01-19, Mateusz Konieczny via Tagging đã viết:
>> Jan 19, 2021, 19:34 by >> minh at nguyen.cincinnati.oh.us>> :
>> 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
>> or misleading
> I'm not convinced that enough of the data items' "Wikidata concept" statements or Wikidata's "OSM tag or key" statements are useless that we should cast aspersions on both properties -- if only because these properties aren't necessarily used in ways that require the degree of semantic precision and binary correctness that has been suggested in this thread.
You are right, I even added
"There are some potential uses for linking between Wikidata items and OSM tags,
but displaying them in infoboxes does not appear to be an useful one."
to the proposal text.
"very large part of supposed matches being useless or misleading if used as part of the tag definition"
would be better and describe my problem with them?
> (Template:Place, I'm looking at you. )
>  But seriously: > https://wiki.openstreetmap.org/wiki/Template_talk:Place#MapDust
"Error in loading GML file mms/kml/3194326_232989024.kml", lovely
I removed it as clearly replaced by notes, hopefully this one is not going to be controversial
> The OSM Wiki needs more care and attention in general. Others have claimed that Wikidata could serve as a stopgap for the wiki's unfortunate gaps in translation. I'm sympathetic to that notion because relatively few of OSM's popular languages have made a dent in terms of translation coverage on the wiki. (Not sure we even have statistics on that, aside from the handful of languages privileged enough to have tracking categories.)
If someone is curious, it would be simple to generate such coverage info report about
existing tag pages. I would use script that I used to generate my recent post about
what is missing at OSM Wiki.
> If the community finds the tradeoff of semantic imprecision to be anathema, then the alternative to a dependency on Wikidata is that wiki needs to be more self-sufficient. Self-sufficiency requires a _lot_ more activity from a broader cross-section of the mapping community. Some outstanding proposals to upgrade the wiki  would facilitate that increased activity, but even some subscribers to this list are intimidated by the wiki's basic editing workflow. Of course, it would also help if standard parts of the wiki's pages, such as the infobox, were more self-explanatory or at least better documented, so that folks can more easily identify mistakes.
For example I tried creating
as Wiki would really benefit from more people researching and documenting some popular
widely used tags (though in some cases rather revert of undiscussed import is needed)
building=plot (increase by 9253 in last 100 days):
man_made=tar_kiln (increase by 6924 in last 100 days):
man_made=avalanche_protection (increase by 4752 in last 100 days):
natural=tree_group (increase by 747 in last 100 days):
>> 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.
> If you can spare the time and effort, I'm sure the Wikidata proponents would appreciate your help identifying these problems. Getting these associations right will also benefit OSM, not just Wikidata. Correspondence tables are a great way to spot gaps in our tagging system, as I'm discovering trying to map U.S. traffic signs to OSM tags. 
Do you want on this list also sort-of-related-by-topic like matching
https://wiki.openstreetmap.org/wiki/Key:dog "Describes if dogs are allowed" to
https://www.wikidata.org/wiki/Q144 "dog - domestic animal"?
is matched to https://www.wikidata.org/wiki/Q42973
"architect - person trained to plan and design buildings, and oversee their construction"
Wikidata probably has or should have "is it OK to enter with dog" and
"office of an architect" item.
Similar problem is with other access tags and many other values.
>> There are many like
>> flag:type=military >> https://wiki.openstreetmap.org/wiki/Tag:flag:type%3Dmilitary>> <>> https://wiki.openstreetmap.org/wiki/Tag:flag:type%3Dmilitary>> >
>> 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.
> I solved this one by creating a new item to represent military flags in general. Wikidata actually needed this item anyways, because Wikimedia Commons was distinguishing between military flags and war flags, whereas Wikipedia was not. 
> I don't think a handful of examples proves that the 2,191 "Wikidata concept" data item statements or the 2,959 "OSM tag or key" Wikidata statements are generally unreliable. (Though you happened to find a mistake I made in haste, so if anything, I'm unreliable!)
My problem was that out of random sample it was easy to find many, many problematic
matches. Or at least what seemed problematic to me.
> Regardless, I think we can find agreement on the merits of the infobox link (or lack thereof) before even considering its reliability.
Yes, though if someone is fan of both Wikidata and OSM and wants to improve
match quality I can help a bit as a side effect, why not :)
I also expect that any systematic review would reveal issues in OSM tagging
what may be useful (though right now I have quite long list of
OSM tagging issues for fixing so I a not looking for more :) - hello
>> 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)
> My first thought was to simply fold the Wikidata link into the "Tools for this tag" list.  At least this sets the expectation that Wikidata is some kind of external helper tool. In the context of documentation about a specific tag, Wikidata is probably no more relevant than taginfo or overpass turbo anyways.
> Secondly, if we point a new mapper to the wiki as a valuable resource that somehow gives them enough guidance to avoid nastygrams about tagging in changeset comments, then I'm not sure they'd necessarily know the distinction between "Implies", "Requires", and "Useful combination"; what taginfo is; what the taginfo numbers mean; or what the "IN" link does. We've managed to squeeze in a few links and tooltips, but those things are hardly discoverable or comprehensive. The Wikidata link is just one more usability papercut.
> Contextualization means explicitly clarifying the relationship between the link and the overall page and pointing out any major caveats. It may be too much to expect of such a small amount of real estate. That, to me, would be a stronger argument for removing the link than any hairsplitting about washrooms.
>  > https://wiki.openstreetmap.org/wiki/Special:Diff/2094793
Especially as washroom part is actually fixable, while this is not.
Would it be OK to quote that part at
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Tagging