Which are the differences of NGSI-LD and JSON-LD? - fiware

Question

In Fiware tutorials I read that NGSI-LD is not 100% JSON-LD. Can you explain me which are the differences?

Answer 1

JSON-LD is an extension to JavaScript Object notation which enables linked data concepts to be expressed in JSON and provide a format which is both human and computer readable. This is JSON-LD:
JSON-LD
{
"#context": "https://json-ld.org/contexts/person.jsonld",
"#id": "http://dbpedia.org/resource/John_Lennon",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
NGSI-LD is an API which uses multiple payload formats, but here is the John Lennon entity expressed using "normalized" NGSI-LD - one of several formats that all NGSI context-brokers must support (they also cover plain key-values JSON and GeoJSON for example - see below).
"normalized" NGSI-LD
GET ../ngsi-ld/v1/entities/John_Lennon Content-Type: application/ld+json
{
"#context": [
"https://json-ld.org/contexts/person.jsonld",
"https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld"
],
"id": "http://dbpedia.org/resource/John_Lennon",
"type": "Person",
"name": {"type": "Property", "value": "John Lennon"},
"born": {"type": "Property", "value": "1940-10-09"},
"spouse": {
"type": "Relationship", "object":
"http://dbpedia.org/resource/Cynthia_Lennon"
}
}
Every NSGI-LD payload is a valid JSON-LD document. However this "normalized" NGSI-LD format has additional rules and restrictions (e.g. all attributes must have a type of Property or Relationship) therefore not all JSON-LD snippets are valid "normalized" NGSI-LD.
Much like JSON-LD being JSON plus linked data concepts, NGSI-LD is NGSI-v2 plus linked data concepts.
The NGSI-LD specification describes how to make requests to a context broker and the expected format of the responses. There are 27 well-defined operations within NGSI. Additionally NGSI-LD defines strict definitions of terms such as Subscription and Registration and Property and Relationship, how timestamps should only be held in an observedAt, geographical position must be found in a location attribute as a GeoJSON Point and so on.
JSON-LD is a data representation only, it makes no assumptions about how the payload is to be accessed or how the payload is to be structured beyond having attributes in JSON format and an #context attribute.
Context-Broker to Context-Broker operations in "normalized" NGSI-LD can make the assumption that the core context https://uri.etsi.org/ngsi-ld/v1/ngsi-ld-core-context.jsonld is assumed to be part of the request and is processed last and therefore always overrides other #context elements. the #context element can also be represented using a Link Header
JSON-LD representations must always contain an #context attribute (after all that is what makes them application/ld+json rather than just plain application/json) and the #context is processed according the order of the array of elements found.
Since NGSI-LD is defined as an API, responses to NGSI-LD requests may also be returned in JSON application/json and GeoJSON application/geo+json format or as "normalized" or as key-value pairs with or without the #context and Properties annotations. For example, the key-values format will return the John_Lennon entity as follows:
"key-values" NGSI-LD
GET ../ngsi-ld/v1/entities/John_Lennon?options=keyValues Content-Type: application/ld+json
{
"#context": "https://json-ld.org/contexts/person.jsonld",
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
which is the same as the original JSON-LD example. And it's also possible to return as plain JSON or GeoJSON by amending the content-type.
GET ../ngsi-ld/v1/entities/John_Lennon?options=keyValues Content-Type: application/json
{
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
GET ../ngsi-ld/v1/entities/John_Lennon?options=keyValues Content-Type: application/geo+json
{
"type": "Feature",
"geometry": {
"type": "Point",
"coordinates": [-73.975, 40.775556]
},
"properties": {
"name": "John Lennon",
"born": "1940-10-09",
"spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
}
"normalized" is typically used for broker-to-broker data exchange. "keyValues" is more likely to be used by an application developer. Indeed when you get the data back as just JSON all the attributes have been washed using a expansion/compaction operation which means that you can get data from multiple sources using different attribute names to return using a single common short name for agreed IRIs - this is the goal of an interoperability exchange API for data.
So in summary the "normalized" NGSI-LD format is an extended subset of JSON-LD. The NGSI-LD API itself is a more flexible API which outputs various JSON and JSON-LD formats and is used for data exchange.
If you need more information, there is also a more extensive review of NGSI-LD data formats (including a new "concise" data format) in a recent Video Presentation from the FIWARE Foundation.