[OSM-dev] OSM IDs as foreign keys (was: ODbL "virality" questions)

[Frederik Ramm]

Hi,

(for those on dev; this started out as a discussion on whether or not we 
want to put any legal/license restrictions on external users linking to 
OSM objects for identification, e.g. a restaurant guide saying "this pub 
is OSM node #12345")

Matt Amos wrote:
> i would hope so too, as it makes OSM data more attractive for those
> users who don't need to manipulate the data, but need to annotate it
> or reference it. i, for one, would really like to see the next
> beerintheevening or tripadvisor based on OSM data, not just the tiles.

My problem with this is that while I'd gladly allow anybody to do that 
from a licensing point of view, I'd rather not have people do that from 
a technical point of view (and that's why I'm switching over to dev with 
this).

Personally I view OSM object IDs as quite frail, and subject to change 
without notice at any time. I do not think that OSM object IDs should be 
used as foreign keys in any application. I even object to all those 
lists on the Wiki which point to hard-coded relation IDs - I, for one, 
will delete and re-create an object any time without much thought if it 
makes sense to me, breaking any such external entry point.

I fear that if many people treat OSM IDs as permanent, this will have a 
restraining influence on us editing our own data ("I wanted to replace 
this restaurant node by a building outline for the restaurant but then I 
got complaints from users of 15 restaurant guides and Flickr because the 
restaurant had suddenly vanished there, and so I reverted my edit").

Until now, if someone asked me a question in that direction, I always 
said they should make their own ID a foreign key and tag the OSM object 
with something like "restaurant_guide_xyz_id:1234". Which is not ideal 
from a data access perspective of course, but allows people editing OSM 
to properly work with that.

If we really want to head in a direction where external users refer to 
OSM objects, then I think it would be wise to manifest that in the 
database somehow, and create some kind of "permanence API" or so, where 
you can request a permanent handle for a certain object from the API, 
and the API will give you a number, and then if someone deletes and 
re-creates an object they will be able to transfer that number to the 
new object somehow.

This is of course something for the future, but letting external users 
refer directly to OSM IDs sounds like asking for trouble to me.

Bye
Frederik