[Fwd: SIG meeting]

Mike,

Another contribution as input to the January face-to-face meeting, this time by Sean Bechhofer, of OILed fame.

He makes various points that are also echoed by others. One point deserves particular attention, which is his last: the weak notion of "import" in current DAML+OIL. It is both a blunt instrument (all or nothing, no information hiding) and has no precise meaning. I agree with most of what he writes. 

Frank.
   ---

(Sean, Mike has taken over my role of collecting input on language usage/experience for the January face-to-face meeting of the Web Ontology WG, so that's why I've taken the freedom to forward your email to him).

-------- Original Message --------
Subject: SIG meeting
Date: Tue, 11 Dec 2001 17:21:45 +0000 (GMT)
From: Sean Bechhofer <seanb@cs.man.ac.uk>
To: Frank.van.Harmelen@cs.vu.nl


Frank -

Here are a number of remarks and comments arising from last week's
meeting. They're somewhat unstructured and are very rough, but I'm
just trying to get down as much as I can regarding some of the
thoughts that I had during the meeting.

Throughout this discussion I'll refer to DAML+OIL as a concrete
example as it's a language that already exists, but the issues will be
there with whatever WebOnt produces.  

Feel free to forward this to the mailing list if you think it's
appropriate. 

Why are you doing it?
=====================

Why define a Web ontology language? There are a number of different
reasons why you might want to define a language and although they
share many characteristics, they have, I think, different
requirements. A rough classification could be:

1) Exchanging ontologies 

   a completely syntactic common formatting and conversion exercise.
   This guarantees that people will use the same words but guarantees
   nothing about their interpretation.

2) Sharing ontologies 

   a common semantic interpretation of the constructs and constraints
   in the language to support interoperation

3) Interacting with ontologies 

   a set of services supported by the ontology, such as querying or
   updating reasoning services.

4) Building ontologies 

   the systematic construction of ontologies supported by the
   interaction services and perhaps supported by
   classification/subsumption reasoning services

If we were only ever concerned with delivering the ontologies to
agents via some kind of API, then issues like usability and readability
and the problems that we discussed to do with DAML+OIL's lack of a
frame-like approach when compared to the original OIL language don't
really crop up, as all that the agents should really be concerned
about is the ability to share (i.e. the common semantics). 

If we want to support humans or ontologists building models, then
those things do become important. I have worried about this in the
past [1], and still think that it's an important issue. It's still not
clear to me how (and why) the frame-based aspects of OIL got lost
during the birth of DAML+OIL.

How much redundancy do you want in the language? Sometimes it's quite
nice to be able to say the same thing in different ways (for example
by adding properties to the definition of a class or by asserting
axioms). DAML+OIL seems to have removed some of that redundancy (the
frame descriptions) but still has some lurking around. For example the
unambiguous properties, which I believe one can do through the use of
an inverse and a unique property. 


RDF/RDFS and WebOnt
===================

How wedded does the language have to be to RDFS? I think from what
Frank said during the meeting that this is a given for the WebOnt
working group -- i.e. the language they come up with has to sit on top
of RDFS. I'd be happier, however, if the language design was as
separated from RDF as much as possible (so, for example, one could
provide some alternative syntax such as an XML Schema, or even a
BNF). That would make things a little clearer in some cases -- a lot
of the problems I've had as an implementor have been to do with having
to process and understand models using DAML+OIL represented in
RDFS. 


Reading, Writing and "Compliance"
=================================

This is perhaps a tools rather than a language issue, but I think it's
relevant here. What does it mean to read and write DAML+OIL?  There
are now a number of tools around that claim to support DAML+OIL, but
exactly what this means is perhaps different for each tool.

As far as writing or producing DAML+OIL, that's relatively easy -- any
tool representing basic taxonomies or properties can output RDFS using
the DAML+OIL schema. 

However, reading (and understanding) DAML+OIL is a different
matter. For example, a tool that understands basic RDFS can read in a
DAML+OIL model, but may choose to ignore things that it doesn't
understand, for example axioms or complex conceptual definitions. 

I think being precise about exactly how much of the language is being
supported by a tool is important. I'm certainly guilty of this :-) --
some earlier versions of OilEd didn't deal with all of the language,
and I still haven't provided any support in my tools for XML Schema
Types other than some very basic things that allow the use of
primitive data types such as integers or strings. In fact I only
noticed today that axioms of a particular form get ignored by the
parser. Oops :-). 

Of course that's not to say that a tool that doesn't support all the
language is a bad tool. However, it needs to be made clear if that is
the situation.


Ontology Containment
====================

Another issue which was touched on briefly in the SIG is that of what
one might call ontology containment. This is something that troubles
me and I discussed it briefly in [2], but the basic problem here (as I
see it) is being able to identify "what is an ontology?". With an
approach like DAML+OIL, the classes and properties in an ontology are
defined by a number of statements (primitive concept definitions and
axioms). So far, examples of DAML+OIL ontologies tend to be given as
URIs, with an XML serialization of those RDF statements forming the
body of the resource. Within those models, classes _tend_ to be given
names which are relative URIs to the URI of the ontology. But there's
nothing within the specification that says this must be the
case. 

So a collection of statements at a particular URI may make assertions
about any classes from elsewhere. This is fine (I'm not objecting to
that), but we have to then be explicit about what we mean by an
ontology, i.e. which particular collection of assertions that form the
context within which we're going to interpret some information. I
can't just assume that the definition of the class 

http://cohse.semanticweb.org/ontologies/animals#elephant 

will be given at that URL. Although they look like they might be,
namespaces aren't doing this -- they're simply a syntactic mechanism
that allows us to disambiguate between things that might have the same
name ("animal" in my ontology and "animal" in your ontology). 

This isn't a terrible problem, but I think we must be careful of users
making assumptions about the context within which they are
interpreting some facts so it's important to be explicit about
things. 

Cheers,

	Sean


[1] Sean Bechhofer, Carole Goble, Ian Horrocks. DAML+OIL is not
enough. SWWS-1, Semantic Web working symposium, Stanford (CA), July
29th-August 1st,
2001. http://potato.cs.man.ac.uk/papers/not-enough.pdf

[2] Sean Bechhofer, Carole Goble. Towards Annotation using
DAML+OIL. K-CAP 2001 workshop on Knowledge Markup and Semantic
Annotation, Victoria B.C, October
2001. http://potato.cs.man.ac.uk/papers/kcap01.pdf


==========================================================================
| 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, 18 December 2001 19:27:47 UTC