The Design Decision
Loka will never reject a triple for violating an OWL constraint. The database accepts everything. It is a store, not a reasoner.
OWL validation happens in the SDKs (Python, TypeScript, Rust, etc.), not in the database engine. When you insert a triple through an SDK:
- The SDK loads the OWL ontology from the database
- The SDK checks the triple against OWL constraints (domain, range, cardinality, disjoint classes, etc.)
- If the triple violates a constraint, the SDK throws an exception before the triple reaches the database
- If the triple passes, the SDK sends it to the database, which stores it unconditionally
Why Not Validate in the Database?
- Performance: OWL reasoning can be computationally expensive (OWL DL is decidable but worst-case exponential). Putting this in the write path would make inserts unpredictably slow.
- Flexibility: Sometimes you want to store data that violates the ontology — during migration, bulk import, or when the ontology itself is being revised.
- Simplicity: The database engine stays lean. It does one thing (store and query triples) and does it well. Reasoning is a separate concern.
SDK Behavior
| Setting | Behavior |
|---|
| OWL validation enabled (default) | SDK throws on constraint violation before sending to database |
| OWL validation disabled | SDK sends all triples directly, no checking |
| Direct HTTP/SPARQL access | No validation — database accepts everything |
OWL validation is enabled by default in all SDKs. This means most users get constraint checking out of the box, but can disable it when they need raw performance or flexibility.
OWL as Data
The OWL ontology is stored in the database as regular RDF triples. The SDKs read it from the database and use it for validation. This means:
- The ontology is queryable via SPARQL like any other data
- The ontology can be updated by inserting/deleting triples
- Loka Studio can browse and visualize the ontology (Protege-like functionality)