RE: Intersection of properties?

[back to list]

>-----Original Message-----
>From: Jeff Thompson [mailto:jeff@thefirst.org]
>Sent: Tuesday, August 05, 2008 8:42 PM
>To: Michael Schneider
>Subject: Re: Intersection of properties?
>
>Hello Michael.  Your response if very helpful.  

Thanks! :)

>I feel like my questions
>are getting off-topic for the OWL email list since my concerns may be
>"out of scope" for the OWL standard, so may I try asking you directly?

No, going a bit beyond current OWL doesn't mean that it's off topic in this
list - quite the opposite (actually this group isn't only about "owl", but
also about "dev" :-)). And your questions have evoked a lot of interesting
and definitely on-topic answers, so I allowed myself to put this discussion
back to list.

>You say "depending on the size and form of your ontology, it might
>happen that you have to wait for the result of the consistency check for a
>pretty long time".  I understand this, but I don't understand what people
are
>expected to do about this. 

They do research on "tractable fragments" of OWL.

>It seems that people have taken these approaches:
>1) Only use small toy ontologies like "pizza",
>2) Use a large ontology but with only very simple structure such as
>names and addresses,
>3) Rely on Pellet to "perform a consistency check before it starts a
>reasoning task"
>without knowing how long it will take or whether the algorithm it uses
>is valid. 

If these alone were the options, then OWL might be doomed, I guess. :)

Well, option 2) comes closest to what I mentioned above, but luckily, it's
not necessary to use *that* simple structured ontologies. Tractable
fragments of OWL are sublanguages of the complete OWL language, which turn
out to perform efficiently under all circumstances, i.e. they have, unlike
OWL DL, a reasonably good worst case complexity.

By "sublanguage" I mean that they miss some of the language features of OWL,
or the usage of certain language features is restricted in some way. Several
such languages already exist, each following a different strategy on which
features are allowed and which are missing, which makes different languages
interesting for different application domains. 

The drawback is that, in order to exploit the efficiency advantage, you have
to learn the specific features of such a language, so that you can build
"efficient" ontologies. 

However, to my understanding, it probably won't be necessary to use specific
reasoners for these tractable languages, at least not in the future. I
rather expect that most future OWL DL reasoners will detect that a given
ontology matches one of the more popular tractable fragments (only a syntax
check is needed to detect this, so that's easy in principle!), and will
delegate the ontology to a language specific reasoning engine, which is an
internal part of the OWL-DL reasoner. Only if no one of the internally known
languages match, then an original OWL-DL reasoner will be used as a default
reasoning engine, which may or may not lead to poor efficiency. 

I hope other people in this list can confirm my guess here, and can
elaborate on the state of the art a bit.

Further, I have heard rumors that there is some research underway on
"efficiency patterns", i.e. pragmatics which, when applied, will often lead
to efficient OWL ontologies, even when these ontologies do not match any of
the known tractable OWL fragments. But I would guess that it is pretty hard
to come up with a good catalogue on such patterns. I hope that other people
here in the list can tell us more about this.   
 
> This is very important to me and it really confuses me that the
>OWL documents are silent on what to do here.  If an algorithm is important,
>then the OWL standard should say something about it and not just leave it
up
>to various implementors to pick their own solutions.  I don't think the
>standardization process is complete without this.

So then you will be happy to hear that OWL 2 will ship with (at the time of
writing) three of these tractable languages, called "OWL profiles". Here is
a snapshot of the current (WG-internal) working draft:

  <http://www.w3.org/2007/OWL/wiki/index.php?title=Profiles&oldid=10320>

>So I don't what to do 1, 2 or 3.  It is inevitable that a real-world
>ontology will have inconsistencies and, as you say, you can't rely on a
>consistency check on all your data (for a real-world large ontology with 
>many contributors).

Wait! In your previous mail you talked about ontologies with "millions of
axioms", which will probably often result in problems, even with tractable
fragments. Just imagine a sublanguage of OWL which guarantees a quadratic
number of reasoning steps in each case. With a million axioms, that's still
a trillion reasoning steps in the worst case, compared to at most a few
billion elementary processing steps a modern computer can perform per
second... But I really won't expect a lot of that big ontologies, at least
not as publicly accessible RDF/XML files on the SemWeb. :)   

>So, the best solution is to have a rule for dealing with an
>inconsistency when it is discovered.  And the rules should be specified
either by the
>standard, or as rules in the ontology itself, so that people know that they
are
>resolving the inconsistencies in the same way and getting the same results.

In current OWL, being based on classical logic, and having a model-theoretic
semantics, it's very clear what it means to reason about an inconsistent
ontology: Every syntactically well-formed assertion would follow from such
an ontology! Thus, it makes a lot of sense when Pellet tells you that it
cannot reason with inconsistent ontologies. The alternative would be to
answer each question with "yes". Not very informative, if not misleading, I
guess. :)

>Otherwise, you really haven't exchanged data reliably.  Seems to me this is
a necessary
>part for making an "web ontology" usable, and I'm very confused why this is
left out of the
>standards process.

Again, you seem to look for a non-classical alternative to OWL here. And
again, that's out of scope for the current OWL working group, because there
is no well-established approach around, at least not to my knowledge (though
this doesn't mean much). But things may change in the future, of course... 

>Sorry for the long message and thanks for any feedback,
>- Jeff

Cheers,
Michael

--
Dipl.-Inform. Michael Schneider
FZI Forschungszentrum Informatik Karlsruhe
Abtl. Information Process Engineering (IPE)
Tel  : +49-721-9654-726
Fax  : +49-721-9654-727
Email: Michael.Schneider@fzi.de
Web  : http://www.fzi.de/ipe/eng/mitarbeiter.php?id=555

FZI Forschungszentrum Informatik an der Universität Karlsruhe
Haid-und-Neu-Str. 10-14, D-76131 Karlsruhe
Tel.: +49-721-9654-0, Fax: +49-721-9654-959
Stiftung des bürgerlichen Rechts
Az: 14-0563.1 Regierungspräsidium Karlsruhe
Vorstand: Rüdiger Dillmann, Michael Flor, Jivka Ovtcharova, Rudi Studer
Vorsitzender des Kuratoriums: Ministerialdirigent Günther Leßnerkraus