JavaScript Object Notation for Linked Data popularly known as JSON-LD is a lightweight syntax to inject Linked Data into JSON so that it can be widely used in web applications and can be parsed by JSON storage engines.

This post is in continuation of the previous post which describes the basics of JSON-LD and will contain more of its features and concepts. I’ll recommend you to go through that for an easy understanding. Well then, let’s get started.

It contains a variety of features that are really helpful for someone working with it. Some of them are described below

Versioning

Since JSON-LD has two major version as 1.0 and 1.1, you can define which version to be used for processing your JSON-LD document as per your use case. It can be done by defining the @version key in your @context. For eg.

{ "@context": { "@version": 1.1 } }

The first context which defines the @version tells which version should be used for processing your JSON-LD document, unless it is defined explicitly.

Default Vocabulary

Very often, many properties and types come from same vocabulary eg schema.org is widely used vocabulary for defining semantics for various terms. JSON-LD’s @vocab keyword provides us the feature to set a common prefix for all the properties and types that do not resolve to any IRI’s. For eg.

{ "@context": { "@vocab": "http://schema.org/" }, "@id": "http://example.org/places#BrewEats", "@type": "Restaurant" , "name" : "Brew Eats" }

The words Restaurant and name doesn’t resolve to any IRI, hence they would use @vocab’s IRI as prefix. However, there may arise a case in which you wouldn’t want a term to expand using the @vocab’s IRI. For that, the terms should be set to null explicitly. For eg.

{ "@context": { "@vocab": "http://schema.org/", "databaseId": null }, "@id": "http://example.org/places#BrewEats", "@type": "Restaurant", "name": "Brew Eats", "databaseId" : "23987520" }

Here, the key databaseID would not resolve to any IRI.

Aliasing Keywords

JSON-LD provides a way to give aliases to JSON-LD keywords except for the @context. This feature allows the legacy JSON code to be utilized by JSON-LD by re-using the JSON keys that already exist in the code. But a keyword can’t be aliased to another keyword. Consider an example for this

{ "@context": { "id": "@id" , "type": "@type" , }, " id ": "http://example.com/about#gutsytechster", " type ": "http://xmlns.com/foaf/0.1/Person", }

Here, the @id and @type keywords has been aliased to id and type respectively and used accordingly.

Internationalization

Sometimes we require to annotate a piece of text in certain language. JSON-LD provides the @language keyword to use this feature. For a global language setting, the @language keyword can be defined under @context. For eg.

{ "@context": { "@language": "ja" } , "name": "花澄" , "occupation": "科学者" }

You can also override default values using the expanded term definition as

{ "@context": { "@language": "ja" }, "name": "花澄", "occupation": { "@value": "Scientist", "@language": "en" } } I liked this feature the most. It’s just amazing. 🙂 Embedding and Referencing

JSON-LD provides a way to use a node object as a property value. What? You ask me what a node object is. Well, a node object is a piece of information that can be uniquely identified within a document and lies outside the JSON-LD context. Let’s consider an example to understand this

[{ "@context": { "@vocab": "http://schema.org/", "knows": {"@type": "@id"} }, "name": "Shiva Saxena", "@type": "Person", "knows": "http://foaf.me/gutsytechster#me" }, { "@id": "http://foaf.me/gutsytechster#me", "@type": "Person", "name": "Prashant Sharma" } ]

Here the two node object are defined, one for Shiva Saxena and Other for Prashant Sharma. These two are separated through a comma having properties of its own. Here the node objects are linked through referencing using the knows property. knows property refer to the identifier of the another node object ie Prashant in this case.

Two node objects can also be linked through embedding by using the node objects as property values. It is commonly used to create the parent-child relationship between two nodes. For eg.

{ "@context": { "@vocab": "http://schema.org/" }, "name": "Shiva Saxena", "knows": { "@id": "http://foaf.me/gutsytechster#me", "@type": "Person", "name": "Prashant Sharma" } }

Here note that type-coercion for knows property is not required as its value is not a string.

Expansion

Expansion in terms of JSON-LD is the process of taking a JSON-LD document and convert into a document in which no @context is required by expanding all the IRIs, types and values defined in @context itself. For eg

{ "@context" : { "name" : "http://xmlns.com/foaf/0.1/name" , "homepage" : { "@id" : "http://xmlns.com/foaf/0.1/homepage" , "@type" : "@id" } }, "name" : "Prashant Sharma" , "homepage" : "https://gutsytechster.wordpress.com/" }

After expanding, it looks something like this

[ { "http://xmlns.com/foaf/0.1/homepage": [ { "@id": "https://gutsytechster.wordpress.com/" } ], "http://xmlns.com/foaf/0.1/name": [ { "@value": "Prashant Sharma" } ] } ]

And I actually didn’t write that expanded form myself. There is a JSON-LD playground here where you can actually check if it is wrong or right!

Compaction

Now, can you guess what compaction might be? Well, it’s just opposite of Expansion. It is a process to apply the context to an already expanded JSON-LD document which results in shortend IRIs, terms or compact IRIs. Taking the same expanded document from above and applying the following context to it.

{ "@context" : { "name" : "http://xmlns.com/foaf/0.1/name" , "homepage" : { "@id" : "http://xmlns.com/foaf/0.1/homepage" , "@type" : "@id" } } }

We will get our original JSON-LD documents back in the same form. I’ll ask you to try yourself in the JSON-LD playground.

But are you wondering, what’s the need for these Expansion and Compaction algorithms. The answer is pretty simple. Machine understands IRI’s to work with. So it expands the JSON-LD document for itself so that it can process the document and then compact it for developers to return in the same format as it was given.

I guess, we have explored quite a bit about JSON-LD. But it’s still doesn’t contain in-depth use case for each of these features. There are many other features which are available. I leave the rest on your curiosity.

References and Further Reading

Well, then meet you in next blog post. Till then,

be curious and keep learning!