i'm not 100% sure about this but i am starting to think that the way #jsonld context declarations propagate by default is generally an anti-pattern
-
@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.
-
@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 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.
@trwnh Namespaces don't solve this? You lost me there, sorry. Could you explain that?
-
@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 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.
@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 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.
-
@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 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.
-
@trwnh Namespaces don't solve this? You lost me there, sorry. Could you explain that?
@jens namespaces are only a solution for people willing to deal with namespaces. there are JSON consumers who don't understand namespacing at all. the JSONLD context qualifies a term like `actor` to be as:actor or schema:actor or whatever, but the naive JSON consumer is looking for the literal key `actor` *without expanding to the full IRI*.
-
@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.
-
@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 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.
-
@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!
-
@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 What I mean is, don't do LD. Problem solved.
-
@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!
@jens i need to stress that the JSON agent is, in this case, creating the problem where there wasn't a problem before.
as two separate JSON documents, all is fine and dandy.
it's when you naively merge the two JSON documents that you might accidentally produce a resulting document that has errors. this merging is foundational for Web use-cases.
-
@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!
@trwnh You're still in LD headspace.
In basic namespace headspace, "actor" doesn't exist. It's either e.g. "as:actor", which the consumer may understand (should in the context of AS), or it's "foo:actor", which the consumer doesn't understand and doesn't process.
Keep in mind that MIME has existed for decades, and was used in Email *and* HTTP (Until the QUIC crowd forked it [TL;DR]) with this simple a scheme for headers, and there was no semantic ambiguity here.
-
@trwnh What I mean is, don't do LD. Problem solved.
@jens no, i want to do LD because i want to be able to fetch documents over the Web and reason about things. the LD agent knows what it's doing and doesn't cause problems.
-
@jens i need to stress that the JSON agent is, in this case, creating the problem where there wasn't a problem before.
as two separate JSON documents, all is fine and dandy.
it's when you naively merge the two JSON documents that you might accidentally produce a resulting document that has errors. this merging is foundational for Web use-cases.
@trwnh See, this I disagree with. I think rather that JSON-LD didn't sufficiently consider that pure JSON processors would process their documents. But that is not a productive squabble to have, so I won't die on that hill
-
@trwnh You're still in LD headspace.
In basic namespace headspace, "actor" doesn't exist. It's either e.g. "as:actor", which the consumer may understand (should in the context of AS), or it's "foo:actor", which the consumer doesn't understand and doesn't process.
Keep in mind that MIME has existed for decades, and was used in Email *and* HTTP (Until the QUIC crowd forked it [TL;DR]) with this simple a scheme for headers, and there was no semantic ambiguity here.
@jens but it's *not* literally `foo:actor` in the serialized JSON document -- it's `actor`. just that two different documents both use `actor` in different ways... and context propagation means that an earlier definition still applies until redefined. which you can't do for protected terms.
things like MIME and HTTP headers work because of centralized IANA registries acting as the namespace. you can to some degree think of a MIME type as having its own implicit context via specified semantics.
-
@trwnh See, this I disagree with. I think rather that JSON-LD didn't sufficiently consider that pure JSON processors would process their documents. But that is not a productive squabble to have, so I won't die on that hill
@jens JSON processors need to be careful that they are processing their document in a way that doesn't shred the underlying semantics, no?
like, the root cause of the problem is that there are multiple documents, and it matters how you dereference a reference. you have semantic consistency within each document, but you can't just smush the two documents together any which way you please and expect others to understand what you did. you'd be changing semantics for everyone else.
