OWL2 infrastructure (Thea)

Vangelis Vassiliadis and Chris Mungall developed Thea which does something similar to OWLAPI for Java: be able to read/write OWL2 ontologies in multiple serializations, manipulate these and reason about them. The reasoning takes several routes: it talks through JPL and OWLAPI to external reasoners such as Pellet, it can reason using Prolog rules over the OWL2 axioms and it can translate an ontology to a (tabled) Prolog program (as well as for several other LP systems such as DLV).

The project is implemented in SWI-Prolog for its RDF libraries and general connectivity. Sensible reasoning about OWL2 ontologies without tabling is really hard though. Since we now have usable tabling which will further evolve to hopefully pretty good tabling formal reasoning, for example involving OWL2, can become an attractive new domain for SWI-Prolog.

I’ve started doing some work on Thea, notably to update it to support SWI-Prolog 8. I also started completing the Manchester Syntax Parser of Thea. This seems a good starting point for a project I’m involved in. Chris merged most of these patches. He is not much involved in this particular area of ontology manipulation though. My fork is at GitHub, branch janw.

I was wondering whether other people are interested in this domain? And, if so, whether people are willing to help. There are several things that need attention:

  • The Java OWLAPI binding is really old.
  • Complete Manchester syntax support. Notably translating the parser output to OWL2 axoims. lso translating backwards, i.e., generate Manchester syntax output.
  • Turn into a SWI-Prolog pack.
  • Checkout threading and modularization such that we can use this in SWISH, providing a shared platform for ontology management and reasoning.

Thanks for taking this up Jan!

When I last worked on Thea there was no tabling in SWI, lots of exciting possibilities now!

I agree with all of the things needing attention. Updating the OWLAPI bindings is really important if you want to use a non-ancient reasoner.

One design decision we made in Thea was to use unit clauses for OWL axioms. E.g. subClassOf/2 is a fact / unit clause. Also blank nodes are translated into OWL expressions. So you might have a fact subClassOf(finger, someValuesFrom(part_of, hand)). There is no dependency on library/semweb, except as a means of translating RDF into facts or vice versa. This makes a lot of sense when working with complex TBoxes. However, we do throw out a lot of the goodies of semweb/rdf11.

I have actually switched to using rdflib a lot more for various reasons. I have started gathering some common OWL construct patterns in an owl_util module that lives in sparqlprog. E.g.

Here OWL constructs are rules rather than unit clauses, and the built-in prolog triplestore accessed via rdf/3 is the database, rather than prolog facts. This has upsides and downsides. One thing I quite like about it is that I can do OWL queries using high-level prolog predicates and have them auto-translate to complex SPARQL using sparqlprog.

owl_util is nowhere near as complete as Thea, my ultimate goal is to see these converge more, so that as a user I can use the same programs regardless of whether I want to store my ontology as unit clauses, in a prolog triplestore, or an external triplestore.

1 Like

Cool! My initial thought was that we should use Prolog for the T-box as Thea now does and use the RDF store and/or sparqlprog for the A-box. If you want to do T-box reasoning using rules over triples this would of course not work. Can we aim at a layer that is either implemented using unit clauses or rules but is otherwise fully compatible? If we can use the old Thea unit clauses as standard the two would nicely cooperate. I might be talking nonsense :slight_smile:

P.s. I’ve completed the Manchester grammar. Still need to deal with the translation to axioms and eventually the reverse translation. Also needs some syntax error rules to get something better than false :slight_smile:

1 Like

Yes, I think using the existing Thea predicates as standard makes perfect sense!