You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -28,6 +28,124 @@ The tutorial uses [cUrl](https://ec.haxx.se/) commands throughout, but is also a
28
28
>
29
29
> — Sophocles, Oedipus at Colonus
30
30
31
+
The NGSI-LD API is a flexible mechanism for producing context data in mulitple formats.
32
+
This was demonstrated in the initial Getting Started [tutorial](https://github.com/FIWARE/tutorials.Getting-Started/tree/NGSI-LD) where both "normalized" and "key-values" pairs format were produced. The default, verbose data format is so-called "normalized" NGSI-LD where every **Property** is defined by `"type": "Property`
33
+
and every **Relationship** is defined by `"type": "Relationship`. These keywords ( `type`, `Property` and `Relationship`) are in turn strictly defined JSON-LD terms which can be found in the core @context served with every request.
34
+
35
+
36
+
### Normalized NGSI-LD
37
+
38
+
The full "normalized" form is an excellent choice for data exchange, since through the the `@context` and the definition of JSON-LD keywords, machines are given all the tools to fully comprehend
39
+
the payload format. Responses return the complete current state of each entity, with payloads all including sub-attributes such as Properties-of-Properties,
40
+
Properties-of-Relationships and other standard metadata terms like `observedAt` and `unitCode`. Furthermore normalized payloads are exceedingly regular and parseable, and can easily be reduced down to the relevant `value` elements if such an operation necessary. However with the normalized format, is necessary to repeatedly supply common defining attributes such as `"type": "Property` throughout the payload to ensure that machines can fully understand the data represented.
41
+
42
+
#### Normalized NGSI-LD using `options=normalized`
Open in [**JSON-LD Playground**](https://tinyurl.com/4nw9z83m)
71
+
72
+
73
+
74
+
### Simplified NGSI-LD
75
+
76
+
The use of the normalized format can be contrast with the "key-values" pairs format, which is a simplified version concentrating purely on the values of the first level of attributes only. The payloads are remain regular, but are much shorter and to the point, and not all information is returned by the request - `unitCode` and `observedAt` will not be returned in the payload.
Open in [**JSON-LD Playground**](https://tinyurl.com/2p93h8p6)
100
+
101
+
102
+
This key-values payload matches the simple JSON-LD payload which can be seen on the front-page of the official [JSON-LD website](https://json-ld.org/)
103
+
104
+
Both normalized and key-values NGSI-LD formats are valid JSON-LD, but since the key-values format is lossy, until recently, all updates to an NGSI-LD context broker must be made using the normalized format.
105
+
106
+
### Concise NGSI-LD
107
+
108
+
To make the API easier to use and reduce the burden on developers, NGSI-LD now accepts an intermediate "concise" format which still offers all of the context data in the payload, but
109
+
removes the redundancy of repeatedly adding `"type": "Property` throughout each payload. The concise representation is a terser, lossless form of the normalized representation, where redundant "type" members are omitted and the following rules are applied:
110
+
111
+
- Every **Property** without further sub-attributes is represented by the Property value only.
112
+
- Every **Property** that includes further sub-attributes is represented by a value key-value pair.
113
+
- Every **GeoProperty** without further sub-attributes is represented by the GeoProperty’s GeoJSON representation only
114
+
- Every **GeoProperty** that includes further sub-attributes is represented by a value key-value pair.
115
+
- Every **LanguageProperty** is defined by a languageMap key-value pair.
116
+
- Every **Relationship** is defined by an object key-value pair.
0 commit comments