Re: Feature Synopsis for OWL Lite and OWL

On June 24, Deborah McGuinness writes:
> I am enclosing the current version of the
>         Feature Synopsis for OWL Lite and OWL
> document.
> Frank van Harmelen co-edited this version of the document with me.
> 
> It is posted at:
>     http://www.ksl.stanford.edu/people/dlm/webont/OWLFeatureSynopsis.htm
> 
> and is also attached to this message for archiving.
> 
> Comments welcome to webont (www-webont-wg@w3.org)

I have quite a number of comments. Bottom line: good job getting the
document out in a hurry, but IMHO it still needs quite a bit of work.

1. I think the motivation section needs some work. For one thing, it
is not a motivation for the document, but (almost entirely) a
motivation for OWL lite. I believe that the motivation should first
say why we need this document at all, what it is intended to achieve
and say how it tries to do it (i.e., give an overview of its
contents). Along the way, it could reasonably explain that a subset of
the language called OWL lite will be described first. 

As to why we need OWL lite, the motivation says that it should be
explainable and understandable and easy to implement. I thought we
already agreed that the explainable and understandable part is
nonsense - I wont bother to go over the arguments AGAIN. I'm not sure
what "easy to implement" means either - easier to implement what? This
needs to be clarified.

2. The introduction also says that OWL lite "provides more than
RDFS". As we know, this isn't strictly true - it provides more in some
respects and less in other respects.

3. Features: could consider adding disjoint as it is useful and already
   expressible anyway

4. Section 3: 

- There are too many assumptions about the reader's familiarity with
DL terminology, e.g., "fillers", and too many uses of technical terms
that haven't been introduced, e.g., "unique name assumption", "pair
(x,y) is an instance of P", "extension" of a class etc. It may be
useful/necessary to have a section that gives a bit of technical
background and defines/discusses technical terms to be used in the
text (or to find some way to avoid using them).

- Much of what is said in Section 3 (e.g., about rdf) is generally
applicable and could/should be moved out of the lite section.

- Not clear that it will be correct to use rdf:<term> at all -
reference to this should be removed. 

- I notice an occurrence of ">From", a bug introduced by emailing the
document, I believe.

- no mention of Thing or Nothing.

- Classes may be "created". I'm not sure anything is created. Classes
can be described, perhaps. Should also make it clear that there may be
multiple descriptions of the same class.

- Property paragraph seems rather confused: "terms that are to be used
as relationships between individuals and classes may be defined as
properties". What does that mean? Are we slipping back into talking
about definitions? Also, the comment about use of individual should be
moved to some introductory section.

- Don't like "the first argument of the property must be an instance
of the domain class". For one thing, "the first argument" seems
strange in this context (properties haven't been described as things
that would have arguments); for another, there is a danger of it being
misinterpreted as the constraint view of the world (i.e., an error if
data doesn't conform to schema) rather than the inference
view (mini example is much clearer on this point). Suggest "i.e., when
one individual is related to another by the property, the first
individual is implicitly an instance of the domain class.".

- Same for range.

- sameClassAs: "i.e., the classes have the same extension", as we
didn't say anything about extensional semantics here it might be
better not to refer to extensions here (not sure what to suggest,
perhaps something like "the classes denote/refer to the same set
of individuals", if that is any better?). I don't like the text about
the "side effect" - seems neither clear nor relevant.

- sameIndividualAs: is it really possible to use this to give a name
to an unnamed individual? How do you refer to the unnamed guy, given
that it has no name?

- differentIndividualFrom: too much assumption of familiarity with KR,
DLs in general and Classic/OKBC in particular. E.g., "unique name
assumption", "filler". I suspect this isn't the only example of this
malaise, but I'm not very good at spotting it as, like Deb and Frank,
I am too familiar with this stuff myself. Whole document probably
needs careful checking by people with different backgrounds. Also,
mentions that RDF doesn't make unique name assumption, but doesn't say
anything about OWL. Example is difficult/impossible to understand, in
particular the final sentence.

- inverseOf: "inversely related"? Why not "One property can be stated
to be the inverse of another."? Here we start using terminology like
"the pair (y,z) is an instance of P". This may again be too technical
in view of the fact we didn't say anything about the interpretation of
properties as sets of pairs. 

- IsTheOnlyValueFor: "reasoner may deduce that if two things have the
same social security number, then they denote the same thing". Too
many things - suggest not to use "thing" at all!

- eachValueFrom: does "(universal local range restriction)" help the
target reader? Explanatory "fluff" seems more confusing than
helpful - might be better to go straight into X,Y style, or start with
the example. Care again needed to avoid suggestion of "constraints".

- someValueFrom: ditto

- cardinality: "restrictions limit the cardinality of that property on
subclasses and instances of the class" doesn't make sense - should be
something like "restrictions limit the cardinality of that property on
instances of the class (and on instances of its subclasses)" - in fact
bit about subclasses probably best dispensed with
altogether. Explanations make it sound as though properties are
specific to classes, e.g., "A class may have a property".

5. Section 4: 

- oneOf: care needed with use of terms like "defined" and classes
being equal to sets of individuals etc. In fact it is the extension of
the class that is equal to the set of (the extensions of) the
individuals. More use of un-introduced technical terms.

- unionOf, complementOf, and intersectionOf: intersection of all the
class of all Dutch citizens -> intersection of the class of all Dutch
citizens. Could use some better examples, particularly for union and
complement. Defined crops up again.

That's all for now!

Ian




> 
> thanks,
> Deborah
> 
> --
>  Deborah L. McGuinness
>  Knowledge Systems Laboratory
>  Gates Computer Science Building, 2A Room 241
>  Stanford University, Stanford, CA 94305-9020
>  email: dlm@ksl.stanford.edu
>  URL: http://ksl.stanford.edu/people/dlm
>  (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)
> 801 705 0941
>

Received on Monday, 1 July 2002 00:35:48 UTC