7.5 Semantic Queries and Query Scope
Note
In the following descriptions, the general term semantic resource is used to refer to <semanticDescriptor>, <ontology> resources, <contentInstance> 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 semantics Filter 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
Editor's Note: Replace with PlantUML Diagram
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 <group> 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 <semanticFanOutPoint> (as specified by the "To " parameter), i.e., the child resources of the <group> resource. As a result, this <group> 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 <group> resource).
When the semantic query scope is explicitly defined by the <group> 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 <group> resource. The Originator may first discover various <group> resources and select the one with the desired RDF data basis, before launching a semantic query request. For example, the <semanticDescriptor> child resource of <group- 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 <semanticFanOutPoint> child resource of the <group- 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 <semanticFanOutPoint> resource shall use the memberIDs attribute of the parent <group> 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 <semanticFanOutPoint> resource uses membersAccessControlPolicyIDs attribute in the parent <group> 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 <semanticFanOutPoint> for semantic queries is detailed in clause 6.2.2.