Documentation-of-the-Knowledge-Graph.md

-The Knowledge Graph (or KG for short) is a data structure that describes the industrial system, the machines, the sensors and actuators,  the interfaces, the configuration and the environment of this system. In its largest extent, our KG is distributed, with parts of it hosted in France, in Germany and in Switzerland.
+The Knowledge Graph (or KG for short) is a data structure that describes the industrial system, the machines, the sensors and actuators,  the interfaces, the configuration and the environment of this system.
 
 ## Preliminaries
 
 Our KG is stored using the [Resource Description Framework](https://www.w3.org/TR/rdf11-primer/) (RDF), a Web standard for data exchange and interlinking on the Web. The largest part of the KG is hosted by Mines Saint-Étienne and accessible in two ways:
 - via a graph database (called a triplestore) by way of [SPARQL queries](https://www.w3.org/TR/sparql11-query/).
-- in multiple small files that each describe a particular element of the system, with links to related resources (see for instance the description of the [IT'm Factory](https://ci.mines-stetienne.fr/kg8/itmfactory/itm#this))
+- in multiple small files that each describe a particular element of the system, with links to related resources (see for instance the description of the [IT'm Factory](https://ci.mines-stetienne.fr/kg/itmfactory/itm#this))
 
-Following the RDF recommendation, the KG identifies every thing using [Internationalized Resource Identifiers](https://www.ietf.org/rfc/rfc3987.txt) (or IRIs). The factory in Mines Saint-Étienne and everything inside makes use of IRIs of the form: https://ci.mines-stetienne.fr/kg/itmfactory/XXXX#this where XXXX is the local name of the entity being identified. Mines Saint-Étienne describes its buildings, rooms, spaces, and itself by identifying these things with IRIs of the form: https://ci.mines-stetienne.fr/kg/emse/XXXX. Additionally, the document at https://ci.mines-stetienne.fr/kg/index serves as a configuration file that makes explicit which machines the production line consists in, and that links to relevant information.
+Following the RDF recommendation, the KG identifies every thing using [Internationalized Resource Identifiers](https://www.ietf.org/rfc/rfc3987.txt) (or IRIs). The factory in Mines Saint-Étienne and everything inside makes use of IRIs of the form: https://ci.mines-stetienne.fr/kg/itmfactory/XXXX#this where XXXX is the local name of the entity being identified. Mines Saint-Étienne describes its buildings, rooms, spaces, and itself by identifying these things with IRIs of the form: https://ci.mines-stetienne.fr/kg/emse/XXXX. Additionally, the document at https://ci.mines-stetienne.fr/kg serves as a configuration file that makes explicit which machines the production line consists in, and that links to relevant information.
 
 To simplify the presentation, from now on, we will use a prefixed notation for all IRIs, according to the following prefix and base definitions:
 
@@ -27,13 +27,13 @@ The most important parts of the KG are the description of the machines, especial
 
 ## Finding affordances
 
-These machines are identified as instances of `td:Thing` and their description contains the interfaces for their property affordances and action affordances (what they can "tell" and what they can "do"). For each affordance, we provide a `td:name` that helps identifying what the affordance serves for. An affordance has a form (`td:hasForm`) which is itself composed of several characteristics: a target (`hctl:hasTarget`) that identifies what resource must be queried, and what is the content type of the payload for the request (`hctl:forContentType`). Each affordance have a type, usually defined in our custom ontology. These types of affordance can be used to find mutiple affordances that serves a similar purpose. For instance, `onto:ActivityStatus` correspond to a type of affordance that provides a status about a certain action. This way, it is not always necessary to know the name (`td:name`) of an affordance to find it and use it. Some affordances require a certain JSON schema, which is documented using the `js:` vocabulary.
+These machines are identified as instances of `td:Thing` and their description contains the interfaces for their property affordances and action affordances (what they can "tell" and what they can "do"). For each affordance, we provide a `td:name` that helps identifying what the affordance serves for. An affordance has a form (`td:hasForm`) which is itself composed of several characteristics: a target (`hctl:hasTarget`) that identifies what resource must be queried, and what is the content type of the payload for the request (`hctl:forContentType`). Each affordance have a type, usually defined in our custom ontology. These types of affordances can be used to find mutiple affordances that serves a similar purpose. For instance, `onto:ActivityStatus` correspond to a type of affordances that provide a status about a certain action. This way, it is not always necessary to know the name (`td:name`) of an affordance to find it and use it. Some affordances require a certain JSON schema, which is documented using the `js:` vocabulary.
 
 Some machines have multiple affordances of the same type (because they achieve the same thing but at different places). For instance, there are multiple optical sensors in the filling machine, at each end of the conveyor belt. To select the right one, it may be necessary to rely on their `td:name`, but for more flexibility, we will see how we can rely on the knowledge graph to find which affordance is associated with what physical property they act on or measure.
 
 In addition, each machine may have a location where material that must be used should be put (`onto:inputArea`), and a location where the final product will be placed (`onto:outputArea`). For instance, the filling machine (described in `itm:dx10`) has a location at one end of its conveyor belt where the empty cups are placed; it has a location at the other end of the conveyor belt where the full cups arrive. These locations are given with 3 coordinates (`onto:coordX`, `onto:coordY`, `onto:coordZ`). This way, it is possible to find in the knowledge graph the relevant location where the robotic arm has to move and take cups. To avoid changing the values of the coordinates each time a machine moves, the coordinates are given relatively to a point of reference of the machine, and the machine is located relatively to the room where they are.
 
-Moreover, the location of input material or the location of product are features of interest that may be observed by sensors, for instance, to detect the presence of a cup and start the filling process, or detect multiple a cup at the location of product so as to stop the filling machine and avoid accumulation of products at the end of the conveyor belt, etc.
+Moreover, the location of input material or the location of product are features of interest that may be observed by sensors, for instance, to detect the presence of a cup and start the filling process, or detect multiple cups at the location of product so as to stop the filling machine and avoid accumulation of products at the end of the conveyor belt, etc.
 
 ## Structure of the production line description