Wikidata

Wikidata:Property proposal/OSM object

< Wikidata:Property proposal

OSM object edit

Originally proposed at Wikidata:Property proposal/Place

   Done: no label (P10675) (Talk and documentation)
Descriptionway or node in Open Street Map for the item, generally linking back to Wikidata. If possible, use "OpenStreetMap relation ID" (P402).
RepresentsOpenStreetMap (Q936)
Data typeString
Domainexisting items for geographical objects
Allowed values(way|node)/\d+
Example 1Biblioteca Lúcio Craveiro da Silva (Q18500432) → way/121590158
Example 2Statue of Liberty (Q9202) → way/32965412 (contrast with relation/9731524 which is linked to Q359939)
Example 3Burj Khalifa (Q12495) → way/446646206
Example 4Mount Everest (Q513) → node/8827029797
Formatter URLhttps://www.openstreetmap.org/$1
See also
Distinct-values constraintyes

Motivation edit

Currently we have mainly OpenStreetMap relation ID (P402) to link to OSM. This as relations are seen as a sufficiently stable to link them with an external-id property.

OSM links to Wikidata also from ways and nodes. We avoided creating a external-identifier properties for them as they are seen as less stable.

The result is that many objects are present in both Wikidata and OSM, but can't be queried from Wikidata directly.

An alternate way is proposed here: instead of an external identifier property, a string datatype property is proposed. Further, to ensure a reasonable stability, the OSM object would generally link to the Wikidata item. When using the value, one should ensure that this is the case (Add your motivation for this property here.) --- Jura 12:06, 17 December 2020 (UTC)[reply]

Discussion edit

  •   Weak support. Creating relations for the sole purpose of linking from Wikidata is tiresome. As for stability… well-tagged stuff (what we want to reference) don't generally go away, but may get merged and change ID. --Artoria2e5 (talk) 23:58, 16 February 2021 (UTC)[reply]
  •   Oppose Not as stable as relations; linkage already exists from OSM to Wikidata and thus can be queried from Overpass. NMaia (talk) 00:09, 17 February 2021 (UTC)[reply]
    • @NMaia: Stability can be achieved in other ways (see above). That Wikidata items can be queried on other websites is never a reason to not add information to Wikidata. The presence of relations is just to much random that we could rely on that only. --- Jura 00:14, 17 February 2021 (UTC)[reply]
  •   Comment I do not understand this property or the instability of its values, but it is easy for me to confirm the importance of linking OSM and Wikidata. Maps from OSM appear through Wikimedia projects and the two projects share the philosophies of open media, multilingualism, user community governance, and public benefit in the service of the individual end user. If anyone can describe a plan for matching OSM and Wikidata then for this exceptional partner I am in support of making unusual exceptions to develop the collaboration. Blue Rasberry (talk) 18:06, 20 May 2021 (UTC)[reply]
  •   Support. I don't see why way IDs should in principle be less stable as relation IDs. Also, it seems that there are inverse constraints for some inter Wikidata references (e.g. P749 and P355), so I don't quite understand the argument that the OSM -> Wikidata link is enough? But I'm new here... Arminus68 (talk) 11:47, 2 July 2021 (UTC)[reply]
  •   Oppose OSM IDs are not only unstable but very unstable as they can change when even very minor edits occur. Abbe98 (talk) 07:08, 13 July 2021 (UTC)[reply]
    • What's your view on the mitigation strategy proposed above? --- Jura 19:38, 13 July 2021 (UTC)[reply]
      I don't think it should be stored as a string, having it as an external identifier makes it easier to check if it's still valid which becomes more important not less if it's unstable.
      I wonder if a better solution wouldn't be to expose Kartotherian somehow to WDQS, to enable querying from Wikidata without storing unstable identifiers. It might be something one could propose on the community wishlist. Abbe98 (talk) 09:55, 16 July 2021 (UTC)[reply]
      • There shouldn't be any difference in the way you can check it depending on the datatype (if so, please explain how). Links to OSM are still possible and constraints can be the same. The datatype merely acknowledges your point, i.e. that these are less stable than relations. However, the mitigation strategy proposed above suggests to check if they are backlinks from OSM when the values are being used. The datatype and the proposed strategy together will ensure that users with requirements for higher levels of stability would also be able to work with these and wont use them mistakenly as they would use external-datatype properties. This could possibly be enhanced later with your addition to the community wishlist. --- Jura 11:52, 16 July 2021 (UTC)[reply]
  •   Support. While arbitrary individual nodes can indeed very easily disappear (e.g. points along a road or in the outline of a building), nodes/ways that correspond to entities notable enough to have a Wikidata item typically are well-mapped, and can have their geometry updated, but rarely will outright disappear. I see their stability as similar to that of relations (neither is 100% permanent, but both are stable enough to add more value than maintenance effort). --Waldyrious (talk) 21:25, 2 September 2021 (UTC)[reply]
    • @Waldyrious: Agree. Depending on the use, I think the check for reciprocal linking can easily solve it for those with more rigorous requirements. Eventually, we would probably need to set up a check for cases where relations get created for items we use this property on. These items could then be changed to use P402. --- Jura 11:50, 4 September 2021 (UTC)[reply]
  •   Oppose Inherently unstable, and thus unsuitable, per previous discussions. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:50, 3 September 2021 (UTC)[reply]
  •   Support. It doesn't make any sense to have a property only for relations. In my opinion there should be only one property, with N W R before number and with a warning like "avoid using on objects likely to change ID often", it can happen with any of the types of element, not only with ways and nodes. And if a ID changes what is the problem? It can be corrected. Marty5550 (talk) 16:28, 19 December 2021 (UTC)[reply]
  •   Comment And I would add that it depends. A church would be unlikely to change ID, not to mention places. What are the chances of place nodes to change ID? Only minor POIs can be a little more unstable, but that could be only an incentive to improve them and removing the reasons for which they might be. Marty5550 (talk) 16:38, 19 December 2021 (UTC)[reply]
    @Marty5550 That is an interesting point. Are there numbers available how many times Wikidata QIDs at OSM are moved between objects that are not relations? --- Jura 13:50, 9 January 2022 (UTC)[reply]
  •   Support OSM nodes are not inherently more unstable than relations. In particular I'm interested in cases where a node marks a distinct place that does not actually have any official or definable boundary. E.g. neighborhoods in many cities, or unincorporated villages for which there are thousands of entries in Wikidata. It's silly that there is no way to reference these just because they aren't (and can't be) mapped as relations. To pick an example just at random, this node has represented the same thing consistently for 14 years now. Nate Wessel (talk) 14:51, 13 January 2022 (UTC)[reply]
  •   Support —MasterRus21thCentury (talk) 19:13, 18 April 2022 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/OSM_object&oldid=1853479004"