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/?

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/?

in "property-scoped" terms, we would have to say that `tag.*.actor` *always* means either Activity.actor or Movie.actor. in effect, we are saying that every `tag` MUST be an Activity, or MUST be a Movie. in other words, our semantic range is no longer unbounded.

now, remember this problem only happened because we naively merged in a JSON resource into another JSON resource, leading to a conflict between the two contexts. what's a better way to handle graph merges while maintaining context?

5/?

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/?

in "property-scoped" terms, we would have to say that `tag.*.actor` *always* means either Activity.actor or Movie.actor. in effect, we are saying that every `tag` MUST be an Activity, or MUST be a Movie. in other words, our semantic range is no longer unbounded.

now, remember this problem only happened because we naively merged in a JSON resource into another JSON resource, leading to a conflict between the two contexts. what's a better way to handle graph merges while maintaining context?

5/?

another approach is to disable propagation. but this is something context authors have to choose to do, and for terms that *do* need to propagate, you'd need to include a duplicate definition as a "property-scoped" term.

simplest example: we might say that none of the terms propagate, and that a context declaration should be included for every individual qualified resource. put a context on the top-level Activity, on the actor, and on the object. this enables naive JSON merging.

7/?

@trwnh JSON namespaces keep rearing their head. This expired draft has one: https://datatracker.ietf.org/doc/id/draft-saintandre-json-namespaces-00.html

But the same underlying problem is also being discussed as part of https://datatracker.ietf.org/doc/draft-bortzmeyer-rpp-json-dot-namespaces/

@jens i mean... aren't JSONLD contexts basically just namespace injection? this seems to be a mostly solved problem, it's just the DX that can be a bit annoying when trying to accommodate JSON processors that fundamentally don't understand JSONLD. (within a single resource that doesn't link out to other resources, there is no problem.)

@jens afaict "disable propagation and put a context on every qualified resource node" seems to be directly analogous to "put an xml namespace on every qualified resource node"

@trwnh It's a sort of solved problem, because apparently JSON-LD context come with issues that a simple namespacing scheme would avoid. Plus, you don't need the LD part.

I'm going back and forth with LD in this context (pun intended). It seems to solve issues only on the condition you mention, that it needs LD processors.

It's something I don't mind, particularly, but the fact that this thread exists seems to say that perhaps it's best to embrace that some folk don't want to bother with it.

@trwnh So when you have tech that brings benefits with "bother", you can kind of understand why it's not adopted as widely as one might like.

This has long history in tech, and is sometimes instrumentalized. Early SGML based HTML was fairly permissive, then XML based XHTML came along. That was, actually, pretty good - it cut through a bunch of issues by just being a tad stricter. With XHTML 2.0, it was finished, but Google pushed hard for HTML5, because the more permissive nature of it meant...

@trwnh ... it felt like less of a bother. It also meant implementation complexity went back to SGML levels, and now only Google has the resources to develop a browser engine.

SOAP was a different beast. It was permissive in a way that let vendor extensions proliferate, but the way it happened was that, essentially, SOAP from one vendor was incompatible with that from another. Frustrated, the community proposed XML-RPC, which is also permissive, but embraced simplicity at the same time.

...

@trwnh Then JSON came along, making working with JS a lot easier, but the fundamental model of sending JSON around is very, very similar to how XML-RPC handled it.

JSON-LD provides much the same "feel" as SOAP. Yes, there's more clarity in it. But it comes at a complexity cost that also allows for abuse. And in that sense, the XHTML/HTML5 story is the same ad the SOAP story, is the same (almost) as the JSON-LD story:

Clarity (avoiding ambiguity) is what people wish for, complexity is not.

...

@trwnh Arguably, that specific combination does not exist yet, so people keep proposing namespaces as a simple yet effective alternative.

FWIW there's a related issue with the back and forth between "use schemata to generate code" vs. "use code to generate schemata".

Schema first approaches provide clarity. But code generation means that schema changes overwrite code, which you may have modified. So that's unpleasant to deal with. In the past, frameworks often suggested an indirection ...

@trwnh ... layer, which avoids that issue, but then you have two layers to maintain compatibility between. Not fun.

OoenAPI started out solving that, it was schema first, but didn't generate code. Instead it let you tag your schema in a way that an API framework could use to map between your implementation and the schema. It still requires adjustment, but it's less disruptive.

Now modern API frameworks have gone the opposite direction again and generate schemata from code, which shifts the...

@trwnh ... maintenance burden onto the consumer of the API. Personally, I think that is very stupid: schemata are contracts, and unilaterally breaking them invites pain. But here we are.

Nonetheless, even though this detour has strayed a bit from the OT, the point remains that devs seek clarity *and* simplicity (which provides for its own kind of clarity), and that's a difficult balance to strike.

But if you don't, chances are it'll get worse before it gets better.

@jens i think you read a bit too much "problem" into what i wrote; i was trying to formulate a way for graph-unaware consumers to do graph merges "properly", i.e. without introducing errors. namespaces alone don't really solve that; it's the *propagation of context* that is introducing issues. a context-unaware consumer might assume their context applies everywhere, even for resources where it doesn't. in xml terms, it's like changing the default namespace (xmlns), not really any prefix stuff.

@jens i think you read a bit too much "problem" into what i wrote; i was trying to formulate a way for graph-unaware consumers to do graph merges "properly", i.e. without introducing errors. namespaces alone don't really solve that; it's the *propagation of context* that is introducing issues. a context-unaware consumer might assume their context applies everywhere, even for resources where it doesn't. in xml terms, it's like changing the default namespace (xmlns), not really any prefix stuff.

@jens basically, the issue is how do we maintain "well-formedness" of the LD when an LD-unaware processor starts to mutate and manipulate the graph while not treating it as a graph.

it's less of a problem in the xml ecosystem because you generally expect xml processors to already understand namespaces. and also in the xml world, namespaces don't carry any semantic information; they're just a way to prefix things more efficiently. for jsonld, this would be like only defining prefix terms.

@jens basically, the issue is how do we maintain "well-formedness" of the LD when an LD-unaware processor starts to mutate and manipulate the graph while not treating it as a graph.

it's less of a problem in the xml ecosystem because you generally expect xml processors to already understand namespaces. and also in the xml world, namespaces don't carry any semantic information; they're just a way to prefix things more efficiently. for jsonld, this would be like only defining prefix terms.