OWLRL

This module is a brute force implementation of the OWL 2 RL profile.

RDFLib works with ‘generalized’ RDF, meaning that triples with a BNode predicate are allowed. This is good because, e.g., some of the triples generated for RDF from an OWL 2 functional syntax might look like [ owl:inverseOf p ], and the RL rules would then operate on such generalized triple. However, as a last, post processing steps, these triples are removed from the graph before serialization to produce ‘standard’ RDF (which is o.k. for RL, too, because the consequent triples are all right, generalized triples might have had a role in the deduction steps only).

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.OWLRL.OWLRL_Semantics(graph, axioms, daxioms, rdfs=None)[source]

Bases: owlrl.Closure.Core

OWL 2 RL Semantics class, i.e., implementation of the OWL 2 RL closure graph.

Note

Note that the module does not implement the so called Datatype entailment rules, simply because the underlying RDFLib does not implement the datatypes (i.e., RDFLib will not make the literal “1.00” and “1.00000” identical, although even with all the ambiguities on datatypes, this 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 OWL 2 RL document.

Parameters
  • 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()[source]

Add axioms

add_d_axioms()[source]

Add the datatype axioms

add_error(message)

Add an error message

Parameters

message (str) – Error message.

closure()

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_stored_triples()

Empty the internal store for triples.

flush_stored_triples()

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

one_time_rules()[source]

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.

These are: cls-thing, cls-nothing1, prp-ap, dt-types1, dt-types2, dt-eq, dt-diff.

post_process()[source]

Remove triples with Bnode predicates. The Bnodes in the graph are collected in the first cycle run.

pre_process()

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.

restriction_typing_check(v, t)[source]

Helping method to check whether a type statement is in line with a possible restriction. This method is invoked by rule “cls-avf” before setting a type on an allValuesFrom restriction.

The method is a placeholder at this level. It is typically implemented by subclasses for extra checks, e.g., for datatype facet checks.

Parameters
  • v – The resource that is to be ‘typed’.

  • t – The targeted type (ie, Class).

Returns

Boolean.

Return type

bool

rules(t, cycle_num)[source]

Go through the various rule groups, as defined in the OWL-RL profile text and implemented via local methods. (The calling cycle takes every tuple in the graph.)

Parameters
  • t – A triple (in the form of a tuple).

  • cycle_num – Which cycle are we in, starting with 1. This value is forwarded to all local rules; it is also used locally to collect the bnodes in the graph.

store_triple(t)

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

owlrl.OWLRL.identity(v)