7.10 Semantic Validation

7.10.1 Introduction

The <semanticDescriptor> resource contains a descriptor attribute which can store any RDF triples as the semantic description (i.e. annotation) of the associated resource (usually the parent resource of the <semanticDescriptor>). In the same time, <semanticDescriptor> resource may also contain an ontologyRef attribute, which is a reference (URI) of the ontology used to represent the information that is stored in the descriptor attribute. Normally, the triples stored in the descriptor attribute should be compliant with the ontology referenced by the ontologyRef attribute. However, there is no guarantee that an issuer (e.g. an AE) which creates or updates the <semanticDescriptor> will always provide the consistent information. In case the semantic description (as triples in descriptor attribute) is not compliant with the referenced ontology, it basically means the <semanticDescriptor> is not valid and cannot be used by the AE and/or CSE properly e.g. for semantic query or reasoning.

To solve the potential inconsistency between the <semanticDescriptor> resources and the referenced ontology, two message flows of semantic validation are specified in the following clauses.

7.10.2 Semantic validation independent of <semanticDescriptor> resource operation

Figure 7.10.2-1: Message flow for semantic description validation independent
of <semanticDescriptor> resource operation

Editor's Note: Replace with PlantUML Diagram

This flow can be used independent of <semanticDescriptor> resource operation. For example, an AE can validate a <semanticDescriptor> resource after retrieving it from a hosting CSE, so as to ensure the validity of the RDF triples in the retrieved resource before using it in the application layer process (e.g. reasoning). An AE or a CSE may also choose to validate a <semanticDescriptor> resource representation before actually creating it in the oneM2M system.

This flow can also be used as a part of the semantic validation procedure during a <semanticDescriptor> resource Create or Update operation as specified in clause 7.10.3.

Step 1. The Issuer (e.g. an AE or CSE) shall send a semantic validation request to the ontology hosting CSE of the referenced ontology according to ontologyRef attribute of the <semanticDescriptor> resource to be validated. The request shall be an Update request addressing the <semanticValidation> virtual resource of the ontology hosting CSE as specified in oneM2M TS-0001 [1]. It shall contain the <semanticDescriptor> resource representation to be validated, which includes the semantic description (descriptor attribute), the URI of the referenced ontology (ontologyRef attribute) against which to validate, and potentially URIs (relatedSemantics attribute, or triples with annotation property_m2m:resourceDescriptorLink_ in the_descriptor_ attribute) to other linked <semanticDescriptor> resources that are also incorporated for validation.

Step 2. After receiving the semantic validation request, the ontology hosting CSE shall retrieve any linked <semanticDescriptor> resources (including the semantic description - descriptor and the URI of the referenced ontology - ontologyRef) according to the relatedSemantics attribute and triples with annotation property m2m:resourceDescriptorLink in the_descriptor_ attribute of the <semanticDescriptor> resource in the request. In case the linked <semanticDescriptor> resources are further linked to more <semanticDescriptor> resources, the ontology hosting CSE shall repeat this step iteratively to retrieve all linked <semanticDescriptor> resources. In case the ontology hosting CSE cannot retrieve the linked <semanticDescriptor> resources (due to access right control or other exceptional reasons) within a reasonable time (according to local policy), skip Step 3.

Step 3. The ontology hosting CSE shall use the referenced ontologies (indicated by the ontologyRef attribute) of the received <semanticDescriptor> resource and the linked <semanticDescriptor> resources to validate the semantic description of the received <semanticDescriptor> resource and the linked <semanticDescriptor> resources all together. The aspects to be checked in semantic validation is specified in clause 7.10.4.

Step 4. The ontology hosting CSE shall return the validation response to the Issuer. In case Step 3 succeeds, the response code shall indicate success of validation, otherwise (including Step 3 is skipped due to Step 2 fails), the response shall indicate failure of validation.

7.10.3 Semantic validation triggered when Create or Update a <semanticDescriptor> resource

Editor's Note: Replace with PlantUML Diagram

Figure 7.10.3-1: Message flow for semantic description validation triggered by <semanticDescriptor> resource Create/Update

Step 1. The issuer shall send a Create or Update request to the hosting CSE of a <semanticDescriptor> resource (called <semanticDescriptor> hosting CSE). The request shall contain the <semanticDescriptor> resource representation, which includes a validationEnable attribute (set to 'true') to trigger the semantic validation process, the semantic description (descriptor attribute), the URI of the referenced ontology (ontologyRef attribute) against which to validate, and potentially URIs (relatedSemantics attribute, or triples with annotation property_m2m:resourceDescriptorLink_ in the_descriptor_ attribute) to other linked <semanticDescriptor> resources that are also incorporated for validation.

Step 2. After receiving the request, the <semanticDescriptor> hosting CSE shall firstly check if semantic validation is needed according to the value of the validationEnable attribute. If true, it shall further check if the addressed <semanticDescriptor> resource is linked to any other remote <semanticDescriptor> resources according to the URIs in the relatedSemantics attribute or triples with annotation property m2m:resourceDescriptorLink in_descriptor_ attribute. If no, the procedure goes to Case 1 (Step 3a to 4a ), otherwise, goes to Case 2 (Step 3b to 6b ).

Note

The <semanticDescriptor> hosting CSE may override the value of the validationEnable attribute according to its local policy so as to enforce or disable the following semantic validation procedures regardless of the requested value from the issuer.

Case 1: stand-alone <semanticDescriptor>

Step 3a. The <semanticDescriptor> hosting CSE shall retrieve the referenced ontology representation according to the URI in the ontologyRef attribute of the addressed <semanticDescriptor> resource from the ontology hosting CSE (which hosts the referenced ontology). In case the ontology representation cannot be retrieved (due to access right control or other exceptional reasons), skip Step 4a.

Step 4a. The <semanticDescriptor> hosting CSE shall use the retrieved referenced ontology to validation the semantic description (the triples in descriptor attribute) of the addressed <semanticDescriptor> resource. The aspects to be checked in semantic validation is specified in clause 7.10.4.

Case 2: linked <semanticDescriptor>

Step 3b. This step shall follow Step 1 of figure 7.10.2-1, wherein the <semanticDescriptor> hosting CSE shall act as the Issuer and the <semanticDescriptor> resource to be validated is the addressed <semanticDescriptor> resource in the received Create or Update request.

Step 4b. This step shall follow Step 2 of figure 7.10.2-1.

Step 5b. This step shall follow Step 3 of figure 7.10.2-1.

Step 6b. This step shall follow Step 4 of figure 7.10.2-1, wherein the response is sent to the <semanticDescriptor> hosting CSE.

Step 7. The <semanticDescriptor> hosting CSE shall perform the normal operation (Create or Update) on the addressed <semanticDescriptor> resource according to the original request from the issuer. In addition, based on the validation result of Step 4a (in Case 1 ) or the validation response received in Step 6b (in Case 2 ), The <semanticDescriptor> hosting CSE shall update the semanticValidated attribute properly to reflect the validation status (validated or not) of the addressed <semanticDescriptor> resource accordingly. If Step 4a is skipped due to Step 3a fails, it's also considered as not validated.

Step 8 . The <semanticDescriptor> hosting CSE shall return the operation (Create or Update) response to the issuer.

7.10.4 Aspects to be checked in semantic validation

Several aspects shall to be checked in order to make sure that the content of descriptor attribute of <semanticDescriptor> resource consists of valid RDF triples and they are indeed capable of interoperating semantically with other oneM2M resources. Taking into account the nature of semantically annotated data, three levels of validation can be distinguished:

1. Lexical check. This level of check consists of verifying the correctness of RDF serialization regarding to the declared type. For example, the <semanticDescriptor> resource is marked in XML representation (according to the descriptorRepresentation attribute) whereas the semantic annotation (in the descriptor attribute) is indeed serialized in JSON, or the XML document contains some error that causes parse error, the lexical check fails.

2. Syntactic checks. After the basic lexical checks, the syntactic check consists of verifying the correctness of the "syntax" of the RDF triples represented by the underlined serialization format, more specifically:

   • a) Untyped of resources and literals. Here resource refers to instances of a class, and literal refers to a textual or numerical value. The type of resource or literal is the link of an annotation back to the ontology which enables the semantic capabilities. Any un-typed element presented in an annotation is problematic towards the semantic interoperability.
   • b) Ill-formed URIs. URI is essential and critical for identification of a resource. They shall be checked against RFC3968 which defines the generic syntax of URI.
   • c) Problematic prefix and namespaces. Namespaces play the role of linking the annotation to the reference ontologies and vocabularies, and it shall be consistent with ontologyRef attribute. If the URI of the namespace is problematic (e.g. wrong URI, URI contains illegal character), it may cause others to mis-interpret the data semantics and types. Prefix is a unique reference to replace the namespaces in the local file. A one-to-one mapping between the prefix and namespace is essential and shall be checked to ensure a correct reference.
   • d) Unknown classes and properties. A prerequisite of semantic interoperability is that all the resources use a common and agreed vocabulary. As consequence, if any resource uses in its annotation a class or property that is not defined in the reference ontology(ies), other resources would have no way to understand it, so that the semantic interoperability is impossible.

3. Semantic checks. Following a successful syntactic validation, the semantic check consists of verifying the logical consistence of the semantic annotation regarding to the reference ontology(ies):

   • a) Cardinality inconsistency :

     • i) Inconsistency of object properties. If the ontology defines that class A has an object property that can have one and only one instance of class B, and in the annotation, there are two instances of B related to one instance of A, there is a problem.
     • ii) Inconsistency of data properties. If the ontology defines that class A has a data property that can have one and only one data value, and in the annotation, there are two instances of the data properties of different value, there is a problem.

   • b) Problematic relationship or inheritance. Following the relationship defined in the reference ontology, if an instance of a class A is wrongly annotated to be at same time an instance of class B which is disjoint from class A, there is a conflict and the instance cannot be resolved by the semantic engine. A concrete example in detailed in clause 8.3.1 in oneM2M TR-0033 [i.3].

   • c) Remaining dependencies. If deleting a property of an instance of a class for which this property is mandatory, there is a problem.

The validation response returned to the issuer depends on the result of each of the above tests. To conclude that an annotation is validated, a complete check of all the above checks shall to be performed and passed. However, as several tests are independent from others (for example, 3.a and 3.b do not have an impact on each other), several "validated profiles" may be defined as a subset of all the aspects to be checked.