3 · Deployment — RDFox, materialised alarms, idempotent updates

Why RDFox

RDFox (Oxford Semantic Technologies) is the reference implementation of high-performance OWL 2 RL with incremental materialisation. When a container's hazard code is asserted, RDFox does NOT recompute the whole graph — it walks just the rules whose antecedents include the new triple, and adds (or retracts) the consequents. Latency: milliseconds.

Alternatives: Stardog with ICV-RL, GraphDB with the OWL2-RL ruleset, or Apache Jena with custom rules. The shape of the deployment is the same.

The data flow

1. A container-tracking event arrives on Kafka.
2. A small consumer asserts :container/X :hazardCode haz:IMDG_3 into RDFox.
3. RDFox's incremental materialiser fires the :HazardousCall rule. The vessel call gets a new rdf:type :HazardousCall triple — automatically.
4. The dashboard queries every 2 seconds: SELECT ?call WHERE { ?call a :HazardousCall ; :assignedBerth ?b . ?b a :PassengerBerth }. The duty officer is alerted.

Notice step 4 is trivial SPARQL. All the semantics happened in step 3, at write time. The query layer doesn't need a reasoner.

Idempotent updates — the operations principle

The Kafka consumer asserts the same triple every time it sees the same event. RDF is a set; re-asserting is a no-op. The downstream materialisation is idempotent because the assertion itself is idempotent. This is why streaming + RDF is a natural fit — exactly-once is structural, not engineered.