Section 3.12 Stability of ID

[c933103]

The study tried to contrast the stability of OSM object IDs with Wikidata's QID, saying Wikidata QID is more premanent and can be used as a reference ID for OSM objects. But it is not always the case. Wikidata's QID codes are also subjected to edit, merge, deletion, split, and so on, although they probably happen a bit less often than IDs for objects in OSM, yet there are still no defined rule in Wikidata guaranteeing QIDs of each entries on Wikidata will always remain the same.

[ckrahe]

The study gave useful examples of why OSM ids change over time; they are logical outcomes given the nature of OSM. Has anyone studied Wikidata enough to give examples of why QIDs change, let alone the understand actual volatility of QIDs in the first place?

Moreover, is it possible that, despite not have a defined rule guaranteeing QID stability, the perception that they are stable increases the likelihood that they will remain so? Refer to Wikidata for Digital Preservation, "The Qids assigned to Wikidata items are their unique, persistent identifiers."; and COVID-19 and Wikidata QIDs, "We therefore typically recommend the “Wikidata QID” as the best general purpose identifier that is guaranteed to be stable over time". Sure, just because everyone believes something doesn't make it true, but it's hard to imagine widespread QID changes knowing the ripple effects it would create.

[fititnt]

Just to let it here some previous links about the topic

• https://community.openstreetmap.org/t/persistent-and-stable-identifiers/6819 (recent ongoing discussion)
• https://wiki.openstreetmap.org/wiki/Persistent_Place_Identifier (see also talk page)
• https://wiki.openstreetmap.org/wiki/Permanent_ID (see also talk page)
• https://wiki.openstreetmap.org/wiki/Overpass_API/Permanent_ID

Also Key ref

• https://wiki.openstreetmap.org/wiki/Key:ref

[ckrahe]

Great links.

Lots of good content in the recent, ongoing community.openstreetmap.org discussion, e.g.:

SK53 -I’m still somewhat sceptical about wikidata’s implementation because many entries refer to two or more divergent concepts, or very poorly defined ones.
...
Min_Nguyen - Many Wikidata items suffer from dual-tagging just as many OSM features do, though I think there’s a general awareness that dual-tagging should be reduced over time. Wikidata’s built-in validator encourages contributors to clean up constraint violations often caused by dual-tagging.
...
SimonPoole - The usual question: pls detail which changes to a restaurant make it no longer the restaurant that the stable id referred to.
...
pangoSE - My suggestion is to have entity gatekeepers, someone with a good track record and has the trust of the local community can edit the entities in a specific area.

The Permanent ID page in the OSM wiki, section "Wikidata-IDs as first step for Permanent IDs", seems well-thought out and links to the Permanent ID/Proposal-QID.

[Adamant36]

At least from what I've seen in working with the Name Suggestion Index in cases where Wikidata's QID of a brand we were working with was deleted the process to have it undeleted was always pretty easy and caused minimal disruption. Also, we were eventually able implement our own unique id system outside of Wikidata OSM Name Suggestion Index identifier that acts as a property for brand related QIDs so they are less likely to be deleted. I'd be interested to know how the process of having QIDs undeleted, as well as the ability to create properties that can act as safeguards, factor into research on stability. Obviously, QIDs will seem way less stable if the only metrics of study are how often QIDs are merged, deleted, and split. But without considering how things like un-deletion requests, unique properties that can act as stability enhancers, Etc. Etc. can act as offsets, if not completely mitigate non-stability.