Open melvincarvalho opened 1 year ago
{
"@context": ["https://www.w3.org/ns/activitystreams", "http://w3id.org/webid"],
"@id": "",
"primaryTopic": {
"@id": "#me",
"@type": ["Person", "Actor"],
"name": "Will Smith",
"img": "avatar.png",
"storage": "/",
"knows": "http://alice.example/#me",
"followers": "followers",
"following": "following",
"inbox": "inbox",
"outbox": "outbox",
"publickey": "1234abc"
}
}
Instead may be:
{
"@context": ["https://www.w3.org/ns/activitystreams", "http://w3id.org/webid"],
"@id": "#me",
"isPrimaryTopicOf": "",
"@type": ["Person", "Actor"],
"name": "Will Smith",
"img": "avatar.png",
"storage": "/",
"knows": "http://alice.example/#me",
"followers": "followers",
"following": "following",
"inbox": "inbox",
"outbox": "outbox",
"publickey": "1234abc"
}
This isn’t completely clear to me, but I’ll see how it evolves. There are a few technical issues with the latest update. If you prefer, I can create GitHub issues going forward.
The activitystreams @context entry must be first because the WebID context is protected and there are overlapping terms. (There’s a missing comma in the @context too. I’m catching these issues by entering the example document into JSON-LD Playground.)
I’m assuming the Actor type is supposed to be the AP Actor (?). However, there is no Actor term in the AP/AS context. To use AS Person you’d need to specify it as as:Person because of the clash with foaf:Person.
Using as:Person is technically compliant since it’s the result of compacting the document with the normative context (combined with the WebID addition). However, it’s very unlikely to be interoperable with any AP implementation doing simple JSON processing (almost all of them), even if they support multiple types.
(If the AP implementation does support multiple types, it might work in a hacky way. A plain JSON-based app is typically going to consider the “Person” type value as the AP type and ignore the “as:Person” because it doesn’t know what it is.)
This is why I originally suggested adding the AS actor property to the WebID profile and keeping the AP actor documents (and ids/URLs) separate. That way, AP “clients” can dereference the actor and get what they expect and WebID will work as expected too while still linking to the AP resource. It also makes it relatively easy to incrementally add WebID support to an existing AP implementation (compared to a merged document).
https://socialhub.activitypub.rocks/t/how-solid-and-activitypub-complement-each-other-best/727/23