Recent searches
Search options
Administered by:
As a JSON-LD noob, I think this is what JSON-LD is trying to solve:
- maintain consistency on what data represents what
- provide a specification what document belongs to what set of objects (via @`type`)
- provide a specification on how documents are related to other documents (via @`id`)
But I might be wrong.
I'm thinking out loud because I'm trying to figure out how to make sense of JSON-LD
Something about naively parsing JSON-LD like regular JSON feels a little off #JSONLD #LinkedData #LD #OpenData
That is an understatement.
@reiver no kidding.
I cringe whenever I see someone being satisfied with merely throwing a JSON-LD payload into a json.Unmarshal or JSON.parse, and then calling it a day.
Doing so will really leave a world of hurt.
@manlycoffee I see it as a compromise to take RDF-like data, and representing it in a way that's more palatable to mainstream developers.
Unfortunately by making it look like just JSON it's often treated as just JSON, completely ignoring the @context. In principle you can use completely different property names as long as they map to the same URI through the context, but in practice that rarely works.
I think the problem JsonLD tried to solve was: "How can we specify an extensible data format without ending up with a complicated, underspecified, unusable, and bloated mess?"
I don't think they were successful. I don't think anybody else has done a better job. For example @type and @id are roughly what one wants. @id is pretty much what I expect. @type being a set is super awkward.
@h @manlycoffee In ActivityPub world It helps to solve the problem of naming things - even if you work with plain JSON like I do.