From 8f29db6dbde6fba038fd5e262bd422543f8f08fe Mon Sep 17 00:00:00 2001 From: Barry Nouwt Date: Tue, 14 Jul 2026 14:11:43 +0200 Subject: [PATCH] Change directory name and improve README.md --- .../README.md | 86 +++++++------------ .../dk.rules | 0 .../docker-compose.yml | 0 .../gladoss/adaptors/.gitignore | 0 .../gladoss/adaptors/knowledge_engine.py | 0 .../gladoss/adaptors/knowledge_engine.toml | 0 .../requirements_verification.sh | 0 .../sensor/Dockerfile | 0 .../sensor/test_device_publisher.sh | 0 9 files changed, 31 insertions(+), 55 deletions(-) rename examples/{anomaly-detection => data-exchange-and-validation}/README.md (81%) rename examples/{anomaly-detection => data-exchange-and-validation}/dk.rules (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/docker-compose.yml (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/gladoss/adaptors/.gitignore (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/gladoss/adaptors/knowledge_engine.py (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/gladoss/adaptors/knowledge_engine.toml (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/requirements_verification.sh (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/sensor/Dockerfile (100%) rename examples/{anomaly-detection => data-exchange-and-validation}/sensor/test_device_publisher.sh (100%) diff --git a/examples/anomaly-detection/README.md b/examples/data-exchange-and-validation/README.md similarity index 81% rename from examples/anomaly-detection/README.md rename to examples/data-exchange-and-validation/README.md index e1d1c27f..fa631659 100644 --- a/examples/anomaly-detection/README.md +++ b/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: - - 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 `[PASSED]` +## 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: diff --git a/examples/anomaly-detection/dk.rules b/examples/data-exchange-and-validation/dk.rules similarity index 100% rename from examples/anomaly-detection/dk.rules rename to examples/data-exchange-and-validation/dk.rules diff --git a/examples/anomaly-detection/docker-compose.yml b/examples/data-exchange-and-validation/docker-compose.yml similarity index 100% rename from examples/anomaly-detection/docker-compose.yml rename to examples/data-exchange-and-validation/docker-compose.yml diff --git a/examples/anomaly-detection/gladoss/adaptors/.gitignore b/examples/data-exchange-and-validation/gladoss/adaptors/.gitignore similarity index 100% rename from examples/anomaly-detection/gladoss/adaptors/.gitignore rename to examples/data-exchange-and-validation/gladoss/adaptors/.gitignore diff --git a/examples/anomaly-detection/gladoss/adaptors/knowledge_engine.py b/examples/data-exchange-and-validation/gladoss/adaptors/knowledge_engine.py similarity index 100% rename from examples/anomaly-detection/gladoss/adaptors/knowledge_engine.py rename to examples/data-exchange-and-validation/gladoss/adaptors/knowledge_engine.py diff --git a/examples/anomaly-detection/gladoss/adaptors/knowledge_engine.toml b/examples/data-exchange-and-validation/gladoss/adaptors/knowledge_engine.toml similarity index 100% rename from examples/anomaly-detection/gladoss/adaptors/knowledge_engine.toml rename to examples/data-exchange-and-validation/gladoss/adaptors/knowledge_engine.toml diff --git a/examples/anomaly-detection/requirements_verification.sh b/examples/data-exchange-and-validation/requirements_verification.sh similarity index 100% rename from examples/anomaly-detection/requirements_verification.sh rename to examples/data-exchange-and-validation/requirements_verification.sh diff --git a/examples/anomaly-detection/sensor/Dockerfile b/examples/data-exchange-and-validation/sensor/Dockerfile similarity index 100% rename from examples/anomaly-detection/sensor/Dockerfile rename to examples/data-exchange-and-validation/sensor/Dockerfile diff --git a/examples/anomaly-detection/sensor/test_device_publisher.sh b/examples/data-exchange-and-validation/sensor/test_device_publisher.sh similarity index 100% rename from examples/anomaly-detection/sensor/test_device_publisher.sh rename to examples/data-exchange-and-validation/sensor/test_device_publisher.sh