Change directory name and improve README.md

examples/anomaly-detection/README.md → examples/data-exchange-and-validation/README.md

@@ -1,73 +1,23 @@
-# Knowledge-driven Data Exchange and Validation Framework for Networked Smart Buildings
+# Semantics 2026: Knowledge-driven Data Exchange and Validation Framework for Networked Smart Buildings
 
 This is a demo combining a knowledge validator with the knowledge engine. We want to have a scenario that demonstrates/uses the following:
 - using a (saref + custom) ontology to reach semantic interoperability.
 - using context data (i.e. building data) about sensors to improve knowledge validator performance.
 - using a converter knowledge base to convert from Fahrenheit to Celsius and improve the knowledge validator performance.
 
-The example consists of 8 knowledge bases:
-
-- `knowledge-validator-kb`: A knowledge base that contains the knowledge validator which only looks at `building1`.
-  - It reacts to sensor measurements by printing the results.
-- `dashboard-kb`: A knowledge base that subscribes to anomaly reports published by the `knowledge-validator-kb`.
-  - It reacts to validation reports by logging them to the standard output.
-- `sensor1-kb`: A knowledge base that publishes celsius temperature measurements from a Dutch sensor type.
-  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
-  - This sensor should have the appropriate reasoner level and load RDFS rules and SAREF.
-- `sensor2-kb`: A knowledge base that publishes fahrenheit measurements from a United States sensor type.
-  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
-  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
-- `sensor3-kb`: A knowledge base that publishes celsius measurements from a European sensor type but is contained in building 2.
-  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
-  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
-  - The idea is that this sensor's data is not received by the knowledge validator.
-- `sensor4-kb`: A knowledge base that publishes fahrenheit measurements from a United States sensor type but is contained in building 2.
-  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
-  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
-  - The idea is that this sensor's data is not received by the knowledge validator.
-- `converter-kb`: A knowledge base that converts fahrenheit into celsius measurements.
-  - It converts bindings in the `ARGUMENT_PATTERN` form into bindings in the `RESULT_PATTERN` form, using the Python function `react` defined in `REACT_FUNCTION_DEF`.
-- `building-kb`: A knowledge base that contains static building information to provide more context information to the knowledge validator.
-
-## Running
-
-When running the project, and showing the logs of the `knowledge-validator-kb` service:
-
-```
-docker compose up -d
-docker compose logs -f dashboard-kb
-```
-
-After the knowledge validator's learning period is over, you will see that the `dashboard-kb` receives the validation reports:
-
-```
-dashboard-kb-1  | INFO:dashboard-kb:REACT KI is handling a request...
-dashboard-kb-1  | INFO:dashboard-kb:Reacting with empty bindingset to [ ... ]...
-dashboard-kb-1  | INFO:dashboard-kb:REACT KI is handling a request...
-dashboard-kb-1  | INFO:dashboard-kb:Reacting with empty bindingset to [ ... ]...
-```
-
-## Requirement verification instructions
+## Instructions
 
 To run and verify the demo, follow the instructions below. Note that they require console access. Only the last step for running the requirements verification script requires a \*nix system, while the other steps work on both Windows and *nix systems:
-<!--
-- extract `demo.zip` (note that it will extract into a folder called 'demo'): `unzip demo.zip`
-- navigate to the `demo` folder
-- make sure docker is installed and started: `docker --version`
-- remove any previous images with the same names: `docker image rm directory:latest knowledge-engine:latest knowledge-validator:latest`
-- load the included docker images:
-  - `docker image load -i directory.tar`
-  - `docker image load -i knowledge-validator.tar`
-  - `docker image load -i knowledge-engine.tar`
--->
 - build the docker compose project: `docker compose build`
 - run the docker compose project: `docker compose up -d`
 - wait until knowledge-validator is finished learned: `docker compose logs -f dashboard-kb`
-- Wait for text `Reacting with empty bindingset to …` to appear
+- Wait for text `Reacting with empty bindingset to …` to appear (this will take a few minutes)
 - Exit the dashboard logs using `CTRL+C`
 - Run the requirements verification script: `./requirements_verification.sh`
 - Wait for the script to finish with all tests <span style="color:green">`[PASSED]`</span>
 
+## Verification
+
 This demo verifies the requirements below.
 
 Knowledge Engine requirements:
@@ -85,6 +35,32 @@ Knowledge Validator requirements:
 - RQ.KV-5: Report on detected deviations
 - RQ.KV-6: Provide explanations for detected deviations
 
+## Components
+
+The example consists of 8 knowledge bases:
+
+- `knowledge-validator-kb`: A knowledge base that contains the knowledge validator which only looks at `building1`.
+  - It reacts to sensor measurements by printing the results.
+- `dashboard-kb`: A knowledge base that subscribes to anomaly reports published by the `knowledge-validator-kb`.
+  - It reacts to validation reports by logging them to the standard output.
+- `sensor1-kb`: A knowledge base that publishes celsius temperature measurements from a Dutch sensor type.
+  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
+  - This sensor should have the appropriate reasoner level and load RDFS rules and SAREF.
+- `sensor2-kb`: A knowledge base that publishes fahrenheit measurements from a United States sensor type.
+  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
+  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
+- `sensor3-kb`: A knowledge base that publishes celsius measurements from a European sensor type but is contained in building 2.
+  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
+  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
+  - The idea is that this sensor's data is not received by the knowledge validator.
+- `sensor4-kb`: A knowledge base that publishes fahrenheit measurements from a United States sensor type but is contained in building 2.
+  - It makes available the data in `KB_DATA`, using the pattern in `GRAPH_PATTERN`
+  - This sensor should have the appropriate reasoner level and load RDFS rules and a custom ontology.
+  - The idea is that this sensor's data is not received by the knowledge validator.
+- `converter-kb`: A knowledge base that converts fahrenheit into celsius measurements.
+  - It converts bindings in the `ARGUMENT_PATTERN` form into bindings in the `RESULT_PATTERN` form, using the Python function `react` defined in `REACT_FUNCTION_DEF`.
+- `building-kb`: A knowledge base that contains static building information to provide more context information to the knowledge validator.
+
 ## Ontology
 We use the following simple custom ontology based on SAREF: