I spent some time attempting to work with the W3C Web Annotation Data Model. That data model is serialized as JSON-LD.

After spending about 50 hours reading the documents and attempting to implement some of it, I have a general idea what JSON-LD is.

I wasn't really trying to achieve anything, so I basically quit once something seemed opaque enough I couldn't figure it out in a short period of time. When I visited the JSON-LD Test Suite page to see what implementations are expected to do [0], I found:

> Tests are defined into compact, expand, flatten, frame, normalize, and rdf sections

I had a hard time figuring out what each of these verbs meant, and they were about all that the various implementations I found did. For example, the term normalize doesn't even appear in the JSON-LD 1.0 specification [1]. shrug I'm sure I could have figured out more if I spent the time to actually read the whole thing and all the related documents.

[0]: https://json-ld.org/test-suite/

[1]: https://www.w3.org/TR/json-ld

JSON-LD is RDF. Or rather is what RDF would look like if it was serialized in JSON instead of XML. If you look from the Semantic Web angle JSON-LD is just a serialization format, like e.g. Turtle, but using JSON as JSON is popular nowadays.

Sometimes I wonder why this is not said directly, probably because Semantic Web and RDF are passe now.

Actually the post's author addresses this point:

> I made it a point to not mention RDF at all in the JSON-LD 1.0 specification because you didn’t need to go off and read about it to understand what was going on in JSON-LD.

...

> Tests are defined into compact, expand, flatten, frame, normalize, and rdf sections

These are just sub-formats of JSON-LD, information represented is the same but JSON looks a little bit different. Some sub-formats are easier for tools to process, some are better for humans.

> Sometimes I wonder why this is not said directly, probably because Semantic Web and RDF are passe now.

It seems to me that on one hand JSON-LD wanted to bootstrap the network effects by bringing along people who were doing RDF both technically (the JSON-LD spec says "JSON-LD is a concrete RDF syntax as described in [RDF11-CONCEPTS].") and socially (published by the RDF WG), but on the other hand the negative brand equity of RDF is recognized as an obstacle for bringing along even more people, hence the OP professing "Hate the Semantic Web" and "Kick RDF in the Nuts".

It's kinda weird how mentioning the RDF connection of JSON-LD in the sense of past experiences with RDF having any bearing on JSON-LD is treated as a social no-no. Despite the above-quoted bit from the spec saying "JSON-LD is a concrete RDF syntax as described in [RDF11-CONCEPTS].", we are supposed to play along with JSON-LD totally having nothing to do with RDF.

> Sometimes I wonder why this is not said directly

There are multiple flavours of RDF and I think json-ld only supports a subset of one of them. Its been a while since I read the spec but I believe there are various fudges with lists, reification and datatype coercion.

Any time I get close to an RDF stack I find its a broken mess. Its complexity seems to almost guarantee incompatibility instead of interoperability.

I use JSON-LD for the ConceptNet API at http://conceptnet.io .

I'm not sure if anyone cares that it's JSON-LD as opposed to any other decent JSON API, to be honest.

But here's an oblique benefit. I used to be asked why, as a knowledge graph, ConceptNet wasn't in RDF. The undiplomatic answer was "because the RDF technology stack is a pain in the ass and I hate it". But now JSON-LD is a form of RDF that I don't hate.

I posted the story because, egged on by Google's 'Rich Data Cards' item in their search console, I finally snapped and I thought that I'd try it on one of my sites.

I am not encouraged by lots of handwaving in various docs, apparent schoolboy errors in (eg) Google's examples, and apparent incompleteness in the spec for such things as temporalCoverage (can an open-ended and still-continuing data set be indicated with "temporalCoverage":"20140721T10:13Z/" ?).

Turns out that the open-ended temporalCoverage thang is an open issue (and I may have correctly guessed the 'right' answer):

https://github.com/schemaorg/schemaorg/issues/1365

In a way what I learned with my 30 year-old AI degree was that meaningful semantic networks are hard ("is A", anyone?) but I'd have thought that some of these basics would have been nailed in a practical schema by now!

A year ago I implemented JSON-LD using Google's documentation and validator on a brand new website. Months later, it had zero impact on the results and it didn't even picked up the city, only after I added it to the footer that results started changing (like "business + city").

A practical benefit for using JSON-LD in API development is being able to link every field in the response directly to a definition, ideally a shared one such as schema.org. This overlaps a bit with definition formats like OpenAPI (Swagger), RAML, et al, but to completely replace those, you'd need a media type that documents the API semantics.

It's possible to use JSON-LD in an opaque fashion by remapping all of its reserved keys to whatever your JSON looks like, i.e. from "@id" to "href" which is more familiar. It doesn't have to look like an ugly mess of "@" prefixes, for example: http://micro-api.org/#finding-resources

(disclosure: I am the author of Micro API)

I build tech with json-ld.

This uses json-ld: http://beta.einnsyn.no

And this uses json-ld: https://difi.github.io/dcat-ap-no-validator/

I like JSON-LD because we have a graph database in the back, and JSON-LD can support graph data.

In the frontend we transform JSON-LD into the javascript object model. JSON-LD is great for this, and much better than JSON, since it supports datatypes, languages and many to many relationships (eg. a book has many authors, authors can write many books).

Would be interested in learning more about how you use JSON-LD with a graph database.

That's really the easiest part.

We use Stardog, but there are a bunch of other databases you can use including Oracle Spatial and Graph, Fuseki, GraphDB, Virtuoso, AllegroGraph, MarkLogic and Blazegraph.

Many of these database will answer queries in json-ld, but since you are likely to want to have a backend anyway you can use Apache Jena or Eclipse RDF4J (previously Sesame) with Java to connect and extract data. Both Jena and RDF4J will let you output that data as JSON-LD.

It's the format used for reservations and other rich data in email. I dealt with it quite a bit when implementing the email parser that would look for your reservations, and found the format quite easy to approach.

Yes! In web application, where underlying restful service returns JSON-LD; Because underlying db was using RDF database.

We added JSON LD to our site at work so that our results in Google would be richer. It's annoying always having to play catch up with whatever new toy Google decides to implement on their search engine which is for all practical purposes the heart of the entire web.

JSON+LD is extremely mediocre in my experience. It's more human readable and easier to edit than XML but it suffers from some of the same issues where specifications quickly turn into a mess that is anything but specific. Do a Google search for any kind of product that returns enhanced results and look at how each of those sites implements their JSON+LD data and even if they are using the same spec each will have come to different conclusions about what it means.