OWL-cool

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.

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.

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.

Point (v): RDF syntax is horrible.  The OWL languages inherit
that horribleness.  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.  Not only
are they hard for people to read, they are difficult 
to interpret by non-DL inference engines.  When you
buy into OWL-DL, you may be kissing good-bye to 
rule-based inference.

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.

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.

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

Cheers, Bob