NodeBB-ActivityPub Bridge Test Instance

@trwnh Since we're working with plain text analogies here, this is like putting non-ASCII bytes into a string without specifying anything about what they mean (i.e. an encoding).

@trwnh ...anything at all about the represented data.

If this changes anything about the semantics of the LD, then JSON-LD shouldn't be using JSON references (brutally put, I know), because it knowingly breaks the underlying JSON semantics.

@trwnh ... JSON processor resolving JSON references and replacing them with their referred to objects, this sits somewhere on an intermediate layer between JSON and JSON-LD.

If the processor "speaks" references, then according to any and all rules about processing them, this is fine.

It isn't doing anything wrong, because the data structure derived from parsing the doc-with-refs-preserved and the one derived from parsing doc-with-refs-resolved is the same.

In that sense, it isn't changing...

@trwnh Yes, you would have the same issues, but there's a semantic (haha) difference:

Lower level processors cannot make assumptions about higher level processors, without being told to make them. So a string processor cannot really perform any modifications to the string, unless they're told it's fine to do them.

Similarly, a JSON processor cannot make modifications to the document structure, unless they're told that's fine.

Here's the rub: in the example you were giving a while back, of a..

@trwnh Structured data is never this "flat", the structure is the semantics and vice versa.

So, by assuming the JSON representation is arbitrarily malleable, you're breaking the structured data model.

You can argue that sucks, FWIW, but it's nonetheless the case for all structured data: JSON, YAML, TOML, XML, SGML, CBOR, all of those (more or less) follow the structured data model (attributes in XML/SGML and to a lesser degree YAML have additional structural properties, sure).

@trwnh ... that ".children" and ".follows" do not have the same semantics. Yes, the specs both state they're Person, but those aren't the semantics really. The semantics are that one Person is a child of the enclosing Person, and the other is a "uni-directional social relation" (https://schema.org/follows).

So moving those objects elsewhere in the graph modifies the semantics.

This is what LD doesn't really "get", because the knowledge graph is built (can be built) out of a flat list of triplets.

@trwnh ... view, pretty much superfluous.

It's not *entirely* superfluous if you consider that Any or Variant definitions may exist, in which case you need sole type specifier. But it's superfluous in this case, because the textual definition of the meaning of ".children" is unambiguous: https://schema.org/children

The contained object must be Person.

So rather than saying that the parent *overrides*, it's better to state that the parent determines what is permissable.

But that also means...

@trwnh It's a weirdly LD way of putting it.

In what I call structured data now, the semantics are derived from the position in the data graph, i.e. the structure, and whichever definitions are associated with this structure.

If we take e.g. https://schema.org/Person 's example 4, ".children.name" has semantics derived from the fact that ".children" has the definition "must also be a Person", not because ".children.@type" has a value of "Person". That field is, from a structured data point of...

@trwnh Or to go back to a previous phrasing: you think in terms of knowledge graphs. In JSON, the graph *is* the structure of the serialization.

You cannot make JSON understand a knowledge graph *unless* you map it into the graph structure that JSON understands. Anything else is futile.

@trwnh ... to offend you, quite the contrary! But this really isn't going to work, and I am trying my best to get you to understand that.

JSON is just a serialization format from an LD perspective. But from a JSON perspective, LD is just payload; semantics derive from position within the structured data (and specs relating to those positions).

To make JSON-LD compatible with JSON processors is to embrace the structured data model.

@trwnh Again: this is *only* the case if your mental model is LD. That is what I keep trying to get across.

If your mental model is "structured data", then you *cannot* assume two different structures have the same semantics.

You want to make LD "safe" for structured data processors. That is only going to happen, IMHO, if you accept how structured data processors deal with semantics.

Instead, you seem to complain that structured data processors aren't linked data processors.

I don't want...

@trwnh Again, though, ".actor" and ".object.actor" have different semantics, because of the semantics of ".object", so there really isn't a problem IMHO.

‍️

@trwnh So we do arrive at it from two different points of view. That much is clear.

What my impression is, is that you have a linked data type of model firmly in your head, and JSON-LD is compatible with that. A pure JSON processor won't understand that, and mess with things.

What I'm trying to get across is that having the linked data model as a starting point when you *know* pure JSON processors will be involved is a mistake.

You can still *use* LD, you just can't use it as a precondition.

@trwnh You know, I understand what you're writing, but don't seem to get across what I mean. I'll step away from this. Maybe I'll figure out a different way to say it ‍️

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

@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 ... 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 ... 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 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 But if it's an incomplete definition, then it's hardly the naive JSON processor's fault