Re: OWL-cool

Hi:

Here are some personal comments on your message.

From: "Bob MacGregor" <macgregor@ISI.EDU>
Subject: OWL-cool
Date: Sun, 6 Apr 2003 12:07:49 -0700

> 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.
> 
> Fixing (a) is trivial -- you just say that its OK, and you're
> done.

This actually has already been done, in the most-recent (last call)
versions of the working drafts.  

> Now (b):  Suppose we want to assert that a property P can be used with
> classes C and D.  Here is one way to do that, using
> RDF triple syntax:
> 
>    P rdfs:domain _:d1
>    C rdfs:subClassOf _:d1 
>    D rdfs:subClassOf _:d1 
> 
> That wasn't so hard.  Unfortunately, its kind of clumsy -- enough
> so that I wouldn't expect people to use it.  We could sugar-coat
> it rather easily by inventing a property one might call 'subDomain'.
> Then
> 
>    P subDomain C
>    P subDomain D
> 
> would expand into
> 
>    P rdfs:domain _:d1
>    C rdfs:subClassOf _:d1
>    P rdfs:domain _:d2
>    D rdfs:subClassOf _:d2
> 
> Since 'rdfs:domain' is functional, the two blank nodes
> must denote the same domain.

All this depends on what is means to say that P can be use with a class C.

If what you want is the ability to mimic how OO classes work, then the
above doesn't really get you there.  First of all different OO languages
work in different ways.  Some require something close to the first group of
triples above.  Others only need something like the second group of triples
above.

In any case, if all you want is to be able to use P in an instance of C,
you can just do so.  You don't need any domain information on P at all.  If
what you want to do is to use P *only* on C and D, then you need a much
more involved set of triples, and you have to be careful to not want a
non-monotonic solution.

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

There is some research work on (c) already.  It is not particularly easy,
however, do add keys to classes, but it appears that it can be done, at
least in languages similar to OWL DL.

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

Certainly adding annotations doesn't cause problems.  Keys are a source of
complication.

> Point (v): RDF syntax is horrible.  The OWL languages inherit
> that horribleness.  

I agree entirely and RDF/XML is a horrible syntax.

> However, RDF has an escape from that
> horribleness -- if you use something like N3, then you can
> say the same things, and its quite attractive.  Most of the
> e-mail RDF discussions use triples syntax.
> OWL-lite can pull the same trick -- one can use triple
> syntax for saying things in OWL-lite.
> 
> Unfortunately, when you expand OWL-DL structures into
> triples, you get something really awful.  

I agree entirely.  Triples are good for representing triples, but terrible
for encoding anything that requires more structure.  However, OWL Lite
isn't much better, in my view.  Encoding OWL Lite restrictions or OWL Lite
complete class axioms in triples ends up with a mess of triples.

> Not only
> are they hard for people to read, they are difficult 
> to interpret by non-DL inference engines.  

This I don't understand.  Certainly parsing OWL (Lite, DL, or Full) in
triples is not trivial.

> When you
> buy into OWL-DL, you may be kissing good-bye to 
> rule-based inference.

Again, I don't see the point here.  Both OWL Lite and OWL DL don't fit well
into rule-based inference, as far as I can tell.

> My recommendation is the following.  Create a new language,
> which for the moment I will call 'OWL-cool'.  OWL-cool
> is  OWL-lite with extensions (a) annotations on classes
> and properties, (b) subdomains, and (c) database-like keys
> for classes,  If no one but me likes (c), we could drop (c).
> Either we rename 'FunctionalInverseProperty', or we invent
> a synonym for it in OWL-cool.

Annotations are in already.  I don't think that subdomains get you
anything.  Keys are probably possible, but with a potential increase in the
complexity of inference.

> Question: Have we now satisfied the five prerequisites that
> I originally started with?  Its impossible to categorically
> assert that it doesn't leave out anything essential, so
> here I'm claiming that it is a step in the right direction.
> The key contribution is that it adds a couple of very
> important capabilities without sacrificing (iv) ease of
> implementation, and (v) readable syntax.  The latter is
> true because OWL-cool translates into readable triples.

Are you actually claiming that OWL-cool, which includes OWL Lite, has a
readable triple syntax?  What about the triple version of 
 Class(foo complete bar allValuesFrom(baz bbb) minCardinality(baz 3))
which is (something like)
 foo owl:equivalentTo _:l1 .
 _:l1 rdf:first bar .
 _:l1 rdf:rest _:l2 .
 _:l2 rdf:first _:r1 .
 _:l2 rdf:rest _:l3 .
 _:l3 rdf:first _:r2 .
 _:l3 rdf:rest rdf:nil .
 _:r1 owl:onProperty baz .
 _:r1 owl:allValuesFrom bbb .
 _:r2 owl:onProperty baz .
 _:r2 owl:minCardinality "3"^^http://...#nonNegativeInteger .

> OWL-cool has only one drawback -- its not upward-compatible
> with OWL-DL.

Well if keys are considered to be important for OWL-cool they certainly
could also be added to OWL DL.  Annotations are already in OWL DL.  I don't
view subdomains as useful.

> Cheers, Bob

peter

Received on Wednesday, 9 April 2003 11:09:29 UTC