@jens they can be the same semantics actually

id: foo
actor: i
type: Like
object:
id: bar
actor: you
type: Like
object: that

".object" doesn't imply any semantics for <bar>, nor does it imply anything for ".object.actor" or any other properties. that's because <foo> and <bar> are in essence separate resources

it's semantically equivalent to saying

- id: foo
actor: i
type: Like
object: bar
- id: bar
actor: you
type: Like
object: that

only the serialization is different.

@jens (in jsonld this is the difference between compacted form and flattened form)

@jens they can be the same semantics actually

id: foo
actor: i
type: Like
object:
id: bar
actor: you
type: Like
object: that

".object" doesn't imply any semantics for <bar>, nor does it imply anything for ".object.actor" or any other properties. that's because <foo> and <bar> are in essence separate resources

it's semantically equivalent to saying

- id: foo
actor: i
type: Like
object: bar
- id: bar
actor: you
type: Like
object: that

only the serialization is different.

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

@jens i’m not “complaining”, and it’s not even about LD per se; it’s about the boundary between resources. what you call “two different structures” can be combined without regard for semantics. i just want to preserve semantics.

if the JSON vs JSONLD thing is tripping you up, then consider an example where someone dumps the json to a plaintext string and tries to do an even more naive string find-and-replace. or consider an example where someone manipulates the raw bytes

@jens no offense taken, btw!

@jens if the argument is “they can’t be combined while preserving JSONLD semantics”, i would argue that they can. if anything, they can’t be combined while preserving *JSON* semantics, because nesting a JSON object under a certain key in the document fundamentally alters the semantics of that nested object (if i understand you correctly)

@jens the mere act of nesting erases the boundary between parent and child; the parent’s semantics always override whatever semantics the child had.

is that correct?

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

@jens even without LD you'd still have issues if you applied plaintext merging rules on json objects dumped to strings, which is the equivalent operation at a lower level.

the thing is, in the example you give, you're staying within the schema.org vocabulary, and you're also looking at it purely from the lens of the root object (the Person that is the parent). i'm looking at it from the lens of the nested object.

if a Person's child is also a Person, then can't that child also have children?

@jens say we have a JSON object, id: foo.

".children" has an id: bar.

".children.children" has an id: baz.

it seems entirely reasonable to me to consider foo, bar, and baz to be individual JSON objects, just nested within each other. is there anything wrong with this interpretation?

in an XML tree, you can consider a subtree to also be an XML tree. maybe that subtree originated from a different XML document, like how we can include SVG in HTML.

@jens the crossover from "HTML semantics" to "SVG semantics" is invisible to most people who aren't aware of the distinction, but that doesn't mean it doesn't exist.

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