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

@jens we are less concerned with schematic validation; we are more concerned with semantic confusion. we don't stop at knowing the difference between as:actor and schema:actor; we also want to know that the value is a Thing and not a String, i.e. that it is a reference and not a literal.

really, the complexity of jsonld processing is less to do with the actual LD and more to do with the ability to take arbitrarily complex JSON and still interpret it as a semantic graph.

@jens really, the challenge is that people produce all kinds of "bad JSON", because of poor data models, lots of indirection, etc. -- it can be complex to unravel all those bad practices and get the true simple meaning out of the soup.

@trwnh Namespaces don't solve this? You lost me there, sorry. Could you explain that?

@trwnh Again, lost me. XML namespaces don't carry semantic information how?

I *think* I know what you mean, but if so, I might disagree. Can't be sure, though ‍️

@jens XML namespaces are a simple prefix mechanism, just like JSONLD can be used as a simple prefix mechanism if you only use simple term definitions to define prefixes

but the full context is more than that. you take `actor` and you can expand to `http://schema.org/actor` and that's where namespaces stop. you still need to know whether the value is a string literal or a reference to something else on the graph.

@trwnh Sure. But you're not going to avoid that. People will always be people.

You need a way to keep one bad data model from not interfering with another. Anything else becomes tilting at windmills IMHO.

@jens that's the goal of the thread

the LD agent sees the graph as a graph, but the JSON agent sees the graph as a JSON document. it might understand that a certain value is actually a reference, but then how can it dereference?

the LD agent does a graph merge. no problems.

the JSON agent fetches a JSON document and naively sets that JSON object as the value of the property to be expanded. oops, problems! you might have just accidentally redefined a term from the parent document!

@trwnh Correct.

But a naive consumer can (and should) simply not process namespaces they don't understand.

I think you may need to let go a little of what namespaces mean in JSON-LD, and consider what they mean elsewhere.

@jens the problem is that terms conflict, and the naive consumer isn't "simply not process[ing] namespaces they don't understand" -- they straight up don't understand the concept of namespacing.

this is a problem because they will then perform data manipulations that cause all kinds of semantic hell, completely unaware that they are doing anything wrong.

they don't understand that `actor` can mean two different things. for all they know, `actor` ALWAYS means as:actor, even when it doesn't!

@jens the problem is that terms conflict, and the naive consumer isn't "simply not process[ing] namespaces they don't understand" -- they straight up don't understand the concept of namespacing.

this is a problem because they will then perform data manipulations that cause all kinds of semantic hell, completely unaware that they are doing anything wrong.

they don't understand that `actor` can mean two different things. for all they know, `actor` ALWAYS means as:actor, even when it doesn't!