DAML+OIL and OIL

Some context to this posting: I've recently been responsible for the
development of OilEd (see http://img.cs.man.ac.uk/oil), a lightweight
ontology editor primarily intended to demonstrate how reasoning can
help when building ontologies. I've been adding some DAML+OIL support
(input/output of ontologies represented in DAML+OIL, based on the
recent DAML+OIL release http://www.daml.org/2000/12/daml+oil), and
came up against a number of issues. After a brief private discussion
with Frank van Harmelen, he asked me to air my views on this list, so
here goes....

The original OIL language
(http://www.ontoknowledge.org/oil/rdf-schema/2000/11/10-oil-standard)
allowed for the explicit construction of "frame-like" expressions,
i.e. things with a number of superclasses and slot restrictions, as
well as the ability to add axioms. Frame-based modelling primitives
are often cited as one of the "three roots of OIL", along with
well-defined (DL based) semantics/reasoning and Web languages. We
built OilEd using this simple "frame paradigm" (and I believe it's the
approach used by other, similar, tools such as Protege and
OntoEdit). Of course in terms of the semantics (i.e. mapping into
SHIQ), there's no difference between defining a class with explicit
superclasses/slot constraints and throwing in an axiom asserting the
subsumption relationship.

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).

Of course, due to the extensible nature of RDF, there's nothing to
stop me putting my own tags into a DAML+OIL ontology that tell me how
to reconstruct the model (i.e. flagging whether subclass assertions
are intended as part of a definition or an axiom), but that leads to a
rather "closed" representation where you have to understand *my* extra
tags, and it may be that models built with X's modelling tool will not
be (fully) understandable by Y's modelling tool. This would hinder
ontology exchange.

A related issue here is that the DAML+OIL spec seems to have discarded
many of the "frame-based" modelling primitives that OIL
provided. Everything's simply axioms so we're back to a much more
"logic-flavoured" approach. This might prove unpopular -- our
experience with people trying to build models in bioninformatics is
that they like the frame paradigm (but are also excited by the ability
to provide reasoning).

A contrary argument may go like this: 

    Argument> I'm not so sure I agree with you here. I don't see how the
    Argument> modelling paradigm of DAML+OIL is different from
    Argument> OIL. Proof: OILed is still the same. People still think
    Argument> they're editing frames, even though below the surface the
    Argument> semantics is the same as a bunch of logical axioms. That
    Argument> was true for OIL (after all, it translated into SHIQ), and
    Argument> it's true for DAML+OIL, no less, but also no more. 

Now the editor may still work the same and spits out DAML+OIL, but the
problem is that outlined earlier -- the resulting DAML+OIL may have
the right semantics, but all the information about the way the
information was *structured* has been lost. The difference here is
that OIL has explicit constructions to support frame-style modelling
whereas with DAML+OIL some manipulation and translation is required --
this is more obvious when you try and translate from DAML+OIL to
OilEd's internal representation. The tool has to guess what the frames
might be. Relating to the comment about translation to FaCT, both OIL
and DAML+OIL can be translated to FaCT/SHIQ, but I certainly wouldn't
claim that SHIQ supports a frame-based modelling paradigm. We can see
them as points on a sliding scale:

	OIL <------> DAML+OIL <------> SHIQ

as we move from left to right, we get more "logical" and less
"frame-like". Although we can always translate and preserve the
underlying semantics, I think the different modelling constructs make
for a difference modelling experience.

Any thoughts?

Cheers,

	Sean

==========================================================================
| Sean Bechhofer               |                                         |
| Research Fellow              |                                         |
| Information Management Group |                                         |
| Computer Science Department  |                                         |
| The University of Manchester | email: seanb@cs.man.ac.uk               |
| Oxford Road                  | Tel: +44-161-275-6145                   |
| Manchester M13 9PL           | Fax: +44-161-275-6236                   |
|------------------------------------------------------------------------|
| WWW: http://www.cs.man.ac.uk/~seanb                                    |
==========================================================================

Received on Wednesday, 28 February 2001 11:11:53 UTC