From a57be7a025433c055281362c7c215f596be58fde Mon Sep 17 00:00:00 2001 From: Marco Cavalli Date: Wed, 17 Sep 2025 14:54:52 +0000 Subject: [PATCH 1/3] fix style in tables, classnames in text, images and caption formats --- annex-b.md | 32 +++------ annex-c.md | 8 +-- clause-2_References.md | 8 +-- clause-3_Definitions.md | 2 +- clause-4.md | 24 +++---- clause-5.md | 135 ++++++++++++++---------------------- clause-6.md | 150 ++++++++++++++-------------------------- executive-summary.md | 2 - introduction.md | 2 - 9 files changed, 127 insertions(+), 236 deletions(-) diff --git a/annex-b.md b/annex-b.md index f6a5f6e..b8c52b0 100644 --- a/annex-b.md +++ b/annex-b.md @@ -10,37 +10,25 @@ Although each ontology definition may have its own motivation - maybe different oneM2M is a partnership project for IoT (originally defined as "machine to machine communication" in the Telecom world). OneM2M provides an OWL ontology that can be partially mapped to the ISG CIM cross-domain ontology, as illustrated in Figure B.1. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image31.png) -::: TF -Figure B.1: Mapping NGSI-LD meta-model and cross-domain ontology to oneM2M base ontology -::: +**Figure B.1: Mapping NGSI-LD meta-model and cross-domain ontologyto oneM2M base ontology** ## B.2 Mapping to W3C WoT Thing Description W3C Web of Things (WoT) Thing Description provides both cross-domain and domain-specific vocabularies, and is tentatively mapped to the NGSI-LD cross-domain ontology as represented in Figure B.2. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image32.png) -::: TF -Figure B.2: Mapping NGSI-LD to W3C WoT Thing Description -::: +**Figure B.2: Mapping NGSI-LD to W3C WoT Thing Description** ## B.3 Mapping to W3C Time Ontology The NGSI-LD cross-domain ontology uses a time-specific vocabulary to provide temporal information (either general, or as metadata associated to properties/relationships). Such temporal vocabulary can be taken from W3C Time Ontology rather than redefining them. This also allows interested users/systems who are using W3C Time Ontology to align with the NGSI-LD cross-domain ontology, and can be itself considered as an extension for temporal vocabularies for people who start by using the NGSI-LD ontology. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image33.png) -::: TF -Figure B.3: Mapping NGSI-LD to W3C Time Ontology -::: +**Figure B.3: Mapping NGSI-LD to W3C Time Ontology** ## B.4 GSMA NGSI-LD-Entities @@ -54,10 +42,6 @@ The GSMA NGSI-LD-Entities ontology is available at: ]{style="position: relative; display: inline-flex;"} -::: +![](media/image34.png) -::: TF -Figure B.4: Mapping NGSI-LD to SAREF -::: +**Figure B.4: Mapping NGSI-LD to SAREF** diff --git a/annex-c.md b/annex-c.md index 087ce1a..eaf364a 100644 --- a/annex-c.md +++ b/annex-c.md @@ -20,12 +20,8 @@ Some properties in the NGSI-LD API have specifically been defined such that they Consider the following explanatory example: -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image35.png) -::: TF -Figure C.1: Example of different kinds of information representation -::: +**Figure C.1: Example of different kinds of information representation** The two "createdAt" and "producedAt" properties might seem to convey similar ideas, yet "createdAt" is a cross-domain property that applies to the creation of a record in some database i.e. has a special use in the NGSI-LD information model as a non-reifiable property and thus a purely informational descriptor, while "producedAt" is understood to apply to the actual physical production of the real world "thing" that the NGSI-LD Entity identified by URI1 stands for, so that "producedAt" is a domain-specific property that is reified by attaching a blank node to its object (shown in bold in the figure). diff --git a/clause-2_References.md b/clause-2_References.md index 9922310..a6525d8 100644 --- a/clause-2_References.md +++ b/clause-2_References.md @@ -6,11 +6,11 @@ References are either specific (identified by date of publication and/or edition Referenced documents which are not found to be publicly available in the expected location might be found in the [ETSI docbox](https://docbox.etsi.org/Reference/). -> > > [!note] NOTE: +>>> [!note] 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. @@ -26,11 +26,11 @@ The following referenced documents are necessary for the application of the pres 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] NOTE: +>>> [!note] 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. diff --git a/clause-3_Definitions.md b/clause-3_Definitions.md index 6eddb48..e873e58 100644 --- a/clause-3_Definitions.md +++ b/clause-3_Definitions.md @@ -117,7 +117,7 @@ DATA Data Solutions DBMS DataBase Management System -GSMA[™]{.ondemand_CHAR_size_8} GSM Association +GSMA™ GSM Association HTTP HyperText Transfer Protocol diff --git a/clause-4.md b/clause-4.md index f90307c..368d08f 100644 --- a/clause-4.md +++ b/clause-4.md @@ -28,27 +28,19 @@ Two examples of structural representations of city environments will be used as The following graphical conventions are used throughout the present document: -- []{style="position: relative; display: inline-flex;"} Regular (physically-matched) entities are represented as black rectangles. -- []{style="position: relative; display: inline-flex;"} 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. -- []{style="position: relative; display: inline-flex;"} 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. +- ![](media/image2.png) Regular (physically-matched) entities are represented as black rectangles. +- ![](media/image3.png) Relationships between these entities are represented as diamonds (rhombuses) overlaid on the corresponding arc of the graph, a convention borrowed from "entity-relationship" diagrams. +- ![](media/image4.PNG) 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. +- ![](media/image5.png) 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. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image6.png) -::: TF -Figure 1: Property graph example (1) -::: +**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. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image7.png) -::: TF -Figure 2: Property graph example (2) -::: +**Figure 2: Property graph example (2)** diff --git a/clause-5.md b/clause-5.md index 7859e29..f489d95 100644 --- a/clause-5.md +++ b/clause-5.md @@ -29,13 +29,9 @@ There are several key differences between property graphs (PG in the following) 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 TC DATA. Consider the following simple example. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image8.png) -::: TF -Figure 3: Property graph example to be represented in RDF using reification -::: +**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: @@ -63,13 +59,9 @@ This can be done by adding a blank node to obtain an RDF-reified equivalent of t *[\_blank_node_n 🡪 hasCoverage 🡪 "70 %"]* ::: -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image9.png) -::: TF -Figure 4: RDF reified example -::: +**Figure 4: RDF reified example** This solution is especially convenient when the graph is serialized using JSON-LD [n.1] (see clause 5.4) 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. @@ -81,57 +73,40 @@ With alternative reification methods, users and developers shall include supplem 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. -::: programcode -+---------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ -| {TF} | {TF} | -| | | -| []{style="position: relative; display: inline-flex;"} | []{style="position: relative; display: inline-flex;"} | -| | | -| Figure 5: Standard RDF reification | Figure 6: Singleton property reification | -+=============================================================================================================================================+=============================================================================================================================================+ -| **JSON-LD Format:** | **JSON-LD Format:** | -| | | -| [\[]{.ondemand_CHAR_size_8} | [\[]{.ondemand_CHAR_size_8} | -| | | -| [{"@id": "CameraA",]{.ondemand_CHAR_size_8} | [{"@id": "CameraA",]{.ondemand_CHAR_size_8} | -| | | -| ["monitors": {"@id": "StreetA"}}]{.ondemand_CHAR_size_8} | ["monitors#id1":]{.ondemand_CHAR_size_8} | -| | | -| [{"@id": "Statement_1",]{.ondemand_CHAR_size_8} | [{"@id": "StreetA}}]{.ondemand_CHAR_size_8} | -| | | -| ["subject":]{.ondemand_CHAR_size_8} | [{"@id": "monitors#id1",]{.ondemand_CHAR_size_8} | -| | | -| [{"@id": "CameraA"},]{.ondemand_CHAR_size_8} | ["singletonPropertyOf":]{.ondemand_CHAR_size_8} | -| | | -| ["predicate":]{.ondemand_CHAR_size_8} | [{"@id": "monitors"},]{.ondemand_CHAR_size_8} | -| | | -| [{"@id": "monitors"},]{.ondemand_CHAR_size_8} | ["hasCoverage": "90%" }]{.ondemand_CHAR_size_8} | -| | | -| ["object": ]{.ondemand_CHAR_size_8} | [\]]{.ondemand_CHAR_size_8} | -| | | -| [{"@id": "StreetA"},]{.ondemand_CHAR_size_8} | | -| | | -| ["hasCoverage": "70%" }]{.ondemand_CHAR_size_8} | | -| | | -| [\]]{.ondemand_CHAR_size_8} | | -+---------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ -| **SPARQL Query:** | **SPARQL Query:** | -| | | -| [SELECT ?R WHERE {]{.ondemand_CHAR_size_8} | [SELECT ?R WHERE {]{.ondemand_CHAR_size_8} | -| | | -| [?st rdf:subject :CameraA.]{.ondemand_CHAR_size_8} | [:CameraA ?p :StreetA.]{.ondemand_CHAR_size_8} | -| | | -| [?st rdf:predicate]{.ondemand_CHAR_size_8} | [?p :singletonPropertyOf]{.ondemand_CHAR_size_8} | -| | | -| [:monitors.]{.ondemand_CHAR_size_8} | [:monitors.]{.ondemand_CHAR_size_8} | -| | | -| [?st rdf:object StreetA.]{.ondemand_CHAR_size_8} | [?p :hasCoverage ?R]{.ondemand_CHAR_size_8} | -| | | -| [?st :hasCoverage ?R]{.ondemand_CHAR_size_8} | [}]{.ondemand_CHAR_size_8} | -| | | -| [}]{.ondemand_CHAR_size_8} | | -+---------------------------------------------------------------------------------------------------------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------+ -::: ++--------------------------------------------+--------------------------------------------------+ +| ![](media/image10.png) | ![](media/image11.png) | +| | | +| **Figure 5: Standard RDF reification** | **Figure 6: Singleton property reification** | ++============================================+==================================================+ +| **JSON-LD Format:** | **JSON-LD Format:** | +| | | +| ``` json | ``` json | +| [ | [ | +| {"@id": "CameraA", | {"@id": "CameraA", | +| "monitors": {"@id": "StreetA"}} | "monitors#id1": | +| {"@id": "Statement_1", | {"@id": "StreetA}} | +| "subject": | {"@id": "monitors#id1", | +| {"@id": "CameraA"}, | "singletonPropertyOf": | +| "predicate": | {"@id": "monitors"}, | +| {"@id": "monitors"}, | "hasCoverage": "90%" } | +| "object": | ] | +| {"@id": "StreetA"}, | ``` | +| "hasCoverage": "70%" } | | +| ] | | +| ``` | | ++--------------------------------------------+--------------------------------------------------+ +| **SPARQL Query:** | **SPARQL Query:** | +| | | +| ``` json | ``` json | +| 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: @@ -143,7 +118,7 @@ SELECT ?R WHERE { } ``` -For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the [owl:propertyChainAxiom]{.ETSI-code_Char} is used as follows: +For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the [owl:propertyChainAxiom]{.HTML_Sample} is used as follows: ``` json :monitors owl:propertyChainAxiom (:monitors:hasObject). @@ -153,7 +128,7 @@ This can be defined for all reifiable properties similar to "monitors" in the pr ``` json SELECT ?S where { -:CameraA : monitors ?S.} +:CameraA :monitors ?S.} ``` ## 5.3 Formal definition @@ -206,9 +181,9 @@ Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD E **NGSI-LD ListRelationship:** description of an ordered array of directed links between a subject which is either an NGSI-LD Entity, an NGSI-LD Property or another NGSI-LD Relationship on one hand, and a series of objects, which are NGSI-LD Entities, on the other hand, and which uses the special *hasObjectList* property to define its target objects -::: ondemand_PAR_first_line_indent_-70_left_indent_85_space_after_10 +>>> [!tip] EXAMPLE: EXAMPLE: "A bus route services the following bus stops" can be represented by an NGSI-LD *ListRelationship* whose name is "route" which holds an array of directed links towards a series of NGSI-LD Entities of type (Type name) ["BusStop"]{.HTML_Code} -::: +>>> **NGSI-LD Property:** description instance which associates a main characteristic, i.e. an **NGSI-LD Value**, to either an NGSI-LD Entity, an NGSI-LD Relationship or another NGSI-LD Property and that uses the special *hasValue* property to define its target value @@ -248,13 +223,9 @@ Bob's private car 'speed' NGSI-LD Value is the number 100 (kilometres per hour). >>> -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image12.png) -::: TF -Figure 7: NGSI-LD core meta-model diagram -::: +**Figure 7: NGSI-LD core meta-model diagram** ### 5.3.1 Entity Types @@ -268,7 +239,7 @@ Similar to Entity types, the types for Properties and Relationships are defined 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]{.ETSI-code_Char} are direct subclasses of the [rdfs:Resource]{.ETSI-code_Char}or [owl:Thing]{.HTML_Sample}class (default for classes for RDFS and OWL respectively). +[Entity, Property, Relationship]{.HTML_Sample} are direct subclasses of the [rdfs:Resource]{.HTML_Sample}or [owl:Thing]{.HTML_Sample}class (default for classes for RDFS and OWL respectively). ::: code [:Entity rdf:type owl:Class .]{.HTML_Sample} @@ -278,7 +249,7 @@ Property (or Relationship) types shall be identified by a URI. These types shall [...]{.HTML_Sample} ::: -[Value]{.ETSI-code_Char} in the NGSI-LD meta-model is not limited to the [rdfs:Literal]{.HTML_Sample}. The class [Value]{.ETSI-code_Char} is extensible as needed to allow more value formats in domain specific extensions of the meta-model. [Value]{.ETSI-code_Char} may be an [rdfs:Literal]{.HTML_Sample}, but may also be some specific type as defined by a programming language, e.g. integer. A value shall be neither an [Entity]{.ETSI-code_Char}, a [Property]{.ETSI-code_Char}, nor a [Relationship]{.ETSI-code_Char}. +[Value]{.HTML_Sample} in the NGSI-LD meta-model is not limited to the [rdfs:Literal]{.HTML_Sample}. The class [Value]{.HTML_Sample} is extensible as needed to allow more value formats in domain specific extensions of the meta-model. [Value]{.HTML_Sample} may be an [rdfs:Literal]{.HTML_Sample}, but may also be some specific type as defined by a programming language, e.g. integer. A value shall be neither an [Entity]{.HTML_Sample}, a [Property]{.HTML_Sample}, nor a [Relationship]{.HTML_Sample}. ::: code [:Entity owl:disjointWith :Value .]{.HTML_Sample} @@ -292,9 +263,9 @@ Property (or Relationship) types shall be identified by a URI. These types shall [:Relationship owl:disjointWith :Value .]{.HTML_Sample} ::: -Two primitive RDF properties are defined: [hasValue]{.ETSI-code_Char} and [hasObject]{.ETSI-code_Char}. These are used to "pre-reify" all relationships and properties by enabling their potential reification with blank nodes as explained in clause 5.2, even if these properties or relationships are not actually the subject of another property or relationship. +Two primitive RDF properties are defined: [hasValue]{.HTML_Sample} and [hasObject]{.HTML_Sample}. These are used to "pre-reify" all relationships and properties by enabling their potential reification with blank nodes as explained in clause 5.2, even if these properties or relationships are not actually the subject of another property or relationship. -In OWL, [owl:DatatypeProperty]{.ETSI-code_Char} and [owl:ObjectProperty]{.ETSI-code_Char} correspond to two kinds of [rdf:Property]{.ETSI-code_Char}, 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. +In OWL, [owl:DatatypeProperty]{.HTML_Sample} and [owl:ObjectProperty]{.HTML_Sample} correspond to two kinds of [rdf:Property]{.HTML_Sample}, 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. ::: code [:hasValue rdf:type owl:DatatypeProperty .]{.HTML_Sample} @@ -316,7 +287,7 @@ In OWL, [owl:DatatypeProperty]{.ETSI-code_Char} and [owl:ObjectProperty]{.ETSI-c [rdfs:range :Entity .]{.HTML_Sample} ::: -An example of usage of [hasValue]{.ETSI-code_Char} for applying a property (ObservedAt) to another "pre-reified" property (colour) is given below: +An example of usage of [hasValue]{.HTML_Sample} for applying a property (ObservedAt) to another "pre-reified" property (colour) is given below: ::: code [:Car1 :colour\_:bn]{.HTML_Sample} @@ -336,13 +307,9 @@ JSON-LD is a JSON-based syntax standardized by W3C [n.1] for serialization of Li The property graph example given Figure 1 can be represented in RDF, using the reification method with blank nodes as shown in Figure 8. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image13.png) -::: TF -Figure 8: Property graph example transformed to RDF with blank-node reification -::: +**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 clause 5.3.2. diff --git a/clause-6.md b/clause-6.md index 5afef79..db8301d 100644 --- a/clause-6.md +++ b/clause-6.md @@ -4,13 +4,9 @@ The proposed cross-domain ontology provides definitions of Entity types, relationship types, property types and types that are considered to be common denominator between all domains where NGSI-LD will be applied, bridging vertical ontologies used in these domains and the core meta-model defined before. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image14.png) -::: TF -Figure 9: NGSI-LD cross-domain ontology positioning -::: +**Figure 9: NGSI-LD cross-domain ontology positioning** The cross-domain ontology is the second part of the NGSI-LD information model, which is no less important than the core meta-model defined before. The scope of this cross-domain ontology is strictly limited so as to be useful for describing common concepts, situations or constraints, to avoid redefining them separately (and probably in a different way) in each domain-specific ontology. This promotes consistency when applications need to combine data from different sources, themselves from different domains. @@ -32,35 +28,27 @@ Even if it has been previously defined by the CIM API specification (besides oth Figure 10 shows an RDF/RDFS/OWL based diagram representing the hierarchical relation between types defined in the cross-domain ontology, as well as their relation to the core meta-model, as they have been defined in a minimal way for the strict needs of the NGSI-LD API. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image15.png) -::: TF -Figure 10: Minimal cross-domain ontology used in NGSI-LD API -::: +**Figure 10: Minimal cross-domain ontology used in NGSI-LD API** This cross-domain information model is completely compliant with the previous API ontology (ETSI GS CIM 009 [n.2]). It uses the same vocabulary yet it additionally provides a bigger set of definitions that may be helpful for many users for maintaining consistency. Figure 11 shows the full cross-domain ontology of the information model. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image16.png) -::: TF -Figure 11: NGSI-LD cross-domain ontology diagram (Full) -::: +**Figure 11: NGSI-LD cross-domain ontology diagram (Full)** The classes in the cross-domain meta-model are colour-coded according to the following legend. -[]{style="position: relative; display: inline-flex;"}: [With capital initial]. Used to refer to a class that is a subclass of Entity or Value. +![](media/image17.png): [With capital initial]. Used to refer to a class that is a subclass of Entity or Value. -[]{style="position: relative; display: inline-flex;"}: [With capital initial]. Used to refer to a class that is a subclass of Property or Relationship, but which is not itself a property or a relationship. These classes serve as super-classes for a set of properties or relationships in the same domain or aspect. +![](media/image18.png): [With capital initial]. Used to refer to a class that is a subclass of Property or Relationship, but which is not itself a property or a relationship. These classes serve as super-classes for a set of properties or relationships in the same domain or aspect. -[]{style="position: relative; display: inline-flex;"} and []{style="position: relative; display: inline-flex;"}: [With small initial]. Used to refer to a proper (direct) class of properties or relationships. +![](media/image19.png) and ![](media/image20.png): [With small initial]. Used to refer to a proper (direct) class of properties or relationships. -[]{style="position: relative; display: inline-flex;"}: [With small initial and underlined text]. Used to refer to the name of a property that is considered to be "lite" in its informational representation since it shall not be reified, rather a value is directly attached to it. +![](media/image21.png): [With small initial and underlined text]. Used to refer to the name of a property that is considered to be "lite" in its informational representation since it shall not be reified, rather a value is directly attached to it. -[]{style="position: relative; display: inline-flex;"}: [With small or capital initial]. Used to refer to a class or a vocabulary that is inherited from another publicly available standard or ontology. +![](media/image22.png): [With small or capital initial]. Used to refer to a class or a vocabulary that is inherited from another publicly available standard or ontology. The class characteristics of the information model are general enough to be used in a common way throughout different domain specific ontologies. In addition, such distinction is itself useful for enriching the semantics of data. @@ -74,13 +62,9 @@ The same holds for relationships. A single URI corresponds to an RDF property an Figure 12 shows an example of how typing holds for blank nodes following the reification of the relationship "isContainedIn". -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image23.png) -::: TF -Figure 12: Blank node typing example for reification -::: +**Figure 12: Blank node typing example for reification** The example of Figure 12 includes the information that "Room A" is spatially contained in "Building A". @@ -91,9 +75,9 @@ The first step is to assert a property chain as follows: (:isContainedIn :hasObject) . ``` -In the current example this means it can be inferred that "Building A" is also directly connected to the "isContainedIn" RDF property, and not only to the "[hasObject]{.ETSI-code_Char}" property. +In the current example this means it can be inferred that "Building A" is also directly connected to the "isContainedIn" RDF property, and not only to the "[hasObject]{.HTML_Sample}" property. -The second step is to define the RDF class that is a range for the "[isContainedIn]{.ETSI-code_Char}" RDF property. This should be a union of two RDF classes, the RDF class "[isContainedIn]{.ETSI-code_Char}" (to account of the blank node instances) and the RDF class "[Entity]{.ETSI-code_Char}". This is defined in OWL as follows: +The second step is to define the RDF class that is a range for the "[isContainedIn]{.HTML_Sample}" RDF property. This should be a union of two RDF classes, the RDF class "[isContainedIn]{.HTML_Sample}" (to account of the blank node instances) and the RDF class "[Entity]{.HTML_Sample}". This is defined in OWL as follows: ``` json :isContainedIn rdfs:range @@ -103,25 +87,25 @@ The second step is to define the RDF class that is a range for the "[isContained A general set of restriction rules that serve for establishing compatibility between the cross-domain ontology and the core meta-model are defined in the following. For the definition of the information model, some basic rules should always be followed while defining the vocabulary of the cross-domain ontology in the RDF/OWL standards (Turtle format is used in the following descriptions). -Another set of rules are defined for property types (e.g. [observationSpace]{.ETSI-code_Char}). These rules apply to both OWL-DL and OWL-full when not specified, but they only apply to OWL-full when specified beside the rule. +Another set of rules are defined for property types (e.g. [observationSpace]{.HTML_Sample}). These rules apply to both OWL-DL and OWL-full when not specified, but they only apply to OWL-full when specified beside the rule. -For each property type [p]{.ETSI-code_Char}: +For each property type [p]{.HTML_Sample}: - the following rules shall hold: - - [prdf:typeowl:ObjectProperty]{.ETSI-code_Char} - - [prdfs:subPropertyOfProperty]{.ETSI-code_Char} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Property.)* - - [prdfs:subClassOfProperty]{.ETSI-code_Char} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subClassOf some class which is a subclass of Property.)* - - \[OWL-full\] [p owl:propertyChainAxiom (p hasValue]{.ETSI-code_Char}) *(Since reification uses a supplementary property hasValue with Properties, a shortcut for extracting data by only using the property p is allowed. This assertion means that any property p usage followed by a hasValue usage is semantically equivalent to using p alone. This allows implicitly inferring the values of properties without using the reification through blank nodes, but directly through the name of the property when no other information is needed.)* + - [prdf:typeowl:ObjectProperty]{.HTML_Sample} + - [prdfs:subPropertyOfProperty]{.HTML_Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Property.)* + - [prdfs:subClassOfProperty]{.HTML_Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subClassOf some class which is a subclass of Property.)* + - \[OWL-full\] [p owl:propertyChainAxiom (p hasValue]{.HTML_Sample}) *(Since reification uses a supplementary property hasValue with Properties, a shortcut for extracting data by only using the property p is allowed. This assertion means that any property p usage followed by a hasValue usage is semantically equivalent to using p alone. This allows implicitly inferring the values of properties without using the reification through blank nodes, but directly through the name of the property when no other information is needed.)* - the following rules may hold: (where restrictions are needed): - - [prdfs:domainC]{.ETSI-code_Char} (*Where* [C]{.ETSI-code_Char} *is a subclass of* [Entity, Property]{.ETSI-code_Char}*, or* [Relationship]{.ETSI-code_Char})(*This limits the usage of p on a certain class of Entities, Properties, or Relationships.*) - - [prdfs:rangeV]{.ETSI-code_Char} (*Where* [V]{.ETSI-code_Char} *is a subclass of* [Value]{.ETSI-code_Char})(*This limits the values that can be associated with p.*) + - [prdfs:domainC]{.HTML_Sample} (*Where* [C]{.HTML_Sample} *is a subclass of* [Entity, Property]{.HTML_Sample}*, or* [Relationship]{.HTML_Sample})(*This limits the usage of p on a certain class of Entities, Properties, or Relationships.*) + - [prdfs:rangeV]{.HTML_Sample} (*Where* [V]{.HTML_Sample} *is a subclass of* [Value]{.HTML_Sample})(*This limits the values that can be associated with p.*) -Some properties in the NGSI-LD API have specifically been defined such that they shall never be reified and do not use the "hasValue" construct. Those properties include: *observedAt*, *createdAt*, *modifiedAt*, *deletedAt*, *start*, *end* and *unitCode*. Those properties are direct instances (using *rdf:type*) of the class [Property]{.ETSI-code_Char}**.** Similar to property types, the rules for relationship types are defined. +Some properties in the NGSI-LD API have specifically been defined such that they shall never be reified and do not use the "hasValue" construct. Those properties include: *observedAt*, *createdAt*, *modifiedAt*, *deletedAt*, *start*, *end* and *unitCode*. Those properties are direct instances (using *rdf:type*) of the class [Property]{.HTML_Sample}**.** Similar to property types, the rules for relationship types are defined. -For each relationship type [r]{.ETSI-code_Char}: +For each relationship type [r]{.HTML_Sample}: - the following rules shall hold: @@ -129,16 +113,16 @@ For each relationship type [r]{.ETSI-code_Char}: r rdf:type owl:ObjectProperty ::: -- [r rdfs:subPropetyOf Relationship]{.ETSI-code_Char} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Relationship.)* -- [r rdfs:subClassOf Relationship]{.ETSI-code_Char} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subClassOf some class which is a subclass of Relationship.)* -- [r rdf:type r]{.ETSI-code_Char}*(r is both a class which is the class of relationship blank node instances, and an instance of itself because it is used as a property that links subjects to the relationship blank nodes.)* -- [r owl:propertyChainAxiom (r hasObject)]{.ETSI-code_Char} *(Since reification uses a supplementary property "hasObject" with Relationships, a shortcut is allowed for extracting data by only using the relationship r. This assertion means that any relationship r usage followed by a hasObject usage is semantically equivalent to using r alone. This allows implicitly inferring the values of relationships without using the reification through blank nodes, but directly through the name of the relationship when no other information is needed.)* +- [r rdfs:subPropetyOf Relationship]{.HTML_Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Relationship.)* +- [r rdfs:subClassOf Relationship]{.HTML_Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subClassOf some class which is a subclass of Relationship.)* +- [r rdf:type r]{.HTML_Sample}*(r is both a class which is the class of relationship blank node instances, and an instance of itself because it is used as a property that links subjects to the relationship blank nodes.)* +- [r owl:propertyChainAxiom (r hasObject)]{.HTML_Sample} *(Since reification uses a supplementary property "hasObject" with Relationships, a shortcut is allowed for extracting data by only using the relationship r. This assertion means that any relationship r usage followed by a hasObject usage is semantically equivalent to using r alone. This allows implicitly inferring the values of relationships without using the reification through blank nodes, but directly through the name of the relationship when no other information is needed.)* - the following rules may hold: (where restrictions are needed): - - [r rdfs:domain C1]{.ETSI-code_Char} (*Where* [C1]{.ETSI-code_Char} *is a subclass of* [Entity, Property]{.ETSI-code_Char}*, or* [Relationship]{.ETSI-code_Char}) (*This limits the usage of r on a certain class of Entities, Properties, or Relationships*) - - [r rdfs:range C2]{.ETSI-code_Char} (*Where* [C2]{.ETSI-code_Char} *is a subclass of* [Entity]{.ETSI-code_Char}) (*This limits the Entities that can be associated with r*) + - [r rdfs:domain C1]{.HTML_Sample} (*Where* [C1]{.HTML_Sample} *is a subclass of* [Entity, Property]{.HTML_Sample}*, or* [Relationship]{.HTML_Sample}) (*This limits the usage of r on a certain class of Entities, Properties, or Relationships*) + - [r rdfs:range C2]{.HTML_Sample} (*Where* [C2]{.HTML_Sample} *is a subclass of* [Entity]{.HTML_Sample}) (*This limits the Entities that can be associated with r*) In clauses 6.3.1 through 6.3.6, different subsets of the cross-domain meta-model are described in detail. @@ -148,19 +132,15 @@ Given an Entity, it is optional, but recommended, to choose a mobility typing wh The cross-domain ontology distinguishes between three mutually exclusive types of mobility: -1. **Stationary:** Location property associated with such an Entity is also a static property (by [owl:restriction]{.ETSI-code_Char}). -2. **Movable:** Location property associated with such an Entity is also a semi-static property (by [owl:restriction]{.ETSI-code_Char}). Location historic data may be available for such an Entity. -3. **Mobile:** Location property associated with such an Entity is also an instantaneous property (by [owl:restriction]{.ETSI-code_Char}). Location historic data may be available for such an Entity. +1. **Stationary:** Location property associated with such an Entity is also a static property (by [owl:restriction]{.HTML_Sample}). +2. **Movable:** Location property associated with such an Entity is also a semi-static property (by [owl:restriction]{.HTML_Sample}). Location historic data may be available for such an Entity. +3. **Mobile:** Location property associated with such an Entity is also an instantaneous property (by [owl:restriction]{.HTML_Sample}). Location historic data may be available for such an Entity. ### 6.3.2 Properties -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image24.png) -::: TF -Figure 13: Cross-Domain Properties -::: +**Figure 13: Cross-Domain Properties** The cross-domain ontology distinguishes between three types of mutually exclusive properties with respect to the time-validity of their respective values: @@ -175,29 +155,25 @@ This distinction may be useful within some applications for defining error/promp Like mobility, this property distinction also allows implementations to control historic data storing behaviour. -[StateProperty]{.ETSI-code_Char}**:** in the formal acceptation of dynamical system theory, a [StateProperty]{.ETSI-code_Char} captures a component of the state of a system represented by the corresponding Entity, in the sense that it memorizes/summarizes past interactions between this system and its environment ("inputs" to the system), in a way that is *sufficient to adequately predict future states of this system, given present and future inputs*. This is related to the notion of "statefulness" used in computer science, yet the state thus maintained is defined as an abstraction of the state to the physical system being represented, not a purely informational construct. This property does also capture the necessary differentiation between the state properties of a system and other "stateless" data streams like sensor readings. +[StateProperty]{.HTML_Sample}**:** in the formal acceptation of dynamical system theory, a [StateProperty]{.HTML_Sample} captures a component of the state of a system represented by the corresponding Entity, in the sense that it memorizes/summarizes past interactions between this system and its environment ("inputs" to the system), in a way that is *sufficient to adequately predict future states of this system, given present and future inputs*. This is related to the notion of "statefulness" used in computer science, yet the state thus maintained is defined as an abstraction of the state to the physical system being represented, not a purely informational construct. This property does also capture the necessary differentiation between the state properties of a system and other "stateless" data streams like sensor readings. -The [StateProperty]{.ETSI-code_Char} class is disjoint with the [Static]{.ETSI-code_Char} property class. A state property cannot be static since it represents a property that, by its very nature, changes with time. There are two types of state properties [i.4]: +The [StateProperty]{.HTML_Sample} class is disjoint with the [Static]{.HTML_Sample} property class. A state property cannot be static since it represents a property that, by its very nature, changes with time. There are two types of state properties [i.4]: -1. [ContinuousTime]{.ETSI-code_Char} (e.g. Car position): Such properties shall correspond to ContinuousValue system states. +1. [ContinuousTime]{.HTML_Sample} (e.g. Car position): Such properties shall correspond to ContinuousValue system states. -6. [DiscreteTime]{.ETSI-code_Char} (e.g. Occupancy of a parking place): DiscreteTime systems in general may have state properties whose value may be either ContinuousValue or DiscreteValue. Event-driven discrete time systems, which are the most usual case addressed in computer-controlled cyber-physical systems, have discrete value states. +6. [DiscreteTime]{.HTML_Sample} (e.g. Occupancy of a parking place): DiscreteTime systems in general may have state properties whose value may be either ContinuousValue or DiscreteValue. Event-driven discrete time systems, which are the most usual case addressed in computer-controlled cyber-physical systems, have discrete value states. ### 6.3.3 Location (Property or Relationship) -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image25.png) -::: TF -Figure 14: Cross-Domain Location -::: +**Figure 14: Cross-Domain Location** Our cross-domain meta-model differentiates between three notions of location: -1. **Geographic Location (GeoProperty):** More generally, this is a special case of[ CoordinateBasedLocation]{.ETSI-code_Char}. There are many standards/ontologies that allow expressing geographic location data. Since the NGSI-LD API uses JSON-LD as a main serialization format, the **geoJSON** standard is used for geographic location expressions. Only the specified GeoProperties represented in geoJSON can be used in geographic queries of the NGSI-LD API. Other standards/ontologies may be more expressive in terms of vocabulary (e.g. OGC standards). While these are not promoted as main methods for representing location, they can be mapped as subclasses of the **Geographic Location** class in order to utilize their rich vocabulary. +1. **Geographic Location (GeoProperty):** More generally, this is a special case of[ CoordinateBasedLocation]{.HTML_Sample}. There are many standards/ontologies that allow expressing geographic location data. Since the NGSI-LD API uses JSON-LD as a main serialization format, the **geoJSON** standard is used for geographic location expressions. Only the specified GeoProperties represented in geoJSON can be used in geographic queries of the NGSI-LD API. Other standards/ontologies may be more expressive in terms of vocabulary (e.g. OGC standards). While these are not promoted as main methods for representing location, they can be mapped as subclasses of the **Geographic Location** class in order to utilize their rich vocabulary. @@ -209,13 +185,9 @@ Our cross-domain meta-model differentiates between three notions of location: ### 6.3.4 Values -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image26.png) -::: TF -Figure 15: Cross-Domain Values -::: +**Figure 15: Cross-Domain Values** In compliance with properties distinctions, values that are **Continuous** are distinguished from those that are **Discrete**. @@ -225,13 +197,9 @@ In compliance with properties distinctions, values that are **Continuous** are d ### 6.3.5 Temporal Properties and Values -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image27.png) -::: TF -Figure 16: Cross-Domain Temporal Properties -::: +**Figure 16: Cross-Domain Temporal Properties** The core vocabulary for time related meta-data is given as follows: @@ -259,13 +227,9 @@ A complementary motivation for defining systems is the separation of concerns wh In the NGSI-LD information model the following vocabulary is used for the definition of systems and their composition as explained in the following subclauses. For comparison, see W3C specifications for part/whole relations [i.5]. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image28.png) -::: TF -Figure 17: Cross-Domain System Composition -::: +**Figure 17: Cross-Domain System Composition** #### 6.3.6.1 Top-down system composition @@ -285,23 +249,15 @@ The mapping of NGSI-LD Entities to graphs is typically many-to-one and one-to-ma Figure 18 shows a set of such system graphs, capturing a structural overlay on the example introduced in Figure 1. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image29.png) -::: TF -Figure 18: System Clustering Example (1) -::: +**Figure 18: System Clustering Example (1)** Figure 19 shows a more complicated set of intersecting systems, capturing an overlay on the example introduced in Figure 18. -::: FL -[]{style="position: relative; display: inline-flex;"} -::: +![](media/image30.png) -::: TF -Figure 19: System Clustering Example (2) -::: +**Figure 19: System Clustering Example (2)** The example consists of a building and its parts (using "hasPart" relationships) forming the structure of the building, in addition to other devices that are included in the building. The building has a garage and an apartment. 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. Besides, there is a separate public parking that also appears in the example. diff --git a/executive-summary.md b/executive-summary.md index d8b749a..e69de29 100644 --- a/executive-summary.md +++ b/executive-summary.md @@ -1,2 +0,0 @@ -# Executive summary - diff --git a/introduction.md b/introduction.md index 3d07efe..e69de29 100644 --- a/introduction.md +++ b/introduction.md @@ -1,2 +0,0 @@ -# Introduction - -- GitLab From 004496ba748abe857d5cf6e28306e2805f39c3b9 Mon Sep 17 00:00:00 2001 From: Marco Cavalli Date: Mon, 22 Sep 2025 16:00:02 +0000 Subject: [PATCH 2/3] fix: style names and tables --- annex-d.md | 588 ++++++++++++++++++++-------------------- annex-e.md | 2 + clause-3_Definitions.md | 16 +- clause-5.md | 66 ++--- clause-6.md | 52 ++-- history.md | 2 + 6 files changed, 366 insertions(+), 360 deletions(-) diff --git a/annex-d.md b/annex-d.md index afa08d3..3c5158d 100644 --- a/annex-d.md +++ b/annex-d.md @@ -1,1177 +1,1177 @@ # Annex D (informative): OWL-DL representation of the Information Model ::: code -[\@prefix : .]{.HTML_Sample} +[\@prefix : .]{.HTML-Sample} ::: ::: code -[\@prefix owl: .]{.HTML_Sample} +[\@prefix owl: .]{.HTML-Sample} ::: ::: code -[\@prefix rdf: .]{.HTML_Sample} +[\@prefix rdf: .]{.HTML-Sample} ::: ::: code -[\@prefix xml: .]{.HTML_Sample} +[\@prefix xml: .]{.HTML-Sample} ::: ::: code -[\@prefix xsd: .]{.HTML_Sample} +[\@prefix xsd: .]{.HTML-Sample} ::: ::: code -[\@prefix rdfs: .]{.HTML_Sample} +[\@prefix rdfs: .]{.HTML-Sample} ::: ::: code -[\@base .]{.HTML_Sample} +[\@base ]{.HTML-Sample}[]{.HTML-Sample}[.]{.HTML-Sample} ::: ::: code -[ rdf:type owl:Ontology .]{.HTML_Sample} +[ rdf:type owl:Ontology .]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\# Object Properties]{.HTML_Sample} +[\# Object Properties]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ContinuousTime]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ContinuousTime]{.HTML-Sample} ::: ::: code -[:ContinuousTime rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:ContinuousTime rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :StateProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :StateProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range :ContinuousValue .]{.HTML_Sample} +[rdfs:range :ContinuousValue .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#CoordinateBasedLocation]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#CoordinateBasedLocation]{.HTML-Sample} ::: ::: code -[:CoordinateBasedLocation rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:CoordinateBasedLocation rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :LocationProperty .]{.HTML_Sample} +[rdfs:subPropertyOf :LocationProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#DiscreteTime]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#DiscreteTime]{.HTML-Sample} ::: ::: code -[:DiscreteTime rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:DiscreteTime rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :StateProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :StateProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range \[rdf:type owl:Class ;]{.HTML_Sample} +[rdfs:range ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:unionOf ( :ContinuousValue]{.HTML_Sample} +[owl:unionOf ( :ContinuousValue]{.HTML-Sample} ::: ::: code -[:DiscreteValue]{.HTML_Sample} +[:DiscreteValue]{.HTML-Sample} ::: ::: code -[)]{.HTML_Sample} +[)]{.HTML-Sample} ::: ::: code -[\] .]{.HTML_Sample} +[\] .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#GeoProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#GeoProperty]{.HTML-Sample} ::: ::: code -[:GeoProperty rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:GeoProperty rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :CoordinateBasedLocation ;]{.HTML_Sample} +[rdfs:subPropertyOf :CoordinateBasedLocation ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Geometry .]{.HTML_Sample} +[rdfs:range :Geometry .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#GraphBasedLocation]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#GraphBasedLocation]{.HTML-Sample} ::: ::: code -[:GraphBasedLocation rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:GraphBasedLocation rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :LocationRelationship .]{.HTML_Sample} +[rdfs:subPropertyOf :LocationRelationship .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Instantaneous]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Instantaneous]{.HTML-Sample} ::: ::: code -[:Instantaneous rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:Instantaneous rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property ;]{.HTML_Sample} +[rdfs:subPropertyOf :Property ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Instantaneous .]{.HTML_Sample} +[rdfs:range :Instantaneous .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LocationProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LocationProperty]{.HTML-Sample} ::: ::: code -[:LocationProperty rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:LocationProperty rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property .]{.HTML_Sample} +[rdfs:subPropertyOf :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LocationRelationship]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LocationRelationship]{.HTML-Sample} ::: ::: code -[:LocationRelationship rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:LocationRelationship rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Relationship .]{.HTML_Sample} +[rdfs:subPropertyOf :Relationship .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#MeasurementProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#MeasurementProperty]{.HTML-Sample} ::: ::: code -[:MeasurementProperty rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:MeasurementProperty rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Instantaneous .]{.HTML_Sample} +[rdfs:subPropertyOf :Instantaneous .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Property]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Property]{.HTML-Sample} ::: ::: code -[:Property rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:Property rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range \[rdf:type owl:Class ;]{.HTML_Sample} +[rdfs:range ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:unionOf ( :Property]{.HTML_Sample} +[owl:unionOf ( :Property]{.HTML-Sample} ::: ::: code -[:Value]{.HTML_Sample} +[:Value]{.HTML-Sample} ::: ::: code -[)]{.HTML_Sample} +[)]{.HTML-Sample} ::: ::: code -[\] .]{.HTML_Sample} +[\] .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Relationship]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Relationship]{.HTML-Sample} ::: ::: code -[:Relationship rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:Relationship rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :Entity ;]{.HTML_Sample} +[rdfs:domain :Entity ;]{.HTML-Sample} ::: ::: code -[rdfs:range \[rdf:type owl:Class ;]{.HTML_Sample} +[rdfs:range ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:unionOf ( :Entity]{.HTML_Sample} +[owl:unionOf ( :Entity]{.HTML-Sample} ::: ::: code -[:Relationship]{.HTML_Sample} +[:Relationship]{.HTML-Sample} ::: ::: code -[)]{.HTML_Sample} +[)]{.HTML-Sample} ::: ::: code -[\] .]{.HTML_Sample} +[\] .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SemiStatic]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SemiStatic]{.HTML-Sample} ::: ::: code -[:SemiStatic rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:SemiStatic rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property ;]{.HTML_Sample} +[rdfs:subPropertyOf :Property ;]{.HTML-Sample} ::: ::: code -[rdfs:range :SemiStatic .]{.HTML_Sample} +[rdfs:range :SemiStatic .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SetBasedLocation]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SetBasedLocation]{.HTML-Sample} ::: ::: code -[:SetBasedLocation rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:SetBasedLocation rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :LocationRelationship .]{.HTML_Sample} +[rdfs:subPropertyOf :LocationRelationship .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#StateProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#StateProperty]{.HTML-Sample} ::: ::: code -[:StateProperty rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:StateProperty rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property .]{.HTML_Sample} +[rdfs:subPropertyOf :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Static]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Static]{.HTML-Sample} ::: ::: code -[:Static rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:Static rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property ;]{.HTML_Sample} +[rdfs:subPropertyOf :Property ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Static .]{.HTML_Sample} +[rdfs:range :Static .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#connectsTo]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#connectsTo]{.HTML-Sample} ::: ::: code -[:connectsTo rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:connectsTo rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :GraphBasedLocation ;]{.HTML_Sample} +[rdfs:subPropertyOf :GraphBasedLocation ;]{.HTML-Sample} ::: ::: code -[rdf:type owl:TransitiveProperty ;]{.HTML_Sample} +[rdf:type owl:TransitiveProperty ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :connectsTo]{.HTML_Sample} +[owl:propertyChainAxiom ( :connectsTo]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasDirectPart]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasDirectPart]{.HTML-Sample} ::: ::: code -[:hasDirectPart rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasDirectPart rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :hasPart ;]{.HTML_Sample} +[rdfs:subPropertyOf :hasPart ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :hasDirectPart]{.HTML_Sample} +[owl:propertyChainAxiom ( :hasDirectPart]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasMeasure]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasMeasure]{.HTML-Sample} ::: ::: code -[:hasMeasure rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasMeasure rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :MeasurementProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :MeasurementProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Measurement .]{.HTML_Sample} +[rdfs:range :Measurement .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasObject]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasObject]{.HTML-Sample} ::: ::: code -[:hasObject rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasObject rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :Relationship ;]{.HTML_Sample} +[rdfs:domain :Relationship ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Entity .]{.HTML_Sample} +[rdfs:range :Entity .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasObservationZone]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasObservationZone]{.HTML-Sample} ::: ::: code -[:hasObservationZone rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasObservationZone rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :LocationRelationship ;]{.HTML_Sample} +[rdfs:subPropertyOf :LocationRelationship ;]{.HTML-Sample} ::: ::: code -[rdfs:range \[rdf:type owl:Class ;]{.HTML_Sample} +[rdfs:range ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:unionOf ( :Relationship]{.HTML_Sample} +[owl:unionOf ( :Relationship]{.HTML-Sample} ::: ::: code -[:Zone]{.HTML_Sample} +[:Zone]{.HTML-Sample} ::: ::: code -[)]{.HTML_Sample} +[)]{.HTML-Sample} ::: ::: code -[\] ;]{.HTML_Sample} +[\] ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :hasObservationZone]{.HTML_Sample} +[owl:propertyChainAxiom ( :hasObservationZone]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasOpertationZone]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasOpertationZone]{.HTML-Sample} ::: ::: code -[:hasOpertationZone rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasOpertationZone rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :LocationRelationship ;]{.HTML_Sample} +[rdfs:subPropertyOf :LocationRelationship ;]{.HTML-Sample} ::: ::: code -[rdfs:range \[rdf:type owl:Class ;]{.HTML_Sample} +[rdfs:range ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:unionOf ( :Relationship]{.HTML_Sample} +[owl:unionOf ( :Relationship]{.HTML-Sample} ::: ::: code -[:Zone]{.HTML_Sample} +[:Zone]{.HTML-Sample} ::: ::: code -[)]{.HTML_Sample} +[)]{.HTML-Sample} ::: ::: code -[\] ;]{.HTML_Sample} +[\] ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :hasOpertationZone]{.HTML_Sample} +[owl:propertyChainAxiom ( :hasOpertationZone]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasPart]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasPart]{.HTML-Sample} ::: ::: code -[:hasPart rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasPart rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Relationship ;]{.HTML_Sample} +[rdfs:subPropertyOf :Relationship ;]{.HTML-Sample} ::: ::: code -[rdf:type owl:TransitiveProperty ;]{.HTML_Sample} +[rdf:type owl:TransitiveProperty ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :hasPart]{.HTML_Sample} +[owl:propertyChainAxiom ( :hasPart]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasState]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasState]{.HTML-Sample} ::: ::: code -[:hasState rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:hasState rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :StateProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :StateProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range :State .]{.HTML_Sample} +[rdfs:range :State .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isContainedIn]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isContainedIn]{.HTML-Sample} ::: ::: code -[:isContainedIn rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:isContainedIn rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :SetBasedLocation ;]{.HTML_Sample} +[rdfs:subPropertyOf :SetBasedLocation ;]{.HTML-Sample} ::: ::: code -[rdf:type owl:TransitiveProperty ;]{.HTML_Sample} +[rdf:type owl:TransitiveProperty ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :isContainedIn]{.HTML_Sample} +[owl:propertyChainAxiom ( :isContainedIn]{.HTML-Sample} ::: ::: code -[:hasObject]{.HTML_Sample} +[:hasObject]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isNodeOfGraph]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isNodeOfGraph]{.HTML-Sample} ::: ::: code -[:isNodeOfGraph rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:isNodeOfGraph rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Relationship ;]{.HTML_Sample} +[rdfs:subPropertyOf :Relationship ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :Entity ;]{.HTML_Sample} +[rdfs:domain :Entity ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Graph ;]{.HTML_Sample} +[rdfs:range :Graph ;]{.HTML-Sample} ::: ::: code -[owl:propertyChainAxiom ( :isNodeOfGraph]{.HTML_Sample} +[owl:propertyChainAxiom ( :isNodeOfGraph]{.HTML-Sample} ::: ::: code -[:isSubGraphOf]{.HTML_Sample} +[:isSubGraphOf]{.HTML-Sample} ::: ::: code -[) .]{.HTML_Sample} +[) .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isSubGraphOf]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#isSubGraphOf]{.HTML-Sample} ::: ::: code -[:isSubGraphOf rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:isSubGraphOf rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Relationship ;]{.HTML_Sample} +[rdfs:subPropertyOf :Relationship ;]{.HTML-Sample} ::: ::: code -[rdf:type owl:TransitiveProperty ;]{.HTML_Sample} +[rdf:type owl:TransitiveProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :Graph ;]{.HTML_Sample} +[rdfs:domain :Graph ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Graph .]{.HTML_Sample} +[rdfs:range :Graph .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#location]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#location]{.HTML-Sample} ::: ::: code -[:location rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:location rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :GeoProperty .]{.HTML_Sample} +[rdfs:subPropertyOf :GeoProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#observationSpace]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#observationSpace]{.HTML-Sample} ::: ::: code -[:observationSpace rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:observationSpace rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :GeoProperty .]{.HTML_Sample} +[rdfs:subPropertyOf :GeoProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#operationSpace]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#operationSpace]{.HTML-Sample} ::: ::: code -[:operationSpace rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:operationSpace rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :GeoProperty .]{.HTML_Sample} +[rdfs:subPropertyOf :GeoProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ListRelationship]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ListRelationship]{.HTML-Sample} ::: ::: code -[:ListRelationship rdf:type owl:ObjectProperty ;]{.HTML_Sample} +[:]{.HTML-Sample}[ListRelationship ]{.HTML-Sample}[rdf:type owl:ObjectProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Relationship;]{.HTML_Sample} +[rdfs:subPropertyOf :]{.HTML-Sample}[Relationship]{.HTML-Sample}[;]{.HTML-Sample} ::: ::: code -[rdfs:range :VectorValue.]{.HTML_Sample} +[rdfs:range :VectorValue.]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\# Data properties]{.HTML_Sample} +[\# Data properties]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#TemporalProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#TemporalProperty]{.HTML-Sample} ::: ::: code -[:TemporalProperty rdf:type owl:DatatypeProperty .]{.HTML_Sample} +[:TemporalProperty rdf:type owl:DatatypeProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#createdAt]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#createdAt]{.HTML-Sample} ::: ::: code -[:createdAt rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:createdAt rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :TemporalProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :TemporalProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range xsd:dateTime .]{.HTML_Sample} +[rdfs:range xsd:dateTime .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasValue]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasValue]{.HTML-Sample} ::: ::: code -[:hasValue rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:hasValue rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :Property .]{.HTML_Sample} +[rdfs:domain :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasValueList]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasValueL]{.HTML-Sample}[ist]{.HTML-Sample} ::: ::: code -[:hasValueList rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:]{.HTML-Sample}[hasValueList ]{.HTML-Sample}[rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :ListProperty.]{.HTML_Sample} +[rdfs:domain :]{.HTML-Sample}[ListProperty]{.HTML-Sample}[.]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasObjectList]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#has]{.HTML-Sample}[ObjectList]{.HTML-Sample} ::: ::: code -[:hasObjectList rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:]{.HTML-Sample}[hasObjectList ]{.HTML-Sample}[rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :ListRelationship.]{.HTML_Sample} +[rdfs:domain :]{.HTML-Sample}[ListRelationship]{.HTML-Sample}[.]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasVocab]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasVocab]{.HTML-Sample} ::: ::: code -[:hasVocab rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:]{.HTML-Sample}[hasVocab ]{.HTML-Sample}[rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :VocabProperty .]{.HTML_Sample} +[rdfs:domain :]{.HTML-Sample}[Vocab]{.HTML-Sample}[Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasJson]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#hasJson]{.HTML-Sample} ::: ::: code -[:hasJson rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:hasJson rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:domain :JsonProperty .]{.HTML_Sample} +[rdfs:domain :JsonProperty .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#modifiedAt]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#modifiedAt]{.HTML-Sample} ::: ::: code -[:modifiedAt rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:modifiedAt rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :TemporalProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :TemporalProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range xsd:dateTime .]{.HTML_Sample} +[rdfs:range xsd:dateTime .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#observedAt]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#observedAt]{.HTML-Sample} ::: ::: code -[:observedAt rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:observedAt rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :TemporalProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :TemporalProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range xsd:dateTime .]{.HTML_Sample} +[rdfs:range xsd:dateTime .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#deletedAt]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#deletedAt]{.HTML-Sample} ::: ::: code -[:deletedAt rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:deletedAt rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :TemporalProperty ;]{.HTML_Sample} +[rdfs:subPropertyOf :TemporalProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range xsd:dateTime .]{.HTML_Sample} +[rdfs:range xsd:dateTime .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#unitCode]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#unitCode]{.HTML-Sample} ::: ::: code -[:unitCode rdf:type owl:DatatypeProperty ;]{.HTML_Sample} +[:unitCode rdf:type owl:DatatypeProperty ;]{.HTML-Sample} ::: ::: code -[rdfs:range xsd:string .]{.HTML_Sample} +[rdfs:range xsd:string .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ListProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ListProperty]{.HTML-Sample} ::: ::: code -[:ListProperty rdf:type owl:DatatypeProperty;]{.HTML_Sample} +[:]{.HTML-Sample}[ListProperty ]{.HTML-Sample}[rdf:type owl:DatatypeProperty;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property ;]{.HTML_Sample} +[rdfs:subPropertyOf :Property ;]{.HTML-Sample} ::: ::: code -[rdfs:range :VectorValue.]{.HTML_Sample} +[rdfs:range :VectorValue.]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#JsonProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#JsonProperty]{.HTML-Sample} ::: ::: code -[:JsonProperty rdf:type owl:DatatypeProperty;]{.HTML_Sample} +[:]{.HTML-Sample}[JsonProperty ]{.HTML-Sample}[rdf:type owl:DatatypeProperty;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property .]{.HTML_Sample} +[rdfs:subPropertyOf :Property ]{.HTML-Sample}[.]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#VocabProperty]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#VocabProperty]{.HTML-Sample} ::: ::: code -[:VocabProperty rdf:type owl:DatatypeProperty;]{.HTML_Sample} +[:]{.HTML-Sample}[VocabProperty ]{.HTML-Sample}[rdf:type owl:DatatypeProperty;]{.HTML-Sample} ::: ::: code -[rdfs:subPropertyOf :Property .]{.HTML_Sample} +[rdfs:subPropertyOf :Property ]{.HTML-Sample}[.]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\# Classes]{.HTML_Sample} +[\# Classes]{.HTML-Sample} ::: ::: code -[\#################################################################]{.HTML_Sample} +[\#################################################################]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ContinuousValue]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ContinuousValue]{.HTML-Sample} ::: ::: code -[:ContinuousValue rdf:type owl:Class ;]{.HTML_Sample} +[:ContinuousValue rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :State .]{.HTML_Sample} +[rdfs:subClassOf :State .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#DiscreteValue]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#DiscreteValue]{.HTML-Sample} ::: ::: code -[:DiscreteValue rdf:type owl:Class ;]{.HTML_Sample} +[:DiscreteValue rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :State .]{.HTML_Sample} +[rdfs:subClassOf :State .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Entity]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Entity]{.HTML-Sample} ::: ::: code -[:Entity rdf:type owl:Class ;]{.HTML_Sample} +[:Entity rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:disjointWith :Property ,]{.HTML_Sample} +[owl:disjointWith :Property ,]{.HTML-Sample} ::: ::: code -[:Relationship ,]{.HTML_Sample} +[:Relationship ,]{.HTML-Sample} ::: ::: code -[:Value .]{.HTML_Sample} +[:Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Geometry]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Geometry]{.HTML-Sample} ::: ::: code -[:Geometry rdf:type owl:Class ;]{.HTML_Sample} +[:Geometry rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Value .]{.HTML_Sample} +[rdfs:subClassOf :Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Graph]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Graph]{.HTML-Sample} ::: ::: code -[:Graph rdf:type owl:Class ;]{.HTML_Sample} +[:Graph rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Entity .]{.HTML_Sample} +[rdfs:subClassOf :Entity .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Instantaneous]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Instantaneous]{.HTML-Sample} ::: ::: code -[:Instantaneous rdf:type owl:Class ;]{.HTML_Sample} +[:Instantaneous rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Property .]{.HTML_Sample} +[rdfs:subClassOf :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LineString]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#LineString]{.HTML-Sample} ::: ::: code -[:LineString rdf:type owl:Class ;]{.HTML_Sample} +[:LineString rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Geometry .]{.HTML_Sample} +[rdfs:subClassOf :Geometry .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Measurement]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Measurement]{.HTML-Sample} ::: ::: code -[:Measurement rdf:type owl:Class ;]{.HTML_Sample} +[:Measurement rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Value .]{.HTML_Sample} +[rdfs:subClassOf :Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Mobile]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Mobile]{.HTML-Sample} ::: ::: code -[:Mobile rdf:type owl:Class ;]{.HTML_Sample} +[:Mobile rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:equivalentClass \[rdf:type owl:Restriction ;]{.HTML_Sample} +[owl:equivalentClass ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Restriction ;]{.HTML-Sample} ::: ::: code -[owl:onProperty :location ;]{.HTML_Sample} +[owl:onProperty :location ;]{.HTML-Sample} ::: ::: code -[owl:allValuesFrom :Instantaneous]{.HTML_Sample} +[owl:allValuesFrom :Instantaneous]{.HTML-Sample} ::: ::: code -[\] ;]{.HTML_Sample} +[\] ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Entity .]{.HTML_Sample} +[rdfs:subClassOf :Entity .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Movable]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Movable]{.HTML-Sample} ::: ::: code -[:Movable rdf:type owl:Class ;]{.HTML_Sample} +[:Movable rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:equivalentClass \[rdf:type owl:Restriction ;]{.HTML_Sample} +[owl:equivalentClass ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Restriction ;]{.HTML-Sample} ::: ::: code -[owl:onProperty :location ;]{.HTML_Sample} +[owl:onProperty :location ;]{.HTML-Sample} ::: ::: code -[owl:allValuesFrom :SemiStatic]{.HTML_Sample} +[owl:allValuesFrom :SemiStatic]{.HTML-Sample} ::: ::: code -[\] ;]{.HTML_Sample} +[\] ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Entity .]{.HTML_Sample} +[rdfs:subClassOf :Entity .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Point]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Point]{.HTML-Sample} ::: ::: code -[:Point rdf:type owl:Class ;]{.HTML_Sample} +[:Point rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Geometry .]{.HTML_Sample} +[rdfs:subClassOf :Geometry .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Polygon]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Polygon]{.HTML-Sample} ::: ::: code -[:Polygon rdf:type owl:Class ;]{.HTML_Sample} +[:Polygon rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Geometry .]{.HTML_Sample} +[rdfs:subClassOf :Geometry .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Property]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Property]{.HTML-Sample} ::: ::: code -[:Property rdf:type owl:Class ;]{.HTML_Sample} +[:Property rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:disjointWith :Relationship .]{.HTML_Sample} +[owl:disjointWith :Relationship .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Relationship]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Relationship]{.HTML-Sample} ::: ::: code -[:Relationship rdf:type owl:Class ;]{.HTML_Sample} +[:Relationship rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:disjointWith :Value .]{.HTML_Sample} +[owl:disjointWith :Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ScalarValue]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#ScalarValue]{.HTML-Sample} ::: ::: code -[:ScalarValue rdf:type owl:Class ;]{.HTML_Sample} +[:ScalarValue rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :VectorValue .]{.HTML_Sample} +[rdfs:subClassOf :VectorValue .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SemiStatic]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#SemiStatic]{.HTML-Sample} ::: ::: code -[:SemiStatic rdf:type owl:Class ;]{.HTML_Sample} +[:SemiStatic rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Property .]{.HTML_Sample} +[rdfs:subClassOf :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#State]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#State]{.HTML-Sample} ::: ::: code -[:State rdf:type owl:Class ;]{.HTML_Sample} +[:State rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Value .]{.HTML_Sample} +[rdfs:subClassOf :Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Static]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Static]{.HTML-Sample} ::: ::: code -[:Static rdf:type owl:Class ;]{.HTML_Sample} +[:Static rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Property .]{.HTML_Sample} +[rdfs:subClassOf :Property .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Stationary]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Stationary]{.HTML-Sample} ::: ::: code -[:Stationary rdf:type owl:Class ;]{.HTML_Sample} +[:Stationary rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[owl:equivalentClass \[rdf:type owl:Restriction ;]{.HTML_Sample} +[owl:equivalentClass ]{.HTML-Sample}[\[]{.HTML-Sample}[rdf:type owl:Restriction ;]{.HTML-Sample} ::: ::: code -[owl:onProperty :location ;]{.HTML_Sample} +[owl:onProperty :location ;]{.HTML-Sample} ::: ::: code -[owl:allValuesFrom :Static]{.HTML_Sample} +[owl:allValuesFrom :Static]{.HTML-Sample} ::: ::: code -[\] ;]{.HTML_Sample} +[\] ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Entity .]{.HTML_Sample} +[rdfs:subClassOf :Entity .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Value]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Value]{.HTML-Sample} ::: ::: code -[:Value rdf:type owl:Class .]{.HTML_Sample} +[:Value rdf:type owl:Class .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#VectorValue]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#VectorValue]{.HTML-Sample} ::: ::: code -[:VectorValue rdf:type owl:Class ;]{.HTML_Sample} +[:VectorValue rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Value .]{.HTML_Sample} +[rdfs:subClassOf :Value .]{.HTML-Sample} ::: ::: code -[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Zone]{.HTML_Sample} +[\### https://uri.etsi.org/ngsi-ld/v1/ontology#Zone]{.HTML-Sample} ::: ::: code -[:Zone rdf:type owl:Class ;]{.HTML_Sample} +[:Zone rdf:type owl:Class ;]{.HTML-Sample} ::: ::: code -[rdfs:subClassOf :Entity .]{.HTML_Sample} +[rdfs:subClassOf :Entity .]{.HTML-Sample} ::: diff --git a/annex-e.md b/annex-e.md index c9853b3..ef5e236 100644 --- a/annex-e.md +++ b/annex-e.md @@ -1,6 +1,7 @@ # Annex E (informative): Change History ::: TAL + +-----------------------+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Date | Version | Information about changes | +=======================+=======================+======================================================================================================================================================================================================================================================================================================================================+ @@ -48,4 +49,5 @@ | | | | | | V1.2.5 | | +-----------------------+-----------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ + ::: diff --git a/clause-3_Definitions.md b/clause-3_Definitions.md index e873e58..a78a83a 100644 --- a/clause-3_Definitions.md +++ b/clause-3_Definitions.md @@ -28,19 +28,19 @@ In the NGSI-LD API, an NGSI-LD Entity Type is **uniquely identified by a URI** . >>> [!tip] EXAMPLE 1: -["Vehicle"]{.HTML_Code} is an NGSI-LD Entity Type and is identified with a proper URI. +["Vehicle"]{.HTML-Code} is an NGSI-LD Entity Type and is identified with a proper URI. >>> >>> [!tip] EXAMPLE 2: -Bob's private car whose plate number is ["ABCD1234"]{.HTML_Code} is an NGSI-LD Entity whose NGSI-LD Entity Type name is ["Vehicle".]{.HTML_Code} +Bob's private car whose plate number is ["ABCD1234"]{.HTML-Code} is an NGSI-LD Entity whose NGSI-LD Entity Type name is ["Vehicle".]{.HTML-Code} >>> >>> [!tip] EXAMPLE 3: -Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD Entity types, e.g. ["Vehicle"]{.HTML_Code} and ["Home"]{.HTML_Code} . +Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD Entity types, e.g. ["Vehicle"]{.HTML-Code} and ["Home"]{.HTML-Code} . >>> @@ -56,7 +56,7 @@ Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD E >>> [!tip] EXAMPLE: -"A bus route services the following bus stops" can be represented by an NGSI-LD *ListRelationship* whose name is "route" which holds an array of directed links towards a series of NGSI-LD Entities of type (Type name) ["BusStop"]{.HTML_Code} . +"A bus route services the following bus stops" can be represented by an NGSI-LD *ListRelationship* whose name is "route" which holds an array of directed links towards a series of NGSI-LD Entities of type (Type name) ["BusStop"]{.HTML-Code} . >>> @@ -64,7 +64,7 @@ Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD E >>> [!tip] EXAMPLE: -"Bob's vehicle's speed is 40 km/h" can be represented by an NGSI-LD Property, whose name is "speed", and which characterizes an NGSI-LD Entity, whose NGSI-LD Type is ["Vehicle"]{.HTML_Code} . Such a name can be expanded to a fully qualified name in the form of a URI , for instance ["http://example.org/Vehicle"]{.HTML_Code} or ["http://example.org/speed".]{.HTML_Code} +"Bob's vehicle's speed is 40 km/h" can be represented by an NGSI-LD Property, whose name is "speed", and which characterizes an NGSI-LD Entity, whose NGSI-LD Type is ["Vehicle"]{.HTML-Code} . Such a name can be expanded to a fully qualified name in the form of a URI , for instance ["http://example.org/Vehicle"]{.HTML-Code} or ["http://example.org/speed".]{.HTML-Code} >>> @@ -72,13 +72,13 @@ Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD E >>> [!tip] EXAMPLE 1: -An NGSI-LD Entity of type ["Vehicle"]{.HTML_Code} can be the subject of an NGSI-LD Relationship whose object is an NGSI-LD Entity of type ["Parking"]{.HTML_Code} . +An NGSI-LD Entity of type ["Vehicle"]{.HTML-Code} can be the subject of an NGSI-LD Relationship whose object is an NGSI-LD Entity of type ["Parking"]{.HTML-Code} . >>> >>> [!tip] EXAMPLE 2: -An NGSI-LD Entity of type ["Vehicle"]{.HTML_Code} can be the subject of an NGSI-LD Relationship whose object is an array of NGSI-LD Entities of type ["Passenger"]{.HTML_Code} . +An NGSI-LD Entity of type ["Vehicle"]{.HTML-Code} can be the subject of an NGSI-LD Relationship whose object is an array of NGSI-LD Entities of type ["Passenger"]{.HTML-Code} . >>> @@ -94,7 +94,7 @@ Bob's private car 'speed' NGSI-LD Value is the number 100 (kilometres per hour). >>> [!tip] EXAMPLE: -"Bob's car is a non-commercial vehicle" can be represented by an NGSI-LD [VocabProperty]{.NGSILDTerm} whose name is ["category"]{.HTML_Code} which holds the string value ["non-commercial"]{.HTML_Code} . If the associated JSON-LD context defines the term ["non-commercial" ]{.HTML_Code} as ["http://example.com/non-commercial",]{.HTML_Code} then the returned value shall be expanded using type coercion into the IRI the [.]{.Hyperlink} +"Bob's car is a non-commercial vehicle" can be represented by an NGSI-LD [VocabProperty]{.NGSILDTerm} whose name is ["category"]{.HTML-Code} which holds the string value ["non-commercial"]{.HTML-Code} . If the associated JSON-LD context defines the term ["non-commercial" ]{.HTML-Code} as ["http://example.com/non-commercial",]{.HTML-Code} then the returned value shall be expanded using type coercion into the IRI the [.]{.Hyperlink} >>> diff --git a/clause-5.md b/clause-5.md index f489d95..fb61d00 100644 --- a/clause-5.md +++ b/clause-5.md @@ -67,12 +67,13 @@ This solution is especially convenient when the graph is serialized using JSON-L 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 (e.g. see [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]{.HTML_Sample}, and the properties [rdf:subject, rdf:predicate, and rdf:object]{.HTML_Sample}. 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. +- *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]{.HTML-Sample}, and the properties [rdf:subject, rdf:predicate, and rdf:object]{.HTML-Sample}. 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. - *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 [n.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. + +--------------------------------------------+--------------------------------------------------+ | ![](media/image10.png) | ![](media/image11.png) | | | | @@ -107,6 +108,7 @@ These reification methods are compared in Figure 5 (Standard RDF reification - w | } | ``` | | ``` | | +--------------------------------------------+--------------------------------------------------+ + Using reification with blank nodes, the SPARQL query is as follows: @@ -118,17 +120,17 @@ SELECT ?R WHERE { } ``` -For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the [owl:propertyChainAxiom]{.HTML_Sample} is used as follows: +For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the [owl:propertyChainAxiom]{.HTML-Sample} is used as follows: ``` json -:monitors owl:propertyChainAxiom (:monitors:hasObject). +: 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. ``` json SELECT ?S where { -:CameraA :monitors ?S.} +:CameraA : monitors ?S.} ``` ## 5.3 Formal definition @@ -155,19 +157,19 @@ In the NGSI-LD API, an NGSI-LD Entity Type is **uniquely identified by a URI** . >>> [!tip] EXAMPLE 1: -["Vehicle"]{.HTML_Code} is an NGSI-LD Entity Type and is identified with a proper URI. +["Vehicle"]{.HTML-Code} is an NGSI-LD Entity Type and is identified with a proper URI. >>> >>> [!tip] EXAMPLE 2: -Bob's private car whose plate number is ["ABCD1234"]{.HTML_Code} is an NGSI-LD Entity whose NGSI-LD Entity Type name is ["Vehicle".]{.HTML_Code} +Bob's private car whose plate number is ["ABCD1234"]{.HTML-Code} is an NGSI-LD Entity whose NGSI-LD Entity Type name is ["Vehicle".]{.HTML-Code} >>> >>> [!tip] EXAMPLE 3: -Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD Entity types, e.g. ["Vehicle"]{.HTML_Code} and ["Home"]{.HTML_Code} . +Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD Entity types, e.g. ["Vehicle"]{.HTML-Code} and ["Home"]{.HTML-Code} . >>> @@ -181,15 +183,15 @@ Alice's motorhome has a unique URI as id, but can be assigned multiple NGSI-LD E **NGSI-LD ListRelationship:** description of an ordered array of directed links between a subject which is either an NGSI-LD Entity, an NGSI-LD Property or another NGSI-LD Relationship on one hand, and a series of objects, which are NGSI-LD Entities, on the other hand, and which uses the special *hasObjectList* property to define its target objects ->>> [!tip] EXAMPLE: -EXAMPLE: "A bus route services the following bus stops" can be represented by an NGSI-LD *ListRelationship* whose name is "route" which holds an array of directed links towards a series of NGSI-LD Entities of type (Type name) ["BusStop"]{.HTML_Code} ->>> +::: ondemand_PAR_first_line_indent_-70_left_indent_85_space_after_10 +EXAMPLE: "A bus route services the following bus stops" can be represented by an NGSI-LD *ListRelationship* whose name is "route" which holds an array of directed links towards a series of NGSI-LD Entities of type (Type name) ["BusStop"]{.HTML-Code} +::: **NGSI-LD Property:** description instance which associates a main characteristic, i.e. an **NGSI-LD Value**, to either an NGSI-LD Entity, an NGSI-LD Relationship or another NGSI-LD Property and that uses the special *hasValue* property to define its target value >>> [!tip] EXAMPLE: -"Bob's vehicle's speed is 40 km/h" can be represented by an NGSI-LD Property, whose name is "speed", and which characterizes an NGSI-LD Entity, whose NGSI-LD Type is ["Vehicle"]{.HTML_Code} . Such a name can be expanded to a fully qualified name in the form of a URI , for instance ["http://example.org/Vehicle"]{.HTML_Code} or ["http://example.org/speed".]{.HTML_Code} +"Bob's vehicle's speed is 40 km/h" can be represented by an NGSI-LD Property, whose name is "speed", and which characterizes an NGSI-LD Entity, whose NGSI-LD Type is ["Vehicle"]{.HTML-Code} . Such a name can be expanded to a fully qualified name in the form of a URI , for instance ["http://example.org/Vehicle"]{.HTML-Code} or ["http://example.org/speed".]{.HTML-Code} >>> @@ -197,13 +199,13 @@ EXAMPLE: "A bus route services the following bus stops" can be represented by an >>> [!tip] EXAMPLE 1: -An NGSI-LD Entity of type ["Vehicle"]{.HTML_Code} can be the subject of an NGSI-LD Relationship whose object is an NGSI-LD Entity of type ["Parking"]{.HTML_Code} . +An NGSI-LD Entity of type ["Vehicle"]{.HTML-Code} can be the subject of an NGSI-LD Relationship whose object is an NGSI-LD Entity of type ["Parking"]{.HTML-Code} . >>> >>> [!tip] EXAMPLE 2: -An NGSI-LD Entity of type ["Vehicle"]{.HTML_Code} can be the subject of an NGSI-LD Relationship whose object is an array of NGSI-LD Entities of type ["Passenger"]{.HTML_Code} . +An NGSI-LD Entity of type ["Vehicle"]{.HTML-Code} can be the subject of an NGSI-LD Relationship whose object is an array of NGSI-LD Entities of type ["Passenger"]{.HTML-Code} . >>> @@ -219,7 +221,7 @@ Bob's private car 'speed' NGSI-LD Value is the number 100 (kilometres per hour). >>> [!tip] EXAMPLE: -"Bob's car is a non-commercial vehicle" can be represented by an NGSI-LD [VocabProperty]{.NGSILDTerm} whose name is ["category"]{.HTML_Code} which holds the string value ["non-commercial"]{.HTML_Code} . If the associated JSON-LD context defines the term ["non-commercial" ]{.HTML_Code} as ["http://example.com/non-commercial",]{.HTML_Code} then the returned value shall be expanded using type coercion into the IRI the [.]{.Hyperlink} +"Bob's car is a non-commercial vehicle" can be represented by an NGSI-LD [VocabProperty]{.NGSILDTerm} whose name is ["category"]{.HTML-Code} which holds the string value ["non-commercial"]{.HTML-Code} . If the associated JSON-LD context defines the term ["non-commercial" ]{.HTML-Code} as ["http://example.com/non-commercial",]{.HTML-Code} then the returned value shall be expanded using type coercion into the IRI the [.]{.Hyperlink} >>> @@ -239,66 +241,66 @@ Similar to Entity types, the types for Properties and Relationships are defined 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]{.HTML_Sample} are direct subclasses of the [rdfs:Resource]{.HTML_Sample}or [owl:Thing]{.HTML_Sample}class (default for classes for RDFS and OWL respectively). +[Entity, Property, Relationship]{.HTML-Sample} are direct subclasses of the [rdfs:Resource]{.HTML-Sample}or [owl:Thing]{.HTML-Sample}class (default for classes for RDFS and OWL respectively). ::: code -[:Entity rdf:type owl:Class .]{.HTML_Sample} +[:Entity rdf:type owl:Class .]{.HTML-Sample} ::: ::: code -[...]{.HTML_Sample} +[...]{.HTML-Sample} ::: -[Value]{.HTML_Sample} in the NGSI-LD meta-model is not limited to the [rdfs:Literal]{.HTML_Sample}. The class [Value]{.HTML_Sample} is extensible as needed to allow more value formats in domain specific extensions of the meta-model. [Value]{.HTML_Sample} may be an [rdfs:Literal]{.HTML_Sample}, but may also be some specific type as defined by a programming language, e.g. integer. A value shall be neither an [Entity]{.HTML_Sample}, a [Property]{.HTML_Sample}, nor a [Relationship]{.HTML_Sample}. +[Value]{.HTML-Sample} in the NGSI-LD meta-model is not limited to the [rdfs:Literal]{.HTML-Sample}. The class [Value]{.HTML-Sample} is extensible as needed to allow more value formats in domain specific extensions of the meta-model. [Value]{.HTML-Sample} may be an [rdfs:Literal]{.HTML-Sample}, but may also be some specific type as defined by a programming language, e.g. integer. A value shall be neither an [Entity]{.HTML-Sample}, a [Property]{.HTML-Sample}, nor a [Relationship]{.HTML-Sample}. ::: code -[:Entity owl:disjointWith :Value .]{.HTML_Sample} +[:Entity owl:disjointWith :Value .]{.HTML-Sample} ::: ::: code -[:Property owl:disjointWith :Value .]{.HTML_Sample} +[:Property owl:disjointWith :Value .]{.HTML-Sample} ::: ::: code -[:Relationship owl:disjointWith :Value .]{.HTML_Sample} +[:Relationship owl:disjointWith :Value .]{.HTML-Sample} ::: -Two primitive RDF properties are defined: [hasValue]{.HTML_Sample} and [hasObject]{.HTML_Sample}. These are used to "pre-reify" all relationships and properties by enabling their potential reification with blank nodes as explained in clause 5.2, even if these properties or relationships are not actually the subject of another property or relationship. +Two primitive RDF properties are defined: [hasValue]{.HTML-Sample} and [hasObject]{.HTML-Sample}. These are used to "pre-reify" all relationships and properties by enabling their potential reification with blank nodes as explained in clause 5.2, even if these properties or relationships are not actually the subject of another property or relationship. -In OWL, [owl:DatatypeProperty]{.HTML_Sample} and [owl:ObjectProperty]{.HTML_Sample} correspond to two kinds of [rdf:Property]{.HTML_Sample}, 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. +In OWL, [owl:DatatypeProperty]{.HTML-Sample} and [owl:ObjectProperty]{.HTML-Sample} correspond to two kinds of [rdf:Property]{.HTML-Sample}, 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. ::: code -[:hasValue rdf:type owl:DatatypeProperty .]{.HTML_Sample} +[:hasValue rdf:type owl:DatatypeProperty .]{.HTML-Sample} ::: ::: code -[rdfs:domain :Property .]{.HTML_Sample} +[rdfs:domain :Property .]{.HTML-Sample} ::: ::: code -[:hasObject rdf:type owl:ObjectProperty .]{.HTML_Sample} +[:hasObject rdf:type owl:ObjectProperty .]{.HTML-Sample} ::: ::: code -[rdfs:domain :Relationship ;]{.HTML_Sample} +[rdfs:domain :Relationship ;]{.HTML-Sample} ::: ::: code -[rdfs:range :Entity .]{.HTML_Sample} +[rdfs:range :Entity .]{.HTML-Sample} ::: -An example of usage of [hasValue]{.HTML_Sample} for applying a property (ObservedAt) to another "pre-reified" property (colour) is given below: +An example of usage of [hasValue]{.HTML-Sample} for applying a property (ObservedAt) to another "pre-reified" property (colour) is given below: ::: code -[:Car1 :colour\_:bn]{.HTML_Sample} +[:Car1 :]{.HTML-Sample}[colour]{.HTML-Sample}[\_:bn]{.HTML-Sample} ::: ::: code -[\_:bn hasValue "Blue"]{.HTML_Sample} +[\_:bn hasValue ]{.HTML-Sample}["]{.HTML-Sample}[Blue]{.HTML-Sample}["]{.HTML-Sample} ::: ::: code -[\_:bn observedAt "2018-01-01T00:00:00Z"]{.HTML_Sample} +[\_:bn observedAt ]{.HTML-Sample}["]{.HTML-Sample}[2018-01-01T00:00:00Z]{.HTML-Sample}["]{.HTML-Sample} ::: ## 5.4 Serialization with JSON-LD diff --git a/clause-6.md b/clause-6.md index db8301d..d7dea56 100644 --- a/clause-6.md +++ b/clause-6.md @@ -75,9 +75,9 @@ The first step is to assert a property chain as follows: (:isContainedIn :hasObject) . ``` -In the current example this means it can be inferred that "Building A" is also directly connected to the "isContainedIn" RDF property, and not only to the "[hasObject]{.HTML_Sample}" property. +In the current example this means it can be inferred that "Building A" is also directly connected to the "isContainedIn" RDF property, and not only to the "[hasObject]{.HTML-Sample}" property. -The second step is to define the RDF class that is a range for the "[isContainedIn]{.HTML_Sample}" RDF property. This should be a union of two RDF classes, the RDF class "[isContainedIn]{.HTML_Sample}" (to account of the blank node instances) and the RDF class "[Entity]{.HTML_Sample}". This is defined in OWL as follows: +The second step is to define the RDF class that is a range for the "[isContainedIn]{.HTML-Sample}" RDF property. This should be a union of two RDF classes, the RDF class "[isContainedIn]{.HTML-Sample}" (to account of the blank node instances) and the RDF class "[Entity]{.HTML-Sample}". This is defined in OWL as follows: ``` json :isContainedIn rdfs:range @@ -87,25 +87,25 @@ The second step is to define the RDF class that is a range for the "[isContained A general set of restriction rules that serve for establishing compatibility between the cross-domain ontology and the core meta-model are defined in the following. For the definition of the information model, some basic rules should always be followed while defining the vocabulary of the cross-domain ontology in the RDF/OWL standards (Turtle format is used in the following descriptions). -Another set of rules are defined for property types (e.g. [observationSpace]{.HTML_Sample}). These rules apply to both OWL-DL and OWL-full when not specified, but they only apply to OWL-full when specified beside the rule. +Another set of rules are defined for property types (e.g. [observationSpace]{.HTML-Sample}). These rules apply to both OWL-DL and OWL-full when not specified, but they only apply to OWL-full when specified beside the rule. -For each property type [p]{.HTML_Sample}: +For each property type [p]{.HTML-Sample}: - the following rules shall hold: - - [prdf:typeowl:ObjectProperty]{.HTML_Sample} - - [prdfs:subPropertyOfProperty]{.HTML_Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Property.)* - - [prdfs:subClassOfProperty]{.HTML_Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subClassOf some class which is a subclass of Property.)* - - \[OWL-full\] [p owl:propertyChainAxiom (p hasValue]{.HTML_Sample}) *(Since reification uses a supplementary property hasValue with Properties, a shortcut for extracting data by only using the property p is allowed. This assertion means that any property p usage followed by a hasValue usage is semantically equivalent to using p alone. This allows implicitly inferring the values of properties without using the reification through blank nodes, but directly through the name of the property when no other information is needed.)* + - [p]{.HTML-Sample} [rdf:type]{.HTML-Sample} [owl:ObjectProperty]{.HTML-Sample} + - [p]{.HTML-Sample} [rdfs:subPrope]{.HTML-Sample}[r]{.HTML-Sample}[tyOf]{.HTML-Sample} [Property]{.HTML-Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Property.)* + - [p]{.HTML-Sample} [rdfs:subClassOf]{.HTML-Sample} [Property]{.HTML-Sample} *(Either direct or by inference, i.e. p may also be defined as an rdfs:subClassOf some class which is a subclass of Property.)* + - \[OWL-full\] [p owl:propertyChainAxiom (p hasValue]{.HTML-Sample}) *(Since reification uses a supplementary property hasValue with Properties, a shortcut for extracting data by only using the property p is allowed. This assertion means that any property p usage followed by a hasValue usage is semantically equivalent to using p alone. This allows implicitly inferring the values of properties without using the reification through blank nodes, but directly through the name of the property when no other information is needed.)* - the following rules may hold: (where restrictions are needed): - - [prdfs:domainC]{.HTML_Sample} (*Where* [C]{.HTML_Sample} *is a subclass of* [Entity, Property]{.HTML_Sample}*, or* [Relationship]{.HTML_Sample})(*This limits the usage of p on a certain class of Entities, Properties, or Relationships.*) - - [prdfs:rangeV]{.HTML_Sample} (*Where* [V]{.HTML_Sample} *is a subclass of* [Value]{.HTML_Sample})(*This limits the values that can be associated with p.*) + - [p]{.HTML-Sample} [rdfs:domain]{.HTML-Sample} [C]{.HTML-Sample} (*Where* [C]{.HTML-Sample} *is a subclass of* [Entity, Property]{.HTML-Sample}*, or* [Relationship]{.HTML-Sample})(*This limits the usage of p on a certain class of Entities, Properties, or Relationships.*) + - [p]{.HTML-Sample} [rdfs:range]{.HTML-Sample} [V]{.HTML-Sample} (*Where* [V]{.HTML-Sample} *is a subclass of* [Value]{.HTML-Sample})(*This limits the values that can be associated with p.*) -Some properties in the NGSI-LD API have specifically been defined such that they shall never be reified and do not use the "hasValue" construct. Those properties include: *observedAt*, *createdAt*, *modifiedAt*, *deletedAt*, *start*, *end* and *unitCode*. Those properties are direct instances (using *rdf:type*) of the class [Property]{.HTML_Sample}**.** Similar to property types, the rules for relationship types are defined. +Some properties in the NGSI-LD API have specifically been defined such that they shall never be reified and do not use the "hasValue" construct. Those properties include: *observedAt*, *createdAt*, *modifiedAt*, *deletedAt*, *start*, *end* and *unitCode*. Those properties are direct instances (using *rdf:type*) of the class [Property]{.HTML-Sample}**.** Similar to property types, the rules for relationship types are defined. -For each relationship type [r]{.HTML_Sample}: +For each relationship type [r]{.HTML-Sample}: - the following rules shall hold: @@ -113,16 +113,16 @@ For each relationship type [r]{.HTML_Sample}: r rdf:type owl:ObjectProperty ::: -- [r rdfs:subPropetyOf Relationship]{.HTML_Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Relationship.)* -- [r rdfs:subClassOf Relationship]{.HTML_Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subClassOf some class which is a subclass of Relationship.)* -- [r rdf:type r]{.HTML_Sample}*(r is both a class which is the class of relationship blank node instances, and an instance of itself because it is used as a property that links subjects to the relationship blank nodes.)* -- [r owl:propertyChainAxiom (r hasObject)]{.HTML_Sample} *(Since reification uses a supplementary property "hasObject" with Relationships, a shortcut is allowed for extracting data by only using the relationship r. This assertion means that any relationship r usage followed by a hasObject usage is semantically equivalent to using r alone. This allows implicitly inferring the values of relationships without using the reification through blank nodes, but directly through the name of the relationship when no other information is needed.)* +- [r rdfs:subPropetyOf Relationship]{.HTML-Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subPropertyOf some owl:ObjectProperty which is a subproperty of Relationship.)* +- [r rdfs:subClassOf Relationship]{.HTML-Sample} *(Either direct or by inference, i.e. r may also be defined as an rdfs:subClassOf some class which is a subclass of Relationship.)* +- [r rdf:type r]{.HTML-Sample}*(r is both a class which is the class of relationship blank node instances, and an instance of itself because it is used as a property that links subjects to the relationship blank nodes.)* +- [r owl:propertyChainAxiom (r hasObject)]{.HTML-Sample} *(Since reification uses a supplementary property "hasObject" with Relationships, a shortcut is allowed for extracting data by only using the relationship r. This assertion means that any relationship r usage followed by a hasObject usage is semantically equivalent to using r alone. This allows implicitly inferring the values of relationships without using the reification through blank nodes, but directly through the name of the relationship when no other information is needed.)* - the following rules may hold: (where restrictions are needed): - - [r rdfs:domain C1]{.HTML_Sample} (*Where* [C1]{.HTML_Sample} *is a subclass of* [Entity, Property]{.HTML_Sample}*, or* [Relationship]{.HTML_Sample}) (*This limits the usage of r on a certain class of Entities, Properties, or Relationships*) - - [r rdfs:range C2]{.HTML_Sample} (*Where* [C2]{.HTML_Sample} *is a subclass of* [Entity]{.HTML_Sample}) (*This limits the Entities that can be associated with r*) + - [r rdfs:domain C1]{.HTML-Sample} (*Where* [C1]{.HTML-Sample} *is a subclass of* [Entity, Property]{.HTML-Sample}*, or* [Relationship]{.HTML-Sample}) (*This limits the usage of r on a certain class of Entities, Properties, or Relationships*) + - [r rdfs:range C2]{.HTML-Sample} (*Where* [C2]{.HTML-Sample} *is a subclass of* [Entity]{.HTML-Sample}) (*This limits the Entities that can be associated with r*) In clauses 6.3.1 through 6.3.6, different subsets of the cross-domain meta-model are described in detail. @@ -132,9 +132,9 @@ Given an Entity, it is optional, but recommended, to choose a mobility typing wh The cross-domain ontology distinguishes between three mutually exclusive types of mobility: -1. **Stationary:** Location property associated with such an Entity is also a static property (by [owl:restriction]{.HTML_Sample}). -2. **Movable:** Location property associated with such an Entity is also a semi-static property (by [owl:restriction]{.HTML_Sample}). Location historic data may be available for such an Entity. -3. **Mobile:** Location property associated with such an Entity is also an instantaneous property (by [owl:restriction]{.HTML_Sample}). Location historic data may be available for such an Entity. +1. **Stationary:** Location property associated with such an Entity is also a static property (by [owl:restriction]{.HTML-Sample}). +2. **Movable:** Location property associated with such an Entity is also a semi-static property (by [owl:restriction]{.HTML-Sample}). Location historic data may be available for such an Entity. +3. **Mobile:** Location property associated with such an Entity is also an instantaneous property (by [owl:restriction]{.HTML-Sample}). Location historic data may be available for such an Entity. ### 6.3.2 Properties @@ -155,15 +155,15 @@ This distinction may be useful within some applications for defining error/promp Like mobility, this property distinction also allows implementations to control historic data storing behaviour. -[StateProperty]{.HTML_Sample}**:** in the formal acceptation of dynamical system theory, a [StateProperty]{.HTML_Sample} captures a component of the state of a system represented by the corresponding Entity, in the sense that it memorizes/summarizes past interactions between this system and its environment ("inputs" to the system), in a way that is *sufficient to adequately predict future states of this system, given present and future inputs*. This is related to the notion of "statefulness" used in computer science, yet the state thus maintained is defined as an abstraction of the state to the physical system being represented, not a purely informational construct. This property does also capture the necessary differentiation between the state properties of a system and other "stateless" data streams like sensor readings. +[StateProperty]{.HTML-Sample}**:** in the formal acceptation of dynamical system theory, a [StateProperty]{.HTML-Sample} captures a component of the state of a system represented by the corresponding Entity, in the sense that it memorizes/summarizes past interactions between this system and its environment ("inputs" to the system), in a way that is *sufficient to adequately predict future states of this system, given present and future inputs*. This is related to the notion of "statefulness" used in computer science, yet the state thus maintained is defined as an abstraction of the state to the physical system being represented, not a purely informational construct. This property does also capture the necessary differentiation between the state properties of a system and other "stateless" data streams like sensor readings. -The [StateProperty]{.HTML_Sample} class is disjoint with the [Static]{.HTML_Sample} property class. A state property cannot be static since it represents a property that, by its very nature, changes with time. There are two types of state properties [i.4]: +The [StateProperty]{.HTML-Sample} class is disjoint with the [Static]{.HTML-Sample} property class. A state property cannot be static since it represents a property that, by its very nature, changes with time. There are two types of state properties [i.4]: -1. [ContinuousTime]{.HTML_Sample} (e.g. Car position): Such properties shall correspond to ContinuousValue system states. +1. [ContinuousTime]{.HTML-Sample} (e.g. Car position): Such properties shall correspond to ContinuousValue system states. -6. [DiscreteTime]{.HTML_Sample} (e.g. Occupancy of a parking place): DiscreteTime systems in general may have state properties whose value may be either ContinuousValue or DiscreteValue. Event-driven discrete time systems, which are the most usual case addressed in computer-controlled cyber-physical systems, have discrete value states. +6. [DiscreteTime]{.HTML-Sample} (e.g. Occupancy of a parking place): DiscreteTime systems in general may have state properties whose value may be either ContinuousValue or DiscreteValue. Event-driven discrete time systems, which are the most usual case addressed in computer-controlled cyber-physical systems, have discrete value states. ### 6.3.3 Location (Property or Relationship) @@ -173,7 +173,7 @@ The [StateProperty]{.HTML_Sample} class is disjoint with the [Static]{.HTML_Samp Our cross-domain meta-model differentiates between three notions of location: -1. **Geographic Location (GeoProperty):** More generally, this is a special case of[ CoordinateBasedLocation]{.HTML_Sample}. There are many standards/ontologies that allow expressing geographic location data. Since the NGSI-LD API uses JSON-LD as a main serialization format, the **geoJSON** standard is used for geographic location expressions. Only the specified GeoProperties represented in geoJSON can be used in geographic queries of the NGSI-LD API. Other standards/ontologies may be more expressive in terms of vocabulary (e.g. OGC standards). While these are not promoted as main methods for representing location, they can be mapped as subclasses of the **Geographic Location** class in order to utilize their rich vocabulary. +1. **Geographic Location (GeoProperty):** More generally, this is a special case of[CoordinateBasedLocation]{.HTML-Sample}. There are many standards/ontologies that allow expressing geographic location data. Since the NGSI-LD API uses JSON-LD as a main serialization format, the **geoJSON** standard is used for geographic location expressions. Only the specified GeoProperties represented in geoJSON can be used in geographic queries of the NGSI-LD API. Other standards/ontologies may be more expressive in terms of vocabulary (e.g. OGC standards). While these are not promoted as main methods for representing location, they can be mapped as subclasses of the **Geographic Location** class in order to utilize their rich vocabulary. diff --git a/history.md b/history.md index 1f6bed9..d5339d4 100644 --- a/history.md +++ b/history.md @@ -3,6 +3,7 @@ ::: ondemand_PAR_alignment_CENTER_space_before_3_space_after_3 +:-----------------------:+:-----------------------:+:-----------------------:+ | **[Document history]{.ondemand_CHAR_size_12}** | + +-------------------------+-------------------------+-------------------------+ | V1.1.1 | July 2019 | Publication | +-------------------------+-------------------------+-------------------------+ @@ -10,4 +11,5 @@ +-------------------------+-------------------------+-------------------------+ | V1.3.1 | March 2024 | Publication | +-------------------------+-------------------------+-------------------------+ + ::: -- GitLab From 5e611d153db69ab8f8c6d88efad5476cc5987a81 Mon Sep 17 00:00:00 2001 From: Marco Cavalli Date: Tue, 23 Sep 2025 06:43:41 +0000 Subject: [PATCH 3/3] fix: remove space from ":" --- clause-5.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/clause-5.md b/clause-5.md index fb61d00..8e37028 100644 --- a/clause-5.md +++ b/clause-5.md @@ -123,14 +123,14 @@ SELECT ?R WHERE { For targeting directly the query to the object of "monitors" instead of the value of the coverage of the monitoring, the [owl:propertyChainAxiom]{.HTML-Sample} is used as follows: ``` json -: monitors owl:propertyChainAxiom (:monitors:hasObject). +: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. ``` json SELECT ?S where { -:CameraA : monitors ?S.} +:CameraA :monitors ?S.} ``` ## 5.3 Formal definition -- GitLab