@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 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"

@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.

@jens of course combining the two documents is easy. it's splitting them apart that's challenging. like trying to separate two balls of differently colored play-doh.

the act of injecting movie.json (json, ld+json, hypothetically schemadotorg+json) into like.json (json, ld+json, activity+json) is impure wrt the resource <ghostbusters>. the semantics of activity+json are leaking in and through the semantic boundary of the original two resources.

so either plug the leak, or don't combine. right?

@jens well, people are combining anyway and not plugging the leak, because they don't know the leak is there.

it's like trying to fit two sections of a water pipe together, except instead of properly screwing them into a fitting, you just glue them together without the fitting.

ideally people would stop gluing together their pipes and use proper fittings instead, but at least i can scrape off the glue and use my own fitting, i guess?

@jens this is all from the angle of taking arbitrary JSON and "upgrading" it to JSONLD, sure, but even without JSONLD you are still doing the arithmetic in your head.

the same kinds of complexity issues exist for other media formats too. no one said building a web browser was easy!

/fin

@trwnh Again, though, ".actor" and ".object.actor" have different semantics, because of the semantics of ".object", so there really isn't a problem IMHO.

‍️

@jens they can be the same semantics actually

id: foo
actor: i
type: Like
object:
id: bar
actor: you
type: Like
object: that

".object" doesn't imply any semantics for <bar>, nor does it imply anything for ".object.actor" or any other properties. that's because <foo> and <bar> are in essence separate resources

it's semantically equivalent to saying

- id: foo
actor: i
type: Like
object: bar
- id: bar
actor: you
type: Like
object: that

only the serialization is different.

@jens (in jsonld this is the difference between compacted form and flattened form)

@jens they can be the same semantics actually

id: foo
actor: i
type: Like
object:
id: bar
actor: you
type: Like
object: that

".object" doesn't imply any semantics for <bar>, nor does it imply anything for ".object.actor" or any other properties. that's because <foo> and <bar> are in essence separate resources

it's semantically equivalent to saying

- id: foo
actor: i
type: Like
object: bar
- id: bar
actor: you
type: Like
object: that

only the serialization is different.

@trwnh Again: this is *only* the case if your mental model is LD. That is what I keep trying to get across.

If your mental model is "structured data", then you *cannot* assume two different structures have the same semantics.

You want to make LD "safe" for structured data processors. That is only going to happen, IMHO, if you accept how structured data processors deal with semantics.

Instead, you seem to complain that structured data processors aren't linked data processors.

I don't want...

@trwnh ... to offend you, quite the contrary! But this really isn't going to work, and I am trying my best to get you to understand that.

JSON is just a serialization format from an LD perspective. But from a JSON perspective, LD is just payload; semantics derive from position within the structured data (and specs relating to those positions).

To make JSON-LD compatible with JSON processors is to embrace the structured data model.

@trwnh Or to go back to a previous phrasing: you think in terms of knowledge graphs. In JSON, the graph *is* the structure of the serialization.

You cannot make JSON understand a knowledge graph *unless* you map it into the graph structure that JSON understands. Anything else is futile.

@jens i’m not “complaining”, and it’s not even about LD per se; it’s about the boundary between resources. what you call “two different structures” can be combined without regard for semantics. i just want to preserve semantics.

if the JSON vs JSONLD thing is tripping you up, then consider an example where someone dumps the json to a plaintext string and tries to do an even more naive string find-and-replace. or consider an example where someone manipulates the raw bytes

@jens no offense taken, btw!

@jens if the argument is “they can’t be combined while preserving JSONLD semantics”, i would argue that they can. if anything, they can’t be combined while preserving *JSON* semantics, because nesting a JSON object under a certain key in the document fundamentally alters the semantics of that nested object (if i understand you correctly)