Hi, All use cases you describe are valid. It's up to the users of OSM permanent id to keep track of changing OSM ids - it's an offer of OSM. The only constraint I would propose is to avoid to delete and recreate a new id only because of a tool (like an editor) likes to do it like this.
The concept of permanent, unique and never-reused object ids is a well-known property in the Object-Oriented and Linked Data technology. As I said: The killer criteria not to use overpass-approach is that there exist many OSM objects which have too few or no tags at all. And using coordinates as identifiers is no solution neither because it's a float number with different precision and implementation dependent. OO overcame exactly this restriction of the relational paradigm (which identified a tupel by the set of it's values). Responsible for the unique generation of a permanent id is finally the OSM server instance(s). In case the OSM servers are distributed a distributed id scheme is applied as in NoSQL databases and here [1]. Yours, Stefan [1] http://www.interlis.ch/oid/oid_e.php 2013/5/7 Peter Wendorff <[email protected]>: > Hi. > > Do you have any idea how this permanent ID could look like? > You dislike the overpass-approach (and yes, it's far from perfect). > What is your idea how a stable permanent ID to an object may be achieved? > > Let's use a shop as an example (and wikidata as the foreign database as > an example, too). > > 1st stage: it's not mapped at all - okay, nothing to link to. > 2nd stage: someone maps a shop - and only that shop, without name or > anything like that. Wikidata could of course link to the osm id, even if > it only contains a coordinate and "shop=supermarket", but if they want > to do that, they have more information they could add to osm easily, > like name and usually at least parts of the address. > 3rd stage: someone (e.g. the wikidata people) adds these details - the > overpass-api get's slightly more stable (I know, not completely stable > of course). > 4th stage: someone replaces the node by a polygon mapping the > supermarkets building as a whole. Now the osm id has changed, so your > approach to use that as a link key fails here. > 5th stage: someone refines that polygon to include the hole in the > middle, so it get's a multipolygon relation. again the internal osm id > changes, the overpass-api (when designed usefully) is kept. > > 6th stage: the name of the shop changes (small change due to corporates > decision, nothing really useful): The osm id is stable here, overpass is > likely to fail now (but knows about this failure as it's possible to > acknowledge the dead link). > > 7th stage: the shop moves to another address, therefore the tags are > moved to another building, let's say, 3 streets away. The OSM id looks > like it's still stable, but links to the wrong object. The overpass-id > is either still valid or is automatically known to be a dead link. > > I agree, that the overpass-api isn't perfect and it's still possible to > produce links that are either (or may get) ambiguous or that may break > due to any edit in future. But the internal OSM ID has even more > drawbacks: while the overpass-permanent-id includes semantics for the > link, the osm id is a pure technical link. > > I'm keen to get a better idea how that could be achieved, or why you > really think that the osm id is really better than overpass with respect > to stability and maintainability. > > regards > Peter > > Am 07.05.2013 00:31, schrieb Stefan Keller: >> Hi, >> >> I also think that linking from an OSM object to a growing no. of >> external databases (incl. Wikipedia/Wikidata) is not a good idea. And >> I respect the wish of the OSM maintainers to change the OSM id in the >> future. But the overpass-permanent-osm-id is no solution neither, >> primo because a set of key-values is a clumsy id, and secondo because >> there exist many OSM objects which have no identifying tags (or none >> at all). >> >> As this issue pops up from in increasingly frequent intervals I think >> it's time to think about a good mid term solution (short term is >> sticking to the OSM id). >> >> I'm proposing a solution alongside one of the following two directions: >> * either to implement a Linked Data API/service which maps from >> permanent ids to OSM objects (and which is what I like about overpass >> - being a service) - >> * or to add a permanent id as an additional XML tag to every OSM >> object! And if somebody thinks that's a waste of space we can easily >> drop the XML tag "user" which is completely redundant to "uid" (which >> in turn needs another simple API to find out the current users display >> name). >> >> Yours, Stefan >> >> >> >> 2013/5/6 Peter Wendorff <[email protected]>: >>> Am 06.05.2013 23:07, schrieb andrzej zaborowski: >>>> Hi, >>>> >>>> On 6 May 2013 21:20, Peter Wendorff <[email protected]> wrote: >>>>> Am 06.05.2013 20:26, schrieb Tobias Knerr: >>>>>> On 06.05.2013 18:54, Peter Wendorff wrote: >>>>>> >>>>>> [...] >>>>>>> Let's see this example: A building that was a merchants kontor a few >>>>>>> hundret years ago, and now contains a museum and a restaurant, while in >>>>>>> between it was - let's say - a hospital). >>>>>> >>>>>> That's historical mapping. The problems would be the same for e.g. the >>>>>> name. But as for the parts of the example that are not directly >>>>>> "historic": >>>>> >>>>> No, it's not. I did not speak about mapping the hospital and the >>>>> merchants kontor, but about wikidata entries ahout the hospital and the >>>>> merchants kontor - and wikidata in fact includes historical entities >>>>> like that, too. >>>> >>>> If you're not adding those historical entities to OSM (or a similar >>>> database like that historical osm once discussed) then there's no >>>> issue with linking to Wikidata because there's nothing to be linked. >>> >>> Why not? >>> The building is the same, and it's not of interest, that the tag >>> amenity=museum is not (any more) existent in osm. >>> >>> If that's an argument any wikidata entity that's not tagged as complete >>> as the wikidata entity itself would be "nothing to be linked". >>> >>> Your cross-reference (only add a reference osm pointing to wikidata to >>> the building, but link all other entities of wikidata to the building) >>> argument may be valid, but it's complex (that's my question below); but >>> especially historical entities are of interest to be linked, as they are >>> not directly findable by going out and watch. >>> >>> >>>> [...] >>>>>>> - the restaurant's page >>>>>> >>>>>> Can be linked using the wikidata key at the restaurant POI. >>>>> You assume here that osm has distinct objects for building, restaurant >>>>> and museum, but often that's not the case. >>>>> Let's say the building mainly "is"/hosts the museum, and the restaurant >>>>> is a small part of it, covering a part of the building only (may be part >>>>> of the museum, too. >>>> >>>> If it doesn't occupy the entire building then you can probably add the >>>> museum tag on the building geometry but later once you want to add a >>>> wikidata tag you'd probably split it out like you'd split a street >>>> object when you want to add an attribute that applies to a part of the >>>> attribute. If you're into indoor mapping then you'd draw the museum >>>> outline separately anyway. >>> so you propose to split it up because of an external ID you propose to >>> add... >>> While I in general agree that objects of osm are split when they get >>> mapped in more detail (like in this example), I'm not happy to do that >>> for the reason to enable matching to external references. >>> >>>> Or you could do namespaces, basically using the same criteria as with >>>> different attributes. For example opening_hours which may be >>>> different for the museum and the building. The mechanism can be the >>>> same for wikidata=* as for e.g. opening_hours=* and oneway=*. >>> and it's not working for opening_hours either afaik; usually we split >>> the pois in these cases. >>> >>>>>> [...] >>>>>>> Perhaps look into the overpass-permanent-ID solution for that. >>>>>> >>>>>> In my opinion that's not really a good solution here. Manually creating >>>>>> Overpass API queries is too hard. >>>>> That's true, but what you propose is (yet) hard, too: >>>>> To decide where to link to wikidata and where to rely on wikidatas >>>>> internal links requires deep knowledge about the wikidata system, which >>>>> is IMHO not acceptable as a general precondition for mappers (whose >>>>> majority will have to deal with that in future to keep these links >>>>> reasonably up to date). >>>> >>>> Again mappers are already dealing with this problem when they add >>>> phone= or website= tags. There's no clear criteria but it's not a a >>>> problem specific to wikidata links. >>> Of course not, but even the external id problem is not specific to >>> wikidata links. >>> >>> Wikipedia links are for a long time relatively stable, and as wikipedia >>> I think is often used as one reference for osm, too, it's widely >>> accepted to be of benefit for both sides. >>> >>> Wikidata is not yet proven that stable nor that useful, and - >>> especially: it's a data project. It would be a great task and solution >>> to design e.g. an overpass-permanent-osm-id-editor that defines the link >>> in a useful gui (e.g. derived from wikidata attributes like country, >>> county, city, postcode, location/coordinate, address, ... which might be >>> part of wikidata, I think. >>> >>> Wikidata links are harder to maintain, nearly impossible to check >>> (without opening the page), while wikipedia links have meaningful names. >>> >>> Wikidata links currently are mostly duplicates of wikipedia article's >>> entities (as that's the big imported stuff from the beginning). >>> >>> Therefore I personally oppose currently to reference wikidata entities >>> from osm objects; at least where no good rules exist where and when to >>> link which types of objects, and which not. >>> >>> regards >>> Peter >>> >>> _______________________________________________ >>> talk mailing list >>> [email protected] >>> http://lists.openstreetmap.org/listinfo/talk >> > > > _______________________________________________ > talk mailing list > [email protected] > http://lists.openstreetmap.org/listinfo/talk _______________________________________________ talk mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk
