These algorithms described below are informative, but NGSI-LD implementations should aim at either implementing them as they are described here or providing equivalent @context elements for their payloads to provide interoperability with their internationalized context entities.
Since Internationalization is not core to context information management, any direct support within NGSI-LD systems is limited. Annex G proposes a series of best practices for maintaining, querying and displaying interoperable internationalized data.
The content of the @context utilized for the referred Entities within these examples uses pre-existing URNs used for internationalization and is as follows:
"inLanguage": "http://schema.org/inLanguage","sameAs": "http://schema.org/sameAs"
Where a context Entity is associated with a single natural language, include a well-defined Property indicating the natural language of the content. For example an Event taking place in French may be defined as follows:
Where a Property of a context entity can be associated to one more natural language, include additional metadata as a sub-Property of that Property. For example, a Hotel with booking forms available in English, French and German may be defined as follows:
Where equivalent context entities in multiple natural languages exist, they may be associated with each other through the use of a one-to-many relationship, where each relationship holds an additional sub-Property indicating the natural language of the equivalent entities.
For example, three Events (such as a walking tour which is available in English, French and German) may be associated to each other as follows:
All strings within an NGSI-LD system are defined and sorted as a sequence of Unicode characters. As such there is no simple collation mechanism to query entities ignoring case, diacritic marks or matching diphthong single letters such as the German "ö" to also match with "oe".
Many databases support a degree of natural language support, in general collation support will always depend upon the underlying database and as such will vary from implementation to implementation. This therefore and cannot be standardized and exposed as part of the context information management API. Furthermore, collation is slow and processor intensive, and for massive systems is better achieved using a separate index.
For systems that require it, this clause proposes a mechanism as an extension to a NGSI-LD Context Broker which can be modified and used to offer collation support to the natural language attributes found within context entities where necessary through creating, querying and maintaining an additional property of a property for collated attributes.
Other substitutions could be made where local spelling rules vary (for example different for German ö = oe).
Create a simple forwarding proxy around the NGSI-LD system. For any urls with a q param (and a collate flag) run a clean-up of the q param and amend the query string:
The following request on the proxy:
is altered on the fly and is sent to the NGSI-LD system as shown:
Once again, the substitutions to make to the query string will depend on the rules of the natural language to be supported.
Context data entities are designed to be interoperable and therefore all dates are held as UTC dates, all currency amounts are held as JSON numbers (with the unitCode property-of-a-property available to hold the currency), etc. Localization should not occur within the context data entities themselves. Offering fully localized responses is not a concern of the NGSI-LD API.
If localization support is necessary, a simple proxying a conversion mechanism could be used to amend the context data received from the NGSI-LD system before being passed to a third party system for display.
For example, if a system needs to display DateTime data in Islamic Date format
The following request on the proxy:
is forwarded unaltered and is sent to the NGSI-LD system as shown:
The response from the NGSI-LD system is always in UTC format:
And the proxy can be used to update this to the desired format:
Using an internationalization script such as the following:
It should be noted that post-localization, the transformed date is no longer valid NGSI-LD.