@jens well, syntactically it’s either a JSON string (meant to be parsed as an id reference) or a JSON hash… or a JSON array containing either of these. (except the naive processor is so naive they probably don’t understand arrays because they expect a single value in all cases.)

semantically, it’s saying “jens created something”, where the object of the sentence “something” can be whatever. you need to dereference “something” to get… 100% arbitrary information about it

@trwnh Just to distinguish this *a little*, the syntax is JSON, and JSON processors will likely only process the document if it's valid JSON.

Whether the value is an object, array, string or other JSON type is technically still part of the key's semantics, which should be defined.

FWIW, I'm not hung up on whether you count that as part of syntax or semantics. It's basically a layering issue. If you look top down from meaning to bit stream, it seems more like syntax. But if you look bottom...

@trwnh ... up, once you've turned a bit stream into structured, typed data, it's semantics.

The key thing is how much meaning you assign to the notion of type here. You essentially treat type as "the full, abstract meaning is encapsulated" whereas I treat it as "I can distinguish it in code well enough to keep it apart from other types".

The point being, it should be part of the specifications of the key whether a string, array or object is *valid* here.

It's totally fine to e.g. say it has..

@trwnh ... to be an object with a "type" field that specifies other valid fields, or an array of such objects, or a JSON reference pointing at such an object or array.

And then I can still write a naive-ish processor that can handle this, or a very naive processor that doesn't care at all about the value.

But I do not have to know all possible type values or what they imply for the value.

This is where you can go and say "well, but if I use LD for those objects, I can reason about stuff...

@trwnh ... without hardcoding knowledge about different types", and that's true.

But that isn't preventing a naive JSON processor from doing sensible things at the parent layer, nor is it preventing a semi-naive JSON processor to do sensible enough things with those objects for which it has some knowledge hardcoded.

Again, it's only when you want to use LD to manipulate the entire document as a knowledge graph that you run into issues.

That isn't really necessary, though. It's why I...

@trwnh ... brought up MIME as a very robust encoding that allows for namespacing and so keeps processors from having to know everything about everything, prevents them from having to understand a complete generic data model, and still allows them to selectively process individual fields.

There's a reason MIME is living for this long.

@jens i think we’re mostly on the same page except for the bit about what a key’s semantics are. {id: foo, bar: {id: baz}} says that foo has a property bar whose value is baz. it doesn’t say anything about baz.

<foo>.actor and <baz>.actor mean different things in different documents, despite being a top-level key `actor` in both.

the analogy to MIME is that each document can be thought of as having a different media type, despite both being nominally json and/or ld+json

@jens there is a concept in later jsonld-based specs of “media type specificity”: a document that is application/cid is also implicitly application/ld+json, and also implicitly application/json, and arguably also text/plain, and arguably also application/octet-stream. each specific media type is a refinement of the one before it, or in other words, a more specific media type is just adding more constraints and semantics on top of everything before it.

@jens so consider one document is application/activity+json and the other document is a hypothetical application/schemadotorg+json. you want to merge them as ld+json and that’s fine; no issues. but the result is no longer purely activity+json, because a subnode is redefining `actor` according to schemadotorg+json. this is still fine if you allow for extended activity+json, but naive agents don’t know how to properly handle extensibility while reserializing for others.

@jens again though, it’s not a fatal error unless a term is protected, which usually happens as part of defining an IANA media type. the newer jsonld based media types provide a protected context that guarantees e.g. that `service` ALWAYS means the same thing in a document of type application/did. you can’t redefine `service` later in the document and still call the result semantically valid“application/did”. it would, however, be valid ld+json, if not for protected terms

@jens all’s well and good as long as you don’t reserialize two documents into a combined document without accounting for the difference in semantics.

this is, unfortunately, what naive agents are quite likely to do, because they are so completely unaware of the difference in semantics. their processing doesn’t have even a *concept* of semantics higher than JSON.

not *strictly* a problem for now, since activity+json’s context is not protected, but it could be.

@jens this isn’t to say that semantics are being unhandled entirely… think of it as if the semantics are being understood at an agent level instead of at a data format level. it’s like, instead of using an svg processor, you open it in a text editor and manually edit the text of the svg. if you’re not careful, you might create a syntactically valid xml document but you have altered the resulting svg image in a way you might not understand.

@trwnh You know, I understand what you're writing, but don't seem to get across what I mean. I'll step away from this. Maybe I'll figure out a different way to say it ‍️

@jens it's mostly this part:

> it's only when you want to use LD to manipulate the entire document as a knowledge graph that you run into issues.

which is incorrect, so there's still some miscommunication on my part.

the issues occur when you use *JSON* to manipulate a *serialization*, like doing a find-and-replace on an English sentence resulting in nonsense.

it's like a student says "I is..." and the teacher says, "no, it's *am*", so the student says "I am the ninth letter of the alphabet"

@jens i get a sense that we're looking at it from somewhat unrelated angles... like, you're saying

> it should be part of the specifications of the key whether a string, array or object is *valid* here

except they're all valid. we just can't constrain it any further. an `object` of an Activity is... the activity's object. this describes the activity but it doesn't describe its object

so JSON semantics are fully defined, but there's still a higher level of semantics

@jens that's all, really -- if we're going in circles then it probably isn't productive to continue, as you say.

@trwnh So we do arrive at it from two different points of view. That much is clear.

What my impression is, is that you have a linked data type of model firmly in your head, and JSON-LD is compatible with that. A pure JSON processor won't understand that, and mess with things.

What I'm trying to get across is that having the linked data model as a starting point when you *know* pure JSON processors will be involved is a mistake.

You can still *use* LD, you just can't use it as a precondition.

@jens i guess i don't really think "generic json processing" or "generic xml processing" really makes any sense. it's like trying to do "generic plaintext processing" or "generic octet stream processing". there should be *some* precondition of shared understanding; otherwise, communication breaks down. this understanding is baked into the application logic, media type, etc... and it always exists at least implicitly, although it can be explicitly described

@jens so the goal of the thread was to take something like "i before e except after c" and extend it to account for edge cases: "or unless it's followed by an r or a g"

the takeaway is basically "jsonld context authors should consider disabling propagation when using protected terms across semantic boundaries (like when merging two documents)"

the alternative is to never do a JSON find-and-replace, and instead strictly process the two documents separately.

@jens

basically this is fine:

{"id": "foo", "actor": "i", "type": "Like", "object": "ghostbusters"}

{"@\context": "schema.org", "id": "ghostbusters", "type": "Movie", "actor": "bill-murray"}

and this would be problematic if activity+json used a protected context:

{"id": "foo", "actor": "i", "type": "Like", "object": {"@\context": "schema.org", "id": "ghostbusters", "actor": "bill-murray"}}

note that activity+json doesn't currently use a protected context... but arguably it does in spirit.