Skip to content
Jose M. Cantera edited this page Oct 2, 2018 · 36 revisions

Orion-LD Implementation Notes

Reference documents

Design Review Meeting Notes

mongoDB Data Model

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

URI design issues. Entity identifiers.

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

@context issues

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

  • The only exception is 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

misc issues

  • s/cSourceRegistrations/csourceRegistrations/g

  • URNs shall be validated against the grammar defined at IETF RFC 8141: "Uniform Resource Names (URNs)".

Clone this wiki locally