611 docker examples should be up to date with new reasoner level configuration

docs/docs/faq.md

@@ -254,18 +254,15 @@ For ontologies, the subset/superset definition is sometimes explained as follows
 
 Since the idea of the Knowledge Engine is that the *data* is always kept at the source and is only retrieved when necessary for an interaction, it is more suitable to talk about subset/superset at the definition level and not at the data level.
 This is because all data is simply not available in a single location.
-The definition level is also the level where currently the *matching* between graph patterns happens.
-The *matcher* (as opposed to the *reasoner*) does not support subset/superset matching.
+The definition level is also the level where currently the *matching* between graph patterns happens and the *reasoner* supports subset/superset matching.
 
 We can consider the following concrete questions when dealing with subset/superset:
 1. Is `a b c.` a subset or superset of `a b c . d e f .`?
 	- I would say graph pattern `a b c` is a subset of the graph pattern `a b c . d e f`.
    		Note that graph pattern typically contain variables like `?a`.
    		Graph pattern _matching_ ignores variable names and triple order.
 2. When using POST/REACT, do argument and result graph patterns *both* need to match or can they be a subset/superset?
-	- Yes, the argument graph pattern and result graph pattern should both match if two POST/REACT interactions want to exchange data.
-   	This may change when you use the reasoner instead of the matcher.
+	- No, the argument graph pattern and result graph pattern do not need to match if two POST/REACT interactions want to exchange data. If the POST does not have a result graph pattern, but the REACT does have a result graph pattern, the result binding set from the REACT will not reach the results of the POST. When the POST has both a argument and result graph pattern, but the REACT does not have a result graph pattern, then the REACT will still trigger, but its result will end up being empty in the results of the POST.
 3. Would the following interactions match? A REACT with result graph pattern `a b c. d e f.` and a POST with result graph pattern `a b c.`
-	- This will not match if you are using the graph pattern _matcher_ instead of a _reasoner_.
-    The reasoner would allow them to interact if the POST result pattern is a subset of the REACT result pattern.
+    - The reasoner would allow them to interact if the POST result pattern is a subset of the REACT result pattern.
     In that case, the result binding set at the POST side should also be a subset (in fields) of the binding set given by the REACT side.

docs/docs/get-started/graph-patterns.md

@@ -69,8 +69,7 @@ So, if you write them twice, they will still only occur once.
 So, by using a fixed individual for `property` in the graph pattern, it becomes semantically impossible to determine that `sensor1` is measuring the property Motion and Smoke, while sensor2 is measuring Energy!
 
 Therefore, while using a fixed property is syntactically correct, it is semantically incorrect.
-Using a fixed property in the current version of the KE (with a matcher instead of a reasoner) will probably work fine and the data is exchanged as expected.
-This is, however, probably not the case with the future version of the KE with reasoner, because the reasoner will actually semantically interpret the graph pattern and binding set and when you ask something like:
+Using a fixed property in the KE with reasoner will not work, because the reasoner will actually semantically interpret the graph pattern and binding set and when you ask something like:
 
   ```sparql
   ?device <https://saref.etsi.org/core/measuresProperty> <http://interconnectproject.eu/pilots/greek/property#property> .

examples/reasoner/docker-compose.yml

@@ -6,7 +6,7 @@ services:
     environment:
       KE_URL: http://knowledge-engine:8280/rest
       KB_ID: http://example.org/kb1
-      ENABLE_REASONER: true
+      KE_REASONER_LEVEL: 2
       PREFIXES: |
         {
           "ex": "http://example.org/",

examples/unreachable-runtimes/docker-compose.yml

@@ -21,7 +21,6 @@ services:
       KE_RUNTIME_PORT: 8081 # The port that the KE uses to listen for inter-KE-runtime communication.
       KE_RUNTIME_EXPOSED_URL: http://runtime-1:8081 # The URL where the runtime is available for inter-runtime communication from the outside.
       KD_URL: http://knowledge-directory:8282
-      ENABLE_REASONER: false
       JAVA_TOOL_OPTIONS: "-Djdk.httpclient.keepalive.timeout=1 -agentlib:jdwp=transport=dt_socket,address=0.0.0.0:8000,server=y,suspend=n"
   runtime-2:
     build: .
@@ -31,7 +30,6 @@ services:
       KE_RUNTIME_PORT: 8081
       KE_RUNTIME_EXPOSED_URL: http://runtime-2:8081
       KD_URL: http://knowledge-directory:8282
-      ENABLE_REASONER: false
       JAVA_TOOL_OPTIONS: "-Djdk.httpclient.keepalive.timeout=1"
     extra_hosts:
       - "host.docker.internal:host-gateway"
@@ -43,7 +41,6 @@ services:
       KE_RUNTIME_PORT: 8081
       KE_RUNTIME_EXPOSED_URL: http://runtime-3:8081
       KD_URL: http://knowledge-directory:8282
-      ENABLE_REASONER: false
       JAVA_TOOL_OPTIONS: "-Djdk.httpclient.keepalive.timeout=1"
     extra_hosts:
       - "host.docker.internal:host-gateway"