Formatting texts

Author: jason-fox

docs/concise.md

@@ -279,8 +279,8 @@ curl -iX POST 'http://localhost:1026/ngsi-ld/v1/entities/' \
 }'
 ```
 
-New entities can be added by making a POST request to the `/ngsi-ld/v1/entities` endpoint. Notice that because
-`name` is a Property that has no sub-attributes, it does not require a `value` element.
+New entities can be added by making a POST request to the `/ngsi-ld/v1/entities` endpoint. Notice that because `name` is
+a Property that has no sub-attributes, it does not require a `value` element.
 
 As usual, the request will fail if the entity already exists in the context.
 
@@ -406,11 +406,7 @@ The request will fail if any of the attributes already exist in the context. The
 been successful and the reason for failure (if any has occurred).
 
 ```json
-[
-        "urn:ngsi-ld:TemperatureSensor:002",
-        "urn:ngsi-ld:TemperatureSensor:003",
-        "urn:ngsi-ld:TemperatureSensor:004"
-]
+["urn:ngsi-ld:TemperatureSensor:002", "urn:ngsi-ld:TemperatureSensor:003", "urn:ngsi-ld:TemperatureSensor:004"]
 ```
 
 ### Batch Create/Overwrite New Data Entities
@@ -563,9 +559,9 @@ The sensor `urn:ngsi-ld:TemperatureSensor:001` is reading at 25°C. The response
 }
 ```
 
-Because `format=concise` was used this is response includes the metadata such as `unitCode` but not
-`"type": "Property"` Context data can be retrieved by making a GET request to the `/ngsi-ld/v1/entities/<entity-id>`
-endpoint and selecting the `attrs` using a comma separated list.
+Because `format=concise` was used this is response includes the metadata such as `unitCode` but not `"type": "Property"`
+Context data can be retrieved by making a GET request to the `/ngsi-ld/v1/entities/<entity-id>` endpoint and selecting
+the `attrs` using a comma separated list.
 
 ### Read a Data Entity (concise)
 
@@ -909,7 +905,7 @@ The response details the selected attributes from the selected entities is retur
                     "unitCode": "5K"
                 },
                 "phenologicalCondition": {
-                    "vocab":  "femaleAdult"
+                    "vocab": "femaleAdult"
                 },
                 "reproductiveCondition": {
                     "vocab": "inCalf"

docs/context-providers.md

@@ -230,9 +230,8 @@ curl -iX POST \
 ```
 
 In both cases we have encoded each entity `id` according to the NGSI-LD
-[specification](https://cim.etsi.org/NGSI-LD/official/front-page.html) - the proposal
-is that each `id` is a URN follows a standard format: `urn:ngsi-ld:<entity-type>:<entity-id>`. This will mean that every
-`id` in the system will be unique.
+[specification](https://cim.etsi.org/NGSI-LD/official/front-page.html) - the proposal is that each `id` is a URN follows
+a standard format: `urn:ngsi-ld:<entity-type>:<entity-id>`. This will mean that every `id` in the system will be unique.
 
 Device information can be requested by making a GET request on the `/ngsi-ld/v1/entities` endpoint. For example to
 return the context data of the devices.
@@ -386,7 +385,7 @@ The updated response including the `controlledAsset` attribute is shown below:
     "id": "urn:ngsi-ld:TemperatureSensor:001",
     "type": "TemperatureSensor",
     "description": "Temperature Gauge 1",
-    "category": {"vocab": "sensor"},
+    "category": { "vocab": "sensor" },
     "controlledProperty": "temperature",
     "temperature": 20,
     "controlledAsset": "urn:ngsi-ld:Building:farm001"

docs/entity-relationships.md

@@ -77,8 +77,8 @@ this principle, allowing the creation of NGSI-LD properties which directly confo
 
 -   An NGSI-LD **LanguageProperty** holds a set of internationalized strings and is defined using the JSON-LD
     `@language` keyword.
--   An NGSI-LD **VocabProperty** holds is a mapping of a URI to a value within the user'`@context` and is defined
-    using the JSON-LD `@vocab` keyword.
+-   An NGSI-LD **VocabProperty** holds is a mapping of a URI to a value within the user'`@context` and is defined using
+    the JSON-LD `@vocab` keyword.
 
 In each case, the meaning of the resultant payload will be altered according to the standard JSON-LD definitions, so the
 output NGSI-LD remains fully valid JSON-LD.
@@ -237,7 +237,8 @@ self-explanatory.
 
 ## Start Up
 
-All services can be initialised from the command-line by running the [services](https://github.com/FIWARE/tutorials.Extended-Properties/blob/NGSI-LD/services) Bash script provided within
+All services can be initialised from the command-line by running the
+[services](https://github.com/FIWARE/tutorials.Extended-Properties/blob/NGSI-LD/services) Bash script provided within
 the repository. Please clone the repository and create the necessary images by running the commands as shown:
 
 ```bash
@@ -289,9 +290,9 @@ strings representing [IETF RFC 5646](https://www.rfc-editor.org/info/rfc5646) la
 
 ### Creating a new data entity
 
-This example creates an entity with a **LanguageProperty** and a **VocabProperty**. Let's create a farm
-**Building** entity in which we want to make the `name` available in three different languages, _English_, _German_, and
-_Japanese_. The process will be to send a **POST** request to the Broker with the following information:
+This example creates an entity with a **LanguageProperty** and a **VocabProperty**. Let's create a farm **Building**
+entity in which we want to make the `name` available in three different languages, _English_, _German_, and _Japanese_.
+The process will be to send a **POST** request to the Broker with the following information:
 
 #### 1️⃣ Request:
 
@@ -350,9 +351,9 @@ Content-Length: 0
 
 #### 2️⃣ Request:
 
-This example creates a second entity with a **LanguageProperty** and a **VocabProperty**. Each subsequent entity
-must have a unique `id` for the given `type`. Note that within a `languageMap`, the `@none` simplified pair indicates
-the default fallback value to be displayed for unknown languages.
+This example creates a second entity with a **LanguageProperty** and a **VocabProperty**. Each subsequent entity must
+have a unique `id` for the given `type`. Note that within a `languageMap`, the `@none` simplified pair indicates the
+default fallback value to be displayed for unknown languages.
 
 ```bash
 curl -iX POST 'http://localhost:1026/ngsi-ld/v1/entities/' \
@@ -688,8 +689,8 @@ curl -G -X GET \
 
 The User's `@context` is a mechanism for mapping URNs and defining the Entities held within the system It is therefore
 possible to retrieve _the same data_ using a different set of short names for the attributes, and in the case of a
-**VocabProperty**, different short names for the values of the attributes themselves. This is particularly useful
-when dealing with distributed data, federations and data spaces as the end user many not have full control of data held
+**VocabProperty**, different short names for the values of the attributes themselves. This is particularly useful when
+dealing with distributed data, federations and data spaces as the end user many not have full control of data held
 within another participant's context broker.
 
 When the **Building** entities were created, we used an `@context` file called `ngsi-context.jsonld`. Within the
@@ -819,8 +820,8 @@ The `alternate-context.jsonld` `@context` file maps all the terms and enumeratio
 #### 1️⃣3️⃣ Request:
 
 When `alternate-context.jsonld` included as a `Link` header in the request, the response will convert all the attribute
-names to short names used in `alternate-context.jsonld`, and in the case of a **VocabProperty**, return the short
-names for the value as well.
+names to short names used in `alternate-context.jsonld`, and in the case of a **VocabProperty**, return the short names
+for the value as well.
 
 ```bash
 curl -G -X GET \

docs/extended-properties.md

@@ -26,7 +26,7 @@ Solution either by connecting to a series of dummy IoT devices or manipulating t
 [![Open in GitHub Codespaces](https://github.com/codespaces/badge.svg)](https://github.com/codespaces/new?template_repository=FIWARE/tutorials.NGSI-LD)
 
 <!-- Global Summit
-<a href="https://www.fiware.org/global-summit/"><img src="https://fiware.github.io//catalogue/img/Summit25.png" width="240" height="70" /></a> &nbsp; <a href="https://www.eventbrite.co.uk/e/fiware-global-summit-2025-rabat-smart-city-morocco-tickets-1249129843989"><img src="https://fiware.github.io//catalogue/img/Training25.png" width="240" height="70" /></a> 
+<a href="https://www.fiware.org/global-summit/"><img src="https://fiware.github.io//catalogue/img/Summit25.png" width="240" height="70" /></a> &nbsp; <a href="https://www.eventbrite.co.uk/e/fiware-global-summit-2025-rabat-smart-city-morocco-tickets-1249129843989"><img src="https://fiware.github.io//catalogue/img/Training25.png" width="240" height="70" /></a>
 -->
 
 <blockquote>
@@ -144,8 +144,7 @@ consume context information. The concept of Linked Data based upon JSON-LD paylo
 passing data between participating organisations.
 
 The NGSI-LD Specification is regularly updated published by ETSI. The latest specification is
-[version 1.7.1](https://cim.etsi.org/NGSI-LD/official/front-page.html) which was
-published in June 2023.
+[version 1.7.1](https://cim.etsi.org/NGSI-LD/official/front-page.html) which was published in June 2023.
 
 An Excel file detailing the current compatibility of the bleeding edge development version of each context broker
 (Orion-LD, Scorpio, Stellio) against the features of the 1.6.1 specification can be found
@@ -168,16 +167,12 @@ attributes used can be found in the following:
 These first tutorials are an introduction to the NGSI-LD Context Brokers, and are an essential first step when learning
 to use NGSI-LD.
 
-&nbsp; 101. [Understanding `@context`](understanding-@context.md) <br/>
-&nbsp; 102. [Working with `@context`](working-with-@context.md) <br/>
-&nbsp; 103. [CRUD Operations](ngsi-ld-operations.md) <br/>
-&nbsp; 104. [Concise Payloads](concise.md) <br/>
-&nbsp; 105. [Merge-Patch and Put](merge-patch.md) <br/>
-&nbsp; 106. [Entity Relationships](entity-relationships.md) <br/>
-&nbsp; 107. [Subscriptions](subscriptions.md) <br/>
-&nbsp; 108. [Registrations](context-providers.md) <br/>
-&nbsp; 109. [Temporal Operations](short-term-history.md) <br/>
-&nbsp; 110. [Extended Properties](extended-properties.md) <br/>
+&nbsp; 101. [Understanding `@context`](understanding-@context.md) <br/> &nbsp; 102.
+[Working with `@context`](working-with-@context.md) <br/> &nbsp; 103. [CRUD Operations](ngsi-ld-operations.md) <br/>
+&nbsp; 104. [Concise Payloads](concise.md) <br/> &nbsp; 105. [Merge-Patch and Put](merge-patch.md) <br/> &nbsp; 106.
+[Entity Relationships](entity-relationships.md) <br/> &nbsp; 107. [Subscriptions](subscriptions.md) <br/> &nbsp; 108.
+[Registrations](context-providers.md) <br/> &nbsp; 109. [Temporal Operations](short-term-history.md) <br/> &nbsp; 110.
+[Extended Properties](extended-properties.md) <br/>
 
 <h3 style="box-shadow: 0px 4px 0px 0px #5dc0cf;">Internet of Things, Robots and third-party systems</h3>
 
@@ -215,4 +210,3 @@ These tutorials show how to create, process, analyze or visualize context inform
 These tutorials show how to create data spaces using NGSI-LD and access NGSI-v2 sources
 
 &nbsp; 601. [Federative Data Spaces](linked-data.md)<br/>
-

docs/index.md

@@ -4,8 +4,8 @@
 **Description:** This tutorial a wires up the dummy [JSON](https://json.org/)-based IoT devices using the
 [IoT Agent for JSON](https://fiware-iotagent-json.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual)
 devices so that measurements can be read and commands can be sent using
-[NGSI LD](https://cim.etsi.org/NGSI-LD/official/front-page.html) requests sent to an
-NGSI-LD compliant context broker such as the [Orion Context Broker](https://fiware-orion.readthedocs.io/en/latest/).
+[NGSI LD](https://cim.etsi.org/NGSI-LD/official/front-page.html) requests sent to an NGSI-LD compliant context broker
+such as the [Orion Context Broker](https://fiware-orion.readthedocs.io/en/latest/).
 
 The tutorial uses [cUrl](https://ec.haxx.se/) commands throughout, but is also available as
 [Postman documentation](https://fiware.github.io/tutorials.IoT-Agent-JSON/ngsi-ld.html)
@@ -54,7 +54,7 @@ A direct comparison of the two IoT Agents can be seen below:
 | HTTP commands posted to a well-known URL - response is in the reply | HTTP commands posted to a well-known URL - response is in the reply | Communications Handshake   |
 | MQTT devices are identified by the path of the topic `/XXX/YYY`     | MQTT devices are identified by the path of the topic `/XXX/YYY`     | Device Identification      |
 | MQTT commands posted to the `cmd` topic                             | MQTT commands posted to the `cmd` topic                             | Communications Handshake   |
-| MQTT command responses posted to the `cmdexe` topic                 | MQTT command responses posted to the `cmdexe` topic                          | Communications Handshake   |
+| MQTT command responses posted to the `cmdexe` topic                 | MQTT command responses posted to the `cmdexe` topic                 | Communications Handshake   |
 
 As can be seen, the message payload differs entirely between the two IoT Agents, but much of the rest of the protocol
 remains the same.
@@ -492,11 +492,11 @@ however it has been included here for completeness.
 
 ### Provisioning a Sensor
 
-The NGSI-LD [specification](https://cim.etsi.org/NGSI-LD/official/front-page.html)
-mandates full URNs when creating context data entities, however the incoming messages from the devices will not be aware
-of this convention. Furthermore, the attribute name on the context data entity should match the short names found within
-the associated `@context` file. These mappings can be defined at the service group level as seen in the previous
-request, or they can be defined by provisioning each device individually.
+The NGSI-LD [specification](https://cim.etsi.org/NGSI-LD/official/front-page.html) mandates full URNs when creating
+context data entities, however the incoming messages from the devices will not be aware of this convention. Furthermore,
+the attribute name on the context data entity should match the short names found within the associated `@context` file.
+These mappings can be defined at the service group level as seen in the previous request, or they can be defined by
+provisioning each device individually.
 
 Three types of measurement attributes can be provisioned:
 

docs/iot-agent-json.md

@@ -4,8 +4,7 @@
 **Description:** This **NGSI-LD** tutorial introduces the concept of an **IoT Agent** and wires up the dummy
 [UltraLight 2.0](https://fiware-iotagent-ul.readthedocs.io/en/latest/usermanual/index.html#user-programmers-manual) IoT
 devices created in the [previous tutorial](https://github.com/FIWARE/tutorials.IoT-Sensors) so that measurements can be
-read and commands can be sent using
-[NGSI LD](https://cim.etsi.org/NGSI-LD/official/front-page.html) requests sent to an
+read and commands can be sent using [NGSI LD](https://cim.etsi.org/NGSI-LD/official/front-page.html) requests sent to an
 NGSI-LD compliant context broker such as the [Orion Context Broker](https://fiware-orion.readthedocs.io/en/latest/).
 
 The tutorial uses [cUrl](https://ec.haxx.se/) commands throughout, but is also available as
@@ -487,11 +486,11 @@ however it has been included here for completeness.
 
 ### Provisioning a Sensor
 
-The NGSI-LD [specification](https://cim.etsi.org/NGSI-LD/official/front-page.html)
-mandates full URNs when creating context data entities, however the incoming messages from the devices will not be aware
-of this convention. Furthermore, the attribute name on the context data entity should match the short names found within
-the associated `@context` file. These mappings can be defined at the service group level as seen in the previous
-request, ot they can be defined by provisioning each device individually.
+The NGSI-LD [specification](https://cim.etsi.org/NGSI-LD/official/front-page.html) mandates full URNs when creating
+context data entities, however the incoming messages from the devices will not be aware of this convention. Furthermore,
+the attribute name on the context data entity should match the short names found within the associated `@context` file.
+These mappings can be defined at the service group level as seen in the previous request, ot they can be defined by
+provisioning each device individually.
 
 Three types of measurement attributes can be provisioned: