@@ -4,33 +4,34 @@ The Knowledge Graph (or KG for short) is a data structure that describes the ind
...
@@ -4,33 +4,34 @@ The Knowledge Graph (or KG for short) is a data structure that describes the ind
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:
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/).
- 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))
- 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))
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 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/index 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 definitions:
To simplify the presentation, from now on, we will use a prefixed notation for all IRIs, according to the following prefix and base definitions:
The most important parts of the KG are the description of the machines, especially the ones identified as [itm:bosch-apas](https://ci.mines-stetienne.fr/kg/itmfactory/bosch-apas), [itm:dx10](https://ci.mines-stetienne.fr/kg/itmfactory/dx10), [itm:vl10](https://ci.mines-stetienne.fr/kg/itmfactory/vl10), and [itm:xy10](https://ci.mines-stetienne.fr/kg/itmfactory/xy10).
The most important parts of the KG are the description of the machines, especially the ones identified as [<bosch-apas#this>](https://ci.mines-stetienne.fr/kg/itmfactory/bosch-apas), [<dx10#this>](https://ci.mines-stetienne.fr/kg/itmfactory/dx10), [<vl10#this>](https://ci.mines-stetienne.fr/kg/itmfactory/vl10), and [<xy10#this>](https://ci.mines-stetienne.fr/kg/itmfactory/xy10). When we identify real world machines, we append `#this` to the name of the file that describes the machine. Therefore `<dx10>` (or `itm:dx10`) identifies an RDF file, while `<dx10#this>` identifies a filling machine.
## Finding affordances
## Finding affordances
These machines are identified as 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 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.
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.
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:locationOfInputMaterial), and a location where the final product will be placed (onto:locationOfProduct). For instance, the filling machine (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.
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 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.
...
@@ -43,13 +44,13 @@ The production line is described according to the pattern of the figure below:
...
@@ -43,13 +44,13 @@ The production line is described according to the pattern of the figure below:
In practice, the blank nodes will have a specific identifier, and it may be typed with a different class than what is shown in the diagram above. However, a class hierarchy can help inferring that a given entity is of the appropriate type. For instance, here is a piece of the description of the IT'm Factory:
In practice, the blank nodes will have a specific identifier, and it may be typed with a different class than what is shown in the diagram above. However, a class hierarchy can help inferring that a given entity is of the appropriate type. For instance, here is a piece of the description of the IT'm Factory:
