Talk:Permanent ID/Proposal-QID
Hi, as I have mentioned in the Wikidata Project Chat, the assumption that Wikidata Q-numbers represent "unique and eternal" identifiers for their objects is wrong. That's why we need unique IDs for OSM elements, so that we can manage the links to OSM elements from within Wikidata. This issue concerns for example all the Wikidata items of museums, archives, libraries, cultural venues and the like which confound the geographical object and the organization. This typically is the case for Wikidata items that were created based on Wikipedia entries and their categories (i.e. tens of thousands of items). On Wikidata, we will end up disentangling these items and their statements, which will "break" the OSM-WD link that has been set on the OSM side with a 50% probability. That's why we should be able to assign the OSM-ID explicitly on the WD-side and have an automatized service in place that handles the discrepancies between OSM and WD whenever objects and identifiers get moved around on the WD or the OSM side. --Beat Estermann (talk) 14:52, 30 August 2018 (UTC)
- Hi @Beat Estermann:, I agree with most of his statements (!) ... Let us then in parts:
- "Maturity process" of the Permanent ID: need a "maturity process", in my opinion it is preferable to a quick transition to "all with a perma_id". The use of the QID will be preserved before and after the adoption of a real OSM's
perma_id. So we can use QID in the "transition process" and web-services that solves the problem. To solve the Wikidata problem is the biggest benefit right now, them later we do the second transition to a perma_id. - We should not worry about what you express as "Wikidata items that were created based on Wikipedia entries and their categories". The focus of this "first step" (item above) is not "a set of aleatory Wikidata items", but the valid OSM's elements with Wikidata tag. See example of profile statiscts.
- "Maturity process" of the Permanent ID: need a "maturity process", in my opinion it is preferable to a quick transition to "all with a perma_id". The use of the QID will be preserved before and after the adoption of a real OSM's
- --Krauss (talk) 15:13, 30 August 2018 (UTC)
- Hi @Krauss:, I cannot pronounce myself as to the best way of transitioning towards a situation where we have unique IDs at OSM that can be linked to from external databases, so I'll leave that to you guys to sort out. From the list of 26 sample entries you provided, two Q-numbers risk not to be permanent:
- How soon a change on Wikidata is to be expected depends on the editing activities on WD. - Is there a way to systematically and reliably detect such changes on the OSM side? (e.g. by checking whether an "amenity" entry points to an organization or a building on Wikidata)? - This might solve the issue of shifting Q numbers. When looking at your list of items, I'm quite confident that such shifts in Q numbers represent exceptions and not the rule.
- Cheers, --Beat Estermann (talk) 16:26, 30 August 2018 (UTC)
Hi Beat: You suggested above "That's why we need unique IDs for OSM elements". Be aware that OSM Ids - including OSM relation Ids - are neither stable nor representing a single "concept" as one may think and as discussed with Permanent ID extensively. I support the idea of an OSM Permanent ID, which in fact is a query of a coordinate with tags (like 47.22730,8.81564 and "historic=castle") in order to constrain to a certain "concept" like the Rapperswil castle as landmark (there could be other concepts/tags, like castle as building, as museum, as night club, as historic object, as energy object etc.).
The suggestion of me (and also long term User:Kolossos being well-known in Wikidata _and_ OSM) is: Use "coordinate location" property (P625) in Wikidata. Don't use "OSM relation id" property (P402) in Wikidata. Coordinates are unique and stable on both projects. This P625 coordinates help to establish Permanent IDs and are supporting also the Wikidata-to-OSM service (and other services like https://wiki.openstreetmap.org/wiki/Sophox). --Geonick (talk) 00:16, 14 February 2019 (UTC)