Closure

The generic superclasses for various rule based semantics and the possible extensions.

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.Closure.Core(graph, axioms, daxioms, rdfs=False)

Bases: object

Core of the semantics management, dealing with the RDFS and other Semantic triples. The only reason to have it in a separate class is for an easier maintainability.

This is a common superclass only. In the present module, it is subclassed by a RDFSClosure.RDFS_Semantics class and a OWLRL.OWLRL_Semantics classes. There are some methods that are implemented in the subclasses only, ie, this class cannot be used by itself!

Parameters:

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

Variables:

• IMaxNum – Maximal index of rdf:_i occurrence in the graph.
• graph – The real graph.
• axioms – Whether axioms should be added or not.
• daxioms – Whether datatype axioms should be added or not.
• added_triples – Triples added to the graph, conceptually, during one processing cycle.
• error_messages – Error messages (typically inconsistency messages in OWL RL) found during processing. These are added to the final graph at the very end as separate BNodes with error messages.
• rdfs – Whether RDFS inference is also done (used in subclassed only).

add_axioms()

Add axioms.

This is only a placeholder and raises an exception by default; subclasses must fill this with real content

add_d_axioms()

Add d axioms.

This is only a placeholder and raises an exception by default; subclasses I{must} fill this with real content

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

This is only a placeholder; subclasses should fill this with real content. By default, it is just an empty call. This set of rules is invoked only once and not in a cycle.

post_process()

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.

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.

rules(t, cycle_num)

The core processing cycles through every tuple in the graph and dispatches it to the various methods implementing a specific group of rules. By default, this method raises an exception; indeed, subclasses must add content to by overriding it.

Parameters:

• t (tuple) – One triple on which to apply the rules.
• cycle_num (int) – 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