Re: OWL-cool

On April 6, Bob MacGregor writes:
> Side-bar conversations with Jim Hendler revealed that
> he thinks OWL-lite is pretty cool, and figures that
> if you need things like attaching data to classes and
> properties, you just switch to OWL-full, and then you're
> OK (Jim, if I paraphrased this improperly, I apologize).
> Unfortunately, switching to OWL-full doesn't make things OK.
> 
> The good news is that it wouldn't take a whole lot to
> convert OWL-lite into a practical language.
> 
> The objective is to define a language that
>   (i) contains a base set of useful primitives
>   (ii) uses names that are easy to understand
>   (iii) doesn't leave out anything essential
>   (iv) is relatively easy to implement
>   (v) has a syntax that is easy to read
> 
> OWL-full fails badly on (iv), which is partly why its not
> a solution for the metadata problem.  It also fails badly
> on (v).
> 
> Point (i):  OWL does contain a base set of useful primitives.
> 
> Point (ii): Most of the OWL names are pretty good.  The only really
> bad one is 'InverseFunctionalProperty'.  I had an e-mail discussion
> with someone who was unaware of the fact that it means 
> approximately the same thing as "defines a single-attribute key".
> If that's how you define an attribute key in OWL, then the
> name ought to reflect that.
> 
> Point (iii):
> 
> If I had to pick three things to add to OWL-lite to make it
> much more usable, they would be:
>    (a) the ability to annotate classes and properties
>    (b) the ability to mimic the way object-oriented programming
>        languages associate attributes with classes
>    (c) the ability to define keys on classes, analogous to the
>        way database people define keys on tables.

[snip]

> I'll leave (c) as an exercise.  Its not very hard.  Note, though,
> that the database notion of a simple (non-compound) key does not
> have the same semantics as 'InverseFunctionalInverse'.
> 
> Point (iv):  OWL-lite is reasonably easy to implement (modulo the
> fact that implementing equality is intrinsically difficult).
> If we added two or three of the extensions that I would like to
> see, it would still be easy to implement.

As Peter already mentioned, we have investigated in some detail the
problem of adding keys to langauges like OWL (Lite/DL) - see [1,2].

The good news is that it is possible to add keys to these langauges
without loosing decidability for key inference problems. The bad news
is that computational complexity is rather high: it is easy to see
that keys are at least as expressive as nominals (oneOf), as integer
keys can be used to simulate an arbitrary number of nominals.

As the lack of nominals in OWL Lite is, form a computational
standpoint, the main feature that distinguishes it from OWL DL,
adding keys to OWL Lite really wouldn't make sense (there would be no
point in continuing to distinguish it from OWL DL).

[snip]

Regards, Ian

[1] http://www.cs.man.ac.uk/~horrocks/Publications/download/2002/LAHS02.pdf
[2] http://www.cs.man.ac.uk/~horrocks/Publications/download/2003/LAHS03a.pdf

Received on Tuesday, 22 April 2003 09:47:04 UTC