[seek-kr-sms] OWL Inference APIs (was Re: SMS stuff)
Serguei Krivov
Serguei.Krivov at uvm.edu
Wed Mar 31 13:06:05 PST 2004
Shawn,
Thanks for the interesting survey. I also have been looking at DL
reasoning with focus on tableaux algorithms and found a few points worth
of attention. Apparently there are a few semantic features which are not
part of present owl, but they are extremely useful and they are
available in some decidable systems.
1. Role boxes: In owl one can not say that role Uncle is subrole of
composition of roles Parent*Brother. Role boxes were avoided for a long
time since in general they lead to undecidable systems. But apparently
some limited (acyclic) role boxes can be added to SHIQ without loose of
decidability:
http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/HoSa03a.pdf
2. Feature(functional role) agreement. In owl one can not say something
like
"for every chemical flow its agent should be the same as agent of
respective stocks it connect"-
flow.agent=flow.source.agent=flow.target.agent. But in very old system
ALCF it is possible. Apparently addition of agreement/disagreement for
functional roles does not lead to undesirability in many even more
complex cases.
3. Reasoning with concrete domain vs time and space. Reasoning about
space and time may not be important for general users of ontologies so
it is not in owl. But it is important for ecologists and perhaps
eventually we shall bump in it. Although Racer supports reasoning with
concrete domains such as integers and friends, it does not come to
space/time. Yet potentially we can use DL reasoner for checking
consistency of statements about space, time , and even space-time as
long as they are represented properly (as admissible domain). I am
attaching paper that surveys this topic in detail. Specifically
interesting points about space and time are in the end and of course
there are many references on this subject worth of reading.
Certainly it is not possible to combine all semantic features we need in
one decidable DL system. But I think it would be good to understand
what features are the most important in context of SEEK. Then we can try
to design a tableaux that accommodates most of the essential features we
need.
Serguei
-----Original Message-----
From: seek-kr-sms-admin at ecoinformatics.org
[mailto:seek-kr-sms-admin at ecoinformatics.org] On Behalf Of Shawn Bowers
Sent: Wednesday, March 31, 2004 2:45 PM
To: seek-kr-sms at ecoinformatics.org
Subject: [seek-kr-sms] OWL Inference APIs (was Re: SMS stuff)
Hello everyone,
This (seemingly long) email is meant to carry the thread started earlier
about APIs, etc., for reasoning.
Basically, I wanted to see what types of operations different systems
use for OWL inference / reasoning tasks. Here are some results from my
investigations ... and I thought I would share them because it might be
of general interest. At least, I hope you find this useful -- looking at
the operators helped me understand what standard DL-based ontology
reasoning is all about (what it can do, can't do, and that there is a
"standard" set of operators).
Just a note: There are a handful of so-called reasoners out there that
support OWL (e.g., Pellet, Jess for OWL, Euler, OWLP, and so on) that
don't have actual APIs -- instead they are stand-alone applications that
do specific reasoning tasks; primarily classification (an exception is
Pellet, which they say will eventually have an API). Instead of looking
into these, I was interested in actual inference operations/APIs that
can be applied to a knowledge-base.
So, I looked at FaCT, Racer, OWL-API, and Jena2. Here is a summary of
the operations they support. Interestingly, FaCT, Racer, and the
OWL-API are all pretty much the same (modulo the names of operations and
the complexity of the languages they support). They provide the same
basic operations. Here is a rundown:
FaCT Ontology-Inference Interface (slightly modified)
=====================================================
NOTE: kb stands for a knowledge-base of description-logic expressions
kb.classify()
- Classifies the knowledge-base (the object denoted by kb), which
computes a partial ordering of the set of named concepts
in kb; the computed partial ordering is represented as a concept
hierarchy, which is a directed acyclic graph in which each
concept
is linked to its direct super- and sub-concepts.
- Note that pre-classifying a knowledge base makes the following
operations essentially look-ups (and is required to call any of
the following operators)
kb.direct-supers(concept-name) : Set<concept-name>
- Finds the direct super-concepts of the given classified concept
kb.all-supers(concept-name) : Set<concept-name>
- Finds all the super-concepts of the given classified concepts
kb.direct-subs(concept-name) : Set<concept-name>
- Finds the direct sub-concepts of the given classified concepts
kb.all-subs(concept-name) : Set<concept-name>
- Finds all the sub-concepts of the given classified concepts
kb.equivalences(concept-name) : Set<concept-name>
- Finds the concepts that are equivalent to the classified concepts
kb.satisfiable(description) : Boolean
- Tests if a given concept description is satisfiable w.r.t. the kb
kb.subsumes(description1, description2) : Boolean
- Tests if the first concept description subsumes (is a
super-concept of) the second w.r.t. the kb
kb.equivalent-concepts(description1, description2) : Boolean
- Tests if two concept descriptions are equivalent w.r.t. the kb
kb.disjoint-concepts(description 1, description2) : Boolean
- Tests if two concept descriptions are disjoint w.r.t. the current
kb
kb.classify-concept(description) : (Set<concept-name>,
Set<concept-name>, Set<concept-name>)
- Finds where a concept description would classify without adding
it
to the knowledge base
- Returns three values: the direct-supers, the direct-subs, and the
equivalent concepts of the description
Racer Ontology-Inference Interface (slightly modified)
======================================================
NOTE: Racer's interface is almost identical to FaCTs with the following
major additions (besides the names of operations):
Classification. The classification approach in Racer is flexible and be
set as either eager or lazy. There is an explicit classification
operation like in FaCT (but isn't required to call the operations).
Roles. Racer provides additional operations for role subsumption
(similar to the concept versions).
Instances. Racer supports the instance classification operations:
kb.is-individual-instance(individual-name, description) : Boolean
kb.concept-instances(description) : Set<individual-name>
kb.all-concepts-for-individual(individual-name) : Set<concept-name>
kb.most-specific-instantiators(individual-name) : Set<concept-name>
- Returns the most-specific atomic concepts that the individual is
an instance of (as opposed to all the concepts the individual is
an instance of)
kb.all-instantiators(individual-name) : Set<concept-name>
- Returns all atomic concepts the individual is an instance of
kb.retrieve-individual-filled-roles(individual-name1,
individual-name2) : Set<role-name>
- Returns all roles that hold from the first individual to the
second individual
kb.all-role-assertions-for-individual-for-domain(individual-name) :
Set<role-name>
- Returns all roles that hold for the individual as the domain
kb.all-role-assertions-for-individual-for-range(individual-name) :
Set<role-name>
- Returns all roles that hold for the individual as the range
OWL-API Ontology-Inference Interface (slightly modified)
========================================================
The OWL-API is a very preliminary (alpha quality?) version of a Java OWL
API for accessing OWL ontologies, etc. It is actually pretty close to
Racer and FaCT. They mention that the API isn't stable, and will
change. The OWLReasoner class is the main class for reasoning.
OWLReasoner.setOntology(OWLOntology owl)
The OWLReasoner class has three subclasses with the following
operations:
OWLClassReasoner operations (subclass of OWLReasoner)
ancestorClassesOf(OWLDescription) : Set<OWLClass>
descendantClassesOf(OWLDescription) : Set<OWLClass>
equivalentClassesOf(OWLDescription) : Set<OWLClass>
isConsistent(OWLDescription) : boolean
isEquivalentClass(OWLDescription, OWLDescription) : boolean
isSubClassOf(OWLDescription, OWLDescription) : boolean
subClassesOf(OWLDescription) : Set<OWLClass>
superClassesOf(OWLDescription) : Set<OWLClass>
OWLIndividualReasoner operations (subclass of OWLReasoner)
instanceOf(OWLDescription) : Set<OWLIndividual>
isInstanceOf(OWLIndividual, OWLDescription) : boolean
OWLTaxonomyReasoner operations (subclass of OWLReasoner)
ancestorClassesOf(OWLClass) : Set<OWLClass>
descendantClassesOf(OWLClass) : Set<OWLClass>
equivalentClassesOf(OWLClass) : Set<OWLClass>
subClassesOf(OWLClass) : Set<OWLClass>
superClassesOf(OWLClass) : Set<OWLClass>
Jena2 Ontology-Inference Interface (slightly modified)
======================================================
Jena2 is the "odd man out" - it provides a set of "model factories" that
build new models (a model is an RDF file, an OWL ontology, etc.) from
existing models, where the new model (a model is represented as a
directed graph) is the result of applying reasoning.
The reasoners are really just simple interfaces that a real reasoner
could implement (i.e., a real reasoner could use the interface as a
wrapper to its services).
The reasoner subclasses include:
TransitiveReasoner
For transitive closure of the subClassOf and subPropertyOf graphs.
FBRuleReasoner
OWLFBRuleReasoner
LPBackwardRuleReasoner
BasicForwardRuleReasoner
There aren't any supported operation (like in FaCT, Racer, OWL-API,
etc.); instead, you navigate an OntModel (which is a special version of
a graph with some ontology iterators for getting classes, subclasses,
etc.)
Kai here at SDSC used the reasoner and found it performed very poorly,
which makes me believe that it is proof of concept. Here is a snippet
from the Jena2 web-site:
"The Jena2 reasoner subsystem includes a generic rule based
inference
engine together with configured rule sets for RDFS and for the
OWL/Lite subset of OWL Full. These reasoners can be used to
construct inference models which show the RDF statements entailed
by
the data being reasoned over. The subsystem is designed to be
extensible so that it should be possible to plug a range of
external
reasoners into Jena, though worked examples of doing so are left to
a future release. Of these components, the underlying rule engine
and the RDFS configuration should be reasonably stable. The OWL
configuration is preliminary and still under development."
So, at this point, it may not be "fair" to judge Jena's OWL reasoning
support. However, my general opinion from looking through the Javadocs
is that the APIs aren't well organized (compared with OWL-API, e.g.),
are a bit confusing (I am still not exaclty sure how the reasoner is
meant to be applied), and probably will be changed in the future. It
appears to be a kludge for now.
Shawn
Rich Williams wrote:
> 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.
>
_______________________________________________
seek-kr-sms mailing list
seek-kr-sms at ecoinformatics.org
http://www.ecoinformatics.org/mailman/listinfo/seek-kr-sms
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 3-review-aiml4.ps
Type: application/postscript
Size: 348808 bytes
Desc: not available
Url : http://mercury.nceas.ucsb.edu/ecoinformatics/pipermail/seek-kr-sms/attachments/20040331/fae62392/3-review-aiml4.ps
More information about the Seek-kr-sms
mailing list