Re: OWL-cool

My MKR language (http://rhm.cdepot.net/)
is a good OWL-cool language!

With respect to your point (b), MKR simply says

    C has P;
    D has P;
or
    C,D has P;
============ 
Dick McCullough 
knowledge := man do identify od existent done;
knowledge haspart proposition list;

  ----- Original Message ----- 
  From: Bob MacGregor 
  To: www-rdf-logic@w3.org 
  Sent: Sunday, April 06, 2003 12:07 PM
  Subject: 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