-
Notifications
You must be signed in to change notification settings - Fork 44
Home
- Gap Analysis. Summary of the main differences between NGSIv2 and NGSI-LD
- NGSI-LD. Preliminary Specification
-
In the mongoDB documents associated to Entities it is preferred not to overload the metadata dictionary, to ensure future compatibility with Entities serialized using NGSIv2.
-
Performance-wise it could be a good idea to store the alias of attributes as that would be needed at Entity rendering time.
- Is there ambiguity in the following API URI?
GET /ngsi-ld/v1/entities/http://E1/attrs/A1
The response is: There should never be ambiguity because, as per RFC 3986, an Entity Id (represented by a URI) should be properly encoded when incorporated to an API URL. Thus,
there could be either two cases:
/ngsi-ld/v1/entities/http%3A%2F%2FE1%2Fattrs%2FA1
or
/ngsi-ld/v1/entities/http%3A%2F%2FE1/attrs/A1
which are clear.
-
It is not needed to serialise Core @context terms as the Core @context is always implicitly present.
-
When expanding terms of the user vocabulary (entity types, attributes, etc. ) the user @context shall be used and not the core @context. The Core @context is defining the terms used by the API itself (the system) and as a result, in general, it should not be part of the user vocabulary. There is one exception though, the "location" attribute which is defined by the @core Context.
So if the alias "name" is used by the user it should not be mapped to "http://uri.etsi.org/ngsi-ld/name", but to whatever the user has defined in the @context, for instance.
"name": "http://schema.org/name"
and if nothing is found in the user @context, then it should be mapped to a default URI
http://example.org/ngsi-ld/name
-
s/cSourceRegistrations/csourceRegistrations/g
-
URNs shall be validated against the grammar defined at IETF RFC 8141: "Uniform Resource Names (URNs)".