BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News JSON-LD Reaches W3C Recommendation Status

JSON-LD Reaches W3C Recommendation Status

The W3C RDF Working Group has moved the JSON-LD and JSON-LD 1.0 Processing Algorithms and API standards forward to recommended status. JSON-LD is a standard to add "linked data" semantics to JSON. A JSON-LD document looks like this:

{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

If you're not familiar with the W3C's standards process, there are three levels of maturity a specification can be in. A Recommendation is the final step in the maturity of a particular specification. The W3C suggests that Recommendations be "widely implemented," meaning that they're ready and stable enough for broad public usage.

It has taken a lot of work for JSON-LD to reach this stage of maturity: 100 teleconferences, 281 issues logged, 2,000 source code commits, and 2,500 emails over the course of four years.

More on JSON-LD

Here's an example, straight from the specification:

{
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

This is a JSON document representing a person. It's easy for humans to infer the semantics here: "name" is the name of the person, "homepage" is their home page, and "image" is some kind of photo of them. Machines don't understand terms like "name" and "image," though.

To resolve this, we can use linked data. Here's the same example with JSON-LD:

{
  "http://schema.org/name": "Manu Sporny",
  "http://schema.org/url": { "@id": "http://manu.sporny.org/" },
  "http://schema.org/image": { "@id": "http://manu.sporny.org/images/manu.png" }
}

By linking to definitions from schema.org, we can teach a machine how to understand the semantics of a "name", "url," and "image." This is a bit more complicated, though. We can achieve the conciseness of the original example and the semantic understanding of the second example through what JSON-LD calls a "context." Let's take that first example, and introduce a context:

{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "name": "Manu Sporny",
  "homepage": "http://manu.sporny.org/",
  "image": "http://manu.sporny.org/images/manu.png"
}

We now link to a context hosted on json-ld.org. A context document looks like this:

{
  "@context":
  {
    "name": "http://schema.org/name",
    "image": {
      "@id": "http://schema.org/image"
      "@type": "@id"
    },
    "homepage": {
      "@id": "http://schema.org/url",
      "@type": "@id"
    }
  }
}

Bam! Another advantage of the contextual approach is that the same context can be used across multiple documents.

Why not RDF?

JSON-LD takes on the flavor of semantic web technologies, but isn't exactly one. They both have similar goals: to provide shared context around some kind of knowledge. For example, it's a shame that every website re-invents concepts around names. Imagine you wanted to investigate several different services to compare the way people identify themselves. In order to get people's names, you'd have to re-build different code for each API to determine exactly how to fetch the name.

With semantic web technologies, each service would expose "This is a Person," and you'd only need to write the code to understand what a Person is one time. You could generically re-use it across services.

While JSON-LD and more traditional semantic web technologies (like RDF) have the same end goals in mind, they don't use the same building blocks. Manu Sporny, char of the JSON-LD W3C Community Group, wrote a blog post about the relationship between the two:

That's why my personal approach with JSON-LD just happened to be burning most of the Semantic Web technology stack (TURTLE/SPARQL/Quad Stores) to the ground and starting over. It's not a strategy that works for everyone, but it's the only one that worked for us, and the only way we could think of jarring the more traditional Semantic Web community out of its complacency.

Manu also elaborates on using simple, clear writing in the specification:

We tried our best to eliminate complex techno-babble from the JSON-LD specification. 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. There was tremendous push back on this point, which I'll go into later, but the point is that we wanted to communicate at a more conversational level than typical Internet and Web specifications because being pedantic too early in the spec sets the wrong tone.

Both of these things point to how JSON-LD tries to move the conversation about semantic web technologies: simple, noncomplex, and for the average developer.

Rate this Article

Adoption
Style

BT