Use of DAML+OIL/SkiCal and iCalendar in DAML+OIL

[Sean Bechhofer]

I think I tried to post this a while back, but it didn't seem to come
through....

On Sun, 6 Oct 2002, Alan Rector wrote:

> Tony - Dan, Libby and Greg
>
> Thanks to Tony for bringing the paper to our attention.
>
> A question for the authors...
>
> Most of the issues concern namespaces and equivalence which I
> shall leave to Sean.

> Towards the end of the paper you have an almost throw away comment
> that
>
>     "Another significant problem was the awkward syntax and limited
> expressivity..."
>
> Leaving aside the awkward syntax, I would be curious to know specific
> examples of the  problems with expressivity in your concrete
> task.  The reference to Pat Hayes isn't helpful because I know
> his theoretical position.  The question is, "What happens in practice?"

I too (as an implementor) have struggled with the issue of awkward syntax.
Collaping the richer models down into the RDF triple model makes things
hard (from an implementation point of view) and produces effectively
unreadable syntax (from a user point of view). However, that shouldn't
necessarily be a problem -- rather it's a requirement for good end-user
tools. RDF shouldn't be seen as a human readable syntax, but as a
mechanism for exchange between machines.

As with Alan, I'd be interested in knowing where the expressivity is
insufficient.

In the concluding section, there's a comment:

"Where DAML+oil is used to describe relations between objects in
ontologies written by different authors, connecting the ontologies
involves hypothesising what the author meant by the ontology. A machine
readable DAML+oil ontology does not capture all the aspects of the world
in the area which it claims to represent, and so there is immense
potential for error, still more so when the ontologies are defined in RDF
Schema or Mime directories or other means less precise than DAML+oil."

This is a good point, and one that's present regardless of the
representation used. One of our hypotheses is that the explicit modelling
capabilities of richer languages will help to alleviate the problems of
interpreting the author's original intent.

"Even within a single ontology, the degree of precision that DAML+oil
enables you to describe between objects is in many cases greater than the
degree of precision that you know pertains in those particular
circumstances. This means that arbitrary decisions are made for those
descriptions, leading to errors of interpretation, and, paradoxically, a
reduction in precision, because of the introduction of this random noise."

Again, are there examples of this? The use of a rich language does not
mandate that one has to use all the functionality. We could quite easily
define simple taxonomies (or even a completely flat vocabulary) using D+O.
Indeed, one of our approaches to building models is to do precisely this
-- start out with a simple taxonomic structure and then incrementally
refine this through definition.

Greg later wrote:

>I am sure all these problems are old hat for others and I am surely the
>least qualified to criticize DAML+OIL. After the fact I would say that
>SkiCal just wasn't "hierarchal" enough to make sense in DAML+OIL and I am
>not quite sure what would be, but Alan has asked for a response, maybe we
>can talk a bit about this on Wednesday and I can brush up on the work and
>be more concrete, otherwise I realize that this too is an "argument with
>out evidence".

Looking briefly at the iCal format, it does look to be lacking many
intensionally defined classes, which is the sort of area that D+O is good
at tackling. iCal seems rather to give a kind of top level schema for the
sort of information that you might want to store about events. I think
that where this kind of scenario would benefit is in the modelling of the
vocabulary that is then used to populate that schema. For example, the
kinds of person that may be involved in an event, or the different kinds
of venue where an event may be held.

Cheers,

	Sean

-- 
Sean Bechhofer
seanb at cs.man.ac.uk
http://www.cs.man.ac.uk/~seanb