When deploying a knowledge graph to production, three triplestores dominate: GraphDB, Stardog, and RDFox. Each approaches reasoning differently.
rdfs:subClassOf
rdfs:subPropertyOf
rdfs:domain/range
owl:sameAs
owl:equivalentClass
owl:inverseOf
owl:TransitiveProperty
owl:FunctionalProperty
owl:SymmetricProperty
owl:intersectionOf
owl:unionOf
owl:someValuesFrom
owl:allValuesFrom
owl:propertyChainAxiom
owl:hasKey
owl:AllDisjointClasses
Key insight: RDF Studio's native Rust engine implements 35 OWL 2 RL rules — covering all important inference patterns used in production ontologies.
The Lehigh University Benchmark (LUBM) is the standard for testing triplestore reasoning performance. From published benchmarks:
"In RDFox and GraphDB inferences are Materialized. For this test, Stardog was configured with reasoning type SL for a combination of RDFS, QL, RL, and EL axioms, plus SWRL rules. RDFox was set to use its fragment of OWL 2 RL, and GraphDB was set to use OWL-Horst Optimized."
"GraphDB inferred nearly twice as many triples as RDFox using the default OWL-Horst Optimized inference ruleset. The OWL 2 RL Optimized was tried (same used by RDFox), however, it threw a heap memory error after running for many hours."
This tells us:
RDF Studio reasons over ontology schemas (TBox) — typically 100–2000 triples. The LUBM benchmark tests reasoning over instance data (ABox) — 100M+ triples. Our use case is 5 orders of magnitude smaller:
GraphDB defaults to OWL-Horst Optimized, which is based on the pD* semantics — a subset of RDFS plus select OWL constructs:
rdfs:subClassOf/subPropertyOf
owl:equivalentClass/equivalentProperty
owl:InverseFunctionalProperty
To get full OWL 2 RL in GraphDB, you must explicitly configure the owl2-rl ruleset — but as the LUBM benchmark showed, this can be extremely resource-intensive on large datasets.
owl2-rl
Stardog's SL (Stardog Language) profile is unique — it combines rules from multiple OWL 2 profiles:
Because Stardog uses query rewriting instead of materialization, it can afford to support this broader rule set without the memory explosion that affects GraphDB's materialization.
RDFox is built by the team at Oxford who invented many OWL reasoning algorithms. It uses:
RDFox's key innovation is its incremental maintenance — when you add or delete a triple, it doesn't recompute the entire closure. It tracks dependencies and only updates the affected inferences.
When you delete a triple that contributed to an inference, the triplestore must decide what to do with the inferred triples. This is the retraction problem, and each triplestore handles it very differently:
RDF Studio's approach (Phase 1): Re-reason the entire ontology from scratch (~200ms for typical ontologies). This matches GraphDB's strategy and is fast enough for TBox-only reasoning. A future Phase 2 may add incremental retraction in Rust for instance data reasoning.
RDFox's incremental maintenance uses the DRed (Delete/Rederive) algorithm:
This is significantly faster than GraphDB's full recomputation for small changes to large datasets — but adds complexity and memory overhead for dependency tracking.
Beyond the "big three," several other triplestores exist with varying reasoning support:
.rules
Key takeaway: Most triplestores provide little to no OWL reasoning out of the box. GraphDB, Stardog, and RDFox are exceptions — and even they differ significantly in coverage and approach.