ETSI GS CIM 006 V1.1.1 (2019-07)

Context Information Management (CIM); Information Model (MOD0)

DGS/CIM-006-MOD0

General Information

• Status: Published
• Publication Date: 24-Jul-2019
• Technical Committee: CIM - cross-cutting Context Information Management
• Current Stage: 12 - Completion
• Due Date: 26-Jul-2019
• Completion Date: 25-Jul-2019

Standards Content (Sample)

GROUP SPECIFICATION
Context Information Management (CIM);
Information Model (MOD0)
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 GS CIM 006 V1.1.1 (2019-07)

Reference
DGS/CIM-006-MOD0
Keywords
information model; interoperability; smart city

ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE

Tel.: [phone]  Fax: [phone]

Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88

Important notice
The present document can be downloaded from:
http://www.etsi.org/standards-search
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 at www.etsi.org/deliver.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
https://portal.etsi.org/TB/ETSIDeliverableStatus.aspx
If you find errors in the present document, please send your comment to one of the following services:
https://portal.etsi.org/People/CommiteeSupportStaff.aspx
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 2019.
All rights reserved.
DECT™, PLUGTESTS™, UMTS™ and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.

3GPP™ and LTE™ 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.
ETSI
3 ETSI GS CIM 006 V1.1.1 (2019-07)
Contents
Intellectual Property Rights . 5
Foreword . 5
Modal verbs terminology . 5
1 Scope . 6
2 References . 6
2.1 Normative references . 6
2.2 Informative references . 6
3 Definition of terms, symbols and abbreviations . 7
3.1 Terms . 7
3.2 Symbols . 7
3.3 Abbreviations . 8
4 Rationale for a multi-layered and multi-scale graph-based context information model . 8
4.1 Why use a graph-based model? . 8
4.2 Separating semantic referencing from structural descriptions . 9
4.3 Graph Examples used in the current document . 9
5 NGSI-LD meta-model . 10
5.0 Introduction . 10
5.1 Fundamentals of property graphs and graph databases . 11
5.2 Reification with blank nodes . 11
5.3 Formal definition . 14
5.3.0 Introduction. 14
5.3.1 Entity Types . 14
5.3.2 Properties and Relationships Types . 15
5.4 Serialization with JSON-LD. 15
6 ETSI ISG CIM cross-domain ontology . 17
6.1 Rationale. 17
6.2 NGSI-LD API compatibility . 17
6.3 Formal specification . 18
6.3.0 Comparison with other approaches . 18
6.3.1 Mobility (of Entities) . 21
6.3.2 Properties . 22
6.3.3 Location (Property or Relationship) . 23
6.3.4 Values . 24
6.3.5 Temporal Properties and Values . 24
6.3.6 Systems Composition . 25
6.3.6.0 Introduction . 25
6.3.6.1 Top-down system composition . 25
6.3.6.2 Bottom-up system composition and clustering . 26
Annex A (informative): Guidelines for Entity Typing . 28
A.0 Introduction . 28
A.1 Additional implementation requirements . 28
A.2 Modelling recommendations . 29
A.3 Using OWL/RDFS/RDF modelling . 29
A.3.0 Introduction . 29
A.3.1 OWL/RDFS/RDF modelling . 29
A.3.2 Object-Oriented modelling . 30
Annex B (informative): Relationship to other cross-domain ontologies and upper ontologies . 31
B.0 Introduction . 31
ETSI
4 ETSI GS CIM 006 V1.1.1 (2019-07)
B.1 Mapping to oneM2M. 31
B.2 Mapping to W3C WoT Thing Description . 32
B.3 Mapping to W3C Time Ontology . 32
B.4 GSMA NGSI-LD-Entities . 33
B.5 Mapping to SAREF . 33
Annex C (informative): Distinguishing real-word entities from NGSI-LD entities . 35
C.0 Introduction . 35
C.1 W3C View . 35
C.2 NGSI-LD View . 35
Annex D (informative): OWL-DL representation of the Information Model . 37
Annex E (informative): Authors & contributors . 43
Annex F (informative): Change History . 44
History . 45

ETSI
5 ETSI GS CIM 006 V1.1.1 (2019-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is 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 Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, 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.
Foreword
This Group Specification (GS) has been produced by ETSI Industry Specification Group (ISG) cross-cutting Context
Information Management (CIM).
Modal verbs terminology
In the present document "shall", "shall not", "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.

ETSI
6 ETSI GS CIM 006 V1.1.1 (2019-07)
1 Scope
The purpose of the present document is to give property graphs a formal semantic grounding based on
RDF/RDFS/OWL, with blank nodes reification, geared to JSON-LD serialization. On top of it, a set of core cross-
domain ontology classes have been defined, based on this meta-model. This whole information model is meant to be
used by many applications as a basis for data representations. It is compatible with the NGSI-LD API defined in [2].
2 References
2.1 Normative 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.
Referenced documents which are not found to be publicly available in the expected location might be found at
https://docbox.etsi.org/Reference.
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 necessary for the application of the present document.
[1] W3C Recommendation: "JSON-LD 1.0: A JSON-based Serialization for Linked Data".
NOTE: Available at https://www.w3.org/TR/json-ld/.
[2] ETSI GS CIM 009 (V1.1.1) (2019-01): "Context Information Management (CIM); NGSI-LD
API".
NOTE: Available at
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.01.01_60/gs_CIM009v010101p.pdf.
[3] W3C Recommendation 19 October 2017: "Time Ontology in OWL".
NOTE: Available at https://www.w3.org/TR/owl-time/.
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] Guinard, D., & Trifa, V. (2016): "Building the web of things", Shelter Island: Manning.
[i.2] Tim Berners-Lee (2006-07-27): "Linked Data", Design Issues W3C.
NOTE: Available at https://www.w3.org/DesignIssues/LinkedData.html.
[i.3] J. Frey, K. Müller, S. Hellmann, E. Rahm and M.-E. Vidal: Semantic Web - Interoperability,
Usability, Applicability an IOS Press Journal: "Evaluation of Metadata Representations in RDF
stores", 2017.
ETSI
7 ETSI GS CIM 006 V1.1.1 (2019-07)
[i.4] Cassandras, C. G., & Lafortune, S. (2009) Springer Science & Business Media: "Introduction to
discrete event systems".
[i.5] W3C: "Simple part-whole relations in OWL Ontologies".
NOTE: Available at https://www.w3.org/2001/sw/BestPractices/OEP/SimplePartWhole.
[i.6] W3C: "A Semantic Web Primer for Object-Oriented Software Developers".
NOTE: Available at https://www.w3.org/TR/sw-oosd-primer/.
[i.7] W3C: "HttpRange14Webography".
NOTE: Available at https://www.w3.org/wiki/HttpRange14Webography.
[i.8] Leo Sauermann and Richard Cyganiak (2008-12-03). W3C Interest Group Note: "Cool URIs for
the Semantic Web".
NOTE: Available at https://www.w3.org/TR/cooluris/.
3 Definition of terms, symbols and abbreviations
3.1 Terms
For the purposes of the present document, the following terms apply:
cross-domain ontology: part of the information model that defines generic classes (formal concepts and constructs,
with associated constraints) that serve as common denominators between domain specific models, addressing the
temporal and structural description of physical systems
domain-specific ontologies: information models that define base classes and their constraints, within specific technical
domains (e.g. buildings, transportation, agriculture) and define their structure and vocabulary
meta-model: part of the information model that formally defines the NGSI-LD foundational classes (Entities,
Relationships, Properties and reification constructs) on the basis of RDF/RDFS/OWL
NGSI-LD entity: informational representative of something that is supposed to exist in the real world, physically or
conceptually. Any instance of such an entity shall be uniquely identified by a URI, and characterized by reference to
one or more NGSI-LD Entity Type(s)
NGSI-LD property: description instance which associates a main characteristic, which is an NGSI-LD Value, to either
an NGSI-LD Entity, an NGSI-LD Relationship or another NGSI-LD Property
NOTE: It includes the special "hasValue" property to define its target value.
NGSI-LD relationship: description of a directed link between a subject which is either an NGSI-LD Entity, an NGSI-
LD Property, or another NGSI-LD Relationship on one hand, and an object, which is an NGSI-LD Entity, on the other
hand
NOTE: It includes the special "hasObject" property to define its target object.
NGSI-LD value: JSON value (i.e. a string, a number, true or false, an object, an array), or a JSON-LD typed value
(i.e. a string as the lexical form of the value together with a type, defined by an XSD base type or more generally an
IRI), or a JSON-LD structured value (i.e. a set, a list, a language-tagged string)
EXAMPLE: An NGSI-LD Entity of type (Type Name) "Vehicle" (when parked) can be the subject of an NGSI-
LD Relationship which has as its object a NGSI-LD Entity of type "Parking".
3.2 Symbols
Void.
ETSI
8 ETSI GS CIM 006 V1.1.1 (2019-07)
3.3 Abbreviations
For the purposes of the present document, the following abbreviations apply:
API Application Programming Interface
CIM Context Information Management
CNIT Consorzio Nazionale Interuniversitario per le Telecomunicazioni
DBMS Database Management System
GSMA GSM Association
HTTP Hypertext Transfer Protocol
IRI Internationalized Resource Identifier
ISG Industry Study Group
JSON Javascript Object Notation
JSON-LD Javascript Object Notation for Linked Data
LOD Linked Open Data
NIR Non-Informational Resource
OGC Open Geospatial Consortium
OWL Web Ontology Language
OWL-DL Web Ontology Language Description Logic
RDF Resource Description Framework
RDFS Resource Description Framework Schema
SAREF Smart Applications REFerence ontology
SAS Société par Actions Simplifiée
URI Uniform Resource Identifier
XML eXtended Markup language
XSD XML Schema Definition
4 Rationale for a multi-layered and multi-scale
graph-based context information model
4.1 Why use a graph-based model?
Systems and environments about which context information is stored and managed encompass many physical and non-
physical entities. Context comprises all characteristics of these entities, as well as their states and other dynamic
properties, together with relationships that stand for actual and virtual connections between them. This context
information may be consolidated on the basis of data obtained from many different primary sources and infrastructures.
Typical examples of such systems would be smart homes, buildings, or cities. Such systems, due to the wide range of
requirements and granularities, are complex from the semantic, structural and behavioural viewpoints.
The expressivity and versatility of graph-based models allows to bring the whole corpus of graph theory to bear and to
capture key information about such complex environments, in a directly usable way, as the graph matches all kinds of
real-world connections between different physical entities.
Graph models bring a fresh view on the definition of context information. In the first wave of context-awareness
research dating back to the early 2000s, context used to be mostly, and implicitly, user-centric, typically capturing
e.g. the activity or location of mobile users to adapt services offered to them. A widely publicized definition of context,
dating from this stage of research, was "any information that can be used to characterize the situation of an entity". In a
broader view of context where the very notion of context is de-centred and relative, this definition may in fact remain
valid if entities are represented as the nodes of a graph. Rather than through a vague notion of situation, context is
defined in the present document as the set of properties characterizing these nodes, together with the set of relationships
that enmesh them together, and the properties of these relationships. In this perspective, the primary data of one
application may be the context of another, and vice versa. Context is, thus decentered and broadly defined, the graph
itself. NGSI-LD thus maintains and exposes context information as a graph of matching links between the informational
units corresponding to real-world entities of these environments.
ETSI
9 ETSI GS CIM 006 V1.1.1 (2019-07)
Traditional (mono-centred) context fitted rather well a classical object-oriented or key-value description, with a set of
more or less detailed context features attached to a single entity. The multi-cantered notion of context address in the
present document requires breaking this rigid hierarchical model by using a more expressive, flexible and adaptable
information model. Graphs are the only model adapted to capture the complex structure of and inter-entity relationships
that make up context information in the sense in which it is defined it here. This information need not be semantically
defined from the outset: it may be natively structural information, capturing e.g. containment or adjacency relationships.
The semantics of this context may be added in a later stage of graph enrichment. This model fits the natively distributed
nature of context data sources.
The Web of Things (WoT) [i.1] does also involve a graph of sorts, but it dispenses with maintaining it explicitly inside
a database. The WoT graph is, like the graph of the original web, an implicit 100 % distributed graph of hyperlinks, not
between web pages but between resources corresponding to connected devices that expose an HTTP interface.
This view also aligns well with the grand evolution of the Web towards Linked Data, an evolution proposed by W3C
from the Semantic Web project [i.2] that is currently supported by RDF-derived graph models. Linked Data provides a
method of publishing structured data so that it can be interlinked and support semantic queries.
4.2 Separating semantic referencing from structural
descriptions
The NGSI-LD information model separates semantic referencing, used in the classical sense of the Semantic Web, from
the structural description proper. The structural description may itself be decomposed into a basis structural graph
whose nodes are physically-matched entities, and an overlay layer used to capture the way in which these entities are
clustered into subgraphs.
Semantic referencing used by NGSI-LD is based on standard RDF/RDS/OWL typing and public ontologies, as shared
by all other semantic information models. All nodes and edges of the structural graph are thus matched to several
relevant classes/categories of these ontologies that jointly characterize the features shared by all instances of these
classes.
A structural graph is a model of the structural description of an environment, capturing the relationships between the
different subsystems that make up this environment. This description is, to some extent, independent of the overlaying
semantic referencing, and it could be considered to "stand on its own", even without this referencing. A structural graph
does in fact have a different kind of semantics of its own, such as e.g. when a graph captures and matches the structure
of a physical network like a power grid or a water distribution network. These semantics apply to the graphs as a whole
and are not reducible to the kind of "per-resource" semantics, which RDF is meant to describe.
4.3 Graph Examples used in the current document
Two examples of structural representations of city environments will be used as lead examples throughout the present
document and are presented in Figure 1. Property graph example (1) and Figure 1. Property graph example (2).
The following graphical conventions are used throughout the present document:
• Regular (physically-matched) entities are represented as black rectangles.
• Relationships between these entities are represented as diamonds (rhombuses) overlaid on the corresponding
arc of the graph, a convention borrowed from "entity-relationship" diagrams.
• Properties are represented by ovals that are on an arc between their entity or relationship and the property
value, but often the arc is shortened to zero length for compactness.
• Values are represented as hexagons that may about the oval of the property of which they are the target,
omitting an arc between the two.
Figure 1 describes a parking scenario, adjacent to two different streets. Information about the streets, parking places,
and the sensors that monitor are attached to entities as shown in the figure. This example is intended to illustrate the full
expressivity of a property graph as used to capture not only pure semantics, as an RDF graph would, but also structural
and behavioural (in this case, the real-time state) information.
ETSI
10 ETSI GS CIM 006 V1.1.1 (2019-07)

Figure 1: Property graph example (1)
Figure 2 example (2) is a more complex example used to illustrate intersecting domains and intertwined technical
systems. The example consists of a building and its parts (using "hasPart" relationships) forming the structure of the
building, in addition to other technical systems that are included in the building. The building is comprised of a garage
and apartments (only one instance is represented below). A parking place within the garage belongs to the apartment,
thus forming one system together. The building is equipped with a security system containing security devices.
Additionally, there is a separate public parking that also appears in the example.

Figure 2: Property graph example (2)
5 NGSI-LD meta-model
5.0 Introduction
The NGSI-LD meta-model provides a formal basis for representing "property graphs" using RDF/RDFS/OWL. It
makes it possible to perform back and forth conversion between datasets based on the property graph model on the one
hand and linked data datasets which rely on the RDF framework, on the other hand. This may be seen as raising the
semantic expressivity of RDF triples to the level of property graphs. Property graphs may, contrary to RDF, use
predicates as subjects of other predicates (properties of properties and properties of relationships).
ETSI
11 ETSI GS CIM 006 V1.1.1 (2019-07)
5.1 Fundamentals of property graphs and graph databases
Property graphs are the implicit semi-formal data models underlying most present-day graph databases. They have
gained widespread following, more in industry than in academia. They make it possible to attach properties (defined as
key-value pairs) to relationships, a feature which RDF does not directly support, but they lack the standardization and
formal underpinnings of RDF and do not interoperate directly with linked data and other RDF datasets. Also they do not
lend themselves to reasoning with RDF-based reasoning tools or querying with standard query languages such as
SPARQL.
Property graphs are usually defined (informally) as follows:
• A property graph is made up of nodes (vertices), relationships, and properties.
• Nodes may have properties in the form of arbitrary key-value pairs. Keys are strings and values are arbitrary
data types.
• A relationship is an arc (uni-directional, i.e. directed edge) of the graph proper, which always has an identifier,
a start node and an end node. Like nodes, relationships can have properties attached to them.
There are several key differences between property graphs (PG in the following) and RDF graphs.
• RDF properties are expressed as regular triples, i.e. arcs of the graph with start node and end node, and their
target can be either a literal, an IRI or a blank node [1], whereas the target of a PG property always
corresponds to an RDF literal.
• PG relationships (i.e. primary graph links between PG vertices) are first-class citizens of the PG model and
have an internal structure similar to that of a vertex, inherited from object-oriented modelling object, with an
optional set of properties defined by key-value pairs.
• The distinction between relationships and properties in the PG model is similar to the distinction between
object properties and datatype properties in OWL, but stronger.
• PG properties are, for simplicity and avoiding clutter in diagrams, usually not represented as additional arcs of
an underlying graph, but are represented as attached to vertices or relationships.
• Identifiers in a Property Graph need only be unique within the scope of a given graph (typically as internal
identifiers assigned by the Graph DBMS), and need not be universally unique like URIs/IRIs.
• Property graphs can be queried with graph-specific query languages such as Cypher that may use graph
patterns (complete subgraphs) as query terms, i.e. are not limited to only nodes identified with specific
key/values.
• PG properties and relationships are individually identified when instantiated, whereas RDF properties are not
instantiated nor identified as individual resources, being only defined by their property type.
• Properties cannot be directly attached to the arc (predicate) of an RDF triple, but RDF reification makes it
possible, in several different ways, to circumvent this limitation by turning a triple into a resource (reification).
5.2 Reification with blank nodes
In the RDF formalism, the reification of a statement turns it into a resource, so that it can be the subject of another
statement. Making statements about statements is useful e.g. for providing information about the provenance (lineage)
of data. It is indispensable for transforming a property graph into an RDF dataset. Many different reification solutions
have been proposed. Reification by way of blank nodes is the simplest for the current purposes and is the solution
chosen by ETSI ISG CIM. Consider the following simple example.
ETSI
12 ETSI GS CIM 006 V1.1.1 (2019-07)

Figure 3: Property graph example to be represented in RDF using reification
To express that the camera monitors only 70 % of the street area, which obviously is not a property of the street, nor of
the camera, but of their relationship, it is needed to reify this statement about the relationship:
[CameraA  monitors  StreetA]
in order to make it the subject of another statement:
[[statement_1]  hasCoverage  70 %],
This can be done by adding a blank node to obtain an RDF-reified equivalent of the example property graph with three
triples as follows and as visualized in Figure 4:
[CameraA  monitors  _blankNode_n]
[_blankNode_n  hasObject  StreetA]
[_blank_node_n  hasCoverage  "70 %"]

Figure 4: RDF reified example
This solution is especially convenient when the graph is serialized using JSON-LD ([1] see following clause) because
blank nodes do not explicitly appear in the textual serialized description, and actually show up only when it is
represented as a RDF graph. It is thus possible for a developer to generate the JSON-LD payload required by the NGSI-
LD API in a form that is very similar to what he would have generated in plain JSON. The simplicity of JSON-LD
representation of property graphs reified with blank nodes is a key argument behind the choice of this solution.
With alternative reification methods, users and developers shall include supplementary terms and shall deal with
complex redundant terms that may distract and confuse them. Several such reification methods have been proposed in
the literature (see e.g. [i.3]). For comparison, here is a brief description of three of the more widely used reification
methods.
• Classical RDF reification defines a new RDF resource that is linked back to the original statement. This uses
RDF built-in reification capabilities, as RDF natively provides a vocabulary intended for describing RDF
statements, namely the type rdf:Statement, and the properties rdf:subject, rdf:predicate, and
rdf:object. A total of 4 additional statements (corresponding to the so-called "reification quad") are required
to fully define a statement as a resource, and this is just in order to be able to make this resource the subject or
object of other statements.
• Singleton properties: this other simple solution to reification amounts to identifying each predicate instance
individually as a resource with its own per instance IRI, and using this new resource as the subject of another
statement. This actually changes the nature of the original RDF graph because what was originally an arc of
the graph becomes a vertex of the transformed graph.
ETSI
13 ETSI GS CIM 006 V1.1.1 (2019-07)
• Named graphs/quads: all RDF triples are redefined as "quadruples" ("quads" for short, unrelated to the
"reification quads" mentioned above). These quads are generalizations of triples, with 4-fold arity (whereas the
above "reification quads" are sets of 4 triples!). These quads have as the extra element an associated IRI that
identifies the statement as an instance of the corresponding predicate (which is itself, as per the RDF model,
defined by a generic IRI). This fourth element, the IRI, makes it possible for the statement to be the subject (or
object) of another RDF triple. Named graphs are much more powerful than this basic quad mechanism, in that
they allow any subgraph (set of interconnected triples) to be jointly identified. JSON-LD [1] supports these
general named graphs but it is a very cumbersome and heavyweight means to reify simple triples. The
reification method used in the present document is much more lightweight than the "Named graphs" approach.
These reification methods are compared in Figure 5 (Standard RDF reification - with quads) and in Figure 6 (Singleton
property reification), with the proposed blank-node-based reification method, from two points of views: (a) JSON-LD
corresponding representation and (b) SPARQL query complexity for extracting data.

Figure 5: Standard RDF reification Figure 6: Singleton property reification

JSON-LD Format: JSON-LD Format:
[ [
{"@id": "CameraA", {"@id": "CameraA",
"monitors": {"@id": "StreetA"}} "monitors#id1":
{"@id": "StreetA}}
{"@id": "Statement_1",
"subject": {"@id": "monitors#id1",
{"@id": "CameraA"}, "singletonPropertyOf":
"predicate": {"@id": "monitors"},
{"@id": "monitors"}, "hasCoverage": "90%" }
"object": ]
{"@id": "StreetA"},
"hasCoverage": "70%" }
]
SPARQL Query: SPARQL Query:
SELECT ?R WHERE { SELECT ?R WHERE {
?st rdf:subject :CameraA. :CameraA ?p :StreetA.
?st rdf:predicate ?p :singletonPropertyOf
:monitors.        :monitors.
?st rdf:object StreetA. ?p :hasCoverage ?R
?st :hasCoverage ?R }
}
Using reification with blank nodes, the SPARQL query is as follows:
SELECT ?R WHERE {
:CameraA :monitors ?bn.
?bn :hasObject :StreetA.
?bn :hasCoverage ?R.
}
For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the
owl:propertyChainAxiom is used as follows:
ETSI
14 ETSI GS CIM 006 V1.1.1 (2019-07)
: monitors owl:propertyChainAxiom (:monitors:hasObject) .

This can be defined for all reifiable properties similar to "monitors" in the preceding statement. The SPARQL query for
the object of the property becomes simple and equivalent to queries without reification.
SELECT ?S where {
:CameraA : monitors ?S.}
5.3 Formal definition
5.3.0 Introduction
For the purposes of the present document, and as shown in clause 3.1, the following terms and definitions apply (for
convenience and brevity the "NGSI-LD" prefix may be omitted in the rest of the present document):
NGSI-LD Entity: An NGSI-LD Entity is the informational representative of something that is supposed to exist in the
real world, physically or conceptually. Any instance of such an entity shall be uniquely identified by a URI, and
characterized by reference to one or more NGSI-LD Entity Type(s).
NGSI-LD Property: A description instance which associates a main characteristic, which shall be an NGSI-LD Value,
to either an NGSI-LD Entity, an NGSI-LD Relationship or another NGSI-LD Property. It shall include the special
"hasValue" property to define its target value.
NGSI-LD Value: An NGSI-LD Value is either a JSON value (i.e. a string, a number, true or false, an object, an array),
or a JSON-LD typed value (i.e. a string as the lexical form of the value together with a type, defined by an XSD base
type or more generally an IRI), or a JSON-LD structured value (i.e. a set, a list, a language-tagged string).
NGSI-LD Relationship: An NGSI-LD Relationship describes a directed link between a subject which shall be either
an NGSI-LD Entity, an NGSI-LD Property, or another NGSI-LD Relationship on one hand, and an object, which shall
be an NGSI-LD Entity, on the other hand. It shall include the special "hasObject" property to define its target object.
EXAMPLE: An NGSI-LD Entity of type (Type Name) "Vehicle" (when parked) can be the subject of an NGSI-
LD Relationship which object is a NGSI-LD Entity of type "Parking".

Figure 7: NGSI-LD core meta-model diagram
5.3.1 Entity Types
Entity types are classes in OWL and shall be defined in a hierarchy as subclasses of the class "Entity".
This allows inheriting common characteristics from super classes, and gives a common vocabulary for all domain-
specific meta-models that will ever be defined over NGSI-LD.
ETSI
15 ETSI GS CIM 006 V1.1.1 (2019-07)
5.3.2 Properties and Relationships Types
Similar to Entity types, the types for Properties and Relationships are defined in a hierarchal manner as subclasses of
the classes "Property" and "Relationship" respectively. They are used to categorize an NGSI-LD Relationship as
belonging to a class of similar relationships.
Property (or Relationship) types shall be identified by a URI. These types shall also be used for typing blank nodes used
for reification, according to the type of the property or relationship which they reify.
Entity, Property, Relationship are direct subclasses of the rdfs:Resource or owl:Thing class (default for classes
for RDFS and OWL respectively).
:Entity rdf:type owl:Class .
…
Value in the NGSI-LD meta-model is not limited to the rdfs:Literal. The class Value is extensible as needed to allow
more value formats in domain specific extensions of the meta-model. Value may be an rdfs:Literal, but may also be
some specific type as defined by a programming language, e.g. integer. A value shall be neither an Entity, a Property,
nor a Relationship.
:Entity owl:disjointWith :Value .
:Property owl:disjointWith :Value .
:Relationship owl:disjointWith :Value .

Two primitive RDF properties are defined: hasValue and hasObject. These are used to "pre-reify" all relationships and
properties by enabling their potential reification with blank nodes as explained in the previous clause, even if these
properties or relationships are not actually the subject of another property or relationship.
In OWL, owl:DatatypeProperty and owl:ObjectProperty correspond to two kinds of rdf:Property, yet in OWL
there is a distinction between the default range of these two classes, where the range of the first is a literal while the
range of the other is a class.
:hasValue rdf:type owl:DatatypeProperty .
rdfs:domain :Property .
:hasObject rdf:type owl:ObjectProperty .
rdfs:domain :Relationship ;
rdfs:range :Entity .
An example of usage of hasValue for applying a property (ObservedAt) to another "pre-reified" property (color) is
given below:
:Car1 :color _:bn
_:bn hasValue "Blue"
_:bn observedAt "2018-01-01T00:00:00Z"

5.4 Serialization with JSON-LD
JSON-LD is a JSON-based syntax standardized by W3C [1] for serialization of Linked Data, and more generally,
RDFdatasets.
The property graph example given Figure 1 can be represented in RDF, using the reification method with blank nodes
as shown in Figure 8.
ETSI
16 ETSI GS CIM 006 V1.1.1 (2019-07)

Figure 8: Property graph example transformed to RDF with blank-node reification
It is an implementation choice whether all property and relationship instances shall be reified, or only specific instances
where reification is needed (i.e. in case of properties/relationships applied on other properties/relationships). In the RDF
example of Figure 8, for simplicity, only reified instances are shown where needed, that is where extra information is
attached to the properties and relationships (e.g. "hasDirection" property is attached to "isConnectedTo" relationship in
the example above). It should be mentioned that the NGSI-LD API requires all properties and relationships to be "pre-
reified" by default (i.e. even if no extra properties are attached to them) using the "special "hasValue and "hasObject"
properties and relationships, as explained in the previous clause.
Our meta-model solution that is based on blank node reification is especially convenient when the graph is serialized
with JSON-LD because blank nodes do not explicitly appear in the textual serialized description, and actually show up
only when it is represented as an RDF graph. It is thus possible for a developer to generate the JSON-LD payload of an
API in a form that is very similar to what he would have generated in plain JSON.
The previous RDF example can be written in the JSON-LD format as follows:
[
...