one approach is to just say "well, plain JSON consumers should just stop being so naive". a valid approach, but not very robust!

our goal is to preserve the semantic boundary between different resources but still allow merging those resources naively (as JSON objects rather than as #JSONLD graphs).

instead of saying that a term will *always* mean the same thing in the entire document, we want to allow the same term to be used in different contexts across semantic boundaries (resources)...

6/?

we have *some* tools to deal with this in #jsonld. we can "type-scope" so that an Activity.actor uses a certain definition, and a Movie.actor uses a certain definition, but this requires us to say ahead-of-time that `Movie` will always mean a schema.org `Movie`. it also won't help us redefine protected terms, since "type-scoped" terms don't override protection. only "property-scoped" terms do. but we can't use "property-scoped" terms because that requires an explicit semantic range.

4/?

let's demo this with a simple case. say you want to `tag` something that is a `Movie` described by schema.org. the `Movie` declares that it has an `actor` who performed in it.

this is redefining the term `actor` as defined at the top-level by #activitystreams -- where `actor` means who performed an `Activity`, not who performed in a `Movie`.

if the activitystreams context was protected, then this would be a fatal error for any #jsonld validator. you cannot be sure which `actor` was meant!

3/?

4/

Note that even in this example, that there are different types of labels!

I have some examples of text labels.

But I also have some examples of Icon labels.

(Other types of labels could exist, too.)

3/

The "describes" field would point to the thing being labelled.

The "attributedTo" field would point to the person or machine that create these label.

And the "attachment" field would be a list of labels.

The (top level) "icon" field would be an icon that would be shown next to the label in the user-interface (UI).

2/

A Fediverse Labeler would output a separate ActivityStreams "Profile" Object for each thing it wants to label.

Each of these should be at a separate URL.

I meant "blank node" in the sense described here. I think it's the JSON-LD Term to refer to objects (= nodes) without an id.

So my point was, implementing the ActivityPub inbox/outbox as OrderedCollections for objects without ids is not fun. It means that you either duplicate all activities for every actor that received it, or assign local ids. I like neither option.

I'm not sure how this relates to deleted objects.

Final note: This is not to say that I think Create/Update/Delete activities should have ids. My preference would be to consider ephemeral objects and rethink the Inbox/Outbox (as OrderedCollections). There's a queue/stream flag somewhere for people to take up the cause.

If it is an ActivityPub thing, and you are not checking for the values being Objects or Sets, you are very lucky to have powerful preprocessing.

For example:

"preferredUsername": {
   "@type": "xsd:string", 
   "@language": "en",
   "@value": "helge"
}

would be 100% reasonable. Thanks to json-ld. Now, imagine that I had a name like "John" that people in Germany would like to Hannes, I would totally use:

"preferredUsername": [{
   "@type": "xsd:string", 
   "@language": "en",
   "@value": "john"
}, {
   "@type": "xsd:string", 
   "@language": "de",
   "@value": "hannes"
}]

and expect people from Germany to address me as hannes@mydomain.example and people from the United States as john@mydomain.example.

I totally think that I have just reached maximal "beauty" in my usage of JsonLD, ActivityPub, Webfinger, and i18n.