This clause specifies functional operations of semantic functions including access control, semantics annotation, semantic filtering and discovery, semantic queries and query scope, semantics reasoning, semantics mashup, semanticsbased data analytics, ontology management, and semantics validation. Some of these functional operations are based on the basic resource procedures as specified in clause 6.
7.2 Access Control
7.2.1 Direct ACP control via semantic graph store
7.2.1.1 Introduction
When realizing semantic functionalities and operations (e.g. semantic resource discovery or semantic query), a centralized Semantic Graph Store (SGS) can be used in the system to store RDF triples which are collected from the resources distributed in the resource tree. However, oneM2M uses resources to define Access Control Policies (ACP) and those resources are hosted in the resource tree and referred/used by other resources through accessControlPolicyIDs attribute. In other words, any resource accesses (e.g. CRUD or discovery) to a specific resource shall be compliant to certain access control policies as specified by the accessControlPolicyIDs attribute of this resource. Since resources have their own access control policies as defined in the accesscontrolPolicyIDs attribute, semantic operations to be executed directly on the RDF triples stored at the SGS shall follow those access control policies in the sense that RDF triples from certain resources shall not be used or involved in a semantic operation processing if it is not allowed by the corresponding access control policies.
Figure 7.2.1.1‑1 gives an example of an access control policy for two resources, where there are two access control policies (i.e. and ). The access to is controlled by and , while the access to is only controlled by .
In direct ACP control via semantic graph store, access control for any semantic operation (e.g. semantic resource discovery, semantic query, etc.) shall be directly enforced in the SGS. For this purpose, the following types of semantic triples shall be generated according to the oneM2M resource tree (i.e. and resources) and added to the SGS before the semantic operation is executed at the SGS; in addition, those four types of semantic triples shall be synchronized with the oneM2M resource tree (i.e. changes on or related to and resources):
SD Original Triples: RDF triples or other semantic representation contained in the descriptor attribute of a resource. In addition, the relationship between a resource and its resource and its accessControlPolicyIDs shall be represented in a semantic form and stored in the SGS.
SD Relationship Triples: RDF triples or other semantic representation used to describe the belonging relationship between each SD Original Triple (i.e. contained in the descriptor attribute of a resource) and the corresponding resource.
ACP-SD Binding Triples: RDF triples or other semantic representation used to describe which shall be applied to which (i.e. the binding relationship between a resource and its accessControlPolicyIDs attribute). For oneM2M, such binding relationship shall be obtained from the resource 's accessControlPolicyIDs attribute.
ACP Triples: RDF triple or other semantic representation used to describe ACP policies/rules (as defined in resources) for semantic resources (e.g. ).
Overall, direct ACP control via the SGS shall consist of the following tasks:
Task 1: Store SD Original Triples in the SGS. Generate SD Relationship Triples, store them in the SGS. This task is detailed in clause 7.2.1.2.
Task 2: Generate ACP-SD Binding Triples and ACP Triples; store them in the SGS. This task is detailed in clause 7.2.1.3.
Task 3: Conduct semantic operations with direct ACP control in the SGS. Semantic operations are conducted with the selected semantic triples which are associated with the Access Control Rules allowing the Originator to operate (which is based on the work of Task 1 and Task 2). This task is detailed in clause 7.2.1.4.
Task 4: Synchronize ACP Triples, ACP-SD Binding Triples, SD Relationship Triples, and SD Original Triples as stored in the SGS with any updated and/or resources in the oneM2M resource tree. This task is detailed in clause 7.2.1.5.
7.2.1.2 Create SD relationship triples
Access control policies for a resource have been defined in its accesscontrolPolicyIDs attribute. In other words, the granularity for defining ACP is on a resource-level in the sense that all the RDF triples stored in the descriptor attribute of the resource should be compliant to the same ACP as specified by the accessControlPolicyIDs attribute of this resource. However, when those RDF triples (i.e. SD Original Triples) are copied to the SGS, they are not stored under any resource/attribute anymore which is different than the way oneM2M resource tree works. Therefore, a way is needed to re-represent the association relationship between a SD Original Triple and its resource in SGS in order to perform the same ACP enforcement directly in the SGS. In other words, SD Relationship Triples shall be generated and stored in the SGS.
In order to do so, an internal ontology (referred to as Semantic Descriptor Ontology) with two classes semanticDescriptor and atomDescription, and several properties describedIn, hasSubject, hasObject and hasProperty shall be used (see Figure 7.2.1.2‑1). Note that the class semanticDescriptor is the concept to model a resource, while atomDescription is used to model a SD Original Triple; the atomDescription has four properties describedIn, hasSubject, hasObject and hasProperty . For example, for a triple like "classX propertyY classZ " stored in a resource (which is termed as SD Original Triple), the following association triples shall be created for building the association and stored in the SGS; those association triples are termed as SD Relationship Triples.
7.2.1.3 Create ACP triples and ACP binding triples
7.2.1.3.1 Access Control Ontology
In order to represent an ACP in a semantic form, the Access Control Ontology is introduced, which is shown in Figure 7.2.1.3.1‑1. This ontology is defined by following how an oneM2M resource is specified in oneM2M TS-0001 [1], where an access-control-rule-tuple consists of parameters such as accessControlOriginators, accessControlOperations, and accessControlContexts. Accordingly, this ontology defines two new classes:
accessControlPolicy; and
accessControlRule.
In addition, five new properties (i.e. hasACPRule, hasACOriginator, hasACOperations, hasACContexts and appliedTo) are defined. More details about those terms are introduced as follows:
The property hasACPRule is used to link an accessControlPolicy instance with an accessControlRule instance. Properties hasACOriginator, hasACOperations and hasACContexts (optional) basically describe an accessControlRule instance and are used to specify who shall issue what operations under which conditions. As these triples describe the ACP themselves, they are referred to as ACP Triples.
The property appliedTo is used to describe which resource an accessControlPolicy instance shall be applied to. As these triples bind and , they are referred to as ACP-SD Binding Triples.
Figure 7.2.1.3.2‑2 describes an example of ACP Triples and ACP-SD Binding Triples in the SGS, based on the resource example shown in Figure 7.2.1.1‑1 and the Access Control Ontology defined in Figure 7.2.1.3.1‑1. In this example, there are two patients Jack and Alice; their doctors are John and Steve, respectively. There are three blood pressure meansurement samples (i.e. Sample1 for Jack, Sample2 and Sample3 for another patient3). Corresponding triples are shown in black text in Figure 7.2.1.3.2‑2, which are generated based on the eHealth Ontology Reference Model in Figure 7.2.1.3.2‑1.
The triples in red text in Figure 7.2.1.3.2‑2 are added for access control purpose according to the proposed Access Control Ontology model in Figure 7.2.1.3.1‑1, when new ACPs are created or updated. In this example, it is assumed two access control polices be created. First, two resources are described (i.e. semanticDescriptor1 contains Sample1 and Sample2, while semanticDescriptor2 contains Sample3. Then, two access control policies are defined (i.e. accessControlPolicy1 is applied to semanticDescriptor1, while accessControlPolicy2 is applied to both semanticDescriptor1 and semanticDescriptor2). Next, the detailed Access Control Rules for accessControlPolicy1 and accessControlPolicy2 are described:
accessControlPolicy1 has two accessControlRules, which states that 1) AE-ID-1, AE-ID-2, and AE-ID-3 can RETRIEVE and DISCOVER triples in the semanticDescriptor which accessControlPolicy1 is applied to (i.e. semanticDescriptor1); 2) AE-ID-1 and AE-ID-3 can CREATE, UPDATE, or DELETE triples in the semanticDescriptor which accessControlPolicy1 is applied to (i.e. semanticDescriptor1).
For accessControlPolicy2, only one accessControlRule is defined; this accessControlRule states that AE-ID-1 and AE-ID-2 can DISCOVER triples in the semanticDescriptor which accessControlPolicy2 is applied to (i.e. semanticDescriptor1 and semanticDescriptor2).
7.2.1.4 Conduct semantic operations with direct ACP control
This clause is to introduce more details on implementing Task-3 as discussed in clause 7.2.1.1. This clause uses semantic query as an example of semantic operatoins to be excuted with direct ACP control in the SGS.
When the Hosting CSE receives a SPARQL query from the Originator, it shall:
add the access control related patterns according to the ID of the Originator and the request operation to be conducted (e.g. semantic discovery) into the received SPARQL statement;
add ACP-SD binding related patterns into the received SPARQL statement (i.e. constraints on ACP-SD Binding Triples). For each triple pattern contained in the original SPARQL query statement, a new ACP-SD binding triple pattern shall be added;
add SD relationship related patterns (i.e. constraints on SD Relationship Triples) to the received SPARQL statement. For each triple in the original SPARQL query statement, four new triple patterns shall be added to describe the SD relationship; and
execute the revised SPARQL statement to make query on the SGS.
For example, in the scenario of the example in Figure 7.2.1.3.2‑2, when AE-ID-3 sends the following SPARQL query request to the Hosting CSE:
The Hosting CSE shall add some access control related statements according to the ID (i.e. AE-ID-3) of the Originator and the request operation (i.e. DISCOVERY) of the query, the revised SPARQL query is given as below (red text for ACP constraints, blue text for ACP-SD binding constraints, and orange text for SD relationship constraints):
Next, the revised SPARQL query statement is excuted within the SGS. Since ACP have already been reprensented in a semantical form, the query result of the revised SPARQL query is the desried result with enforced direct acceess control. Figure 7.2.1.4‑1 shows the SPARQL query result in the above example over the eHealth SGS in Figure 7.2.1.3.2‑2. According to the access control triples added to the SGS (i.e. red text in Figure 7.2.1.3.2‑2), AE-ID-3 is only allowed to DISCOVER samples included in semanticDescriptor1 (i.e. Sample1 and Sample2). As a result, the returned result for SPARQL query in Figure 7.2.1.4‑1 presents the selected content of Sample1 and Sample2.
Figure 7.2.1.4‑1: Example for eHealth semantic query result with access control
Figure 7.2.1.4‑1: Example for eHealth semantic query result with access control
7.2.1.5 Synchronization ACP triples and SD-related triples in the SGS with the resource tree
7.2.1.5.1 Introduction
When making ACP policies/rules be also available in a semantical form (i.e. ACP Triples) in the SGS for supporting direct access control, synchronization between resources at the Hosting CSE and ACP Triples at the SGS is required. Depending on different cases, the Hosting CSE shall perform the following tasks in order to maintain such synchronization:
When a new resource is created, the Hosting CSE shall generate new ACP Triples according to the ACP ontology and stores these new ACP Triples in the SGS (see clause 7.2.1.5.2).
When the privileges attribute of an existing resource is updated, the Hosting CSE shall generate new ACP Triples and update corresponding old ACP Triples at the SGS accordingly (see clause 7.2.1.5.3).
When an existing resource is deleted, the Hosting CSE shall remove the corresponding ACP Triples at the SGS (see clause 7.2.1.5.4).
Similar to ACP Triples, others such as SD Original Triples, SD Relationship Triples, and ACP-SD Binding Triples shall be synchronized. Depending on different cases, the Hosting CSE shall perform the following tasks in order to maintain such synchronization:
When a is created:
In this case, the Hosting CSE shall generate SD Relationship Triples and ACP-SD Binding Triples and then store them in the SGS (see clause 7.2.1.5.5).
When the accessControlPolicyIDs attribute of a resource changes:
In this case, the Hosting CSE shall generate new ACP-SD Binding Triples and use them to update corresponding old ACP-SD Binding Triples in the SGS. This case may apply also when the accessControlPolicyIDs attribute of the parent changes (see clause 7.2.1.5.6).
When the descriptor attribute of a resource changes:
In this case, the Hosting CSE shall generate new SD Relationship Triples and use them to update old SD Relationship Triples in the SGS (see clause 7.2.1.5.7).
When a resource is deleted:
In this case, the Hosting CSE shall delete all corresponding SD Original Triples, SD Relationship Triples and ACP-SD Binding Triples from the SGS (see clause 7.2.1.5.8).
7.2.1.5.2 Procedure for creating ACP triples when a new resource is created
Figure 7.2.1.5.2‑1 illustrates the procedure for creating ACP Triples in SGS, which is triggered when an Originator requests to create a new resource at the Hosting CSE.
The following steps shall be performed:
Step 1: The Originator sends a request to create a new resource to the Hosting CSE. This message contains the representation of to be created (e.g. the value of privileges attribute).
Step 2: The Hosting CSE receives the request in Step 1 and, subject to the Originator access rights verification, shall create the requested resource.
EXAMPLE 1: Assume be the newly created ACP resource and its URI "acp1URI". Assuming has one access control rule (e.g. acr11) and the URI of the corresponding privileges attribute is "acr11URI". For exemplification, assume also that acr11 allows an AE ("AE-ID-1") to perform DISCOVERY operations.
Step 3: The Hosting CSE sends a response to the Originator.
EXAMPLE 2: If Step 1 was successful, "acp1URI" will be contained in this response message.
Step 4: The Hosting CSE generates corresponding ACP Triples based on the content of and the ACP ontology.
EXAMPLE 3: An example of ACP Triples for resource created in Step 1 is illustrated in Figure 7.2.1.5.2‑2.
line#1 defines prefix "acp" which will used in lines #2-#6.
line#2 defines a new acp:accessControlPolicy class instance for resource. The subject value of this triple (i.e. acp:acp1) is "acp1URI", therefore the subject value of this triple makes it possible to locate the corresponding resource . The Hosting CSE shall also use "acp1URI" to locate corresponding triples in the SGS (e.g. when updating existing ACP Triples).
line#3 defines that acp:acp1 instance has an associated access control rule acr11. The object value of this triple (i.e. acp:acr11) is "acr11URI", therefore the object value of this triple, makes it possible to locate the corresponding privileges attribute of resource. The Hosting CSE shall use "acr11URI" to locate the corresponding triples in the SGS (e.g. when updating existing ACP Triples). resource. The Hosting CSE shall use "acr11URI" to locate the corresponding triples in the SGS (e.g. when updating existing ACP Triples).
line#4 defines that acp:acr11 (i.e. the object on line#3) is an acp:accessControlRule class instance.
line#5 and line#6 give the values of two properties of acp:acr11 based on the assumptions in this example.
NOTE: The triples on lines #4-#6 define the access control rule acr11. If has more access control rules, additional access control rules will be defined similarly to those on lines #4-#6.
Optionally: The Hosting CSE may add the address of the SGS to the resource created in Step 2 in a new attribute, to enable direct addressing of the triples.
Step 5: The Hosting CSE sends a SPARQL request to store the ACP Triples created in Step 4 to the selected SGS.
EXAMPLE 4: The ACP Triples shown in Figure 7.2.1.5.2‑2 will be contained in the SPARQL request.
Step 6: The SGS receives the SPARQL request, processes it and saves the ACP Triples into its graph store.
Step 7: The SGS sends a response back to the Hosting CSE to confirm the request in Step 6 is successfully executed.
Editor's Note: This seems to be the wrong diagram. It is the same as Figure 7.2.1.5.3‑1. This one should be about CREATE, not UPDATE.
It is already the wrong diagram in R3 of the spec.
Figure 7.2.1.5.2‑2: Example ACP triples corresponding to resource resource
Figure 7.2.1.5.2‑2: Example ACP triples corresponding to resource resource
7.2.1.5.3 Procedure for updating ACP triples when an existing resource is updated
The procedure for updating ACP Triples in a SGS follows a similar flow to the procedure used when a new resource is created. In this case the Originator requests to update the privileges attribute of an existing resource, as shown in Figure 7.2.1.5.3‑1.
NOTE: This procedure applies also for updates of the accessControlPolicyIDs attribute of the resource.
The following steps shall be performed:
Steps 1 - 3: Similar to those describing Figure 7.2.1.5.2‑1, but reflecting normal processing of an UPDATE operation. In this case the Originator triggers an update of the privileges attribute of an existing .
Step 4: Based on the new value of the privileges attribute the Hosting CSE generates new ACP Triples
EXAMPLE 1: Assume the Originator aims to update the privileges attribute of resource from "DISCOVERY" to "DISCOVERY" and "RETRIEVE" as the new accessControlOperations . To implement these changes in Figure 7.2.1.5.2‑2 the Hosting CSE can simply add a new triple e.g. acp:acr11 acp:hasACOperations "RETRIEVE". Alternatively, the Hosting CSE can replace the triple on Line#6 to the new triple acp:acr11 acp:hasACOperations "DISCOVERY", "RETRIEVE".
Step 5: The Hosting CSE sends a SPARQL request to the SGS to update existing ACP Triples related to resource to reflect the update being requested: resource to reflect the update being requested:
EXAMPLE 2: As described in Step 4, there are two options to implement this.
The Hosting CSE adds a new triple with the following SPARQL request:
@PREFIX acp: .
INSERT DATA
{ acp:acr11 acp:hasACOperations "RETRIEVE". }
The Hosting CSE replaces Line#6 in Figure 7.2.1.5.1‑2 with the SPARQL request:
7.2.1.5.4 Procedure for deleting ACP triples when an existing resource is deleted
The procedure for deleting ACP Triples in a SGS follows a similar flow to the procedure used when a new resource is created. In this case, the Originator requests to delete an existing resource, as shown in Figure 7.2.1.5.4‑1.
The following steps shall be performed:
Steps 1 - 3: Similar to those describing Figure 7.2.1.5.2‑1, but reflecting normal processing of a DELETE operation. In this case the Originator triggers the deletion of an existing resource.
Step 4: The Hosting CSE shall send a SPARQL request to the SGS to delete existing ACP Triples
EXAMPLE: The following SPARQL request implements this request:
7.2.1.5.5 Procedure for creating ACP-SD binding triples and SD relationship triples in SGS
Figure 7.2.1.5.5‑1 illustrates the procedure for creating ACP-SD Binding Triples and SD Relationship Triples in SGS, which shall be triggered when an Originator requests to create a new resource.
After checking the access rights and other related security functions, the Hosting CSE shall create the resource locally (referred to as sd1 and its URI assumed to be sd1URI). Then, the Hosting CSE shall store all semantic triples as described in the descriptor attribute of SD1 resource to the SGS. More importantly, the Hosting CSE shall generate new SD Relationship Triples and ACP-SD Binding Triples and shall store them to the SGS as well. Note that if sd1 has no accessControlPolicyIDs attribute, ACP-SD Binding Triples shall not be generated.
The following steps shall be performed:
Step 1: The Originator sends Create _<semanticDescriptor>_ Resource request to the Hosting CSE. It is assumed that the value of descriptor attribute and accessControlPolicyIDs attribute of resource will be given in this request message:
Assume the descriptor attribute contains only one SD Original Triple "S1 P1 O1".
Assume the value of accessControlPolicyIDs is "acp1URI", i.e. the access control policy acp1 will be applied.
Step 2: The Hosting CSE accordingly creates the resource (referred to as sd1):
Assume its URI is sd1URI.
Step 3: The Hosting CSE sends a response to Originator to inform it if Step 2 is successfully completed.
Step 4: Bases don the SD Original Triple contained in the descriptor attribute of sd1, the Hosting CSE generates SD Relationship Triples.
In our example, there is only one SD Original Triple, as shown below:
Step 6: The Hosting CSE sends a SPARQL request to the SGS to store these SD Relationship Triples and ACP-SD Binding Triples to the SGS.
Step 7: The SGS processes the SPARQL request and store corresponding SD Relationship Triples and ACP-SD Binding Triples in the SGS.
Step 8: The SGS sends a response message to the Hosting CSE to inform it if the SPARQL request in Step 6 is successfully executed.
NOTE: If the resource being created in Step 2 does not have accessControlPolicyIDs attribute, the accessControlPolicyIDs attribute of the parent resource may be used or system default access privileges may be applied. The new ACP-SD Binding Triples will also be generated using either the parent resource's accessControlPolicyIDs attribute or based on the default privileges.
Figure 7.2.1.5.5‑1: Procedure for creating SD relationship triples and ACP-SD binding triples
Figure 7.2.1.5.5‑1: Procedure for creating SD relationship triples and ACP-SD binding triples
7.2.1.5.6 Procedure for updating ACP-SD binding triples in SGS
Figure 7.2.1.5.6‑1 shows the procedure for updating ACP-SD Binding Triples when the accessControlPolicyIDs attribute of a resource is updated. For example, assume the sd1 resource created earlier have its resource is updated. For example, assume the sd1 resource created earlier have its accessControlPolicyIDs changed from acp1 to acp2; with the ACP Triples for the resource acp2 as follows:
Step 1: The Originator sends a request to update the resource sd1's accessControlPolicyIDs from the URI of the resource acp1 to the URI of the resource acp2. The URI of the resource acp2 (i.e. acp2URI) is contained in this request. The URI of the resource sd1 (i.e. sd1URI) is also contained in this request.
Step 2: The Hosting CSE checks access rights. If it is allowed, the Hosting CSE updates sd1's accessControlPolicyIDs with acp2's URI given in Step 1.
Step 3: The Hosting CSE sends a response back to the Originator to inform it if the request in Step 1 is successful or not.
Step 4: Since the sd1's accessControlPolicyIDs is changed, the Hosting CSE generates a new ACP-SD Binding Triple ("acp:acp2 acp:appliedTo sd:sd1") to reflect this change. This new ACP-SD Binding Triple will replace the old ACP-SD Binding Triple (i.e. acp:acp1 acp:appliedTo sd:sd1):
Step 5: The Hosting CSE sends an SPARQL request to replace the old ACP-SD Binding Triple in the SGS with the new ACP-SD Binding Triple as shown in above Step 4. This SPARQL request for this example is shown below:
@PREFIX acp:
Step 6: The SGS processes the SPARQL request and updates the specified ACP-SD Binding Triples in Step 5.
Step 7: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 5 is successfully performed.
NOTE: If the accessControlPolicyIDs attribute of the resource was empty to start with, its parent resource's accessControlPolicyIDs may be enforced. The hosting CSE will apply this step based on updates to the accessControlPolicyIDs attribute of the parent resource.
Figure 7.2.1.5.6‑1: Procedure for updating ACP-SD binding triples in the SGS
Figure 7.2.1.5.6‑1: Procedure for updating ACP-SD binding triples in the SGS
7.2.1.5.7 Procedure for updating SD relationship triples in SGS
Figure 7.2.1.5.7‑1 shows the procedure for updating SD Relationship Triples when the descriptor attribute of a resource is changed. For example, the descriptor of the sd1 resource created earlier is changed to have two SD Original Triples (Old one - resource is changed. For example, the descriptor of the sd1 resource created earlier is changed to have two SD Original Triples (Old one - S1 P1 O1; New one - S2 P2 O2).
The following steps shall be performed:
Step 1: The Originator sends a request to update the resource sd1's descriptor to include one new SD Original Triple (i.e. S2 P2 O2). The URI of the resource sd1 (i.e. sd1URI) is also contained in this request.
Step 2: The Hosting CSE checks access rights. If it is allowed, the Hosting CSE updates sd1's descriptor attribute by adding one new SD Original Triple (i.e. S2 P2 O2).
Step 3: The Hosting CSE sends a response back to the Originator to inform it if the request in Step 1 is successful or not.
Step 4: The Hosting CSE generates new SD Relationship Triples below to reflect this change:
Step 5: The Hosting CSE sends an SPARQL request to replace old SD Relationship Triples and/or add new SD Relationship Triple in the SGS with the new SD Relationship Triple generated in above Step 4. This SPARQL request for this example is shown below:
@PREFIX acp:
Step 6: The SGS processes the SPARQL request and adds new SD Relationship Triples.
Step 7: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 5 is successfully performed.
NOTE: If an old SD Original Triple is removed or updated by a new SD Original Triple, the corresponding SD Relationship Triples related to this old SD Original Triple will be removed from the SGS.
The update of triples in the descriptor attribute may be performed also by targeting the semanticOpExec attribute of the parent resource with a SPARQL query; when this SPARQL query is executed, new SD Original Triples may be added to the descriptor attribute of the resource. In this case Steps 4 - 7 will be performed. More specifically, SPARQL Update consists of DELETE and ADD operations, so the SD relationship triples associated with the old original triples will be deleted, and the new ones stored.
Figure 7.2.1.5.7‑1: Procedure for updating SD relationship triples in the SGS
Figure 7.2.1.5.7‑1: Procedure for updating SD relationship triples in the SGS
7.2.1.5.8 Procedure for deleting SD relationship triples and ACP-SD binding triples in SGS
Figure 7.2.1.5.8‑1 shows a procedure for deleting SD Relationship Triples and ACP-SD Binding Triples from the SGS, which could be triggered by the Initiating AE/CSE or the Hosting CSE to delete a resource. For example, the sd1 resource created earlier is removed.
The following steps shall be performed.
Step 1: The Originator sends "Delete Resource" to the Hosting CSE to delete sd1 resource. The URI of sd1 resource (i.e. sd1URI) is contained in this request.
Step 2: The Hosting CSE deletes sd1 resource locally.
Step 3: The Hosting CSE sends a response to the Originator to inform it if the deletion request in Step 1 is successful.
Step 4: The Hosting CSE sends an SPARQL request to the SGS to remove SD Relationship Triples and ACP-SD Binding Triples related to sd1 resource. The SPARQL will look like:
@PREFIX acp:
Step 5: The SGS processes the SPARQL request in Step 4 and removes corresponding SD Relationship Triples and ACP-SD Binding Triples.
Step 6: The SGS sends a response to the Hosting CSE to inform it if the SPARQL request in Step 4 is successfully performed.
NOTE: Steps 4 - 6 will also be performed if a SPARQL query targeting the semanticOpExec attribute of a resource results in the deletion of existing SD Original Triples.
Figure 7.2.1.5.8‑1: Procedure for deleting SD relationship triples and ACP-SD binding triples from the SGS
Figure 7.2.1.5.8‑1: Procedure for deleting SD relationship triples and ACP-SD binding triples from the SGS
7.3 Semantics Annotation
Semantics annotation is defined as the process to add semantic content (i.e. ) to an oneM2M resource (not a resource) as its child resource. This child resource provides additional semantic information about the oneM2M resource. An AE or a CSE shall use the procedures specified in clause 6.1.2 "Create " to add child resource to an oneM2M resource to fulfill the semantics annotation. In addition, the AE or the CSE can also use the procedures specified in clause 6.1.4 "Update " to update an existing and in turn update semantics annotation. Semantics annotation can be conducted for a single data item (e.g. create a child resource for a resource); it can be also conducted for multiple data items or a data flow (e.g. create child resource for a resource).
7.4 Semantic Filtering and Discovery
7.4.1 Introduction
NOTE: In the following descriptions, the general term semantic resource is used to refer to resources and resources containing semantic information.
This clause describes semantic discovery procedures on semantic descriptions represented as RDF triples, given that an overall semantic description (logical tree) may be distributed across several semantic resources.
Semantic discovery procedures may be performed using RETRIEVE operations as follows:
Using resource
Targeting any resource other than :
The receiver begins processing the request by retrieving the resource of the request target and its descriptor attribute. Related semantic resources are discovered and accessed according to clause 7.4.2 or clause 7.4.3. The content of related descriptor attributes in the case of resources or content attributes in the case of resources are added to the content on which the SPARQL request is being executed. Depending on which of the options described in clauses7.4.2 or 7.4.3 is chosen, all potentially relevant semantic content is added before executing the SPARQL request or they are added when needed during the execution of the SPARQL request.
The resulting content subject to the SPARQL request is provided to the SPARQL engine for processing.
In this case the related semantic resources are the members of the resource parent of the targeted . Based on the memberID attribute of the parent resource all the related descriptors are discovered, and those on the resource all the related descriptors are discovered, and those on the hosting CSE are retrieved together.
If there are semantic resources stored on a different CSE, individual RETRIEVE requests are sent to each CSE for retrieving the external resources.
All semantic resources are retrieved based on the respective access control policies.
Once all of the related semantic resources have been accessed, the content of each semantic attribute is added to the content on which the SPARQL request is being executed.
The full/enlarged content subject to the SPARQL request is provided to the SPARQL engine for processing.
Not using resource
Given that an overall semantic description (logical tree) may be distributed across the semantic resources, there are two methods of constructing the logical tree in the scope of a semantic discovery targeting any resource other than :
If the attribute relatedSemantics is empty or does not exist, the "Annotation-based method" (using resourceDescriptorLink) detailed in clause 7.4.2 shall be used.
If the attribute relatedSemantics is not empty the "Resource link-based method" (using relatedSemantics) detailed in clause 7.4.3 shall be used.
7.4.2 Annotation-based semantic discovery method
In this option, the links to related semantic resources are encoded in the semantic description itself, which is encoded as RDF triples [64] logically structured as . For this purpose, an annotation property called onem2m:resourceDescriptorLink is introduced. It is formally specified as part of the oneM2M Base Ontology defined in [75] and can be used as a predicate in any RDF triple with any subject and without further relation to the oneM2M Base Ontology. Only the use of the onem2m namespace is required to uniquely identify the annotation property.
Whenever further information about a semantic instance is stored in another semantic resource, a new RDF triple onem2m:resourceDescriptorLink may be added to this semantic description, where is the URL of the other semantic resource containing additional information related to . If multiple resources contain relevant further information, these can be added to a resource and the then refers to the virtual then refers to the virtual resource of this group, which will be used for retrieving the aggregated information.
NOTE: The RDF triple syntax in this paragraph is only used for illustration purposes. The actual encoding of the RDF triples used in oneM2M is defined in oneM2M TS-0004 [3].
To make use of the onem2m:resourceDescriptorLink property, the evaluation of semantic queries formulated as SPARQL requests by the SPARQL engine has to be adapted in the following way:
The SPARQL request is executed on the content of the semantic description in the descriptor attribute of the semanticDescriptor resource.
For each semantic instance matched in the SPARQL request, it is checked whether one or more onem2m:resourceDescriptorLink annotations exist.
If this is the case, the execution of the SPARQL request is halted.
The semantic content of the semantic resource referenced by the onem2m:semanticDescriptorLink annotations is added to the content on which the SPARQL request is being executed. If the onem2m:semanticDescriptorLink annotation references a group, the additional semantic content is accessed by performing a retrieve request to the virtual resource referenced.
The execution of the SPARQL request is continued on the enlarged content.
7.4.3 Resource link-based method
In this option, the links to related semantic resources are specified in the relatedSemantics attribute.
Processing of the SPARQL engine procedures at the receiver :
The receiver retrieves the resource of the request target.
Based on the relatedSemantics attribute of the resource targeted, all the related semantic resources are discovered, as follows:
If the relatedSemantics attribute includes a list of links, each of the linked semantic resources are accessed based on the respective access control policies.
If the relatedSemantics points to a resource, the group members from the memberID attribute are used and each of them is accessed based on the respective access control policies.
Once all of the related semantic resources have been accessed, the content of each of the descriptor attribute is added to the content on which the SPARQL request is being executed.
The full/enlarged content subject to the SPARQL request is provided to the SPARQL engine for processing.
7.5 Semantic Queries and Query Scope
NOTE: In the following descriptions, the general term semantic resource is used to refer to ,, resources, resource containing semantic triples, and any other future resources containing semantic information (e.g. semantic content resources, etc.).
This clause describes semantic query procedures on semantic descriptions represented as RDF triples, given that an overall semantic description (i.e. a logical tree) may be distributed across several semantic resources.
In general, semantic queries enable the retrieval of both explicitly and implicitly derived information based on syntactic, semantic and structural information contained in data (such as RDF data). The result of a semantic query is the semantic information/knowledge for answering/matching the query. By comparison, the result of a semantic resource discovery is a list of identified resource URIs. Detailed comparison aspects between semantic query and semantic resource discovery are listed in table 7.5‑1.
Table 7.5‑1: Comparison between semantic query and semantic resource discovery
Aspects
Semantic Query
Semantic Resource Discovery
Objective
The objective of Semantic Query is extracting "useful knowledge" over a set of "RDF data basis".
Semantic resource discovery is targeted to discovery of resources for further resource use (e.g. CRUD operations).
Technical Focus
Semantic Query is a more advanced feature leveraging semantics to derive knowledge from distributed semantic descriptors, based on a query statement.
Semantic resource discovery is a resource-oriented feature to leveraging semantics to enable sophisticated resource discovery.
Result
The semantic query result (representing the derived "knowledge") is provided as semantic information to answer the query not limited to resources URIs.
The processed result of a semantic resource discovery is mainly to include a list of identified resource URIs.
A complete semantic query operation shall include the following steps:
Step 1 : The Originator shall be given or form a semantic query statement (i.e. using SPARQL) based on its needs.
Step 2 : The Originator shall form a RETRIEVE request including the semantic query statement in the semanticsFilter condition and shall set the "Semantic Query Indicator" parameter to "TRUE". The Originator shall send the RETRIEVE request to a Receiver.
Step 3 : The Receiver shall execute the semantic query statement contained in the received semantic query request, for which the following information shall be required: a) the semantic query statement which is received from the Originator; and b) the RDF data basis. The RDF data basis is composed of all the RDF triples in scope of the semantic query. The RDF data basis may be distributed in the resource tree and stored in different semantic resources. Therefore, the Receiver shall perform Semantic Graph Scoping (SGS) which is the process of establishing the "query scope", i.e. RDF data basis. An illustration of SGS is shown in Figure 7.5‑1 and with two approaches described later.
Step 4 : Once the RDF data basis is determined through the SGS process, the Receiver shall apply the semantic query statement to the RDF data basis, yielding the semantic query result.
Step 5 : The semantic query result shall be included in a response message and returned to the Originator.
Figure 7.5‑1: An Illustration of SGS in oneM2M Architecture
Figure 7.5‑1: An Illustration of SGS in oneM2M Architecture
The following two approaches may be used for the SGS process in Step 3 above, in order to decide the semantic query scope of the semantic query:
Approach-1: The scope of the semantic query is provided implicitly.
In Approach-1, a semantic query request message targets any resource (i.e. as specified by the "To " parameter) and the semantic query shall be executed relative to this target resource, similarly to other request messages. The scope of the semantic query is formed through the aggregation of the semantic contents of the target resource's descendants. All the contents of semantic resource descendants of the target resource shall form the RDF data basis for this semantic query to be executed on. Thus, by targeting a oneM2M regular resource in the resource tree, the scope of the semantic query is implicitly decided as discussed above.
Approach-2: The scope of the semantic query is provided explicitly.
In Approach-2 the relevant semantic resources are the members of a resource. The scope of the semantic query is formed through the aggregation of the semantic contents of all the group members. In this approach, the request targets the (as specified by the "To" parameter), i.e., the child resources of the resource. As a result, this resource explicitly specifies the RDF data basis of the semantic query (i.e. the scope is explicitly defined by the semantic resources which are the members of the resource).
When the semantic query scope is explicitly defined by the resource, the processing stage can be decoupled from the SGS process. For example, without processing any semantic query, the Receiver (e.g. a CSE) may proactively aggregate relevant semantic resources together using a resource. The Originator may first discover various resources and select the one with the desired RDF data basis, before launching a semantic query request. For example, the child resource of 1> 1_>_ resource may indicate that this group resource includes all the devices deployed in Building-1. The Originator, whose query is to be limited to Building-1, may then send its semantic query request to the child resource of the 1> 1_>_ resource.
In Approach-2, the SGS processing (included in step 3 above of the sematic query flow) shall include the following steps:
The Receiver of the semantic query request targeting a resource shall use the memberIDs attribute of the parent resource to retrieve all the related semantic information. If there are descriptors stored on different CSEs, individual RETRIEVE requests are sent to each CSE for retrieving the semantic information from the external resources.
All semantic resources are accessed based on the respective access control policies. The resource uses membersAccessControlPolicyIDs attribute in the parent resource for access control policy validation.
Once all of the related semantic information has been retrieved (which forms the RDF data basis for this semantic query), the SPARQL query statement will be executed on the collected RDF data basis in order to provide the semantic query result.
The RETRIVE operation targeting a for semantic queries is detailed in clause 6.2.2.
7.6 Content-related Semantic Resource Discovery and Semantic Query
This clause describes the functionality supporting content-related semantic resource discovery and semantic query operations, where the SPARQL query statements pertain also to data content stored in resources. For example: resources. For example:
A semantic resource discovery with the content constraint: "Return URIs of sensors whose current temperature is greater than 20".
A semantic query with the content constraint: "Return the locations of sensors whose current temperature is greater than 20".
These examples show that semantic resource discovery and semantic query need semantic representations of actual content which enable a variety of entities in a system, including:
Semantic-capable data creators who can directly describe its data in a semantic form such as RDF triples;
Semantic-incapable data creators who only can produce raw data stored as opaque content in the content attribute of the resource and rely on other entities to add semantic annotations to the raw data;
Semantic-capable data consumers who have the semantic resource discovery and/or semantic query capability;
Semantic-incapable data consumers who only can retrieve raw data contents stored in the resource through pre-configurations.
In order to enable this capability, any information that is originally stored in the content attribute of a resource can also be represented as RDF triples and stored in certain resources (see [1]clause 9.6.7 for details). The opaque data in the content attribute of a supports functionality for semantic-incapable data creators and consumers. The semantic formats are provided to enable semantic-capable data creators and consumers and their semantic functionality.
7.7 Semantics Mashup
7.7.1 Introduction
Existing semantic resource discovery in oneM2M can help in discovering various IoT devices and their data. However, in many application scenarios, the discovered data needs to be further processed (e.g. integrated/orchestrated/combined) based on a certain application business logic. For example, users may just be interested in a metric called "weather comfortability index", which cannot be directly provided by physical sensors, and in fact can be calculated based on the original sensory data collected from multiple types of physical sensors (e.g. temperature and humility sensors).
In general, the above process is called "Semantic Mashup", which is defined as a process to discover and collect data from more than one source as inputs, conduct a kind of business logic-related mashup function over the collected data, and eventually generate meaningful mashup results. In particular, semantic mashup emphasizes on leveraging semantic-related technologies during the entire mashup process. For example, in the oneM2M context, an normal resource (e.g. a resource representing a temperature sensor) may be annotated by semantic descriptions and then they could be discovered and identified as a potential data source for a specific mashup application through the semantic resource discovery. resource representing a temperature sensor) may be annotated by semantic descriptions and then they could be discovered and identified as a potential data source for a specific mashup application through the semantic resource discovery.
The above definition also indicates a fact that a complete semantic mashup process may involve multiple stages and multiple entities for each stage. Those entities include:
Mashup Requestor (MR): The entity which initiates a mashup request to Semantic Mashup Function for a certain need. In the context of oneM2M, an AE or a CSE can be an MR.
Resource Host (RH): The entity which hosts data source(s) for a given mashup process. In the context of oneM2M, a data source is typically represented by a oneM2M resource (e.g. a temperature resource) and a RH will be a CSE that hosts oneM2M resources. resource) and a RH will be a CSE that hosts oneM2M resources.
Semantic Mashup Function (SMF): The entity which is responsible for collecting the data inputs from data sources hosted on RHs and mashing them up to generate the mashup result based on a certain business logic. In the context of oneM2M, SMF is a Common Service Function.
7.7.2 Semantic Mashup Function (SMF) Description
7.7.2.1 Introduction
Semantic mashup function including high-level architecture and high-level operations will be described in this clause.
7.7.2.2 High-level architecture
The high-level architecture of an SMF is shown in Figure 7.7.2.2‑1, which shall contain the following components:
Semantic Mashup Job Profile (SMJP): Each specific semantic mashup application has a corresponding SMJP, which not only provides functionality/interaction details for external entities to discover (e.g. MRs), but also defines the internal working details regarding how to realize this mashup application (e.g. the criteria of how to select the qualified data sources as well as the definition of mashup function). The content of an SMJP has been defined in the clause 9.6.53 in oneM2M TS-0001 [1].
Semantic Mashup Instance (SMI): Once an MR identifies a desired SMJP (which can be analogous to a "job description", but not a real job), it can ask SMF to initialize a real mashup process, which corresponds to a "working instance" of this SMJP and is referred to as a Semantic Mashup Instance (SMI). In order to do so, the SMF will inject the corresponding SMJP into the Mashup Engine of SMF for the SMI instantiation, during which the engine may be involved in: 1) Identifying the qualified data sources according to the data source criteria as defined in the SMJP; 2) Collecting data inputs from those identified data sources; 3) Mashing up the collected inputs by applying mashup functions as defined in the SMJP, and finally deriving the mashup result. The content of an SMI has been defined in the clause 9.6.54 in oneM2M TS-0001 [1].
Figure 7.7.2.2‑1: High-level architecture of Semantic Mashup Function
Figure 7.7.2.2‑1: High-level architecture of Semantic Mashup Function
7.7.2.3 High-level operations
An SMF as introduced in clause 7.7.2.2 may involve in different tasks/operations for realizing a complete semantic mashup process. This clause is to introduce those major SMF operations. The high-level SMF operations are shown in Figure 7.7.2.3‑1, where each operation shall be realized using CRUD operations as specified in the clauses6.2.2, 6.3.2, 6.4.2 and 6.5.2, respectively:
Operation 1 - SMJP Discovery: This process is needed when an MR (e.g. MR-1 in Figure 7.7.2.3‑1) tries to discover a desired SMJP for its need. The procedure defined in the clause 6.3.3 for retrieving a shall be leveraged for discovering resources based on resource discovery procedures as defined in oneM2M TS-0001 [1].
Operation 2 - SMI Creation: This process is needed when an MR already identified a desired resource, but there is no corresponding SMI available for use. To implement this operation, an MR shall leverage the procedure defined in the clause 6.4.2 to send an SMI creation request to the CSE hosting SMF in order to instantiate a new SMI (i.e. resource) for the desired SMJP. Alternatively, the SMF can also create a new SMI by itself instead of being triggered by the SMI creation request from the MR.
Operation 3 - Mashup Member Identification: This process is needed when an SMF tries to identify the qualified mashup members (i.e., data sources) for a given SMI, by referring to the criteria as defined in the corresponding SMJP of this SMI (i.e. the memberFilter attribute of a resource). Since in the oneM2M context, data sources (such as sensors) are normally represented as oneM2M resources hosted by RHs, this operation shall be implemented using semantic resource discovery mechanism as defined in clause 7.4.
Operation 4 - Mashup Result Retrieval: This process is needed when an MR tries to retrieve the mashup result from a specific SMI. For a given SMI, it may involve in multiple rounds for mashup result generation especially when the mashup result needs to be refreshed periodically. For each round, the SMF shall collect new data inputs from identified mashup members (via Operation 5) and generate new mashup result which will be stored in the child resource of corresponding resource. There are several alternatives for generating semantic mashup results as defined by the resultGenType attribute of an resource in the clause 9.6.54 in oneM2M TS-0001 [1], for example:
Option 1: After an SMI is created, the SMF proactively and periodically runs the mashup result generation; each time before generating new mashup result, the SMF shall use Operation 5 to collect data inputs from mashup members. Whenever a new mashup result becomes available, it shall be stored in a resource and be exposed to MRs for access.
Option 2: The SMF shall generate mashup result only after receiving an explicit request from an MR (i.e. using the procedure defined in the clause 6.5.2). The benefit of this approach is that SMF works in an on-demand way, which may reduce overhead as compared to Option 1. However, the downside is that it leads to longer waiting time for an MR before the up-to-date mashup result becomes available because data re-collection and mashup result generation will not be triggered until the SMF receives a request from the MR.
Operation 5 - Data Input Collection and Mashup Result Generation: This process is needed when an SMF tries to generate a mashup result for a given SMI. Note that Operation 3 focuses on how to identify the mashup members while Operation 5 focuses on how to collect data inputs from those identified/qualified mashup members. Operation 5 shall be implemented using resource retrieval mechanism as defined in oneM2M TS-0001 [1]. In addition, the working mechanism used for Operation 4 as mentioned above will affect how Operation 5 is conducted by the SMF.
Operation 6 - SMI Discovery and Re-use: An SMI can be discovered, re-used and shared among different MRs. For example, the same SMI of a weather reporting mashup application for New York City Area can be shared by different users asking weather information for this area. Accordingly, Operation 6 is needed when an MR (e.g. MR-2 in Figure 7.7.2.3‑1) tries to discover whether there is already an available/desired SMI ready for use. Since a given SMI is exposed as a resource, existing resource discovery mechanism in oneM2M TS-0001 [1] shall be leveraged to discover a desired SMI from the Hosting CSE. This approach leads to less processing overhead, since other MRs do not need to require the SMF to generate a new SMI (therefore Operation 2 and 3 are not needed).
Figure 7.7.2.3‑1: High-level operations for Semantic Mashup Function
Figure 7.7.2.3‑1: High-level operations for Semantic Mashup Function
7.8 Semantics-based Data Analytics
The procedures are not fully defined in this release.
7.9 Ontology Management
In general, the oneM2M system needs to represent knowledge as a hierarchy of concepts (ontologies), either external or internal to the oneM2M domain, using a shared vocabulary to denote the classes, properties and interrelationships of those concepts. Storage, discovery and management of ontologies (including both oneM2M Base Ontology and external ontologies e.g. SSN [i.1], SAREF [i.2]) within the oneM2M platform are key for supporting basic and advanced semantic functionalities within the oneM2M platform.
An ontology repository as represented by a resource is capable of storing multiple ontologies in the unified languages adopted by the oneM2M system, e.g. RDFS/OWL. Each of the ontology under management is represented as an resource in the oneM2M system. An resource may contain the full representation of an ontology or the IRI reference to it. SPARQL queries can be applied directly on the resource to perform semantic query and triple-level update.
An ontology repository may also provide the semantic validation service (see more in clause 7.10) via the child virtual resource. The service is triggered by sending a UPDATE request that contains the resource to be validated to the virtual resource.
The resource type definitions of , and are specified in oneM2M TS-0001 [1], while the corresponding resource procedures are specified in clause 6 of the present document.
7.10 Semantic Validation
7.10.1 Introduction
The 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 ). In the same time, 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 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 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 resources and the referenced ontology, two message flows of semantic validation are specified in the following clauses.
7.10.2 Semantic validation independent of resource operation resource operation
Figure 7.10.2‑1: Message flow for semantic description validation independent of resource operation
Figure 7.10.2‑1: Message flow for semantic description validation independent of resource operation
This flow can be used independent of resource operation. For example, an AE can validate a 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 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 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 resource to be validated. The request shall be an Update request addressing the virtual resource of the ontology hosting CSE as specified in oneM2M TS-0001 [1]. It shall contain the 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 resources that are also incorporated for validation.
Step 2. After receiving the semantic validation request, the ontology hosting CSE shall retrieve any linked 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 resource in the request. In case the linked resources are further linked to more resources, the ontology hosting CSE shall repeat this step iteratively to retrieve all linked resources. In case the ontology hosting CSE cannot retrieve the linked 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 resource and the linked resources to validate the semantic description of the received resource and the linked 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 resource resource
Figure 7.10.3‑1: Message flow for semantic description validation triggered by resource Create/Update
Figure 7.10.3‑1: Message flow for semantic description validation triggered by resource Create/Update
Step 1. The issuer shall send a Create or Update request to the hosting CSE of a resource (called hosting CSE). The request shall contain the 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 resources that are also incorporated for validation.
Step 2. After receiving the request, the 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 resource is linked to any other remote 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 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
Step 3a. The hosting CSE shall retrieve the referenced ontology representation according to the URI in the ontologyRef attribute of the addressed 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 hosting CSE shall use the retrieved referenced ontology to validation the semantic description (the triples in descriptor attribute) of the addressed resource. The aspects to be checked in semantic validation is specified in clause 7.10.4.
Case 2: linked
Step 3b. This step shall follow Step 1 of figure 7.10.2‑1, wherein the hosting CSE shall act as the Issuer and the resource to be validated is the addressed resource in the received Create or Update request.
Step 6b. This step shall follow Step 4 of figure 7.10.2‑1, wherein the response is sent to the hosting CSE.
Step 7. The hosting CSE shall perform the normal operation (Create or Update) on the addressed 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 hosting CSE shall update the semanticValidated attribute properly to reflect the validation status (validated or not) of the addressed resource accordingly. If Step 4a is skipped due to Step 3a fails, it's also considered as not validated.
Step 8 . The 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 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:
Lexical check. This level of check consists of verifying the correctness of RDF serialization regarding to the declared type. For example, the 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.
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:
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.
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.
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.
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.
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):
Cardinality inconsistency:
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.
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.
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].
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.
7.11 Semantics Reasoning
Semantic reasoning is a mechanism to derive implicit facts that are not explicitly expressed in the existing knowledge/facts (such as RDF triples) by leveraging a set of reasoning rules. A Semantic Reasoning Function (SRF) is defined in this clause in order to support semantic reasoning functionality in the oneM2M system. The key features of a SRF are shown in Figure 7.11‑1:
Figure 7.11‑1: Key Features of Semantic Reasoning Function (SRF)
Figure 7.11‑1: Key Features of Semantic Reasoning Function (SRF)
Feature-1: Enabling semantic reasoning related data
The major functionality of Feature-1 is to enable the semantic reasoning related data (referring to facts and reasoning rules) by be discoverable and publishable/sharable across different entities in the oneM2M system (which is illustrated as the dark yellow arrow in the Figure 7.11‑1). The semantic reasoning related data can be a Fact Set (FS) and/or a Rule Set (RS):
A FS refers to a set of facts. For example, a set of RDF triples stored in a resource can be regarded as a FS. In general, a FS can be used as an input for a semantic reasoning process (i.e. an input FS) or it can be a set of inferred facts as the result of a semantic reasoning process (i.e. an inferred FS). resource can be regarded as a FS. In general, a FS can be used as an input for a semantic reasoning process (i.e. an input FS) or it can be a set of inferred facts as the result of a semantic reasoning process (i.e. an inferred FS).
A RS refers to a set of semantic reasoning rules. For example, oneM2M applications may define their own reasoning rules (user-defined reasoning rules) for different application needs.
Overall, Feature-1 involves the publishing/discovering/sharing of semantic reasoning related data (including both FSs and RSs) through appropriate oneM2M resources. The general flow of Feature-1 is that oneM2M users (as originators) can send requests to certain receiver CSEs in order to publish/discover/update/delete the FS/RS-related resources through the corresponding CRUD operations. Once the processing is done, the receiver CSE will send the response back to the originator.
Feature-2: Optimizing other semantic operations with background semantic reasoning support
The existing semantic operations supported in the oneM2M system (e.g., semantic resource discovery and semantic query) may not yield desired results without semantic reasoning support. The major functionality of Feature-2 of SRF is to leverage semantic reasoning as a "background support" function to optimize other semantic operations (which are illustrated by the pink arrows in the Figure 7.11‑1). In this case, users trigger/initiate specific semantic operations (e.g., a semantic query). During the processing of this operation, semantic reasoning may be further triggered in the background, which is however fully transparent to the user.
Overall, the general flow of Feature-2 is that oneM2M users (as originators) can send requests to certain receiver CSEs for the desired semantic operations (such as semantic resource discovery, semantic query, etc.). During the request processing, the receiver CSE, assuming it supports SRF, can further leverage the reasoning capability. In general, the reasoning capability of the SRF is realized by an underlying semantic reasoner. By leveraging the outputs of semantic reasoning (i.e., reasoning result), the receiver CSE will further produce the optimal result for the semantic operation as requested by the originator (e.g., the semantic query result, or semantic discovery result) and then send the response back to the originator.
Feature-3: Enabling individual semantic reasoning process
oneM2M users (as originators) may also directly interact with the SRF by triggering an individual semantic reasoning process, which is Feature-3 of the SRF. When using this feature, a oneM2M user shall first identify the interested facts (as input FS) as well as the desired reasoning rules based on their application needs. When the input FS and RS are identified, the oneM2M user shall send a request to the SRF for triggering a specific semantic reasoning process by specifying the inputs (i.e. the input FS and RS). The SRF will then initiate a desired semantic reasoning process. Once the SRF works out the semantic reasoning result, it will be returned to the oneM2M users for further usage.
7.12 Ontology Mapping
7.12.1 Introduction
There are already many standardized or proprietary ontologies defined for various vertical domains or cross-domain scenarios. Each ontology specifies the common vocabulary and relationships between concepts within its own namespace, but may sometimes overlap conceptually with other ontologies due to the independent design. This is often true if two ontologies are designed for the same knowledge domain or under a common high level domain. Different terminologies may mean the same or similar concept (e.g. lamp vs. light), or one is the actually the sub-class of another (e.g. device vs. thing).
To enable the semantic interoperability between different ontologies, ontology mapping is a prerequisite. It's an important ontology management method to identify the commonality, similarity as well as inclusion relationships between ontologies, so that the data described in one ontology can be consumed meaningfully by the application who understand only another ontology. Ontology mapping can also help to build a global knowledge base and enhance the system intelligence by linking together a collection of ontologies via the anchors of equal/similar/inclusive concepts.
Ontology mapping can be implemented by either manual approaches or automatic approaches. For example, in Annex B.1 of oneM2M TS-0012 [5], the ontology mapping between Base Ontology and SAREF is specified by manually configured mapping rules (in the format of mapping tables) according to the experts' common understanding on both ontologies.
However, discovering proper mapping relationships manually is often too labour-intensive, error-prone, and impractical for large ontologies, especially for non-standardized and unstable ones. Therefore, oneM2M provides automatic means of ontology mapping to discover, create and save the mapped relationships between semantically related ontologies by using industry-proven mapping algorithms, e.g. the edit distance, language-based similarity, structural-based similarity, or external- resources-based similarity etc.
The solution is based on the resource to configure the input parameters for executing the ontology mapping task and to store the mapping result. Meanwhile, the resource and its child resources are used to host a collection of algorithms for automatic ontology mapping that can be selected for individual ontology mapping tasks. The detailed procedures related to ontology mapping are specified in clause 6.10, 6.11 and 6.12.
Based on the generated ontology mapping result contained in the resource, semantically equivalent operations such as semantic resource discovery and semantic query can be realized in multi-ontology scenarios as specified in resource, semantically equivalent operations such as semantic resource discovery and semantic query can be realized in multi-ontology scenarios as specified in clause 7.12.2.
7.12.2 Semantic query and semantic resource discovery based on the ontology mapping result
7.12.2.1 Introduction
Semantic query and semantic resource discovery operations can be enhanced by leveraging the ontology mapping result stored in the resource, so that an application which understands only one ontology (e.g. Ontology-A) can get the resulting content or resource described in another (e.g. Ontology-B).
This feature requires the issuer to provide an additional request parameter - Ontology Mapping Resources as specified in [1] in a normal semantic query and semantic resource discovery request. This request parameter contains a list of resource identifiers of existing resources that are used as the base of converting the query statement or the semantic description of the target resources into their equivalents.
The following clause describes the detailed procedures using the example ontology mapping result in clause 6.10.2.
NOTE: There is no difference between the semantic query operation and the semantic resource discovery operation in terms of applying the feature of ontology mapping in addition to the respective original procedures. So the following procedures combine the two operations in to one message flow.
7.12.2.2 Procedures
Figure 7.12.2.2‑1: The semantic query (or semantic resource discovery) procedure with ontology mapping
Figure 7.12.2.2‑1: The semantic query (or semantic resource discovery) procedure with ontology mapping
The detailed message flow is depicted in Figure 7.12.2.2‑1 and explained as follows:
The hosting CSE (e.g. an oneM2M platform) receives a semantic query (or semantic resource discovery) request from an Originator (e.g. an oneM2M application). The request shall carry a semanticsFilter request parameter that contains the original query statement described in the first ontology (e.g. Ontology-A), as well as an Ontology Mapping Resources request parameter that contains the resource identifiers of one or multiple resources.
NOTE: Note that the originator may or may not be the one who created the resources. The use of the resources is subject to the associated access control policy against the originator.
For example, the original query statement may be:
SELECT ?device
WHERE {
?device rdf:type Ontology-A:LightSensor.
}
The hosting CSE shall locate the resources according to the resource identifiers in the Ontology Mapping Resources request parameter, and retrieves the mapping results between the first ontology (Ontology-A) and the second ontology (Ontology-B) from the mappingResult attribute of the resources.
For example, the mappingResult may contain the following triple (mapping relationship):
The hosting CSE shall perform the semantic query (or semantic resource discovery) upon the semantic description of the target resources which reference the first ontology (Ontology-A) or the second ontology (Ontology-B), according to the ontology mapping result and the original query statement. The result shall contain both the original outcome of a normal semantic query (or semantic resource discovery) operation as well as additional outcome of the semantic query (or semantic resource discovery) by using the ontology mapping result.
This step comprises the following sub-steps:
The hosting CSE shall perform the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the first ontology (Ontology-A) using the original query statement, and collect the outcome.
For example, a resource may have a resource may have a child resource that references Ontology-A (by the ontologyRef attribute) and contains the following triple that matches the original query statement:
dev-x rdf:type Ontology-A:LightSensor.
The hosting CSE shall perform the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the second ontology (Ontology-B) using the ontology mapping result (provided in the resources), and get the additional outcome. resources), and get the additional outcome.
This step may be performed in two different approaches that are implementation specific (non-normative):
Approach-1: converting the semantic query statement using the ontology mapping result.
The hosting CSE can determine the equivalent query statement described in the second ontology (Ontology-B) by converting from the original query statement described in the first ontology (Ontology-A), according to the ontology mapping result between the first ontology (Ontology-A) and the second ontology (Ontology-B). This can be done by replacing all the ontology class and properties of the first ontology (Ontology-A) in the query statement with the corresponding equivalents of the second ontology (Ontology-B).
According to the examples above, the equivalent query statement becomes:
SELECT ?device
WHERE {
?device rdf:type Ontology-B:Light_Sensor.
}
The hosting CSE then performs the semantic query (or semantic resource discovery) procedure upon the semantic description of the target resources that reference the second ontology (Ontology-B) using the equivalent query statement, and collect the second query (or semantic resource discovery) result.
For example, a resource may have a resource may have a child resource that references Ontology-B (by the ontologyRef attribute) and contains the following triple that matches the converted equivalent query statement:
dev-y rdf:type Ontology-B:Light_Sensor.
Approach-2: converting the semantic description of the target resources according to the resources. resources.
The hosting CSE can determine the equivalent semantic description in the first ontology (Ontology-A) for the target resources which reference the second ontology (Ontology-B), by converting from the original semantic description in the second ontology (Ontology-B) according to the ontology mapping result. This can be done by replacing all the ontology class and properties of the second ontology (Ontology-B) in the related resources of the target resources into the equivalents of the first ontology (Ontology-A).
For example, a resource may have a resource may have a child resource that references Ontology-B (by the ontologyRef attribute) and contains the following triple:
dev-y rdf:type Ontology-B:Light_Sensor.
This triple is then converted into the equivalent triple in Ontology-A that matches the original query statement:
dev-y rdf:type Ontology-A:Light_Sensor.
The hosting CSE then performs the semantic query (or semantic resource discovery) procedure upon the converted equivalent semantic description using the original query statement, and collect the second query (or semantic resource discovery) result.
The hosting CSE shall combine the query (or semantic resource discovery) results from both step 3a and step 3b, and return the combined results to the originator.
For example, in the case of semantic query, the results are the IRIs of dev-x and dev-y. In the case of semantic resource discovery, the results are the resource identifiers of and .
oneM2M TS-0034Release Notes diff from v5.0.3 to v5.0.2
