T
@jens this is why i put "clever" in quotation marks. like, yes, that's just how references work, no problems there.
the problem is that you are taking something that isn't activity+json and sticking it in an activity+json document.
more precisely, the media type no longer applies to the *entire* document; there is a fragment of the document that has a different media type (like the hypothetical schemadotorg+json i was talking about earlier)
@jens but also, any json can become ld+json with a sufficiently complex context definition. the ld+json processor cannot understand the implicit semantics of json; it needs to be made explicit in the form of a jsonld context.
we want the jsonld context's described semantics to not diverge from the *actual* semantics. we can't be aware of every vocab or media type in the world. so the semantic boundaries between individual resources are important.
but we do want to reduce those pesky roundtrips
@jens the "rub" is that AS2 claims to be "JSON-LD but you can totally ignore the LD part we promise lol"
you can *mostly* ignore a lot of the complexity, but only if you stay within the boundaries of activity+json semantics, i.e. "don't use external vocabs, and if you do, don't redefine activitystreams terms"
the extensibility mechanism is ld+json. you can include ld+json inside activity+json but you need to not violate the constraints of activity+json.
@jens we might finally be on the same page 
> Lower level processors cannot make assumptions about higher level processors, without being told to make them.
this is what i was trying to do, yeah. how can a lower level processor preserve higher level semantics? what do you need to "tell" them to retain alignment?
the references are kind of unavoidable, since this is the web we're talking about. you have multiple documents, but naive processors try to be "clever" and save you HTTP requests.
@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.
@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 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?
they enshittified meatspin
@brooke when i first encountered the term and didn't know what it meant, i pronounced it "ki-shit" or "kish-it"
@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?
@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 no offense taken, btw!
@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
@raphael really, that's kind of the whole point of a "fragment" identifier, it identifies a "fragment" of the resource, and its semantics are determined by the media type.
for text/html, a fragment corresponds to an id= attribute or otherwise can be read by javascript. see https://www.iana.org/assignments/media-types/text/html for "Fragment identifier considerations"
@raphael that's part of how HTTP works -- your HTTP request doesn't include the fragment, but the HTTP user agent can handle the fragment resolution after it receives its HTTP response.
for inboxes: inboxes are more like endpoints. i guess you could use a fragment, but it wouldn't mean anything for HTTP POST. it would only mean something for when you HTTP GET and are looking for a subresource fragment.
@jens i am guessing the disconnect is that when you say "semantics" you are including what i would split out as "serialization" and/or "syntax"?
@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.
it's a bit unfortunate that a lot of fedi naively expects id to never be a fragment identifier. and in some particularly unfortunate cases, somehow they baked it into their security model, too -- the top-level object's id is expected to match what they requested *after* chopping off the fragment, not *before*.
i'm playing around with a thought in my head re: URIs and what they identify, in a world where dereferencing that URI usually gets you some text/html
i think using the bare URI to identify the page or document itself is unnecessary, because you can just slap an id="page" attribute on the <html> element if you need to make statements about the page itself.
similarly, slap an id="article" on your <article> if need be.
of course you can also align your fragment ids to other formats like json...