@@ -774,12 +774,12 @@ The following bullet points provide a summary of the NGSI-LD functionalities tha
# 7 Architectural integration of NGSI-LD into oneM2M
# 7.1 Introduction
## 7.1 Introduction
Clause 7 studies solutions for the architectural integration of NGSI-LD and its related functionalities into oneM2M, in particular with respect to oneM2M reference points and the existing oneM2M Common Service Functions.
# 7.2 Mapping Approach - Making oneM2M Information available via NGSI-LD
## 7.2 Mapping Approach - Making oneM2M Information available via NGSI-LD
# 7.2.1 Motivation
### 7.2.1 Motivation
oneM2M resource structures already contain relevant information, however, applications often have to first discover and then individually retrieve this information to check whether it is actually relevant for them. The goal of this approach is to make the information stored in existing oneM2M resources also available to applications via the NGSI-LD API, enabling application to specify and efficiently retrieve the information they actually need.
...
...
@@ -793,9 +793,9 @@ Applications have the following interaction options using NGSI-LD:
- Query relevant information as described above and getting back all results, in form of NGSI-LD Entities, with a single request. There is no seperate discovery step followed by retrieval(s).
- Subscribe to be notified of relevant changes in information, or periodically.
# 7.2.2 Sketch of Mapping Approach
### 7.2.2 Sketch of Mapping Approach
The idea of the approach is to define a general mechanism based on a mapping language. With this approach, users can define a mapping, e.g., how a value that can be extracted from a oneM2M resource is the value of an NGSI-LD property, belonging to a specifc NGSI-LD Entity with a certain NGSI-LD type. These user-provided mappings could be stored in Semantic Descriptor resources. Alternatively, a specific Mapping resource type could be defined.
The idea of the approach is to define a general mechanism based on a mapping language. With this approach, users can define a mapping, e.g., how a value that can be extracted from a oneM2M resource is the value of an NGSI-LD property, belonging to a specifc NGSI-LD Entity with a certain NGSI-LD type. These user-provided mappings could be stored in Semantic Descriptor resources. Alternatively, a specific mapping resource type could be defined.
Figure 7.2-1 shows two oneM2M resource structures, e.g. two \<container\> resources with \<contentInstance\> resources and one \<semanticDescriptor\> resource each. The \<contentInstance\> resources encapsulate information as provided by the source, e.g. a device or IPE. The <semanticDescriptor> resources contain the mapping that describes how the value can be extracted, the value of which NGSI-LD property it represents, to which NGSI-LD Entity the property belongs and what type the Entity has. The resulting information is depicted on right side of Figure 7.2-1 and this information can be accessed through the NGSI-LD API.
...
...
@@ -811,7 +811,6 @@ On the right of Figure 7.2.2 the resulting NGSI-LD entity is represented that ca
**Figure 7.2-2: Mapping example - oneM2M information mapped to NGSI-LD Entity**
# 8 Mapping between the information stored in oneM2M resources and the NGSI-LD information model
<mark>Study the mapping between the information stored in oneM2M resources and the NGSI-LD information model. This includes, but is not limited to the current oneM2M semantic models (in particular SDT and the oneM2M base ontology, including SAREF integration) to the NGSI-LD information model, with the goal of making it available through an integration of NGSI-LD API and the Mca reference point. This may lead to an evolution of the current NGSI-LD and Mca, and the related information models.</mark>
