Fixed more typos

TR-0076-Integrating_NGSI-LD_API_in_oneM2M.md

@@ -876,15 +876,15 @@ The final question is how to anchor the NGSI-LD base resource `ngsi-ld` into the
 
 ### 7.3.1 Motivation
 
-oneM2M typically interfaces with existing systems defining an interworking approach. oneM2M utilizes a specialized Application Entity (AE) called Interworking Proxy Entity (IPE) to handle the interaction between the system to interwork with, using its respetive native API or reference point, and the oneM2M system, using the Mca reference point as shown in Figure 7.3.1-1.
+oneM2M typically interfaces with existing systems defining an interworking approach. oneM2M utilizes a specialized Application Entity (AE) called Interworking Proxy Entity (IPE) to handle the interaction between the system to interwork with, using its respective native API or reference point, and the oneM2M system, using the Mca reference point as shown in Figure 7.3.1-1.
 
 ![oneM2M Interworking Proxy Entity (IPE)](media/oneM2M_Interworking.png)
 
 **Figure 7.3.1-1: oneM2M Interworking Proxy Entity (IPE)**
 
-In general, there are two types of interworking approaches - a synchronization-based approach, where the IPE is responsible for automatically synchronizing information between the two systems - and a request-based approach, where the IPE only acts when triggered by a request from one system, i.e. the information required for answering the request first needs to be gathered from the other system. Both approaches can be applied uni-directionally or bi-directionally, i.e. in one case the information is only fetched from one system an pushed to the other, but not the other way round, and in the other case this happens in both directions. Synchronization-based approaches duplicate data, but make information access more efficient, whereas request-based approach avoid any duplication of data, but answering requests becomes more expensive, possibly prohibitively expensive.
+In general, there are two types of interworking approaches - a synchronization-based approach, where the IPE is responsible for automatically synchronizing information between the two systems - and a request-based approach, where the IPE only acts when triggered by a request from one system, i.e. the information required for answering the request first needs to be gathered from the other system. Both approaches can be applied unidirectionally or bi-directionally, i.e. in one case the information is only fetched from one system an pushed to the other, but not the other way round, and in the other case this happens in both directions. Synchronization-based approaches duplicate data, but make information access more efficient, whereas request-based approach avoid any duplication of data, but answering requests becomes more expensive, possibly prohibitively expensive.
 
-ETSI ISG CIM has already developed three synchronization-based interworking approaches <a href="#_ref_i.6">[i.6]</a>. Two of these are uni-directional, i.e. the idea is to synchronize certain oneM2M information with an NGSI-LD system, but not the other way round, and one can be used bi-directionally, i.e. information can be fully synchronized between two systems.
+ETSI ISG CIM has already developed three synchronization-based interworking approaches <a href="#_ref_i.6">[i.6]</a>. Two of these are unidirectional, i.e. the idea is to synchronize certain oneM2M information with an NGSI-LD system, but not the other way round, and one can be used bi-directionally, i.e. information can be fully synchronized between two systems.
 These three approaches are summarized in the following. Details can be found in <a href="#_ref_i.6">[i.6]</a>. A request-driven interworking approach is sketched as well.
 
 As oneM2M and NGSI-LD follow different approaches, a mapping is needed. This can be a general approach, which requires a mapping language, or a specific approach which relies on a certain resource structure or a data model. The mapping information can either be stored in one (or both) of the systems or in the IPE. 
@@ -923,7 +923,7 @@ The detailed information that is needed for the mapping of the NGSI-LD Attribute
 
 ![Interworking mapping using labels - mapping rule](media/Interworking-Labels-2.png)
 
-The IPE discovers the labelled resources, retrieves the information from the labeled and identified additional resources and uses the mapping rule to create the NGSI-LD entity information that is then updated in the NGSI-LD Context Broker. Thus, the approach is uni-directional, making information originally available in the oneM2M system also available in the NGSI-LD Context Broker.
+The IPE discovers the labelled resources, retrieves the information from the labelled and identified additional resources and uses the mapping rule to create the NGSI-LD entity information that is then updated in the NGSI-LD Context Broker. Thus, the approach is unidirectional, making information originally available in the oneM2M system also available in the NGSI-LD Context Broker.
 
 #### 7.3.2.3 Ontology-based, dynamic interworking
 
@@ -933,7 +933,7 @@ The difference to the label-based interworking approach described in Clause 7.3.
 
 **Figure 7.3.2.3-1: Ontology-based interworking**
 
-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.
+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 unidirectional, making information originally available in the oneM2M system also available in the NGSI-LD Context Broker.
 
 #### 7.3.2.4 Static, bi-directional resource-to-entity mapping
 
@@ -945,10 +945,10 @@ An approach, originally proposed by the Fed4IoT project <a href="#_ref_i.7">[i.7
 
 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.
+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 resource 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 important aspect of the static resource-to-entity mapping is the resource granularity, which plays an important role regarding the number of request needed to retrieve or update NGSI-LD entity information. In the approach shown in Table 7.3.2.4-1, the granularity 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.
+Another important aspect of the static resource-to-entity mapping is the resource granularity, which plays an important role regarding the number of requests needed to retrieve or update NGSI-LD entity information. In the approach shown in Table 7.3.2.4-1, the granularity 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 entities. 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.
 
 ### 7.3.3 Request-driven approach
 
@@ -973,8 +973,8 @@ The general aspects that have to be taken into account for the comparison is eff
 The integrated approach described in clause 7.2 generally enables more efficient access as many of the steps are internal and do not have to go via the external binding. Also, internally, more implementation optimizations are possible, e.g. indexing, pre-fetching of information and pre-processing.
 Furthermore, there is no need to duplicate information. However, there is a significant complexity of implementation that has to be handled by the implementor of the oneM2M system.
 
-The synchronization based interworking approaches all duplicate information, so the respective applications can efficiently access the information. The efficiency of the information access by the Interworking Proxy is worse than in the integrated approach as there is the overhead of the binding for each request and there are less optimization possibilities as in the internal case.
-The request-based interworking approach avoids the duplication of information, but possibly, at the expense of access efficiency and the resulting delay suffered by the reuqesting application.
+The synchronization-based interworking approaches all duplicate information, so the respective applications can efficiently access the information. The efficiency of the information access by the Interworking Proxy is worse than in the integrated approach as there is the overhead of the binding for each request and there are less optimization possibilities as in the internal case.
+The request-based interworking approach avoids the duplication of information, but possibly, at the expense of access efficiency and the resulting delay suffered by the requesting application.
 
 # 8 Mapping between the information stored in oneM2M resources and the NGSI-LD information model