C2S Update Activity (Versioning)

C2S Update Activity (Versioning)
Hi there, just throw a look into ActivityPub but there is not really a clear info about my question.

I created an Object with an create activity (http://localhost:8080/actor1/objectA).

turtle:

<http://localhost:8080/actor1/objectA> a <https://www.w3.org/ns/activitystreams#Object>,
    <https://schema.org/Thing>;
  <https://www.w3.org/ns/activitystreams#name> "Max";
  <https://schema.org/version> "1" .

json-ld:

[
	{
		"@id": "http://localhost:8080/actor1/objectA",
		"@type": [
			"https://www.w3.org/ns/activitystreams#Object",
			"https://schema.org/Thing"
		],
		"https://www.w3.org/ns/activitystreams#name": [
			{
				"@value": "Max"
			}
		],
		"https://schema.org/version": [
			{
				"@value": "1"
			}
		]
	},
	{
		"@id": "https://schema.org/Thing"
	},
	{
		"@id": "https://www.w3.org/ns/activitystreams#Object"
	}
]

Now i send an update activity that changes the name from “Max” to “Anton”. This has to be a partial update.
But my understanding is (and i think that matches to @pukkamustard content based adressing) that the new object should have a new id.

turtle:

<http://localhost:8080/actor1/v2_objectA> a <https://www.w3.org/ns/activitystreams#Object>,
    <https://schema.org/Thing>;
  <https://www.w3.org/ns/activitystreams#name> "Anton";
  <https://schema.org/version> "2" .

json-ld:

[
	{
		"@id": "http://localhost:8080/actor1/v2_objectA",
		"@type": [
			"https://www.w3.org/ns/activitystreams#Object",
			"https://schema.org/Thing"
		],
		"https://www.w3.org/ns/activitystreams#name": [
			{
				"@value": "Anton"
			}
		],
		"https://schema.org/version": [
			{
				"@value": "2"
			}
		]
	},
	{
		"@id": "https://schema.org/Thing"
	},
	{
		"@id": "https://www.w3.org/ns/activitystreams#Object"
	}
]

That is how i will implement the update. Does anyone see an incompatibility with the activityPub specification?

I think about it, or rather i wonder if i should concatenate the versions, e.g. like this:

turtle:

<http://localhost:8080/actor1/objectA> a <https://www.w3.org/ns/activitystreams#Object>,
    <https://schema.org/Thing>;
  <https://schema.org/nextItem> <http://localhost:8080/actor1/v2_objectA>;
  <https://www.w3.org/ns/activitystreams#name> "Max";
  <https://schema.org/version> "1" .

<http://localhost:8080/actor1/v2_objectA> a <https://www.w3.org/ns/activitystreams#Object>,
    <https://schema.org/Thing>;
  <https://schema.org/previousItem> <http://localhost:8080/actor1/objectA>;
  <https://www.w3.org/ns/activitystreams#name> "Anton";
  <https://schema.org/version> "2" .

json-ld:

[
	{
		"@id": "http://localhost:8080/actor1/objectA",
		"@type": [
			"https://www.w3.org/ns/activitystreams#Object",
			"https://schema.org/Thing"
		],
		"https://schema.org/nextItem": [
			{
				"@id": "http://localhost:8080/actor1/v2_objectA"
			}
		],
		"https://www.w3.org/ns/activitystreams#name": [
			{
				"@value": "Max"
			}
		],
		"https://schema.org/version": [
			{
				"@value": "1"
			}
		]
	},
	{
		"@id": "http://localhost:8080/actor1/v2_objectA",
		"@type": [
			"https://www.w3.org/ns/activitystreams#Object",
			"https://schema.org/Thing"
		],
		"https://schema.org/previousItem": [
			{
				"@id": "http://localhost:8080/actor1/objectA"
			}
		],
		"https://www.w3.org/ns/activitystreams#name": [
			{
				"@value": "Anton"
			}
		],
		"https://schema.org/version": [
			{
				"@value": "2"
			}
		]
	},
	{
		"@id": "https://schema.org/Thing"
	},
	{
		"@id": "https://www.w3.org/ns/activitystreams#Object"
	}
]

I am curious about your opinions

In federation, the current practice is delete and redraft. This means that foreign instances are expecting a tombstone or similar on the old version and a new id for the amended object. Whatever convention your software uses for version information will neither cause undesired operation in nor interoperate with software that operates over federation

There aren’t C2S implementations to compare, yet, but I’d expect future implementations to be similarly oblivious to implementation details in naming. Since the server tells the client the ID of created objects, it should “just work”

Since the question was open ended, let me volunteer my bias for making sematic information in a URI a path segment, with segments ordered from general to specific:

Base_URI/path/ID/V

I don’t understand why an Update activity would change the ID of an object, and I would expect doing so to break most implementations. The C2S spec implicitly requires this by saying “the object [ID reference] MUST be modified to reflect the new structure as defined in the update activity”, and the S2S spec explicitly requires this: " an Update activity means that the receiving server SHOULD update its copy of the object of the same id to the copy supplied in the Update activity"

ok, 2 answers 2 opinions. :wink:
@nightpool “I don’t understand why an update activity would change the ID of an object”
That’s one way of looking at it. The question is whether an object that changes can be the same as the one it was before the change?

A solution to both would be to give a head/latest id as the id.

@AceNovo I would prefer to have the id in the “localname”.

  • protocol:namespace:V_ID
  • protocol:namespace:HEAD_ID

Clarifying my position: Update should keep the same identifier on an object; But don’t update. Use delete and a new create if compatibility when you federate is a goal, because caching is hard problem

The ideal situation would be if objects could have multiple identifiers, i.e. instances generally supported lists of equivalent identifiers rather than just a string with a single identifier. In that case, you could have both a canonical object URI and a URI for the specific version in the ID of the object and you wouldn’t need to pick one and munge the object to federate safely

I thought about my requirement again and as an AP C2S client I am able to create a new object for a change and link it to the previous version. so the versioning and linking of the objects with the same identifier can be done in the client. I will make a prototype soon, as I will import such data into rdf-pub anyway. I will report back.

These are my current thoughts.

My Client(Adapter for an existing system) manages Publications which are from type schema:CreativeWork & as:Object.
This are additional types my client uses:

loa:PublicationVersions a rdfs:Class ;
    rdfs:label "PublicationVersions" ;
    rdfs:comment "Meta informations about different versions of a schema:Publication." ;
    rdfs:subClassOf schema:Thing ;    
    rdfs:subClassOf as:Object .
    
loa:publications a rdf:Property ;
    rdfs:label "publications" ;
    rdfs:comment "A sequence of different versions of a publication." ;
    rdfs:range rdf:Seq ;
    rdfs:domain loa:PublicationVersions .

loa:latestPublication a rdf:Property ;
    rdfs:label "latest publication" ;
    rdfs:comment "The latest version of the publication." ;
    rdfs:range rdf:Resource ;
    rdfs:domain loa:PublicationVersions .

And a sample in turte looks like that:

<http://example.com/publication_0815_1> a <https://schema.org/CreativeWork>, <https://www.w3.org/ns/activitystreams#Object>;
  <https://schema.org/identifier> "0815";
  <https://schema.org/version> "1"^^<http://www.w3.org/2001/XMLSchema#int>;
  <https://www.w3.org/ns/activitystreams#name> "publicationA" .

<http://example.com/publication_0815_2> a <https://schema.org/CreativeWork>, <https://www.w3.org/ns/activitystreams#Object>;
  <https://schema.org/identifier> "0815";
  <https://schema.org/version> "2"^^<http://www.w3.org/2001/XMLSchema#int>;
  <https://www.w3.org/ns/activitystreams#name> "publicationB" .

<http://example.com/publication_0815_3> a <https://schema.org/CreativeWork>, <https://www.w3.org/ns/activitystreams#Object>;
  <https://schema.org/identifier> "0815";
  <https://schema.org/version> "3"^^<http://www.w3.org/2001/XMLSchema#int>;
  <https://www.w3.org/ns/activitystreams#name> "publicationC" .


<http://example.com/publicationVersionsA> a <https://linkedopenactors.org/ns/loa#PublicationVersions>,
    <https://www.w3.org/ns/activitystreams#Object>;
  <https://linkedopenactors.org/ns/loa#PublicationVersions> <http://example.com/publicationVersionsAVersions>;
  <https://linkedopenactors.org/ns/loa#latestPublication> <http://example.com/publication_0815_3>;
  <https://schema.org/identifier> "0815";
  <https://www.w3.org/ns/activitystreams#name> "publicationVersions_0815" .

<http://example.com/publicationVersionsAVersions> a <http://www.w3.org/1999/02/22-rdf-syntax-ns#Seq>,
    <https://www.w3.org/ns/activitystreams#Object>;
  <http://www.w3.org/1999/02/22-rdf-syntax-ns#_1> <http://example.com/publication_0815_1>;
  <http://www.w3.org/1999/02/22-rdf-syntax-ns#_2> <http://example.com/publication_0815_2>;
  <http://www.w3.org/1999/02/22-rdf-syntax-ns#_3> <http://example.com/publication_0815_3>;
  <http://www.w3.org/2000/01/rdf-schema#member> <http://example.com/publication_0815_1>,
    <http://example.com/publication_0815_2>, <http://example.com/publication_0815_3> .

So in the initial load case, i post a create activity with <http://example.com/publicationVersionsA> as object. In further calls i post a create activity with a new publication and a update activity for <http://example.com/publicationVersionsA> and <http://example.com/publicationVersionsAVersions>