Theory — OWL 2 RL
The RL philosophy
OWL 2 RL was designed so that every axiom corresponds to a Datalog rule. A reasoner doesn't 'reason' at query time — it walks the rules forward to a fixed point, and writes the inferred triples back into the graph (this is called forward chaining or materialisation).
The trade-off is explicit:
| Profile | When does inference happen? | Where do inferred triples live? |
|---|---|---|
| DL (MedaCore) | Query time (or on classify) | In memory, may not persist |
| EL (NorthWind) | On classify | Pre-materialised |
| QL (Atlas) | Never persisted — rewritten into SQL | Virtual |
| RL (HARBOUR) | On update | Stored as ordinary triples |
Why RL fits HARBOUR
Container moves happen continuously. The duty officer's dashboard queries the graph dozens of times per minute. We cannot afford query-time reasoning — it must be pre-computed. RL materialises the :HazardousCall membership as soon as the container's :hazardCode triple is asserted.
RL-safe vs RL-unsafe
RL permits existentials only on the super-class side of subClassOf (and on the right of equivalentClass definitions that fit the pattern). It forbids existentials on the sub-class side that would require creating new individuals — that's where DL is needed.
Rule of thumb: if a learner finds themselves wanting to express 'every Vessel HAS some Hold' (existential on the sub-class side, asking the reasoner to invent a hold), RL is the wrong profile. RL only re-classifies individuals that already exist.