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

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

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

@jens think of it as "how can a JSON processor combine two valid documents with different semantics and produce another valid document without altering the semantics"

if you don't take care to preserve the semantics, you will get a syntactically valid combined JSON document but there will be semantic confusion because the semantics weren't preserved. the literal key `actor` means different things in different parts of the combined document.

would an example help? i can try to whip one up rn...

@trwnh No, I understand the problem. I think you're assuming that creating a combined document necessitates pulling more deeply nested keys into an object closer to the root. This is not an assumption I'm making.

Put differently, a "foo:bar" in the root object isn't and shouldn't be the same as a "foo:bar" underneath a "baz:quux" key. The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it. It may refer to a...

@trwnh ... more general definition about the key, sure, but the existence under another object determines the relationship.

This isn't very LD like.

You can avoid duplication still by supporting document internal JSON references, if you want. That does require the JSON processor to understand those, of course. You can do *more* than namespaces, sure.

@trwnh As I said: no. JSON-LD is not plain JSON, period. The terms used in one JSON-LD document are only ever valid in this one document. The document is the boundary, you cannot make any assumptions from one document for another one. It's true for all RDF sources, and even laid out explicitly in RDF Syntax and Abstract Concepts. That goes even further: Semantics of one document may change every time you read it (not applicable here, but please just never ignore that JSON-LD is RDF).

@jens

> The "baz" namespace determines what "quux" means, and the definition of "quux" determines the semantics of finding a "foo:bar" underneath it

ok, but how do you deal with a naive processor that doesn't know what any of this means?

i am describing the case where you see this:

<some activity> <has an actor> <me>.
<some activity> <is a> <Like>.
<some activity> <has an object> <ghostbusters>.

then you dereference <ghostbusters> and get:

<ghostbusters> <has an actor> <bill murray>.

@jens an aware agent can merge these two graphs while preserving context. <has an actor> in the first graph gets qualified with a prefix or namespace.

an unaware agent doesn't know what they're doing. they just blindly copy <has an actor> without qualifying it at all. this is what introduces the issue.

@trwnh What issue?

The issue only exist if you insist on interpreting the merged document (! not knowledge graph!) as linked data.

"has an object" isn't something JSON knows. JSON knows keys that point at values. Your value may be a reference, if you go that way, or it may be any other JSON.

Perhaps the key is "hasObject". Perhaps it's "attachment". Either way, the path ".outer-key.actor" is different from ".actor", so whatever sits there as values doesn't have the same semantics.

@nik JSON-LD is not plain JSON, but it can be parsed as plain JSON. this is a core part of ActivityStreams 2.0 -- and most of fedi takes this approach. fedi largely doesn't care about RDF at all, and will happily ignore that...

@trwnh I *know*. I know that most fedi devs don't understand the Social Web, and I know ActivityStreams explicitly promotes flawed implementations. And I know that everyone and their dog follow Eugen's example of making ActivityPub a zoo of proprietary JSON.

@nik right, i also dislike the fragility of fedi implementations. i'm trying to bridge the gap for the LD haters to at least produce valid documents.

@trwnh Thanks for making band-aids.

But maybe get @Gargron to publish his proprietary extensions as RDF-parsable context first instead of letting everyone outside Mastodon guess what his JSON-LD is supposed to mean.

We're making band-aid for things not some small individual Fedi hacker did, but to support corporate decisions of Fedi leaders that get in the way of individual Fedi hackers.

@jens it is possible to merge in a way that results in a valid graph with no semantic confusion. the goal of the thread was to describe such an approach.

> the path ".outer-key.actor" is different from ".actor", so whatever sits there as values doesn't have the same semantics

the ".outer-key" here has no inherent semantics for the value; it only has semantics for the subject. for example, the `object` of an Activity can be anything. you can't assume anything about `object.actor` vs `actor`.

@nik i'm not sure we can expect people who don't understand RDF at all (and indeed don't even *want* to understand it) to suddenly become RDF-friendly good citizens.

@trwnh

This very thread proves that ignoring RDF makes handling JSON-LD so incredibly difficult that it cannot be expected from fedi hackers either.

If you are competent enough to handle that complexity yourself, go and learn RDF instead, it's simpler.

If you aren't, use a library, in which case it should handle RDF *and* help you ignore the complexity.

@nik we can say this as many times and as loudly as we want, but it won't change anyone's minds nor their software.

rather than declaring it all to be junk, it can be preprocessed (or fixed) into something properly semantic. that's because meaning is descriptive, not prescriptive. any arbitrary JSON payload has implicit semantics that can be made explicit with enough description -- that's what the JSON-LD context is.

yes, we can also write more/better libraries at the same time. let's do both.

@trwnh

If we want to allow people to ignore RDF, then at least do it correctly (resolve all terms into full IRIs). The plain JSON form of a JSON-LD document is not the original JSON-LD with the context key stripped away, but with all keys containing full IRIs.

If we do that, I am perfectly fine with people just using it as plain JSON (with really odd keys).