renumbered references and removed unused ones

## A.3 NGSI-LD namespace

NGSI-LD defines a specific URN [n.9] namespace intended to help API users to

NGSI-LD defines a specific URN [n.23] namespace intended to help API users to

design readable, clean and simple identifiers. As it is based on URNs, the usage

of this identification approach is not recommended when dereferenceable URIs are

needed (fully-fledged linked data scenarios).

Below is the definition of the Core NGSI-LD _`@context`_ which shall be

supported by implementations.

Such definition has been tested using [i.7].

Such definition has been tested using [i.19].

```json

{

This annex is informative and is intended to show in action the JSON-LD

representation defined by NGSI-LD.

JSON representations of the examples shown in this annex can be found at [i.15].

JSON representations of the examples shown in this annex can be found at [i.20].

## C.2 Entity representation

As per the algorithms described above and as per the rules for generating the

JSON-LD representation of NGSI-LD entities the above graph will result in the

following JSON-LD representations. The syntax has been checked using the JSON-LD

Playground tool [i.5].

Playground tool [i.21].

### C.2.2 Vehicle Entity

## C.7 Link header utilization clarifications

The JSON-LD Specification [n.2] states clearly that **only one HTTP Link

The JSON-LD Specification [n.8] states clearly that **only one HTTP Link

header** with the link relationship

<​http://www.w3.org/ns/json-ld#context> is required to appear. Such

statement has implications in terms of providing the JSON-LD _`@context`_ when

## C.8 \@context processing clarifications

JSON-LD Specification [n.2] says that "If a term is redefined within a context,

JSON-LD Specification [n.8] says that "If a term is redefined within a context,

all previous rules associated with the previous definition are removed". In

addition, it is stated that "Multiple contexts may be combined using an array,

which is processed in order".

## C.9 ValueType datatype utilization clarifications

Using JSON-LD [n.2] syntax, typed values can be expressed using the JSON-LD

Using JSON-LD [n.8] syntax, typed values can be expressed using the JSON-LD

_`@type`_ keyword when defining a term, where _`@type`_ value holds a URI which

indicates the value's datatype. However, it can be desirable for a [Context

Broker]{.HTML-Keyboard} to be able to hold simpler untyped values within a

## C.10 Entity with digital signature for a Property

As specified in [n.35], the atomic piece of information that creators can

As specified in [n.9], the atomic piece of information that creators can

digitally sign in an NGSI-LD ecosystem is each single Attribute of an Entity. In

the following example, an Entity of type "Store" with two Properties, "address"

and "location" is presented. The "address" Property is digitally signed. The

These algorithms are informative but NGSI-LD implementations should aim at

either implementing them as they are described here or devising similar

algorithms which take exactly the same input and provides exactly the same

output (or an equivalent one as per the JSON-LD specification [n.2]).

output (or an equivalent one as per the JSON-LD specification [n.8]).

## D.2 Algorithm for transforming an NGSI-LD Entity into a JSON-LD document (ALG1)

>>> [!note] NOTE:

An early implementation of this algorithm can be found at [i.5].

An early implementation of this algorithm can be found at [i.21].

>>>

# Annex E [(informative)]{.inform}: RDF-compatible specification of NGSI-LD meta-model

The content of this annex is now in ETSI GS CIM 006 [i.8].

The content of this annex is now in ETSI GS CIM 006 [i.6].