6 Basic Resource Procedures

6.1 Operations

6.1.1 Introduction

The resource is used to store a semantic description pertaining to a resource and potentially sub-resources. Such a description may be provided according to ontologies. The semantic information is used by the semantic functionalities of the oneM2M system and is also available to applications or CSEs. For resource type description see oneM2M TS-0001 [1]clause 9.6.30.

6.1.2 Create

This procedure shall be used for creating a resource.

Table 6.1.2‑1: CREATE

6.1.3 Retrieve

This procedure shall be used for retrieving the attributes of a resource.

Table 6.1.3‑1: RETRIEVE

6.1.4 Update

This procedure shall be used for updating attributes of a resource.

Table 6.1.4‑1: UPDATE

6.1.5 Delete

This procedure shall be used for deleting a resource.

Table 6.1.5‑1: DELETE

6.2 Operations

6.2.1 Introduction

The resource is a virtual resource because it does not have a representation. It is the child resource of a resource and shall be targeted only by RETRIEVE requests. When a request (for semantic discovery or semantic query) is sent to the resource the host uses the memberIDs attribute of the parent resource to retrieve all the related descriptors, then proceeds with the corresponding processing.

See clause 9.6.14a in oneM2M TS-0001 [1] for a full description of the resource type. The use of for semantic resource discovery and semantic query is further described in clause 7.4.

6.2.2 Retrieve

The RETRIVE operation on shall be used for two purposes:

1. performing semantic resource discovery; and
2. performing semantic query.

The procedure below shall be used for performing a semantic discovery or a semantic query procedure using the descriptor content of all member semantic resources belonging to an existing resource.

Table 6.2.2‑1: RETRIEVE for Semantic Resource Discovery and Semantic Query

6.3 Operations

6.3.1 Introduction

The resource represents a Semantic Mashup Job Profile (SMJP). The resource type description is specified in theclause 9.6.53 of oneM2M TS-0001 clause 9.6.53 in oneM2M TS-0001 [1].

A resource can be provisioned to a Hosting CSE which provides semantic mashup function; alternatively, an AE or CSE can request to create resource at the Hosting CSE. Once a resource is provisioned or created at the Hosting CSE, other oneM2M CSEs/AEs, which act as Mashup Requestors, can discover, retrieve, update, or delete it based on the requirements.

Figure 6.3.1‑1 illustrates a generic procedure (e.g. Create/Retrieve/Update/Delete) to operate on a resource.

Figure 6.3.1‑1: Procedures for operating a resource

6.3.2 Create

This procedure shall be used for creating a resource as described in Table 6.3.2‑1.

Table 6.3.2‑1: CREATE

6.3.3 Retrieve

This procedure shall be used for retrieving the attributes of a resource as described in Table 6.3.3‑1.

Table 6.3.3‑1: RETRIEVE

6.3.4 Update

This procedure as described in Table 6.3.4‑1 shall be used to update an existing resource, e.g. an update to its inputDescriptor attribute.

Table 6.3.4‑1: UPDATE

6.3.5 Delete

This procedure as described in Table 6.3.5‑1 shall be used to delete an existing resource.

Table 6.3.5‑1: DELETE

6.4 Operations

6.4.1 Introduction

models and represents a Semantic Mashup Instance (SMI) resource. resource type is specified in theclause 9.6.54 of oneM2M TS-0001 clause 9.6.54 in oneM2M TS-0001 [1].

A CSE/AE as a Mashup Requestor can request to create resources at another oneM2M CSE which implements the semantic mashup function. Each created resource corresponds to a semantic mashup job profile (i.e. a resource); in other words, how the resource should execute the mashup operation to calculate the mashup result is specified in the corresponding resource. Note that the and its corresponding resources may be placed at the same CSE or at different CSEs, and the smjpID attribute of the allows locating the corresponding resource. If the resource has a as its child resource, the Mashup Requestor may use it to retrieve the mashup result.

Figure 6.4.1‑1 illustrates the procedural flow to operate a resource (e.g. Create/Retrieve/Update/Delete a resource).

Figure 6.4.1‑1: Procedures for Operating a Resource

6.4.2 Create

This procedure shall be used for creating a resource as described in Table 6.4.2‑1.

Table 6.4.2‑1: CREATE

6.4.3 Retrieve

This procedure shall be used for retrieving the attributes of a resource as described in Table 6.4.3‑1.

Table 6.4.3‑1: RETRIEVE

6.4.4 Update

This procedure as described in Table 6.4.4‑1 shall be used to update an existing , e.g. an update to its memberStoreType attribute.

Table 6.4.4‑1: UPDATE

6.4.5 Delete

This procedure as described in Table 6.4.5‑1 shall be used to delete an existing .

Table 6.4.5‑1: DELETE

6.5 Operations

6.5.1 Introduction

is a virtual resource because it does not have a representation. It is the child resource of a resource. When a RETRIEVE operation is sent to the resource, it triggers a calculation and generation of the mashup result based on its parent resource .

The resource type is specified in oneM2M TS-0001 [1], clause 9.6.55.

Only Retrieve operation shall be allowed on a virtual resource. A Create, an Update, or a Delete operation on a virtual resource shall not be supported.

6.5.2 Retrieve

This procedure shall be used for triggering the CSE which hosts the to recalculate mashup results and returning the mashup result back to the requestor (e.g. an AE) of this retrieve request as described in Table 6.5.2‑1.

Table 6.5.2‑1: RETRIEVE

6.6 Operations

6.6.1 Introduction

resource stores the mashup result. It is the child resource of a resource. A resource shall be automatically generated by a Hosting CSE when it executes a semantic mashup operation on a resource. The resource type is specified in the clause 9.6.56 in oneM2M TS-0001 [1].

Figure 6.6.1‑1 illustrates the procedure to operate a resource. A resource shall be automatically created when a Hosting CSE executes semantic mashup operation on a resource. Only Retrieve and Delete operations shall be allowed on a resource. Detail descriptions are given in following clauses.

Figure 6.6.1‑1: Procedures for operating a Resource

6.6.2 Retrieve

This procedure shall be used for retrieving the attributes of a resource as described in Table 6.6.2‑1.

Table 6.6.2‑1: RETRIEVE

6.6.3 Delete

This procedure as described in Table 6.6.3‑1 shall be used to delete an existing resource.

Table 6.6.3‑1: DELETE

6.7 Operations

6.7.1 Introduction

The represents an ontology repository which may contain any number of managed ontologies represented as child resources (see clause 6.8). The ontology repository may further provide semantic validation function by the virtual child resource (see clause 6.9).

6.7.2 Create

This procedure shall be used for creating a resource.

Table 6.7.2‑1: CREATE

6.7.3 Retrieve

This procedure shall be used for retrieving resource.

Table 6.7.3‑1: RETRIEVE

6.7.4 Update

This procedure shall be used for updating an existing resource.

Table 6.7.4‑1: UPDATE

6.7.5 Delete

This procedure shall be used for deleting an existing resource.

Table 6.7.5‑1: DELETE

6.8 Operations

6.8.1 Introduction

Each resource represents an ontology under management in the oneM2M system. It may contain the full representation or the IRI reference of the managed ontology. It is managed by simple CRUD operations as ordinary resource or by more advanced SPARQL operations (contained in the payload of the Update and Retrieve) at the granularity of RDF-triple level.

6.8.2 Create

This procedure shall be used for deleting an existing resource.

Table 6.8.2‑1: CREATE

6.8.3 Retrieve

This procedure shall be used for deleting an existing__ resource.

Table 6.8.3‑1: : RETRIEVE

6.8.4 Update

This procedure shall be used for deleting an existing__ resource.

Table 6.8.4‑1: UPDATE

6.8.5 Delete

Table 6.8.5‑1: DELETE

6.8.6 Semantic query on resource via Retrieve

Table 6.8.6‑1: Semantic query on resource via RETRIEVE

Semantic query defined in clause 7.5 shall be used for retrieving the semantic information (triples) from an resource.

Some SPARQL query statement examples are given as follows:

1. get all classes of an ontology:

   get all classes of an ontology:

   • SELECT ?subject WHERE { ?subject rdfs:subClassOf+ owl:Thing }
2. get all object | data properties of ontology:

   get all object | data properties of ontology:

   • SELECT ?subject WHERE { {?subject rdf:type+ owl:ObjectProperty } UNION {?subject rdf:type+ owl:DatatypeProperty } }
3. get direct subclasses of class A:

   get direct subclasses of class A:

   • SELECT ?subject WHERE { ?subject rdfs:subClassOf saref:Command }
4. get also transitive subclasses class A:

   get also transitive subclasses class A:

   • e.g. if information from instances of class A is requested, all subclasses of class A also need to be included as they are also instances of class A;
   • SELECT ?subject WHERE { ?subject rdfs:subClassOf + saref:Command }
5. get all the superclasses of class A:

   get all the superclasses of class A:

   • e.g. if for derived ontologies the class of the base ontology needs to be found from which the class is derived, for example to apply rules defined for the base ontology, e.g. for creating a resource structure;
   • SELECT ?object WHERE { saref:SetAbsoluteLevelCommand rdfs:subClassOf + ?object }
6. get all object | data properties where class A is in the domain:

   get all object | data properties where class A is in the domain:

   • e.g. to find out what properties an instance of class A can possibly have;
   • SELECT ?subject ?object WHERE { ?subject rdfs:domain saref:Service }
7. get all object | data properties where class A is in the range:

   get all object | data properties where class A is in the range:

   • SELECT ?subject ?object WHERE { ?subject rdfs:range saref:Command }
8. get all sub-properties of a property A:

   get all sub-properties of a property A:

   • e.g. if information concerning property A is requested all sub-properties of A also need to be included;
   • SELECT ?subject WHERE { ?subject rdfs:subPropertyOf om:singular_unit }
9. get classes that are equivalent to class A:

   get classes that are equivalent to class A:

   • SELECT ?class WHERE {{ saref:Device owl:equivalentClass ?class} UNION {?class owl:equivalentClass saref:Device}}

6.9 Operations

6.9.1 Introduction

The resource, as a virtual resource of resource, is used for validating an input resource sent from an authorized originator.

6.9.2 Create

The resource shall be created when the parent resource is created by the hosting CSE. The Create operation is not applicable via Mca, Mcc or Mcc'.

6.9.3 Retrieve

The Retrieve operation is not applicable for .

6.9.4 Update

This procedure shall be used for validating a resource contained in the Update request against its referenced ontology. The semantic validation process shall also take into account linked resources (if any) of the resource in the request.

Table 6.9.4‑1: UPDATE

6.9.5 Delete

The resource shall be deleted when the parent resource is deleted by the hosting CSE. The Delete operation is not applicable via Mca, Mcc or Mcc'.

6.10 Operations

6.10.1 Introduction

The ontology mapping task shall be performed by the Create or Update operation against an resource on a Hosting CSE. A Retrieve operation against the same resource shall be used to get the result of ontology mapping. A Delete operation against a resource shall follow the basic procedure as specified in clauseoneM2M TS-0001 [1], clause 10.1.5.

6.10.2 Create (Ontology Mapping)

This procedure shall be used for performing the ontology mapping task by creating a resource as described in Table 6.10.2‑1. Detailed message flows are described in Figure 6.10.2‑1.

Table 6.10.2‑1: CREATE

Figure 6.10.2‑1: The ontology mapping procedure by Create/Update a resource

The normal message flow Create procedure is described as follows:

1. The hosting CSE (e.g. an oneM2M platform) receives an ontology mapping request from an Originator (e.g. an oneM2M application) in the form of a Create operation against an

   The hosting CSE (e.g. an oneM2M platform) receives an ontology mapping request from an Originator (e.g. an oneM2M application) in the form of a Create operation against an resource. The request shall contain the resourceID s of the source and target resources indicated by the sourceOntology and targetOntology attributes in the resource. It shall also contain the information of mapping method description including the mapping policy and the mapping algorithms indicated by the attributes of mappingPolicy and mappingAlgorithmLinks respectively.

   resource. The request shall contain the resourceID s of the source and target resources indicated by the sourceOntology and targetOntology attributes in the resource. It shall also contain the information of mapping method description including the mapping policy and the mapping algorithms indicated by the attributes of mappingPolicy and mappingAlgorithmLinks respectively.
2. The hosting CSE shall determine the source and target ontologies according to the

   The hosting CSE shall determine the source and target ontologies according to the resourceID s of the source and target resources provided in the request. It shall also determine the ontology mapping method according to the information of mapping method description provided in the request. Specifically, the hosting CSE shall first determine the mapping algorithm policy (single, multiple or traversal) according to the mappingPolicy attribute provided in the request. Then it shall determine the mapping algorithm(s) to be used according to the determined mapping algorithm policy and the available mapping algorithm(s) provided by the mappingAlgorithmLinks attribute, and shall perform the ontology mapping process according to Table 6.10.2‑2.

   resourceID

   Table 6.10.2‑2: Ontology mapping process according to different mapping policies and the provided mapping algorithms

   s of the source and target

   +----------------------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------+ | mappingPolicy | mappingAlgorithmLinks | Ontology mapping process by the hosting CSE | +:===========================+:=================================================================================+:================================================================================+ | Single | Contains the resourceID (s) of one or more existing | Decide to use a single ontology mapping algorithm for the ontology mapping | | | resources, or the resourceID of an existing | between the source and target ontologies.  | | | resource. | If more than one resource is provided by the | | | | mappingAlgorithmLinks, or contained in the referenced | | | | resource, the hosting CSE may decide | | | | to use one of the provided algorithms according to its local policy. | +----------------------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------+ | Multiple | Contains the resourceID_s of two or more existing | Decide to use two or more different types of mapping algorithms (based on the | | | _ resources of different types, or the resourceID| algorithmType attribute of the resource) for | | | of an existing resource which contains | the ontology mapping between the source and target ontologies.  | | | two or more resources of different types. | The hosting CSE may decide to use a subset (at least two types) of the provided | | | | algorithms according to its local policy.  | | | | If the number of the types of the provided algorithms is less than two, the | | | | hosting CSE shall reject the request with an error. | +----------------------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------+ | Traversal | Contains the resourceID (s) of one or more existing | Decide to use all the provided ontology mapping algorithms in a traversal way | | | resources, or the resourceID of an existing | for the ontology mapping between the source and target ontologies. | | | resource. | | +----------------------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------+ | > NOTE 1: Any combination of mappingPolicy and mappingAlgorithmLinks not | | covered by this table shall be considered as an exceptional case, and the | | hosting CSE shall reject the request with an error.  | | | | > NOTE 2: For a pre-configured algorithm already stored in the system, the | | resource may not contain the executable of the | | algorithm. In this case, the hosting CSE may invoke the algorithm from the | | system locally according to the resourceName or resourceID attribute.  | | | | > NOTE 3: If more than one algorithms are used, the final ontology mapping | | result shall be a union of all the results from each algorithm. | +----------------------------+----------------------------------------------------------------------------------+---------------------------------------------------------------------------------+

   resources provided in the request. It shall also determine the ontology mapping method according to the information of mapping method description provided in the request. Specifically, the hosting CSE shall first determine the mapping algorithm policy (single, multiple or traversal) according to the mappingPolicy attribute provided in the request. Then it shall determine the mapping algorithm(s) to be used according to the determined mapping algorithm policy and the available mapping algorithm(s) provided by the mappingAlgorithmLinks attribute, and shall perform the ontology mapping process according to Table 6.10.2‑2.

3. The hosting CSE may need to retrieve the source and/or target resources from a remote CSE the sourceOntology and targetOntology attributes if they are not hosted locally.

4. The hosting CSE may need to retrieve the used resources from a remote CSE according to the mappingAlgorithmLinks attribute if they are not hosted locally.

5. The hosting CSE shall create the ontology mapping relationships between the source and target ontologies according to the determined mapping method, and shall store the resulted mapping relationships in the resource.

6. The hosting CSE shall return a success response to the originator.

Figure 6.10.2‑2 shows an example of the ontology mapping between the source ontology (Ontology-A) and the target ontology (Ontology-B). Assuming the mappingPolicy=multiple and the mappingAlgorithmLinks points to two resources which are a "linguistic-feature extraction algorithm" and an "external resource acquisition algorithm" respectively. The hosting CSE first performs the "linguistic-feature extraction algorithm" against Ontology-A and Ontology-B, and generates three mapping relationships (as formatted by Triple#1, Triple#2 and Triple#3 below). The hosting CSE then performs the "external resource acquisition algorithm" with the support from external resources (e.g. the WordNet dictionary), and generates a fourth mapping relationship (as Triple#4 below).

• RDF Triple #1: Ontology-A:Thing owl:equivalentClass Ontology-B:Thing
• RDF Triple #2: Ontology-A:Devices owl:equivalentClass Ontology-B:Device
• RDF Triple #3: Ontology-A:LightSensor owl:equivalentClass Ontology-B:Light_Sensor
• RDF Triple #4: Ontology-A:Switch_off owl:equivalentProperty Ontology-B:Turn_off

The mapping relationships (RDF Triple #1/2/3/4) are stored in the mappingResult attribute of the resource to be created.

The hosting CSE shall return the successful response to the Originator with the resourceID of the created resource.

Figure 6.10.2‑2: Example of the mapping result between ontology A and ontology B

6.10.3 Retrieve (Get the ontology mapping result)

The ontology mapping result can be retrieved by the Retrieve operation against an resource as described in Table 6.10.3‑1. The mapping result is contained in the mappingResult attribute. No resource specific process is required.

Table 6.10.3‑1: RETRIEVE

6.10.4 Update (Ontology Mapping)

The ontology mapping task may also be performed by the Update operation against an resource. This operation shall be used to generate new mapping results based upon an existing configuration of the with only necessary modifications. The procedure is similar to the Create operation described in clause 6.10.2.

Table 6.10.4‑1: UPDATE

6.10.5 Delete

This procedure shall be used for deleting a resource.

Table 6.10.5‑1: DELETE

6.11 Procedure

Ontology mapping algorithms are represented as resources under an resource. They can be added, updated, retrieved and deleted by the CRUD operation against a resource following the basic procedures as specified in clause 10.1 in oneM2M TS-0001 [1]. There is no resource-specific process to be defined.

6.12 Procedure

The CRUD operation against a resource following the basic procedures as specified in clause 10.1 in oneM2M TS-0001 [1]. There is no resource-specific process to be defined.

6.13 Operations

6.13.1 Introduction

A resource is a child resource of the resource. The resource may have one or multiple child resources to represent different sets of reasoning rules in the oneM2M system. A reasoning initiator can create child resources of a resource to initiate desired reasoning operations.

6.13.2 Create

This procedure is used for creating a resource as described in Table 6.13.2‑1.

Table 6.13.2‑1: CREATE

6.13.3 Retrieve

This procedure is used for retrieving the attributes of a resource as described in Table 6.13.3‑1.

Table 6.13.3‑1: RETRIEVE

6.13.4 Update

This procedure is used for updating the attributes of a resource as described in Table 6.13.4‑1.X.4-1.

Table 6.13.4‑1: UPDATE

6.13.5 Delete

This procedure is used for deleting a resource as described in Table 6.13.5‑1.

Table 6.13.5‑1: DELETE

6.14 Operations

6.14.1 Introduction

A resource can be used to store a set of related reasoning rules (e.g. for supporting a particular application). A resource is a child resource of the resource. By performing the CRUD operations on the resources, various reasoning rules (e.g., user-defined reasoning rules based on business logic) can be created, discovered, retrieved, updated and deleted inside the oneM2M system.

6.14.2 Create

This procedure is used for creating a resource as described in Table 6.14.2‑1.

Table 6.14.2‑1: CREATE

6.14.3 Retrieve

This procedure is used for retrieving the attributes of a resource as described in Table 6.14.3‑1.

Table 6.14.3‑1: RETRIEVE

6.14.4 Update

This procedure is used for updating the attributes of a resource as described in Table 6.14.4‑1.

Table 6.14.4‑1: UPDATE

6.14.5 Delete

This procedure is used for deleting a resource as described in tTable 6.14.5‑1.

Table 6.14.5‑1: DELETE

6.15 Operations

6.15.1 Introduction

A Reasoning Initiator (RI), such as an AE or CSE, may trigger two types of reasoning operations. One type is a "one-time" reasoning operation. This is applicable to the case where a reasoning operation can be executed over a Fact Set (FS) and a Rule Set (RS) that may not change over time. In comparison, the other type is a "continuous" reasoning operation. The second type is applicable to the cases where the input FS and RS for reasoning may change over time, and accordingly the previously inferred knowledge may not be valid anymore. Therefore, new reasoning is executed over the latest version of FS and RS in order to generate up-to-date inferred knowledge.

A resource represents a specific reasoning job instance for enabling the two types of reasoning operations. A RI initiates a desired reasoning operation by creating a resource as a child resource of a resource.

6.15.2 Create

This procedure is used for creating a resource as described in Table 6.15.2‑1.

Table 6.15.2‑1: CREATE

6.15.3 Retrieve

This procedure is used for retrieving the attributes of a resource as described in Table 6.15.3‑1.

Table 6.15.3‑1: RETRIEVE

6.15.4 Update

This procedure is used for updating the attributes of a resource as described in Table 6.15.4‑1.

Table 6.15.4‑1: UPDATE

6.15.5 Delete

This procedure is used for deleting a resource as described in Table 6.15.5‑1.

Table 6.15.5‑1: DELETE