Switch to WSL

FIWARE Working with @context.postman_collection.json

@@ -2,7 +2,7 @@
 	"info": {
 		"_postman_id": "37a6dc59-bcbb-4813-b1b3-5b088f4e3bdd",
 		"name": "NGSI-LD Working with @context",
-		"description": "This tutorial examines the interaction between **NGSI-LD** and **JSON-LD** `@context` files. The `@context` files generated in the [previous tutorial](https://github.com/FIWARE/tutorials.Understanding-At-Context) are used as the underlying data model for inputing context data and context information is queries and read back in different formats.\n\nThe `docker-compose` file for this tutorial can be found on GitHub: \n\n![GitHub](https://fiware.github.io/tutorials.Getting-Started/icon/GitHub-Mark-32px.png) [FIWARE-LD 102: Working with `@context` ](https://github.com/FIWARE/tutorials.Getting-Started/tree/NGSI-LD)\n\n# Working with `@context` files\n\n> “Some quotations are greatly improved by lack of context.”\n>\n> ― John Wyndham, The Midwich Cuckoos\n\nFrom the [previous tutorial](https://github.com/FIWARE/tutorials.Understanding-At-Context) we have generated two `@context` files defining the context data entities which will be offered in our simple Smart Farm Management System. This means that we have defined an agreed set of unique IDs (URNs or URLs) for all the\ndata entities and every single attribute within those entities so that other external applications will be able to programmatically understand the data held within our broker.\n\nFor example the attribute `address` is within our smart application is defined as follows:\n\n```jsonld\n\"@context\": {\n    \"schema\": \"https://schema.org/\",\n    \"address\": \"schema:address\"\n}\n```\n\nWhich means that every `address` attribute follows the definition as defined by `schema.org`:\n\n`https://schema.org/address` :\n\n![](https://fiware.github.io/tutorials.Working-with-At-Context/img/architecture-ld.png)\n\nA program written by a third party would therefore be able to extract information such the fact an `address` attribute holds a JSON object with a sub-attribute containing the `streetAddress`  by referring to the full [schema.org **JSON-LD** schema](https://schema.org/version/latest/schemaorg-current-http.jsonld)\n\n```jsonld\n{\n  \"@id\": \"http://schema.org/streetAddress\",\n  \"@type\": \"rdf:Property\",\n  \"http://schema.org/domainIncludes\": {\n    \"@id\": \"http://schema.org/PostalAddress\"\n  },\n  \"http://schema.org/rangeIncludes\": {\n    \"@id\": \"http://schema.org/Text\"\n  },\n  \"rdfs:comment\": \"The street address. For example, 1600 Amphitheatre Pkwy.\",\n  \"rdfs:label\": \"streetAddress\"\n}\n```\n\nThis is the **JSON-LD** programmatic syntax allowing computers to extract meaningful data _The attribute `address.streetAddress` is a street_ directly without the need for human intervention.\n\nImagine the case where a company is contracting agricultural labourers. The farmer will need to be billed for the work done. If such a system is built on JSON-LD, it does not matter if the farmer's Farm Management Information System assigns different names to the attributes of the billing address provided that the farmer and contractor can agree on the well-defined URNS for each attribute as **JSON-LD** can easily translate between the two formats using common expansion and compaction algorithms.\n\n## NGSI-LD Rules\n\n**NGSI-LD** is a formally structured _extended subset_ of **JSON-LD**. Therefore **NGSI-LD** offers all the interoperability and flexibility of **JSON-LD** itself. It also defines its own core `@context` which cannot be overridden for **NGSI-LD** operations. This means that **NGSI-LD** users agree to a common well defined set of rules for structuring their data, and then supplement this with the rest of the **JSON-LD** specification.\n\nWhilst interacting directly with **NGSI-LD** interface of the context broker the additional **NGSI-LD** rules must be respected. However after the data has been extracted it is possible to loosen this requirement and pass the results to third parties as **JSON-LD**.\n\nThis tutorial is a simple introduction to the rules and restrictions behind **NGSI-LD** and  will create some **NGSI-LD** entities and then extract the data in different formats. The two main data formats are _normalized_ and _key-value-pairs_. Data returned in the  _normalised_ format respects the **NGSI-LD** rules and may be used directly by another context broker (or any other component offering an **NGSI-LD** interface). Data returned in the  _key-value-pairs_ format is by definition not **NGSI-LD**.\n\n## Content negociation and the `Content-Type` and `Accept` Headers\n\nDuring content negociation, **NGSI-LD** offers data in one of three formats, these effect the structure of the payload body.\n\n- `Accept: application/json` - the response is in **JSON** format\n- `Accept: application/ld+json` - the response is in **JSON-LD** format\n- `Accept: application/geo+json` - the response is in **GeoJSON** or **GeoJSON-LD** format\n\nThe major difference between **JSON** format and **JSON-LD** format, is that if **JSON-LD** format is chosen, then the `@context` is found as an additional attribute within the body of the response. if the **JSON** only format is used the `@context` is passed as an additional `Link` Header element and is not found in the response body.\n\nSimilarly when sending **NGSI-LD** data to the context broker, an application may choose to send a payload including an additional `@context` attribute (in which case `Content-Type: application/ld+json`) or the application may send NGSI-LD data without an additional `@context` attribute (in which case `Content-Type: application/json` and the `Link` header must also be present).\n\nThe **GeoJSON** format is only used when querying a context broker for existing data and returns the context in a format suitable for GIS systems. It is a recent addition to the **NGSI-LD** specification and therefore will not be discussed further here.\n\n# Prerequisites\n\n## Docker\n\nTo keep things simple all components will be run using [Docker](https://www.docker.com). **Docker** is a container\ntechnology which allows to different components isolated into their respective environments.\n\n-   To install Docker on Windows follow the instructions [here](https://docs.docker.com/docker-for-windows/)\n-   To install Docker on Mac follow the instructions [here](https://docs.docker.com/docker-for-mac/)\n-   To install Docker on Linux follow the instructions [here](https://docs.docker.com/install/)\n\n**Docker Compose** is a tool for defining and running multi-container Docker applications. A\n[YAML file](https://raw.githubusercontent.com/Fiware/tutorials.Working-with-At-Context/master/docker-compose/orion-ld.yml) is used\nconfigure the required services for the application. This means all container services can be brought up in a single\ncommand. Docker Compose is installed by default as part of Docker for Windows and Docker for Mac, however Linux users\nwill need to follow the instructions found [here](https://docs.docker.com/compose/install/)\n\n## Cygwin\n\nWe will start up our services using a simple bash script. Windows users should download [cygwin](http://www.cygwin.com/)\nto provide a command-line functionality similar to a Linux distribution on Windows.\n",
+		"description": "This tutorial examines the interaction between **NGSI-LD** and **JSON-LD** `@context` files. The `@context` files generated in the [previous tutorial](https://github.com/FIWARE/tutorials.Understanding-At-Context) are used as the underlying data model for inputing context data and context information is queries and read back in different formats.\n\nThe `docker-compose` file for this tutorial can be found on GitHub: \n\n![GitHub](https://fiware.github.io/tutorials.Getting-Started/icon/GitHub-Mark-32px.png) [FIWARE-LD 102: Working with `@context` ](https://github.com/FIWARE/tutorials.Getting-Started/tree/NGSI-LD)\n\n# Working with `@context` files\n\n> “Some quotations are greatly improved by lack of context.”\n>\n> ― John Wyndham, The Midwich Cuckoos\n\nFrom the [previous tutorial](https://github.com/FIWARE/tutorials.Understanding-At-Context) we have generated two `@context` files defining the context data entities which will be offered in our simple Smart Farm Management System. This means that we have defined an agreed set of unique IDs (URNs or URLs) for all the\ndata entities and every single attribute within those entities so that other external applications will be able to programmatically understand the data held within our broker.\n\nFor example the attribute `address` is within our smart application is defined as follows:\n\n```jsonld\n\"@context\": {\n    \"schema\": \"https://schema.org/\",\n    \"address\": \"schema:address\"\n}\n```\n\nWhich means that every `address` attribute follows the definition as defined by `schema.org`:\n\n`https://schema.org/address` :\n\n![](https://fiware.github.io/tutorials.Working-with-At-Context/img/architecture-ld.png)\n\nA program written by a third party would therefore be able to extract information such the fact an `address` attribute holds a JSON object with a sub-attribute containing the `streetAddress`  by referring to the full [schema.org **JSON-LD** schema](https://schema.org/version/latest/schemaorg-current-http.jsonld)\n\n```jsonld\n{\n  \"@id\": \"http://schema.org/streetAddress\",\n  \"@type\": \"rdf:Property\",\n  \"http://schema.org/domainIncludes\": {\n    \"@id\": \"http://schema.org/PostalAddress\"\n  },\n  \"http://schema.org/rangeIncludes\": {\n    \"@id\": \"http://schema.org/Text\"\n  },\n  \"rdfs:comment\": \"The street address. For example, 1600 Amphitheatre Pkwy.\",\n  \"rdfs:label\": \"streetAddress\"\n}\n```\n\nThis is the **JSON-LD** programmatic syntax allowing computers to extract meaningful data _The attribute `address.streetAddress` is a street_ directly without the need for human intervention.\n\nImagine the case where a company is contracting agricultural labourers. The farmer will need to be billed for the work done. If such a system is built on JSON-LD, it does not matter if the farmer's Farm Management Information System assigns different names to the attributes of the billing address provided that the farmer and contractor can agree on the well-defined URNS for each attribute as **JSON-LD** can easily translate between the two formats using common expansion and compaction algorithms.\n\n## NGSI-LD Rules\n\n**NGSI-LD** is a formally structured _extended subset_ of **JSON-LD**. Therefore **NGSI-LD** offers all the interoperability and flexibility of **JSON-LD** itself. It also defines its own core `@context` which cannot be overridden for **NGSI-LD** operations. This means that **NGSI-LD** users agree to a common well defined set of rules for structuring their data, and then supplement this with the rest of the **JSON-LD** specification.\n\nWhilst interacting directly with **NGSI-LD** interface of the context broker the additional **NGSI-LD** rules must be respected. However after the data has been extracted it is possible to loosen this requirement and pass the results to third parties as **JSON-LD**.\n\nThis tutorial is a simple introduction to the rules and restrictions behind **NGSI-LD** and  will create some **NGSI-LD** entities and then extract the data in different formats. The two main data formats are _normalized_ and _key-value-pairs_. Data returned in the  _normalised_ format respects the **NGSI-LD** rules and may be used directly by another context broker (or any other component offering an **NGSI-LD** interface). Data returned in the  _key-value-pairs_ format is by definition not **NGSI-LD**.\n\n## Content negociation and the `Content-Type` and `Accept` Headers\n\nDuring content negociation, **NGSI-LD** offers data in one of three formats, these effect the structure of the payload body.\n\n- `Accept: application/json` - the response is in **JSON** format\n- `Accept: application/ld+json` - the response is in **JSON-LD** format\n- `Accept: application/geo+json` - the response is in **GeoJSON** or **GeoJSON-LD** format\n\nThe major difference between **JSON** format and **JSON-LD** format, is that if **JSON-LD** format is chosen, then the `@context` is found as an additional attribute within the body of the response. if the **JSON** only format is used the `@context` is passed as an additional `Link` Header element and is not found in the response body.\n\nSimilarly when sending **NGSI-LD** data to the context broker, an application may choose to send a payload including an additional `@context` attribute (in which case `Content-Type: application/ld+json`) or the application may send NGSI-LD data without an additional `@context` attribute (in which case `Content-Type: application/json` and the `Link` header must also be present).\n\nThe **GeoJSON** format is only used when querying a context broker for existing data and returns the context in a format suitable for GIS systems. It is a recent addition to the **NGSI-LD** specification and therefore will not be discussed further here.\n\n# Prerequisites\n\n## Docker\n\nTo keep things simple all components will be run using [Docker](https://www.docker.com). **Docker** is a container\ntechnology which allows to different components isolated into their respective environments.\n\n-   To install Docker on Windows follow the instructions [here](https://docs.docker.com/docker-for-windows/)\n-   To install Docker on Mac follow the instructions [here](https://docs.docker.com/docker-for-mac/)\n-   To install Docker on Linux follow the instructions [here](https://docs.docker.com/install/)\n\n**Docker Compose** is a tool for defining and running multi-container Docker applications. A\n[YAML file](https://raw.githubusercontent.com/Fiware/tutorials.Working-with-At-Context/master/docker-compose/orion-ld.yml) is used\nconfigure the required services for the application. This means all container services can be brought up in a single\ncommand. Docker Compose is installed by default as part of Docker for Windows and Docker for Mac, however Linux users\nwill need to follow the instructions found [here](https://docs.docker.com/compose/install/)\n\n## WSL\n\nWe will start up our services using a simple bash script. Windows users should download the [Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install)\nto provide a command-line functionality similar to a Linux distribution on Windows.\n",
 		"schema": "https://schema.getpostman.com/json/collection/v2.1.0/collection.json",
 		"_exporter_id": "513743",
 		"_collection_link": "https://fiware.postman.co/workspace/NGSI-LD-tutorials~60157bf9-a93f-4c6e-90d1-0917133c1872/collection/513743-37a6dc59-bcbb-4813-b1b3-5b088f4e3bdd?action=share&creator=513743&source=collection_link"

README.ja.md

@@ -26,7 +26,7 @@
     -   [コンテント・ネゴシエーションと `Content-Type` と `Accept` ヘッダ](#content-negotiation-and-the-content-type-and-accept-headers)
 -   [前提条件](#prerequisites)
     -   [Docker](#docker)
-    -   [Cygwin](#cygwin)
+    -   [WSL](#wsl)
 -   [アーキテクチャ](#architecture)
 -   [起動](#start-up)
 -   [NGSI-LD データ・エンティティの作成](#creating-ngsi-ld-data-entities)
@@ -165,12 +165,10 @@ _normalised_ 形式で返されるデータは **NGSI-LD** ルールを尊重し
 できることを意味します。Docker Compose は、Docker for Windows および Docker for Mac の一部としてデフォルトでインストール
 されますが、Linux ユーザは[こちら](https://docs.docker.com/compose/install/)にある手順に従う必要があります。
 
-<a name="cygwin"/>
-
-## Cygwin
+## WSL
 
 簡単な bash スクリプトを使ってサービスを開始します。Windows ユーザは、Windows 上の Linux ディストリビューションに
-似たコマンドライン機能を提供するために [cygwin](http://www.cygwin.com/) をダウンロードするべきです。
+似たコマンドライン機能を提供するために [を使用して Windows に Linux をインストールする方法](https://learn.microsoft.com/ja-jp/windows/wsl/install) をダウンロードするべきです。
 
 <a name="architecture"/>
 

README.md

@@ -33,7 +33,7 @@ The tutorial uses [cUrl](https://ec.haxx.se/) commands throughout, but is also a
     -   [Content Negotiation and the `Content-Type` and `Accept` Headers](#content-negotiation-and-the-content-type-and-accept-headers)
 -   [Prerequisites](#prerequisites)
     -   [Docker](#docker)
-    -   [Cygwin](#cygwin)
+    -   [WSL](#wsl)
 -   [Architecture](#architecture)
 -   [Start Up](#start-up)
 -   [Creating NGSI-LD data entities.](#creating-ngsi-ld-data-entities)
@@ -167,10 +167,11 @@ used configure the required services for the application. This means all contain
 single command. Docker Compose is installed by default as part of Docker for Windows and Docker for Mac, however Linux
 users will need to follow the instructions found [here](https://docs.docker.com/compose/install/)
 
-## Cygwin
+## WSL
 
-We will start up our services using a simple bash script. Windows users should download [cygwin](http://www.cygwin.com/)
-to provide a command-line functionality similar to a Linux distribution on Windows.
+We will start up our services using a simple bash script. Windows users should download the
+[Windows Subsystem for Linux](https://learn.microsoft.com/en-us/windows/wsl/install) to provide a command-line
+functionality similar to a Linux distribution on Windows.
 
 # Architecture