[seek-kr-sms] OWL Inference APIs (was Re: SMS stuff)

[Bertram Ludaescher]

Shawn:

This is a great summary!

If you get F-OWL to work and the SWI-Prolog SemWeb extensions, maybe
you can add them to your summary.

F-OWL but specifically the RDF stuff from SWI may be quite different
in flavor, but we should include it in this overview (to see how it
differs).

Bertram

>>>>> "SB" == Shawn Bowers <bowers at sdsc.edu> writes:
SB> 
SB> Hello everyone,
SB> 
SB> This (seemingly long) email is meant to carry the thread started earlier 
SB> about APIs, etc., for reasoning.
SB> 
SB> Basically, I wanted to see what types of operations different systems 
SB> use for OWL inference / reasoning tasks.  Here are some results from my 
SB> investigations ... and I thought I would share them because it might be 
SB> of general interest. At least, I hope you find this useful -- looking at 
SB> the operators helped me understand what standard DL-based ontology 
SB> reasoning is all about (what it can do, can't do, and that there is a 
SB> "standard" set of operators).
SB> 
SB> Just a note: There are a handful of so-called reasoners out there that 
SB> support OWL (e.g., Pellet, Jess for OWL, Euler, OWLP, and so on) that 
SB> don't have actual APIs -- instead they are stand-alone applications that 
SB> do specific reasoning tasks; primarily classification (an exception is 
SB> Pellet, which they say will eventually have an API). Instead of looking 
SB> into these, I was interested in actual inference operations/APIs that 
SB> can be applied to a knowledge-base.
SB> 
SB> So, I looked at FaCT, Racer, OWL-API, and Jena2.  Here is a summary of 
SB> the operations they support.  Interestingly, FaCT, Racer, and the 
SB> OWL-API are all pretty much the same (modulo the names of operations and 
SB> the complexity of the languages they support).  They provide the same 
SB> basic operations. Here is a rundown:
SB> 
SB> 
SB> FaCT Ontology-Inference Interface (slightly modified)
SB> =====================================================
SB>    NOTE: kb stands for a knowledge-base of description-logic expressions
SB> 
SB>    kb.classify()
SB>      - Classifies the knowledge-base (the object denoted by kb), which
SB>        computes a partial ordering of the set of named concepts
SB>        in kb; the computed partial ordering is represented as a concept
SB>        hierarchy, which is a directed acyclic graph in which each concept
SB>        is linked to its direct super- and sub-concepts.
SB>      - Note that pre-classifying a knowledge base makes the following
SB>        operations essentially look-ups (and is required to call any of
SB>        the following operators)
SB> 
SB>    kb.direct-supers(concept-name) : Set<concept-name>
SB>      - Finds the direct super-concepts of the given classified concept
SB> 
SB>    kb.all-supers(concept-name) : Set<concept-name>
SB>      - Finds all the super-concepts of the given classified concepts
SB> 
SB>    kb.direct-subs(concept-name) : Set<concept-name>
SB>      - Finds the direct sub-concepts of the given classified concepts
SB> 
SB>    kb.all-subs(concept-name) : Set<concept-name>
SB>      - Finds all the sub-concepts of the given classified concepts
SB> 
SB>    kb.equivalences(concept-name) : Set<concept-name>
SB>      - Finds the concepts that are equivalent to the classified concepts
SB> 
SB>    kb.satisfiable(description) : Boolean
SB>      - Tests if a given concept description is satisfiable w.r.t. the kb
SB> 
SB>    kb.subsumes(description1, description2) : Boolean
SB>      - Tests if the first concept description subsumes (is a
SB>        super-concept of) the second w.r.t. the kb
SB> 
SB>    kb.equivalent-concepts(description1, description2) : Boolean
SB>      - Tests if two concept descriptions are equivalent w.r.t. the kb
SB> 
SB>    kb.disjoint-concepts(description 1, description2) : Boolean
SB>      - Tests if two concept descriptions are disjoint w.r.t. the current
SB>        kb
SB> 
SB>    kb.classify-concept(description) : (Set<concept-name>,
SB>                            Set<concept-name>, Set<concept-name>)
SB>      - Finds where a concept description would classify without adding it
SB>        to the knowledge base
SB>      - Returns three values: the direct-supers, the direct-subs, and the
SB>        equivalent concepts of the description
SB> 
SB> 
SB> Racer Ontology-Inference Interface (slightly modified)
SB> ======================================================
SB> NOTE: Racer’s interface is almost identical to FaCTs with the following 
SB> major additions (besides the names of operations):
SB> 
SB> Classification. The classification approach in Racer is flexible and be 
SB> set as either eager or lazy. There is an explicit classification 
SB> operation like in FaCT (but isn't required to call the operations).
SB> 
SB> Roles. Racer provides additional operations for role subsumption 
SB> (similar to the concept versions).
SB> 
SB> Instances. Racer supports the instance classification operations:
SB> 
SB>    kb.is-individual-instance(individual-name, description) : Boolean
SB> 
SB>    kb.concept-instances(description) : Set<individual-name>
SB> 
SB>    kb.all-concepts-for-individual(individual-name) : Set<concept-name>
SB> 
SB>    kb.most-specific-instantiators(individual-name) : Set<concept-name>
SB>      - Returns the most-specific atomic concepts that the individual is
SB>        an instance of (as opposed to all the concepts the individual is
SB>        an instance of)
SB> 
SB>    kb.all-instantiators(individual-name) : Set<concept-name>
SB>      - Returns all atomic concepts the individual is an instance of
SB> 
SB>    kb.retrieve-individual-filled-roles(individual-name1,
SB>                         individual-name2) : Set<role-name>
SB>      - Returns all roles that hold from the first individual to the
SB>        second individual
SB> 
SB>    kb.all-role-assertions-for-individual-for-domain(individual-name) :
SB>                         Set<role-name>
SB>      - Returns all roles that hold for the individual as the domain
SB> 
SB>    kb.all-role-assertions-for-individual-for-range(individual-name) :
SB>                         Set<role-name>
SB>      - Returns all roles that hold for the individual as the range
SB> 
SB> 
SB> 
SB> OWL-API Ontology-Inference Interface (slightly modified)
SB> ========================================================
SB> The OWL-API is a very preliminary (alpha quality?) version of a Java OWL 
SB> API for accessing OWL ontologies, etc. It is actually pretty close to 
SB> Racer and FaCT.  They mention that the API isn't stable, and will 
SB> change. The OWLReasoner class is the main class for reasoning.
SB> 
SB>    OWLReasoner.setOntology(OWLOntology owl)
SB> 
SB> The OWLReasoner class has three subclasses with the following operations:
SB> 
SB>    OWLClassReasoner operations (subclass of OWLReasoner)
SB> 
SB>      ancestorClassesOf(OWLDescription) : Set<OWLClass>
SB>      descendantClassesOf(OWLDescription) : Set<OWLClass>
SB>      equivalentClassesOf(OWLDescription) : Set<OWLClass>
SB>      isConsistent(OWLDescription) : boolean
SB>      isEquivalentClass(OWLDescription, OWLDescription) : boolean
SB>      isSubClassOf(OWLDescription, OWLDescription) : boolean
SB>      subClassesOf(OWLDescription) : Set<OWLClass>
SB>      superClassesOf(OWLDescription) : Set<OWLClass>
SB> 
SB>    OWLIndividualReasoner operations (subclass of OWLReasoner)
SB> 
SB>      instanceOf(OWLDescription) : Set<OWLIndividual>
SB>      isInstanceOf(OWLIndividual, OWLDescription) : boolean
SB> 
SB>    OWLTaxonomyReasoner operations (subclass of OWLReasoner)
SB> 
SB>      ancestorClassesOf(OWLClass) : Set<OWLClass>
SB>      descendantClassesOf(OWLClass) : Set<OWLClass>
SB>      equivalentClassesOf(OWLClass) : Set<OWLClass>
SB>      subClassesOf(OWLClass) : Set<OWLClass>
SB>      superClassesOf(OWLClass) : Set<OWLClass>
SB> 
SB> 
SB> Jena2 Ontology-Inference Interface (slightly modified)
SB> ======================================================
SB> Jena2 is the “odd man out” – it provides a set of “model factories” that 
SB> build new models (a model is an RDF file, an OWL ontology, etc.) from 
SB> existing models, where the new model (a model is represented as a 
SB> directed graph) is the result of applying reasoning.
SB> 
SB> The reasoners are really just simple interfaces that a real reasoner 
SB> could implement (i.e., a real reasoner could use the interface as a 
SB> wrapper to its services).
SB> 
SB> The reasoner subclasses include:
SB>    TransitiveReasoner
SB>      For transitive closure of the subClassOf and subPropertyOf graphs.
SB>    FBRuleReasoner
SB>      OWLFBRuleReasoner
SB>    LPBackwardRuleReasoner
SB>    BasicForwardRuleReasoner
SB> 
SB> There aren’t any supported operation (like in FaCT, Racer, OWL-API, 
SB> etc.); instead, you navigate an OntModel (which is a special version of 
SB> a graph with some ontology iterators for getting classes, subclasses, etc.)
SB> 
SB> Kai here at SDSC used the reasoner and found it performed very poorly, 
SB> which makes me believe that it is proof of concept.  Here is a snippet 
SB> from the Jena2 web-site:
SB> 
SB>     "The Jena2 reasoner subsystem includes a generic rule based 
SB> inference
SB>      engine together with configured rule sets for RDFS and for the
SB>      OWL/Lite subset of OWL Full. These reasoners can be used to
SB>      construct inference models which show the RDF statements entailed by
SB>      the data being reasoned over. The subsystem is designed to be
SB>      extensible so that it should be possible to plug a range of external
SB>      reasoners into Jena, though worked examples of doing so are left to
SB>      a future release. Of these components, the underlying rule engine
SB>      and the RDFS configuration should be reasonably stable. The OWL
SB>      configuration is preliminary and still under development."
SB> 
SB> So, at this point, it may not be "fair" to judge Jena's OWL reasoning 
SB> support. However, my general opinion from looking through the Javadocs 
SB> is that the APIs aren't well organized (compared with OWL-API, e.g.), 
SB> are a bit confusing (I am still not exaclty sure how the reasoner is 
SB> meant to be applied), and probably will be changed in the future. It 
SB> appears to be a kludge for now.
SB> 
SB> Shawn
SB> 
SB> 
SB> Rich Williams wrote:
SB> 
>> Hey there -
>> 
>> I took a look at some of the API work, which is very useful, and it struck
>> me that there might be some existing work in the semantic web community that
>> we should leverage when it comes time to implement things.  Some of the
>> functionality in the proposed API is very similar to that in any OWL API.
>> Of the ones out there, Jena (http://jena.sourceforge.net/) is probably the
>> most mature and is in wide use in the semantic web community.
>> 
SB> 
SB> 
SB> _______________________________________________
SB> seek-kr-sms mailing list
SB> seek-kr-sms at ecoinformatics.org
SB> http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms