Like many conversations about Wikidata tagging, I think this one suffers from varying levels of stringency -- and perhaps letting the perfect become the enemy of the good.
At the risk of stating the obvious, it is often the case that Wikidata's conceptual model of places does not exactly match OpenStreetMap's more precise spatial model of them: for example, the formal administrative boundaries of a town versus its popular conception; or the historical sense of a place versus its current boundaries. This is not always true, and when it is possible to match the conceptual models precisely, that is of course what should be done (including making Wikidata's model more precise). I think it is a mistake to say that a critique based on these kinds of imprecision necessarily constitutes a good reason for removing the tag. It is often the case that the slightly-mismatched entity is still tremendously useful. First and foremost, in the vast majority of cases the multilingual Wikidata labels on the associated entity will still be correct even when there is a conceptual mismatch. This is a particularly vital function given the OSM community's occasional insistence that mechanical transliterations are a trivial problem. This sort of utility exists with other Wikidata properties as well. And the relationship can be revised to a more precise form as users' needs arise. By way of analogy: a forest area tagged as `natural=wood` can be a useful part of the map even if it contains clearings or meadows. It would be counterproductive to revert features mapped as such rather than focusing on their improvement as user needs demand it. My 0.02. FWIW, we are using Wikidata matched entities extensively in production (albeit matched to data sources other than OSM). As you might imagine, these kinds of mismatch problems are unavoidable for us, too. But the presence of the Wikidata relationship is of truly incredible value, and often delivers substantial utility even when the match is imperfect. Tom
_______________________________________________ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
