Re: DAML+OIL and OIL

Sean,

You express a concern that in RDF there is no distinction between
information about something and its definition.  This is a rather
philosophical question.

I think that actually in the big wide wold, you can't make that distinction
so simply.
What you can do in the web, when the identifier for something is in
a URI space which has concepts of ownership and dereference (such as http:),
is to dereference the term.  If this can be done (not at all always the
case),
then you know from the http transaction that you have information about
the thing which was authorized directly or indirectly by the owner of the
identifier.
In that sense such informatoin is definitive.
So anything you learn about
http://www.w3.org/People#danc
in a document provided by the www.w3.org service as a represnetation of
http://www.w3.org/People
can be taken as definitive.

However, I don't see myself why there is any difference beween the
"definition" information or other infomation about danc in that file.
The same inferences can be made from either and they have the same level of
trust.

Across the web, you may in fact trust some documents which are not the
definitive ones for a term more than you trust the definitive ones, so the
idea
that one bit of informatoin about what identifier refers to is the
"definition"
doesn't in the end mean anything.

What practical use do you need to make of such a distinction, apart from to
preserve it for its own sake?

Tim

----- Original Message -----
From: "Sean Bechhofer" <seanb@cs.man.ac.uk>
To: <www-rdf-logic@w3.org>
Sent: Wednesday, February 28, 2001 11:11 AM
Subject: 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 Tuesday, 6 March 2001 23:38:10 UTC