Wikipedia article describes two or more different objects
The Wikipedia article about Heligoland describes the island and the municipality "Heligoland". Wikidata items should only cover one object. If an Wikidata item falsely describes two or more different objects then there should be created an own item for each missing object. Example for Heligoland: municipality Heligoland island Heligoland
[outdent] Wikidata items do not describe two objects.
OSM relation 3787052 has tag place=island and is, correctly, already tagged wikidata=Q17043877
There is clearly an equivalence between instance_of=island and place=island
There is no equivalence between place=island and instance_of=municipality_of_Germany
- Look at the history, I've fixed the object in Wikidata of course already: https://www.wikidata.org/w/index.php?title=Q3038&action=history I try to figure out more problematic examples.--4rch (talk) 13:26, 17 June 2014 (UTC)
- Another problematic example I've found: https://www.wikidata.org/wiki/Q204096 The mappers have to be made aware of that Wikidata needs much consolidation at the moment and that there are many faults (instance of, duplicates, ...) in Wikidata. And that one object in Wikidata should be one object in OpenStreetMap. Not like Wikipedia where different objects are treated in one article and you can add the same link to different OSM objects. --4rch (talk) 14:09, 17 June 2014 (UTC)
- The two most frequently occurring Wikidata keys are Q146924 (Roman Limes, 66 times) and Q16200592 (List of Stolpersteine in Witten, 18 times). The latter is a list article, but should that really have a Wikidata key? --LA2 (talk) 10:47, 6 August 2014 (UTC)
- Looks like this new way is the one? I don't know enough about 3D buildings or the Taj Mahal to edit here. https://www.openstreetmap.org/way/375257537#map=18/27.17457/78.04166 --ElliottPlack (talk) 18:32, 15 July 2016 (UTC)
- If I look at http://www.wikidata.org/wiki/Q9141, I don't see the reference deleted, it is still the Taj Mahal...
- Same thing for the second example OSM data for Balwin Street: the indicated wikidata value is still valid in Wikidata. — Verdy_p (talk) 18:58, 15 July 2016 (UTC)
- The issue I brought up was regarding this page, not the wikidata entry, which was fine. I see that you have updated the infobox. The deleted item was the OSM object that represents the Taj, the deletion of which ironically demonstrates the very fragility of OSM IDs. http://wiki.openstreetmap.org/w/index.php?title=Key%3Awikidata&type=revision&diff=1326347&oldid=1305699 --ElliottPlack (talk) 06:39, 16 July 2016 (UTC)
- Yes it was not clear in the first message, that's why I not just used the OSM ID in the link, but also used the coordinates. It's very unfortunate that this wellknown monument can be defined first as a relation then deleted and replacd by a single way (when in fact it has not disappeared), the single way is oversimplified anyway, there was no value in editing it this way: there was a relation because it was better defined before (the 3D model supposed to replace it in not in the OSM database. I think that some details should have been kept, even if there was an additional external 3D model... — Verdy_p (talk) 08:04, 16 July 2016 (UTC)
- I agree fully that it is unfortunate! It is too bad that the schema for OSM was not set up for persistence of linkability (or something). Ideally, one could somehow *link* an object to be deleted to a new object. Thanks for fixing the link on the site. I also left a changeset comment for the OSM editor to come check out this page. --ElliottPlack (talk) 16:04, 16 July 2016 (UTC)
Wikidata objects of a sculpture that is located at more places
Example Q10590627 has one article on Wikidata today
- Maybe it's better to create 2 new wikidata entries, one for each location and point to those from that wikidata entry. That way each of those wikidata entries can have its own coordinates tag on wikidata.
- For brands (e.g. a fast-food chain), there is a brand:wikidata tag in addiiton to the wikidata tag. The former is about the brand generally, and the latter is about the specific store (if present). Wikidata is unique for every POI, and brand:wikidata is shared. Perhaps something similar needs to be done here. -- SafwatHalaby (talk) 11:46, 18 November 2017 (UTC)
I tried adding wikidata tags to streets and rivers. The streets are often cut in several OSM ways.
The rivers too, but there we also represent them both in a linear way and when they get wider as riverbanks. Some rivers are canalized to allow boat traffic. When there is a sluice, the canal part forks off, but in general the river is both canal and river, so I added a ; in the wikidata tag.
The way to solve this, is to use part_of:wikidata instead.
You could say we are supposed to use relations and add the wikidata tag to them, but not every river or street has a relation grouping them and in the case of rivers, only the linear parts seem to be added to the river relation.
What are your thoughts on this?
- I add wikidata to waterway relation and ignore individual ways. I create relation if that is necessary. For streets I add wikidata to each way Mateusz Konieczny (talk) 15:39, 7 December 2017 (UTC)
Controlling Wikidata-tag input quality
Suggestion to use some kind of automation in the input ok Wikidata-ID values... See syntax error at https://www.openstreetmap.org/node/261615248 where a the Wikidata-ID is "Q10366821)" instead "Q10366821"...
PS: See also https://help.openstreetmap.org/questions/65157
- @Krauss: JOSM has a validator check for the format. If the wikipedia plugin is used, JOSM even checks if the item exists and is no redirect to another item. But a validator check won't prevent everyone from entering incorrectly formatted data. And I consider this a good thing, OSM editors should alert users of bad tagging, but if the user desires to put in, he/she should be allowed to do so. Tagging schemes can evolve and something considered bad tagging in the past can become accepted later.
- The current measures of preventing incorrect wikidata=* tags already work pretty well: At the moment there are only 3 OSM objects with wrong format for the Q-ID, compared to over a million correct ones: https://overpass-turbo.eu/s/crv --Floscher (talk) 12:23, 6 August 2018 (UTC)
- Edit: The Overpass query was not completely correct: https://overpass-turbo.eu/s/AON . There are 14 "incorrect" objects. --Floscher (talk) 12:32, 6 August 2018 (UTC)
Wikidata -> OSM relation
- WD:Q30158648 = Rottnebyskogen nature reserve in Dalarna, Sweden
- @Salgo60 Hi, you posted a good example, it is a classic problem that will be only solved by a Persistent Place Identifier (an ID that is eternal and independent of the element type).
For now the workaround is edit to envelope by a relation, them use the relation-ID at Wikidata. --Krauss (talk) 16:50, 6 August 2018 (UTC)
- @Salgo60 @Krauss I disagree. You should not create a relation for the sole purpose of being able to link from Wikidata to OSM, that's a unnecessary complication of the data model for very little benefit. As you said, OSM-IDs are not stable and thus a link from Wikidata to OSM might point to a different object after a while. P402 is sort of a compromise to allow this sort of link, since relation IDs are less often subject to change.
- If there is no OSM relation for a Wikidata item, add the wikidata=* tag and if you want to do more, try adding third party IDs to both the OSM object and the Wikidata item (e.g. WDPA_ID:ref=*/P809 in case of Rottnebyskogen). --Floscher (talk) 11:03, 7 August 2018 (UTC)
burried:wikidata or subject:wikidata ?
- person (Q215627) (typically subject:wikidata=* should be used, for artwork depicting humans)
- Example: n6813735406
Could it be used also for persons buried in a grave ?
OSM website and Overpass turbo already display links for subject:wikidata=*