Talk:Permanent ID

From OpenStreetMap Wiki
Jump to: navigation, search

Concepts

The problem is that OSM does not support a conceptual model so there will never be agreement on what concepts you want to support. The trivial case is a pub or bar added as amenity=pub: this typically enshrines at least 3 conceptual elements:

  • A place where members of the public can buy (alcoholic) drinks
  • A retail business
  • A liquor licence
  • Retail premises where the bar is situated
  • A building which may be identical with the retail premises or the bar may just occupy some of the building.

Over time in OSM some of these elements may be made more explicit: the building is added, an operator tag is added etc.

In building permanent IDs one has to take account of this kind of partial information: either instantiate the lot on first appearance, or have some mechanism to generate new ones as data gets refined.

The editors, in general, only deal with the objects in the OSM API. Creating a set of rules for dealing with the semantics of permanent IDs would be orders of magnitude more complex than current tag presets.

See, a very old, blog post setting out my views on the subject: POSSUMs —Preceding unsigned comment added by SK53 (talkcontribs)

Hi @SK53, as you say "permanent IDs would be orders of magnitude more complex", and I agree. We need to see Permanent ID as a persistent ID living together ordinary ID... Step-by-step scenario and algorithm:
  1. Usual osm_nodeId is attributed to a node at OSM, representing the pub added to OSM;
  2. Something like place_id of Nominating (let's label it perma_id with detalils below) is also generated when amenity=pub is attributed to the node;
    (it is a good ID to preserve when the pub grows and node is promoted to a relation, but it is not permanent)
  3. After time and relevance perceived by community, an Wikidata ID (wdId) is attributed to the pub at Wikidata and the wikidata key added at OSM... So, now perma_id will be Permanent.
  4. After some "OSM refresh event", restoring OSM:
    1. the perma_id have a backup that can be used in all features (node, way or relation) that have a wikidata key (it can be cached in a lookup like this),
    2. all other perma_id are generated with no commitment of persistence.
--Krauss (talk) 21:05, 7 July 2018 (UTC)
Nominatim's place_id is an internal identifier. It has absolutely zero meaning outside of of Nominatim, and even differs from one Nominatim instance to the other IIRC. Just don't use it for about anything, really. Mmd (talk) 21:20, 7 July 2018 (UTC)
@Mmd sorry my English... Was not necessary, but to avoid confusion I am changing text above to "perma_id" (see new bold explanation).
About my text, I not say "use it", I say "something like place_id ... will be Permanent". For more details see below #Wikidata is a first step where I add explicit "... but changing the 'regeneratig all IDs' stupid algorithm...". --Krauss (talk) 14:04, 8 July 2018 (UTC)

Name Permanent ID already used for other projects

How about adding a proper disambiguation page? Mmd (talk) 12:30, 1 December 2017 (UTC)

Sure. Technically this page is not about Permanent ID in itself, but rather a requirement gathering page. UUID and OT offer a specific solution. Feel free to reorg. --Yurik (talk) 19:34, 1 December 2017 (UTC)

Why not wikidata?

Why not just use wikidata? If somebody really wants an uniques identifier for object without Wikidata entry, one may create it. Permanent ID support described on this page would require massive amount of work, including ongoing support from mappers and benefits over using wikidata ids are minor Mateusz Konieczny (talk) 17:07, 7 December 2017 (UTC)

I don't think Wikidata will be happy if someone starts adding every single stop sign or building to it. I agree that in many cases, a Wikidata ID is a good solution, but several people have mentioned a permanent ID as an alternative, so I tried to sum-up the requirements of that route. --Yurik (talk) 18:22, 7 December 2017 (UTC)
According to https://www.wikidata.org/wiki/Wikidata:Notability adding every single building and traffic sign would be OK Mateusz Konieczny (talk) 18:35, 7 December 2017 (UTC)
Not sure what you are referring to. I think this is the closest snippet:

It refers to an instance of a clearly identifiable conceptual or material entity. The entity must be notable, in the sense that it can be described using serious and publicly available references. If there is no item about you yet, you are probably not notable.

From my reading, a small tool shed in a backyard wouldn't be described using serious and publicly available reference. --Yurik (talk) 22:39, 7 December 2017 (UTC)
Entities that are so unimportant that no "serious and publicly available references" exists are not worth massive effort proposed on this page to establish permanent ids for them. Mateusz Konieczny (talk) 14:38, 15 December 2017 (UTC)
Is it possible to count building databases (existing in some countries but not all), aerial images or OSM as "serious and publicly available reference"? Mateusz Konieczny (talk) 14:39, 15 December 2017 (UTC)
@Mateusz Konieczny, you do have a point, so establishing a new system just to cover inconsequential buildings seems like a waste of time... It might be difficult for OSM community to embrace Wikidata to this extent. Also, loading Wikidata with all the buildings on the planet might be a fun project in itself... Hopefully WD won't blow up. --Yurik (talk) 16:43, 22 June 2018 (UTC)
CC: @Krauss (who added Wikidata comment at the bottom of the page) --Yurik (talk) 16:34, 22 June 2018 (UTC)
Hi, about notability (relevance) discussion, is important to check "who say that something is important?"... And adopt a mechanism to create Permanent ID only for a thing that is important... It can be so simple as a "watch it" click of Github or Wikipedia pages, but closed concept of the necerrary mechanism is the "capture" concept of Archive.org: eg. the archived openstreetmap.org (other example) need a "COLLECTED BY", indicating person or team that support the link as "relevant" one. At OSM is easy to use something like first-watcher and many endorser-watchers. --Krauss (talk) 16:22, 10 July 2018 (UTC)

Wikidata is a first step

At July 2018 there are:

~1,123,500 OSM features with a wikidata key.
~63,000 Wikidata entities with the OSM relation ID (P402) property pointing to OSM.

It is a good "first step" (!) to be mature in the future. Since now to create and enhance a Permanent ID... Will be easy to generate a really usefull tool, with minimum impact at OSM architecture and infrastruture. The second step will be later, after a good first experience.

As each OSM feature with a key wikidata=specificValue is unique by OSM-type (node/way/relation) we can suppose that "backup recover" or "rebuild OSM" tasks can use it to generate stable IDs before start serial ID.

The "relevance" or "notability" of the OSM feature is also important when there are technical cost or barrier to generate stable IDs. So, as first step we can ellect as "relevant" (to justify the cost) all features that was ellectd by Wikidata as "notable".

About reliability of all checking process: another cost, but we can to control it by software and a little team, and it is the proposal,

WdOsm-semanticBridge.jpg

details at https://github.com/OSMBrasil/semantic-bridge

PS: about "the ID", osm_relataionId is not good, we need also the osm_wayId... Lets use similar infrastructure that used by Nominating as place_id (eg. Berlim is not Q64 neither the relation 62422 but a generic entity place_id=178741737), but changing the "regeneratig all IDs" stupid algorithm to a "read lookup first" to preserve reciprocal-Wikidata stable place_id's... And, labeling it perma_id to avoid confusion with the stupid (non-smart non-permanent) place_id... Although "place_id" is a good label.