Re: Comments on the OWL-Lite draft

Thanks Bob for your comments on the Feature Synopsis Document and, in
particular, on the choices
concerning OWL Lite.
We greatly appreciate comments on the documents and particularly value
comments from people like
youself who have spent many years designing, implementing, and using
knowledge representation and
reasoning systems.
(for those on the mailing list who do not know, Bob MacGregor is the
original author and later
technical lead for Loom and PowerLoom among other things).

Specific responses below.
We welcome any additional input.

thx,
Deborah

Bob MacGregor wrote:

> Recommendations: (1) Toss out cardinalities altogether in OWL-Lite.
> FunctionalProperty alreadycovers the MAX1 case.  Add a
> 'RequiredProperty' property to cover MIN1.Invent a third property to
> cover MAX0.
>
> ***thx for the input.  The initial proposal actually contained this
> general idea.  There was opposition from members who wanted uniformity
> for cardinality statements.
>   People objected to using functional  for the combination of min 0
> and max1
>   and required for max 1
>   and noValues for max0
>
>   Since the two options provide the same expressive power, the group
> went for uniformity.
>   I wonder though - did you say this because you have had experience
> with users who were confused about cardinalities but were happy with
> functional, required, an noValues (or equivalent)?
>   If so, that would be valuable input.
>   (2) State upfront whether or not OWL-Lite is intended to beupward
> compatible with RDF(S).
>
> ***The working group is working on a more precise statement of the
> exact relationship between OWL/OWL Lite and RDFS.  Since work
> continues on refining this statement, we were not precise in the
> feature synopsis document but a future version will be more  precise.
>   The expectation is that it will be upwards compatible in the sense
> that it extends RDFS in expressive power however there will be some
> restrictions on the way expressions are interpreted. (3) Toss out
> TransitiveProperty and SymmetricProperty.  They add littleif any
> value, and make things harder to implement.
>
>
> **thanks for the feedback.  Some members of the working group
> sympathized with this view however some of our use cases in our
> requirements specification required transitive and symmetric.
>   If you have a number of use cases without this expressive power,
> that would be interesting and if you have implementation issues that
> your efforts ran into with transitive and/or symmetric, they would
> also be extremely interesting. (4) Forget about OWL-Heavy (for now;
> maybe forever).
>   **Jim Hendler has responded to this and the next point - i will copy
> them here for completeness:
>
>   jh - this latter is definitely an issue the group will consider -
> it's
>   already in our issue list (i.e. whether to have levels or just
> "heavy" or just lite)
>   Question: What happened to 'first' and 'rest'?  The 'bag' stuff in
> RDF is hideous.If 'first' and 'rest' clash with some other properties
> from a computabilitystandpoint, consider eliminating those other
> properties.***from hendler:
>   the RDF Core WG has announced that they intend to provide a
> collection parsetype similar to the one used in  DAML+OIL (i.e. first
> and rest) -- we currently intend to use their solution to closed sets,
> at the time we wrote these  documents we didn't have details of their
> solution.===========================================
> Bob MacGregor                                   macgregor@isi.edu
> Project Leader                                     voice: 310.448.8423
>
> Distributed Scalable Systems Division   cell: 310.251.8488
> University of Southern California            fax: 310.822.6592
> Information Sciences Institute
> 4676 Admiralty Way
> Marina del Rey, CA 90292

--
 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/index.html
 (voice) 650 723 9770    (stanford fax) 650 725 5850   (computer fax)
801 705 0941