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

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

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

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

@trwnh That depends on what the definition of "outer-key" in the context of the root object means. If the root object defines the key to point to any arbitrary value, that's an incomplete definition.

@jens well, that’s activity streams for ya

an actor can be anything, an object can be anything. the most minimal way to serialize an activity is to just use references, but you often want more information about the actor and/or object, so you dereference those. but a lot of naive json producers want to be “helpful” and save you the extra http requests, so they embed the dereferenced json documents… naively…

@trwnh But if it's an incomplete definition, then it's hardly the naive JSON processor's fault

@jens well, syntactically it’s either a JSON string (meant to be parsed as an id reference) or a JSON hash… or a JSON array containing either of these. (except the naive processor is so naive they probably don’t understand arrays because they expect a single value in all cases.)

semantically, it’s saying “jens created something”, where the object of the sentence “something” can be whatever. you need to dereference “something” to get… 100% arbitrary information about it

@trwnh Just to distinguish this *a little*, the syntax is JSON, and JSON processors will likely only process the document if it's valid JSON.

Whether the value is an object, array, string or other JSON type is technically still part of the key's semantics, which should be defined.

FWIW, I'm not hung up on whether you count that as part of syntax or semantics. It's basically a layering issue. If you look top down from meaning to bit stream, it seems more like syntax. But if you look bottom...

@trwnh ... up, once you've turned a bit stream into structured, typed data, it's semantics.

The key thing is how much meaning you assign to the notion of type here. You essentially treat type as "the full, abstract meaning is encapsulated" whereas I treat it as "I can distinguish it in code well enough to keep it apart from other types".

The point being, it should be part of the specifications of the key whether a string, array or object is *valid* here.

It's totally fine to e.g. say it has..

@trwnh ... to be an object with a "type" field that specifies other valid fields, or an array of such objects, or a JSON reference pointing at such an object or array.

And then I can still write a naive-ish processor that can handle this, or a very naive processor that doesn't care at all about the value.

But I do not have to know all possible type values or what they imply for the value.

This is where you can go and say "well, but if I use LD for those objects, I can reason about stuff...

@trwnh ... without hardcoding knowledge about different types", and that's true.

But that isn't preventing a naive JSON processor from doing sensible things at the parent layer, nor is it preventing a semi-naive JSON processor to do sensible enough things with those objects for which it has some knowledge hardcoded.

Again, it's only when you want to use LD to manipulate the entire document as a knowledge graph that you run into issues.

That isn't really necessary, though. It's why I...

@trwnh ... brought up MIME as a very robust encoding that allows for namespacing and so keeps processors from having to know everything about everything, prevents them from having to understand a complete generic data model, and still allows them to selectively process individual fields.

There's a reason MIME is living for this long.

@jens i think we’re mostly on the same page except for the bit about what a key’s semantics are. {id: foo, bar: {id: baz}} says that foo has a property bar whose value is baz. it doesn’t say anything about baz.

<foo>.actor and <baz>.actor mean different things in different documents, despite being a top-level key `actor` in both.

the analogy to MIME is that each document can be thought of as having a different media type, despite both being nominally json and/or ld+json

@jens there is a concept in later jsonld-based specs of “media type specificity”: a document that is application/cid is also implicitly application/ld+json, and also implicitly application/json, and arguably also text/plain, and arguably also application/octet-stream. each specific media type is a refinement of the one before it, or in other words, a more specific media type is just adding more constraints and semantics on top of everything before it.

@jens so consider one document is application/activity+json and the other document is a hypothetical application/schemadotorg+json. you want to merge them as ld+json and that’s fine; no issues. but the result is no longer purely activity+json, because a subnode is redefining `actor` according to schemadotorg+json. this is still fine if you allow for extended activity+json, but naive agents don’t know how to properly handle extensibility while reserializing for others.

@jens again though, it’s not a fatal error unless a term is protected, which usually happens as part of defining an IANA media type. the newer jsonld based media types provide a protected context that guarantees e.g. that `service` ALWAYS means the same thing in a document of type application/did. you can’t redefine `service` later in the document and still call the result semantically valid“application/did”. it would, however, be valid ld+json, if not for protected terms