@@ -795,7 +795,7 @@ Applications have the following interaction options using NGSI-LD:
### 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 SemanticDescriptor 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 \<semanticDescriptor\> 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.
...
...
@@ -806,7 +806,7 @@ The extraction of values is not limited to \<contentInstance\> resources, but in
**Figure 7.2-1: Core Mca and NGSI-LD provide complementary functionality**
Figure 7.2.2 shows an example. The content instances contain values in different formats. On the left side, the content instances under Resource A contain integers, in the middle, under Resource B, the content instances each contain an XML structure.
The semantic descriptor of Resource A contains mapping information, i.e. that the infomration is about an Entity with the identifer Room123, which is of type Room, has a property called indoorTemperature, whose value is to be extracted from the <contentInstance> resource, and that has a unit as meta information that indicates that the temperature is given in Celsius. The mapping information in the semantic descriptor of Resource B indicates that the information belongs to the same entity, but in this case the property is called occupancy and the information has to be extracted from the XML. The extraction examples only serve illustration purposes here, the actual format specifying how to extract information still has to be specified, taking into account suitable existing standards.
The semantic descriptor of Resource A contains mapping information, i.e. that the information is about an Entity with the identifer Room123, which is of type Room, has a property called indoorTemperature, whose value is to be extracted from the <contentInstance> resource, and that has a unit as meta information that indicates that the temperature is given in Celsius. The mapping information in the semantic descriptor of Resource B indicates that the information belongs to the same entity, but in this case the property is called occupancy and the information has to be extracted from the XML. The extraction examples only serve illustration purposes here, the actual format specifying how to extract information still has to be specified, taking into account suitable existing standards.
On the right of Figure 7.2.2 the resulting NGSI-LD entity is represented that can be accessed using the NGSI-LD API.
