(trimmed crossposts)
On 25 May 2007, at 11:02, Ian Horrocks wrote:
> Hi Matt,
>
> It isn't completely clear whether you are asking about using some
> kind of rule engine
[snip]
Note that this is one of the issues. "Rules" isn't a well-defined
term. Do you mean logic programming rules (and if so, do you mean
datalog, disjunctive datalog, prolog, and then for several of these,
with what sort of specific features and semantics), production rules,
ECA rules, first order logic conditionals?
Each one of these has different expressiveness (though there are
overlap and subset relations). If you pick the "right" one (e.g., to
simplify, first order logic) then there is a simple transliteration
that will work (the so-called standard translation). However, you may
not get a decision procedure out of your FOL reasoner (unless you
tweak a load of parameters; see the excellent work of Renate Schmidt)
and even when you do, it might not be very efficient (certainly on
the standard translation; see the Hoolet papers).
Basically, reducing OWL to something a given rule engine can process
requires theory and engineering to be correct and practical...just as
with any other implementation technique. There are a large number of
tradeoffs along the way.
Also, many rule engines presume, and thus are tuned for, relatively
few rules and a lot of data (see the datalog family). Many OWL
ontologies are the reverse (sometimes no data!). So there can be
other mismatches.
Some fragments of OWL align more neatly with some rule engines. If
you look at the OWL 1.1tractable fragment documents:
http://webont.org/owl/1.1/tractable.html
You'll see that many of the fragments have more or less direct
translations to horn rules. The complexity results give some hints as
well.
As Ian said, incompleteness (in the sense of not being a decision
procedure, but many of the rules variants aren't even complete; i.e.,
using the standard translation to FOL and naively using a FOL
reasoner will get you a sound and complete reasoner, but not a
decision procedure (thus 'incomplete' in the sense ian was saying)).
One might be willing to trade completeness/decidability for other
things (though the cleanest way to do this is to define a fragment).
However, the current infrastructure for helping users *understand*
the significance of failed computations is pretty non-existent.
Working on it :)
Cheers,
Bijan.