@@ -839,7 +839,7 @@ NGSI-LD foresees distributed operations based on registrations as shown in Figur
**Figure 7.2.3-3: NGSI-LD between CSEs**
Figure 7.2.3-4 shows the NGSI-LD REST/HTTP binding. NGIS-LD resources are either static, i.e. exist from the start as defined in the NGSI-LD specification, or are implicitly defined by the information. For example, an NGSI-LD Entity is created and as a result one or more resources exist, so information is created/updated/deleted/queried etc., not resources as such, and there can be multiple ways to create the same information – e.g. as individual entity or via batch operations.
Figure 7.2.3-4 shows the NGSI-LD REST/HTTP binding. NGSI-LD resources are either static, i.e. exist from the start as defined in the NGSI-LD specification, or are implicitly defined by the information. For example, an NGSI-LD Entity is created and as a result one or more resources exist, so information is created/updated/deleted/queried etc., not resources as such, and there can be multiple ways to create the same information – e.g. as individual entity or via batch operations.
@@ -852,10 +852,12 @@ The following base path / resource is defined in the NGSI-LD Specification <a hr
<path>/ngsi-ld/v1/entities
```
Here `<path>` is used as a placeholder. In oneM2M the respective binding and addressing needs to be taken into account that enables targetting the ngsi-ld resource. This is going to be discussed separately, and the remainder of the path is used to target the relevant subresource.
By adding the mapping as shown in Figure 7.2.3-5, the following resources would implicitly become available:
