As you can see, there are more prefixes for wikidata than wikipedia, but I think they should be the same prefixes. So the following elements should be removed or added:
I kind of agree, but I’d describe it as a likely case of dual tagging instead. We have historically tolerated dual tagging to some extent, especially buildings with their sole occupants. Personally, I draw the line at when the building has a separate identity somehow, such as a different name or Wikidata item.
From a purist standpoint, the occupant should always be extracted into an area coextensive with the building, but many mappers (especially JOSM users) really don’t like overlapping features. But there are other precedents following the same syntax, such as bridge:name=*. Rather, the problem with building:name=* or building:wikipedia=* is more that the feature is probably tagged building=yes but all its other usual tags refer to the occupant. One would think the name=* and wikipedia=* would be for the building while shop:name=* or whatever would be for the occupant. But at that point it would be easier to just separate out a second feature for the tenant.
It is quite widely accepted (though I still personally consider it as a bad tagging) where you have single shop in a single building without name or strong identify.
But when you have multiple POI in one building, or building has own name or own wikipedia page…
Then stuff like building:namepoi:namebuilding:wikidatashop:wikidata are just more troublesome in mapping than proper separation. To say nothing about support among data consumers.
right, it is an accepted shortcut for simple (read: rough) mapping, but when you start requiring prefixes for disambiguation the time has come to divide objects and features properly.
The OSM wiki articles specify suffixes for both wikipedia and wikidata keys, and in principle those suffixes should be consistent across both.
For example, with flag, why should an OSM element only allow flag:wikidata=Q### but not the corresponding flag:wikipedia=XXXX? My point is simply that there are more suffixes defined for wikidata than for wikipedia, and that inconsistency is confusing.
Those extra wikidata suffixes are not very clear, and what I am asking here is whether we could consider removing them. As you already showed with your examples, they don’t seem well justified.
Maybe all that is required is to be clearer in the wiki that the lists are common examples and other values are possible? In the case of flag: the wikipedia version is far less commonly used so maybe not necessary to list it.
Which ones specifically? I agree there is a good case for not listing building:wikidata(only 500 uses) but I’m not sure about the others.
flag:wikidata=* is used to avoid any ambiguity as to what flag is flying for data consumers who care, and flag:wikipedia=* is, quite simply, unnecessary
I don’t think flag:wikipedia=* is disallowed (if anything else, due to Any Tags You Like, and there hasn’t been a proposal to deprecate it), it’s simply not featured in the table because it’s usually considered unnecessary and no one has bothered to write an OSM wiki page for it and add it to the OSM wiki table
Similarly, brand:wikidata=* is used to avoid ambiguity among similarly named brands, and brand:wikipedia=* is unnecessary because it either duplicates brand=* or, in cases where Wikipedia’s article title isn’t the same as OSM’s brand text, it duplicates data from brand:wikidata=* plus Wikidata lookup
Generally, :wikipedia=* tags have been seeing reduced use as :wikidata=* tags became more popular. This is for a couple of reasons:
some things have Wikidata items but not Wikipedia articles (e.g. Williams Fresh Cafe - Wikidata or 190 St. George Street - Wikidata) and that will always be the case due to differing inclusion criteria between Wikidata and Wikipedia. So in some cases in OSM we’ll be able to tag :wikidata=* but not :wikipedia=*, so some OSM data consumers will want to consume Wikidata information, so then :wikipedia=* is not strictly necessary
easier support for multilingual items, e.g. stores might have brand=Staples or brand=Bureau en Gros, and brand:wikipedia=* would then also be different (=en:Staples Canada and there’s no French Wikipedia article), but brand:wikidata=Q17149420 is the same in both cases, allowing a simpler search for all Bureau en Gros/Staples locations. Similar deal for Postes Canada/Canada Post and many other examples
As a first attempt, but not as an ideal solution. I think it is generally fine until you start adding more information, at which point it is highly recommendable to divide the entities properly.
I don’t see the issue with wikipedia for Staples Canada, couldn’t you add brand:wikipedia=en:Staples Canada and have the same information?
And isn’t Staples Canada the same brand as this: Staples Inc. - Wikidata
but a different operator?
The Wikidata prefixes are currently being used as if they were Wikipedia prefixes. In that case, should we extend the OSM wiki table for Wikipedia articles to include them? Or should the Wikidata prefixes in the OSM wiki be considered invalid?
(I would like to give you some context: I am going to present at a Wikimedia conference about the points of intersection between Wikimedia and OpenStreetMap. That is why I want to make clear how a Wikimedian can contribute to OSM, by providing a complete and valid list of OSM tags.)
I don’t follow how the numbers in that table relate to the links.
E.g. the tables says only 2 values on 2 objects for genus - but following the link I see 236 values on 64084 objects. Are we talking about different things?
Which 2 values and which 2 objects are you referring to in the table?
I’m asking because you are talking about considering prefixes invalid. Maybe some of the low-usage ones could be considered “inadvisable” if not exactly invalid, and your table seems to imply that many of these are low-usage. But this and several of the others are in fact quite popular. I can’t see any grounds for calling them invalid.
validity is not directly correlated to popularity - for example royal_cypher:wikipedia makes far more sense than building:wikipedia despite being used far less
