@@ -80,6 +80,7 @@ The following referenced documents are not necessary for the application of the
-<aname="_ref_i.4">[i.4]</a> JSON-LD 1.1 - A JSON-based Serialization for Linked Data", W3C Recommendation 16 July 2020, [https://www.w3.org/TR/json-ld11/](https://www.w3.org/TR/json-ld11/)
-<aname="_ref_i.5">[i.5]</a> Smart Data Models [https://smartdatamodels.org/](https://smartdatamodels.org/)
-<aname="_ref_i.6">[i.6]</a> ETSI GR CIM 022: "NGSI-LD/oneM2M interworking proxy proposal" [https://www.etsi.org/deliver/etsi_gr/CIM/001_099/022/01.01.01_60/gr_CIM022v010101p.pdf](https://www.etsi.org/deliver/etsi_gr/CIM/001_099/022/01.01.01_60/gr_CIM022v010101p.pdf)
# 3 Definition of terms, symbols and abbreviations
<mark>Delete from the above heading the word(s) which is/are not applicable.</mark>
...
...
@@ -934,8 +935,23 @@ The difference to the label-based interworking approach described in Clause 7.3.
The IPE uses semantic discovery to find the relevant resources, retrieves the information from the semantically annotated resource plus any additional resources specified in the semantic descriptions, and, together with the mapping information in the semantic descriptor, created the NGSI-LD entity information that the IPE then uses to update the NGSI-LD Context Broker. Again, the approach is uni-directional, making information originally available in the oneM2M system also available in the NGSI-LD Context Broker.
An approach, originally proposed by the Fed4IoT project <ahref="#_ref_i.7">[i.7]</a>, is to map entities to oneM2M resource structures and labels in a bi-directional way. Table 7.3.2.4-1 shows the proposed mapping between NGSI-LD entities and oneM2M Resources.
**Table 7.3.2.4-1 Static resource to entity mapping guidelines**
Using subscriptions to the resources on the oneM2M system side and the NGSI-LD entities on the NGSI-LD Broker side, an IPE can then ensure synchronization in a bi-directional way, as it will be triggered by notifications whenever there is a relevant change.
This approach is suitable for cases, where the same information is to be represented in both the oneM2M system and the NGSI-LD Context Broker, and the reosurce structure in the oneM2M system can be freely decided. It is not suitable for the case that information is already available in a oneM2M system using a different resource structure. At least in such a case, the information would have to be duplicated and kept synchronized.
Another issue with the static resource-to-entity mapping is the resource granularity, which plays an important role regarding the number of request needed to retrieve NGSI-LD entity information. In the approach shown in Table 7.3.2.4-1, the granulary is on the NGSI-LD attribute level, i.e. each attribute is mapped to a oneM2M container resource and the attribute values are stored as content instances. Alternatively, there could be a container for each NGSI-LD entity where the whole entity information is stored in a content instance, or there could even be a single resource for a whole group of entities.
Which resource structure is most suitable depends on the typical requests, i.e. in the case of synchronization, what types of updates are to be expected. Updates pertaining to (parts of) entities have to deal with a higher overhead the larger the entity information is that needs to be handled, e.g. only a single value is updated, but a new content instance has to be created for the whole entity or group of entiies. If there are typically batch updates for all entities of the group, having fewer resources is more suitable as otherwise a large number of requests are needed to update the information on an attribute value level.
# 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>
