This module is brute force implementation of the RDFS semantics on the top of RDFLib (with some caveats, see in the introductory text).

Requires: RDFLib, 4.0.0 and higher.

License: This software is available for use under the W3C Software License.

Organization: World Wide Web Consortium

Author: Ivan Herman

class owlrl.RDFSClosure.RDFS_Semantics(graph, axioms, daxioms, rdfs)[source]

Bases: owlrl.Closure.Core

RDFS Semantics class, ie, implementation of the RDFS closure graph.


Note that the module does not implement the so called Datatype entailment rules, simply because the underlying RDFLib does not implement the datatypes (ie, RDFLib will not make the literal “1.00” and “1.00000” identical, although even with all the ambiguities on datatypes, this I{should} be made equal…).

Also, the so-called extensional entailment rules (Section 7.3.1 in the RDF Semantics document) have not been implemented either.

The comments and references to the various rule follow the names as used in the RDF Semantics document.

  • graph (rdflib.Graph) – The RDF graph to be extended.
  • axioms (bool) – Whether (non-datatype) axiomatic triples should be added or not.
  • daxioms (bool) – Whether datatype axiomatic triples should be added or not.
  • rdfs (bool) – Whether RDFS inference is also done (used in subclassed only).

Add axioms


This is not really complete, because it just uses the comparison possibilities that RDFLib provides.


Add an error message

Parameters:message (str) – Error message.

Generate the closure the graph. This is the real ‘core’.

The processing rules store new triples via the separate method Core.store_triple() which stores them in the added_triples array. If that array is empty at the end of a cycle, it means that the whole process can be stopped.

If required, the relevant axiomatic triples are added to the graph before processing in cycles. Similarly the exchange of literals against bnodes is also done in this step (and restored after all cycles are over).


Empty the internal store for triples.


Send the stored triples to the graph, and empty the container.


Some of the rules in the rule set are axiomatic in nature, meaning that they really have to be added only once, there is no reason to add these in a cycle. These are performed by this method that is invoked only once at the beginning of the process.

In this case this is related to a ‘hidden’ same as rules on literals with identical values (though different lexical values).


Do some post-processing step. This method when all processing is done, but before handling possible errors (ie, the method can add its own error messages). By default, this method is empty, subclasses can add content to it by overriding it.


Do some pre-processing step. This method before anything else in the closure. By default, this method is empty, subclasses can add content to it by overriding it.

rules(t, cycle_num)[source]

Go through the RDFS entailment rules rdf1, rdfs4-rdfs12, by extending the graph.

  • t (tuple) – A triple (in the form of a tuple).
  • cycle_num (int) – Which cycle are we in, starting with 1. Can be used for some (though minor) optimization.

In contrast to its name, this does not yet add anything to the graph itself, it just stores the tuple in an internal set (Core.added_triples). (It is important for this to be a set: some of the rules in the various closures may generate the same tuples several times.) Before adding the tuple to the set, the method checks whether the tuple is in the final graph already (if yes, it is not added to the set).

The set itself is emptied at the start of every processing cycle; the triples are then effectively added to the graph at the end of such a cycle. If the set is actually empty at that point, this means that the cycle has not added any new triple, and the full processing can stop.

Parameters:t (tuple (s,p,o)) – The triple to be added to the graph, unless it is already there