@bakaniko @evan @Bristow_69 @tykayn @vinber what use case do you imagine ?
@cquest @bakaniko @Bristow_69 @tykayn @vinber
For ActivityPub, we have a `location` attribute for every activity type and for content objects. So, "This photo was taken in Antwerp" could be encoded with:
```
{
"type": "Image",
"location": https://activitypub.openstreetmap.example/node/1765433658
}
```
FB, Twitter have their own gazetteers for this, but on the fediverse it would be cool to use OSM.
@evan
Interesting idea! How do you navigate longevity?
On Wikipedia, there would be an article named "Antwerp", and it would likely stay there for a long time. On #OSM, in my understanding anyone could delete it at any time, and it could be re-created by several people with different attributes. Is the data model really suitable for providing external references?
@cquest @bakaniko @Bristow_69 @tykayn @vinber
@schmidt_fu @cquest @bakaniko @Bristow_69 @tykayn @vinber Oh, interesting. I can't say I understand the OSM data model very well; I kind of assumed that nodes, relations and ways would get updated but keep their ID. You're saying that, if I added a new translation to "Antwerp", or an altitude or a link to Wikidata or something, it would get a whole new ID?
@evan
I'm not an expert on the admin's possibilities either, but from a user/editor perspective:
No, changes to the object are not a problem, the ID stays the same.
But there is no inherent protection of a certain object not to be deleted (like on Wikipedia), and on re-creation it would get a completely new ID. Maybe a single node can be restored, but in cases like the recent large-scale vandalism on Tel Aviv it gets messy:
https://www.kiratas.com/2023/10/30/vandalism-on-openstreetmap-tel-aviv-is-slowly-being-restored/
@cquest @bakaniko @Bristow_69 @tykayn @vinber
@evan @schmidt_fu @bakaniko @Bristow_69 @tykayn @vinber the id remains as long as you’re updating the object, but sometimes it’s not enough like when a POI defined by a node is improved and becomes a way
@cquest @schmidt_fu @bakaniko @Bristow_69 @tykayn @vinber meh, that's probably fine.