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 <AE> 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 <AE> 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

Editor's Note: Replace with PlantUML Diagram

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 clauses 6.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 <semanticMashupJobProfile> shall be leveraged for discovering <semanticMashupJobProfile> 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 <semanticMashupJobProfile> 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. <semanticMashupInstance> 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 <semanticMashupJobProfile> 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 <semanticMashupResult> of corresponding <semanticMashupInstance> resource. There are several alternatives for generating semantic mashup results as defined by the resultGenType attribute of an <semanticMashupInstance> 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 <semanticMashupResult> 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 <semanticMashupInstance> 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