Context Information Management (CIM); Handling of Linked Data Event Streams with NGSI-LD

DGR/CIM-0056

General Information

Status
Not Published
Current Stage
12 - Citation in the OJ (auto-insert)
Due Date
18-Dec-2024
Completion Date
27-Feb-2025
Ref Project
Standard
ETSI GR CIM 056 V1.1.1 (2025-02) - Context Information Management (CIM); Handling of Linked Data Event Streams with NGSI-LD
English language
24 pages
sale 15% off
Preview
sale 15% off
Preview

Standards Content (Sample)


GROUP REPORT
Context Information Management (CIM);
Handling of Linked Data Event Streams with NGSI-LD
Disclaimer
The present document has been produced and approved by the cross-cutting Context Information Management (CIM) ETSI
Industry Specification Group (ISG) and represents the views of those members who participated in this ISG.
It does not necessarily represent the views of the entire ETSI membership.

2 ETSI GR CIM 056 V1.1.1 (2025-02)

Reference
DGR/CIM-0056
Keywords
API, architecture, data interoperability, data
sharing, NGSI-LD
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: +33 4 92 94 42 00  Fax: +33 4 93 65 47 16

Siret N° 348 623 562 00017 - APE 7112B
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° w061004871

Important notice
The present document can be downloaded from the
ETSI Search & Browse Standards application.
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the prevailing version of an ETSI
deliverable is the one made publicly available in PDF format on ETSI deliver repository.
Users should be aware that the present document may be revised or have its status changed,
this information is available in the Milestones listing.
If you find errors in the present document, please send your comments to
the relevant service listed under Committee Support Staff.
If you find a security vulnerability in the present document, please report it through our
Coordinated Vulnerability Disclosure (CVD) program.
Notice of disclaimer & limitation of liability
The information provided in the present deliverable is directed solely to professionals who have the appropriate degree of
experience to understand and interpret its content in accordance with generally accepted engineering or
other professional standard and applicable regulations.
No recommendation as to products and services or vendors is made or should be implied.
No representation or warranty is made that this deliverable is technically accurate or sufficient or conforms to any law
and/or governmental rule and/or regulation and further, no representation or warranty is made of merchantability or fitness
for any particular purpose or against infringement of intellectual property rights.
In no event shall ETSI be held liable for loss of profits or any other incidental or consequential damages.

Any software contained in this deliverable is provided "AS IS" with no warranties, express or implied, including but not
limited to, the warranties of merchantability, fitness for a particular purpose and non-infringement of intellectual property
rights and ETSI shall not be held liable in any event for any damages whatsoever (including, without limitation, damages
for loss of profits, business interruption, loss of information, or any other pecuniary loss) arising out of or related to the use
of or inability to use the software.
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying and
microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.

© ETSI 2025.
All rights reserved.
ETSI
3 ETSI GR CIM 056 V1.1.1 (2025-02)
Contents
Intellectual Property Rights . 4
Foreword . 4
Modal verbs terminology . 4
Executive summary . 4
1 Scope . 5
2 References . 5
2.1 Normative references . 5
2.2 Informative references . 5
3 Definition of terms, symbols and abbreviations . 6
3.1 Terms . 6
3.2 Symbols . 6
3.3 Abbreviations . 6
4 Linked Data Event Streams . 7
4.1 Introduction . 7
4.2 TREE to NGSI-LD mapping . 8
4.3 LDES to NGSI-LD mapping . 9
5 Mapping NGSI-LD to LDES . 9
5.0 Foreword . 9
5.1 NGSI-LD Data Representation to LDES mapping . 10
5.1.1 NGSI-LD entity representation to LDES member . 10
5.1.2 Temporal Representation of an Entity to LDES member . 11
6 Architectural Considerations . 12
6.0 Foreword . 12
6.1 LDES to NGSI-LD . 12
6.2 NGSI-LD to LDES . 14
6.2.0 Foreword . 14
6.2.1 Paginated view . 14
6.2.2 Geospatial fragmentation . 15
6.2.3 Reference fragmentation . 16
Annex A: Mapping examples . 18
A.1 Mapping TREE collection and its members . 18
A.2 Mapping TREE collection and its view. 19
A.3 Mapping LDES collection and its members . 21
Annex B: Change history . 23
History . 24

ETSI
4 ETSI GR CIM 056 V1.1.1 (2025-02)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The declarations
pertaining to these essential IPRs, if any, are publicly available for ETSI members and non-members, and can be
found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to
ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the
ETSI IPR online database.
Pursuant to the ETSI Directives including the ETSI IPR Policy, no investigation regarding the essentiality of IPRs,
including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not
referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become,
essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its
Members. 3GPP™, LTE™ and 5G™ logo are trademarks of ETSI registered for the benefit of its Members and of the
3GPP Organizational Partners. oneM2M™ logo is a trademark of ETSI registered for the benefit of its Members and of ®
the oneM2M Partners. GSM and the GSM logo are trademarks registered and owned by the GSM Association.
Foreword
This Group Report (GR) has been produced by ETSI Industry Specification Group (ISG) cross-cutting Context
Information Management (CIM).
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
Executive summary
The present document investigates how LDES sources can be consumed by NGSI-LD context brokers and vice versa
how NGSI-LD context brokers can make their context information available to LDES consumers.
ETSI
5 ETSI GR CIM 056 V1.1.1 (2025-02)
1 Scope
The present document brings an introduction of the Linked Data Event Streams (LDES) and TREE specifications and
maps part of its key concepts to the NGSI-LD model. Also, a mapping of the NGSI-LD entity representation to LDES
members is proposed.
The second part of the present document focuses on the architectural considerations of consuming and publishing LDES
with NGSI-LD context brokers.
2 References
2.1 Normative references
Normative references are not applicable in the present document.
2.2 Informative references
References are either specific (identified by date of publication and/or edition number or version number) or
non-specific. For specific references, only the cited version applies. For non-specific references, the latest version of the
referenced document (including any amendments) applies.
NOTE: While any hyperlinks included in this clause were valid at the time of publication, ETSI cannot guarantee
their long term validity.
The following referenced documents are not necessary for the application of the present document but they assist the
user with regard to a particular subject area.
[i.1] "Linked Data Event Streams Specification". ®
[i.2] W3C : "The TREE hypermedia specification".
[i.3] ETSI GS CIM 009 (V1.8.1): "Context Information Management (CIM); NGSI-LD API". ®
[i.4] OGC : "Web Feature Service". ®
[i.5] OGC APIs. ®
[i.6] W3C Recommendation 21 March 2013: "SPARQL 1.1 Query Language".
[i.7] Linked Data Event Streams Server (Flemish Smart Data Space).
[i.8] Linked Data Event Streams JSON-LD context.
[i.9] Slippy map tilenames.
[i.10] Pagination (Flemish Smart Data Space).
[i.11] Reference Fragmentation (Flemish Smart Data Space).
[i.12] Geospatial fragmentation (Flemish Smart Data Space).
ETSI
6 ETSI GR CIM 056 V1.1.1 (2025-02)
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
LDES member: object whose status cannot change after it was created
LDES view: event stream view that connects the collection to the root node such that all members of the collection can
be found
Linked Data Event Stream (LDES): collection of immutable objects (such as version objects & sensor observations)
NGSI-LD attribute: reference to both an NGSI-LD Property and to an NGSI-LD Relationship
NGSI-LD attribute Type: categorization of an NGSI-LD Property or NGSI-LD Relationships

NGSI-LD element: any JSON element that is defined by the NGSI-LD API
NGSI-LD entity: informational representative of something that is supposed to exist in the real world, physically or
conceptually
NGSI-LD entity type: categorization of an NGSI-LD entity as belonging to a class of similar entities, or sharing a set
of characteristic properties
TREE collection: collection containing members following an imposed shape
NOTE: The members may be spread across multiple nodes.
TREE member: object that is part of a collection
TREE node: HTTP page, which itself may already contain members, that can contain relationships to other nodes
TREE ontology: hypermedia specification for fragmenting collections
TREE root node: home page, which itself may already contain members, through whose linked pages all members can
be found
TREE shape: technical description of the structure to which objects from the collection has to conform
3.2 Symbols
Void.
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
DCAT Data CATalog vocabulary
FSDS Flemish Smart Data Space
HTTP HperText Transfer Protocol
JSON Java Script Object Notation
LDES Linked Data Event Streams
NGSI Next Generation Service Interface
OGC Open Geospatial Consortium
SEMIC Semantic Interoperability Community
SPARQL SPARQL Protocol and RDF Query Language
URI Uniform Resource Identifier
URL Uniform Resource Locator
WFS Web Feature Service
ETSI
7 ETSI GR CIM 056 V1.1.1 (2025-02)
NOTE: TREE is not an abbreviation, but the name of an ontology for fragmenting collections of items across
multiple HTTP pages in a 'tree'-like way (linear, hierarchical, tiling-based, etc.).
4 Linked Data Event Streams
4.1 Introduction
The Linked Data Event Streams (LDES) specification enables datasets to be repurposed in different contexts. All kinds
of datasets are in scope: static data, such as bibliographic records, as well as real-time data, such as sensor observations.
A dataset is represented as an event source, which is an append-only collection of immutable objects: each time the
dataset changes, a new object, called member, is added to the collection and is expected never to change. Typically, a
member is a version object, but this can also be an immutable sensor observation or an activity object describing the
occurred action.
The LDES specification [i.1] is available at https://w3id.org/ldes/specification.
NOTE 1: A collection imposes a certain shape on its members expressing the structure of the members. For
example, members require to have a type "Vehicle" and a property "speed".
EXAMPLE 1: "Bob's vehicle speed is 10 km/h" can be modelled as an immutable sensor
observation.
EXAMPLE 2: "Bob's vehicle brand is Mercedes" can be modelled as a version object of Bob's
vehicle.
EXAMPLE 3: "Bob's vehicle's speed was measured at 10, 20, and 30 km/h" can be represented with
three LDES members.
The LDES specification is based on the TREE hypermedia specification to publish collections. When a collection
becomes too big for one HTTP page, fragmentation in multiple pages is needed. The TREE specification originates
from the idea to provide an alternative to one-dimensional HTTP pagination. It allows to fragment a collection of items
and interlink these fragments. Instead of linking to the next or previous page, a relation between two fragments, called
TREE nodes, describes what elements can be found by following the link to another fragment.
The TREE specification [i.2] is available at https://w3id.org/tree/specification.
EXAMPLE 4: A TREE node identified with query parameter "time=2024-05-14" contains members with a
modifiedAt property greater than "2024-05-14".
EXAMPLE 5: A TREE relation describes that TREE node has members with a modified
greater than "2024-05-14". The relation has as specific type "tree:GreaterThanRelation", has
tree:node property with value , and has a tree:path property with value
modifiedAt.
NOTE 2: LDES typically uses one-dimensional pagination where updates are appended to a "latest" fragment. This
way, consumers only need to be subscribed to one fragment for updates. When this latest fragment
reaches a certain threshold, a new, latest fragment is created.
NOTE 3: The members of an LDES can be published through different types of fragmentations, which are called
TREE views. For example, a view can first fragment a collection in geographical regions, and then enable
a one-dimensional pagination per region.
With LDES, data consumers can set up pipelines to automatically replicate the history of a dataset and stay in sync with
the latest updates. Today, custom code has to be created to integrate data, which makes it rather expensive to integrate
multiple data sources. With LDES, a technical standard [i.1]was created that allows data to be exchanged across silos
using domain-specific ontologies. An LDES allows third parties to build specific services (ETSI GS CIM 009 [i.3],
Web Feature Service (WFS) [i.4], OGC APIs [i.5], SPARQL [i.6]) that are always in sync with the original dataset.
The next clauses describe how the TREE and LDES models map with the NGSI-LD meta model.
ETSI
8 ETSI GR CIM 056 V1.1.1 (2025-02)
4.2 TREE to NGSI-LD mapping
The TREE vocabulary defines 5 classes, and 16 properties in total. The present document only maps the classes and
properties that are required to be retrievable by LDES clients. Features like imports, view descriptions, shapes,
remaining items, etc. are optional in the TREE specification [i.2] and therefore out-of-scope. Figure 4.2-1 demonstrates
for a subset of TREE classes and properties how they map to NGSI-LD Entities, Relationships, Properties and value.
NOTE 1: Following prefixes are used to enhance readability:
 tree: https://w3id.org/tree#
 dcat: http://www.w3.org/ns/dcat#

Figure 4.2-1: High-level mapping of TREE Specification to NGSI-LD Meta Model
The class tree:Collection can be mapped to NGSI-LD entity. A collection corresponds with a dcat:Dataset and has two
relationships:
• The tree:member relationship linking to other members (NGSI-LD entities) that are part of the TREE
collection. Clause A.1 provides an example.
• The tree:view relationship towards a tree:Node being an entrypoint (HTTP page) to retrieve members.
Clause A.2 provides an example.
NOTE 2: The tree:member relationship typically only lists the members that are described in the same page.
The class tree:Node, being an HTTP page containing a part of the collection, can also be mapped to an NGSI-LD entity
and has following property:
• the tree:relation property linking to another tree:Node. Clause A.2 provides an example.
The value of the tree:relation is an instance of a tree:Relation and is mapped as an NGSI-LD Value. More specifically,
as a JSON-LD structured value. The reason is that a tree:Relation always is part of a tree:Node and therefore has no
identity. The tree:Relation has following properties:
• A tree:node property (mandatory) containing the URL of another TREE node.
• A tree:path property (optional) indicating to which of the members' properties this relation applies.
• A tree:value property (optional) indicating a value constraint on the members' values.
NOTE 3: The tree:path and tree:value properties have to be used in conjunction to be useful for an LDES
consumer.
ETSI
9 ETSI GR CIM 056 V1.1.1 (2025-02)
NOTE 4: The tree:path and tree:value properties allow LDES consumers to decide whether to continue to the next
node.
This clause demonstrates how TREE allows to:
i) define a collection of NGSI-LD Entities;
ii) define nodes that contain a subset of the collection; and
iii) use qualified relations to guide consumers to retrieve relevant nodes.
In clause 4.3, it is presented how LDES is a specialization of a TREE collection to replicate versions of entities.
4.3 LDES to NGSI-LD mapping
The LDES vocabulary defines 7 classes, and 8 properties in total. Features like event source, retention policies, version
or materialization are not required to be retrievable by LDES clients and therefore out-of-scope.
Figure 4.3-1 shows that the ldes:EventStream class is mapped to an NGSI-LD entity, similar to its super class
tree:Collection. Two properties are introduced to enable versioning on the entities of a collection:
• The ldes:timestampPath is mapped to an NGSI-LD Property indicating how a member precedes another
member in the LDES using a timestamp.
• The ldes:versionOfPath is mapped to an NGSI-LD Property indicating the non-version object of a member.
An example of these properties and how this resolves in an LDES member can be found in clauses 5.1 and A.3.

Figure 4.3-1: High-level mapping of Linked Data Event Streams data model to NGSI-LD Meta Model
This clause describes how LDES introduces versioning of entities using the timestamp and version of properties. This
way, instances of the same entity have an explicit identifier and consumers know whether an entity version precedes
another. In contrast with clause 4.6.6 in ETSI GS CIM 009 [i.3], entity instances of the same entity are not expected to
come in chronological order. In clause 5, a way will be proposed to map an instance of an NGSI-LD entity to an LDES
member.
5 Mapping NGSI-LD to LDES
5.0 Foreword
This clause 5 describes what needs to be adapted to the NGSI-LD Meta Model to map with the LDES standard. First, it
will be discussed how the NGSI-LD entity representation from the core interfaces maps to one member. Then, it will be
presented how the temporal representation of an entity can be mapped to multiple members.
ETSI
10 ETSI GR CIM 056 V1.1.1 (2025-02)
5.1 NGSI-LD Data Representation to LDES mapping
5.1.1 NGSI-LD entity representation to LDES member
Here is a presentation of an instance of an entity with identifier urn:person:1. The system attributes createdAt and
modifiedAt are provided to explain how a version can be created based on these properties.
EXAMPLE 1: NGSI-LD entity as base example to demonstrate LDES members:
{
"id": "urn:person:1",
"type": "Person",
"name": {
"type": "Property",
"value": "Bill Smith",
"createdAt": "2022-08-09T18:25:02Z",
"modifiedAt": "2022-08-10T18:25:02Z"
},
"createdAt": "2022-08-09T18:25:02Z",
"modifiedAt": "2022-08-10T18:25:02Z"
}
A member of an LDES represents an entity at a certain time. With the modifiedAt temporal property of an NGSI-LD
entity, the last time the entity has been modified can be used to describe the latest version of an entity. Example 2 shows
how the modifiedAt value is appended to create a version-specific identifier. For the timestamp property of a member, it
is not allowed to use modifiedAt, because this is a system attribute and is preserved for internal usage in a context
broker. Therefore, the present document proposes to define the observedAt temporal property at the entity level with
following definition:
• observedAt is defined as the temporal Property at which a certain Entity became valid or was observed. For
example, a person Entity with certain Properties and Relationships was observed at this point in time.
Example 2 shows how the observedAt property was added to the entity version. This version represents how the entity
was observed at the time of modification.
It is also proposed to add the observedAt property on all the Relationships and Properties where this is not yet defined.
Example 1 shows how the observedAt property was added to the name Property.
An isVersionOf property is added as non-reified property (the value only contains the entity id) containing the non-
version entity id. Typically, LDESs use isVersionOf from the Dublin Core initiative
(http://purl.org/dc/terms/isVersionOf).
All system attributes are hidden as this should not be part of the LDES publication.
EXAMPLE 2: Versioned entity using the observedAt temporal property:
{
"id": "urn:ngsi-ld:Person:1:2022-08-10T18:25:02Z",
"type": "Person",
"isVersionOf": "urn:ngsi-ld:Person:1",
"observedAt": "2022-08-10T18:25:02Z",
"name": {
"type": "Property",
"value": "Bill Smith",
"observedAt": "2022-08-10T18:25:02Z"
}
}
EXAMPLE 3: A simplified representation of the versioned entity is also possible:
{
"id": "urn:ngsi-ld:Person:1:2022-08-10T18:25:02Z",
"type": "Person",
"isVersionOf": "urn:ngsi-ld:Person:1",
"observedAt": "2022-08-10T18:25:02Z",
"name": "Bill Smith"
}
ETSI
11 ETSI GR CIM 056 V1.1.1 (2025-02)
EXAMPLE 4: When observedAt is already defined, then this is not replaced with its modifiedAt value:
{
"id": "urn:ngsi-ld:Person:1:2022-08-10T18:25:02Z",
"type": "Person",
"isVersionOf": "urn:ngs
...

Questions, Comments and Discussion

Ask us and Technical Secretary will try to provide an answer. You can facilitate discussion about the standard in here.

Loading comments...