[OSM-talk] Id stability

[Kate Chapman]

I'm not sure I understand why having the ability to link to external
data through some sort of ID is such a bad thing.  This is common in
many APIs and datasets.   It is an opportunity to mix data in new ways
as well.

Frederik also this seems odd to me " I'm not a big fan of UUIDs
because, again, it burdens *our* data with stuff
 that other people want to do with it."  Define other people, do you
mean mappers, data users?  Why aquiesce to use tags at all, making
data more consistent just burdens *our* data with stuff other people
want to do with it.

I think being able to link between datasets can be beneficial.  Maybe
versioning on the API makes sense, maybe UUIDs, but I don't think the
linking is such a bad thing.

-Kate

On Tue, Aug 2, 2011 at 5:31 PM, Frederik Ramm <frederik at remote.org> wrote:
> Andrzej,
>
> andrzej zaborowski wrote:
>>
>> Or create an OSM relation containing just the thing you want to link
>> to and reference the relation's Id.... the editors already support
>> warning when somethign bad happens to a relation member.
>
> Under no circumstances should we burden the mapper with keeping up external
> IDs that someone needs for their application. A relation being edited is not
> "something bad happening", it is something good. We don't want to discourage
> edits, or make them more complex, just so that someone's linked data store
> continues to function - that must be *their*  job, not the mapper's.
>
>> Relations
>> are unlikely to be reused for a compeltely new purpose and they can be
>> undeleted and modified to match changes in reality.
>
> Just because you cannot think of anything right now doesn't mean that (a)
> there isn't anything and (b) there won't be anything in the future. If you
> promise relation ID stability to anyone now, you reduce what *we* can do
> with *our* data in the future.
>
> (One example off the top of my head: Relations for long-distance routes are
> often created in several places at the same time, then they grow until they
> "meet", and are merged, with one of them being deleted.)
>
>>> Of course you would add a UUID tag only to objects that are actualy
>>> referenced. And then you would need some way to enforce uniqueness.
>>
>> Because of the above I'm not sure if you want to enforce uniqueness,
>> you might even want >1 UUIDs per osm entity.
>
> I'm not a big fan of UUIDs because, again, it burdens *our* data with stuff
> that other people want to do with it. We had a lot of discussion about this.
> Andrzej ist right - if five-star restaurant "Chez John" is in a listed
> building, then someone compiling a directory of listed buildings would have
> to use another UUID than someone compiling a list of good restaurants,
> because the restaurant could move elsewhere and it would then have to take
> its UUID with it. Consequently, people have started to use UUID:building and
> UUID:amenity keys but I really have a very bad feeling about this.
>
> Coming back to what Maarten has said above, I would definitely be against
> adding UUIDs to every single house and garden shed "just in case" - like the
> 75.000 "uuid:building" tags we have. If we were to do UUIDs we would have to
> have a way of finding out whether something is actually linked, and if it
> isn't, then don't bother having an UUID.
>
> Which brings me back to something I mentioned earlier - I would like to have
> some kind of "link server" where you can go and say "I want a permanent link
> to this OSM object", then the server says "ok, I have investigated the
> object you mentioned and I'd say I make the permanent link point to 'a
> restaurant named Chez John within 500 metres of this location', is that ok",
> and you go "yes", and the server then says "your permanent link ID is
> 1234567890, thank you". At any later time you can query the server for that
> permanent link ID and you get back either the OSM object, or the current OSM
> object ID, or nothing if the link is broken.
>
> The great thing about such a server would be that the server could indeed
> *always* know which links are still working and which are broken, and broken
> links could even be automatically highlighted on something like
> OpenStreetBugs so anyone who is interested could hunt them down and fix
> them. The server could also track which links are actually used, and expire
> them if they aren't used for a year or so.
>
> This would make one great project for a student thesis (Claus, are you still
> reading...?). I don't know if this is compatible with the linked data store
> idea, maybe explicitly having to register a link is a problem there, but if
> that's the case then I'd say linked data store is just not for us.
>
> And to Steve Bennett ("people need a solution now, not vapourware") -
> sometimes settling for a half-baked solution too early has the risk of
> entrenching half-bakedness and never getting around to implement a good
> solution.
>
> Bye
> Frederik
>
> --
> Frederik Ramm  ##  eMail frederik at remote.org  ##  N49°00'09" E008°23'33"
>
> _______________________________________________
> talk mailing list
> talk at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>