Re: DAML+OIL and OIL

Hello Sean and all the list,

In his message (DAML+OIL and OIL) of 28/02/01,
Sean Bechhofer wrote:
>I had some fun trying to reconcile this underyling frame approach with
>the DAML+OIL model, however, when reading in DAML+OIL
>ontologies. Because everything in DAML+OIL is "collapsed" into axioms,
>we have to try and guess what likely concept descriptions will be. For
>example, in an example model about people, there's simply an assertion
>that an animal_lover is a subclass of [person and (haspet 3 animal)]
>(apologies for the sloppy syntax, but I hope it's understood what I'm
>getting at here). It's not clear whether this should be treated as an
>axiom or a definition. In this case, we can try and add a definition
>of animal_lover as a primitive class, with a subclass of person and a
>slot-constraint of haspet 3 animal.
>
>I have a nasty feeling that this issue may cause problems if people
>try and use DAML+OIL to *exchange* models. Even though the underlying
>semantics is clear, it may be the case that the modeller had a
>particular way that they wanted to organise the information. If one
>was to use an editor to build a model, save it in DAML+OIL, then read
>it back in, it may well look different to the original (but will still
>have the same semantics).
>
>The problem here is in part because of the fact that you can only say
>things in one way in DAML+OIL. To my mind, one of the attractive
>things about OIL is precisely the ability to describe things in more
>than one way (and the fact that the representation preserves those
>differences). If we're just talking about delivering the ontology
>within an application or software agents trying to do reasoning and
>queries, this perhaps isn't too much of an issue (but I wouldn't be
>100% certain about that).

This is an issue with pivot language (it was also true of KIF). It is 
the same (in fact I think that it is worse) when you want to 
translate object-oriented (or frame) like specialization relations 
into a language which cast them into clauses. The users might want to 
see neat hierarchies and not a bag of clauses.

The short term solution to that problem is the one you mention (I 
think that it is also used in Protégé): adding information to the 
formal model meaning that such predicate (or such term) must be 
preferably presented (rendered) as a term in a hierarchy.

Moreover, the problem is far more accurate in a collaborative 
environment like the web because you will want to use OilEd and some 
other would prefer Protégé. The only path here (I am afraid), is to 
adopt a common language for annotating the ontologies. If not, the 
real problem will be that the ontology will not suffer the round trip 
(if you export to protégé, someone edit the ontology, and you import 
it back, then you will have trouble, even if you work on the same 
structures with the same editor!).

By the way, this why MathML is actually two languages: a presentation 
language and a content language. It is certainly too early to so 
decompose DAML+OIL but this might be something to dig in.

This is an example of what I call semiotic [beware the use of the 
word might trigger some new chapter of Jon Awbrey's thesis in 
progress (JATIP) ;-)] mismatch in communication because though 
semantics is preserved, understanding is not). This point is evoked 
in a position paper in the last ECAI Computational semiotics workshop 
[1]. The word semiotics is used here because the problem is related 
to the interpretation of the formal language as signs and not to the 
formal language semantic itself (which is quite clear). Basically, 
the human being is a semiotic animal, though computers are (or we try 
to make them) semantic animals.

One can imagine a solution consisting of expressing the rules of 
interpretation of sign systems and to warrant when translating from 
one language to another that the interpretations are properly 
conveyed. Unfortunately the state of the art in semiotics seems to be 
far for providing a language for expressing interpretation rules. But 
I would be happy to ear about any related work or any interested 
people.

[1] ftp://ftp.inrialpes.fr/pub/exmo/publications/euzenat2000d.ps.gz


-- 
  Jérôme Euzenat                  __
                                  /      /\
  INRIA Rhône-Alpes,            _/  _   _   _ _    _
                               /_) | ` / ) | \ \  /_)
  655, avenue de l'Europe,    (___/___(_/_/  / /_(_________________
  Montbonnot St Martin,       /        http://www.inrialpes.fr/exmo
  38334 Saint-Ismier cedex,  /          Jerome.Euzenat@inrialpes.fr
  France____________________/                Jerome.Euzenat@free.fr

Received on Thursday, 1 March 2001 04:20:01 UTC