Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Contribute

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

Style

## Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

• ##### Semantic Web community suffers from NIH

by peter lin,

• ##### Re: Semantic Web community suffers from NIH

by Eric Jain,

• ##### Re: Semantic Web community suffers from NIH

by peter lin,

• ##### Semantic Web community suffers from NIH

by peter lin,

Your message is awaiting moderation. Thank you for participating in the discussion.

A lot of people have tried to help semantic web over the years and it hasn't gotten any where for a simple reason. The people leading it at W3C suffer from NIH. In the interest of avoiding the same mistakes that RDF made, JSON-LD should cast the net wider and learn from KBR, CBR and other AI topics.

One of the biggest challenges of semantic web is managing the ontologies and trust. Each person can define their own ontology and define what "name, homepage" mean, but how do systems know what is trust worthy? A global semantic ontology isn't practical, so trust is still a critical issue for wide adoption of "any" semantic technology.

my bias 2 cents.

• ##### Re: Semantic Web community suffers from NIH

by Eric Jain,

Your message is awaiting moderation. Thank you for participating in the discussion.

The problem I saw wasn't so much NIH, but that practical matters such as representing ordered lists where secondary to theoretical soundness. I don't want to dismiss the value of latter, but imagine a relational database that supported only pure relational algebra...

• ##### Re: Semantic Web community suffers from NIH

by peter lin,

Your message is awaiting moderation. Thank you for participating in the discussion.

ignoring practical matters is definitely one of the issues with the RDF people at W3C. Early on there was a push to incorporate rules and queries so that users could easily query "RDF store". The W3C ignored it for many years and then rushed to get out sparql when they realize there really was a need.

A lot of researchers have tackled these same issues for over 3 decades. It was counter productive of the RDF group to ignore practical matters. I hope this new effort doesn't suffer the same fate.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p