Re: review of Guide

Just some comments on all these comments - snipping some out



Mike:
>  > I was purposely pitching the abstract at a less academic audience.
>>  When they read the first paragraph I wanted to provide some motivation
>>  to read on.  Perhaps I should assume that if they are reading the
>>  Guide they are already motivated.  I am flexible on this.  What do
>>  others think?
>

Peter:
>Abstracts are supposed to meet quite a lot of requirements, the most
>important of which is conciseness.  As I remember it, one of the sub-points
>of the conciseness requirement is that abstracts are to be one paragraph
>with no special formatting.

that is true of an academic paper, but not of a W3C report.  The 
definitive style manual for W3C is at [1], and it says this of 
abstracts:

>9.2 Abstract
>
>Each document must have an Abstract (a few paragraphs at most) that 
>summarizes what the document is about. The Communications Team may 
>use the Abstract as a whole or in part to publicize your work, so 
>write it for a non-technical audience.

So I would definitely go with what Mike had, not with the more 
concise one and definitely write it for a non-technical audience.


>[snip]



>[snip]



>  > > REMOVE
>>  >
>>  > <p>
>>  > Datatype properties and object properties are collectively the
>>  <em>properties</em> of a
>>  > class.
>>  > </p>
>>
>>  Dependent on the change above.
>
>This statement is both wrong and misleading. Classes do not have properties
>in this sense.  Regardless of any other change to the document, this
>sentence *needs* to be changed.

Properties "associated" with a class?  It is important in the Guide 
that we mirror the way our users will think and use our terms - IMHO 
it is not the document where we most need to worry about technical 
accuracy in the exposition - it is the examples that matter the most, 
and we want people to understand them and be able to cut and paste 
what they need to edit into their forms.  People wanting technical 
detail have the semantics document to go to, and the ref to check - I 
think it important Guide stays readable.

>
>>  ----------------------------------------------------------------------------
>>  > CHANGE
>>  >
>>  > <li>
>>  > <em>Owl Lite</em> has been defined with the intention of
>>  >   satisfying users primarily needing a classification
>>  >   hierarchy and simple constraint features.  For example, while it
>>  >   supports cardinality constraints, it only permits cardinality values
>>  >   of 0 or 1. For these reasons, it should be simpler to provide tool
>>  support for
>>  >   Owl Lite than its more expressive relatives.  
>>  > </li>
>>  >
>>  > TO
>>  >
>>  > <li>
>>  > <em>OWL Lite</em> has been defined to admit simpler tools.
>>  > It does not include all the OWL vocabulary, and places restrictions on
>>  some
>>  > of the OWL vocabularly.
>>  > For example, while it
>>  >   supports cardinality constraints, it only permits cardinality values
>>  >   of 0 or 1.
>>  > As well, OWL Lite incorporates the restrictions placed on OWL DL.
>>  > </li>
>>
>>  Is OWL Lite just about simpler tools?  I thought we were additionaly
>>  targetting a more basic audience.  Maybe not.
>
>As disussed several times in WG teleconferences, *the* rationale for OWL
>Lite is to support simpler tools.  The only other design criterion for OWL
>Lite was that it be a substantial extension to RDFS.

I think I prefer what Mike for GUIDE, features makes it clearer what 
and why the split is, but in this case we are focusing on the USE of 
the Lite stuff, as opposed to technical distinction - if you don't 
like the word intention, we can make it

"OWL Lite supports those users primarily needing a classification 
hierarchy and simple constraint features ...:
   -- I think this is a very important aspect of the language from a 
USE Case perspective, and there are many vocabulary designers out 
there (or web sites we can scrape) which would be attracted to OWL 
through Lite (and, one hopes, eventually use more of it's 
capabilities)

>
>>  ----------------------------------------------------------------------------
>>  > CHANGE
>>  >
>>  > <li>
>>  > <em>OWL DL</em> allows the complete OWL vocabulary, interpreted
>>  >   under a number of simple constraints.  Primary among these is type
>>  >   separation.  Class identifiers cannot simultaneously be properties
>>  >   or individuals.  Similarly, properties cannot be individuals.
>>  >   OWL DL is so named due to its correspondence with
>>  >   <a href="#DescriptionLogics"><em>description logics</em></a>.
>>  >   It was designed to support the existing Description Logic
>>  >   business segment and has desirable computational properties
>>  >   for reasoning systems.
>>  > </li>
>>  >
>>  > TO
>>  >
>>  > <li>
>>  > <em>OWL DL</em> allows the complete OWL vocabulary, but places constraints
>>  > on its use.
>>  > Primary among these is type
>>  >   separation.  Class identifiers cannot simultaneously be properties
>  > >   or individuals.  Similarly, properties cannot be individuals.
>>  >   OWL DL is so named due to its correspondence with
>>  >   <a href="#DescriptionLogics"><em>description logics</em></a>.
>>  >   It was designed to have desirable computational properties
>>  >   for reasoning systems.
>>  > </li>
>>
>>  I'm agnostic about the above change re "the existing Description Logic
>>  business segment".  However, that was inserted based on a previous WG
>>  suggestion.
>
>The change to the first sentence makes it much more correct.
>
>I am unhappy in general with wording like ``support the existing ...''
>unless there is a direct existing whatever that can be pointed to.

the DL business segment does indeed exist, strange as it is for me to 
be the one defending it.  The medical research community uses DL 
tools for ontology development, and looks to be one of the prime 
users of OWL.  I don't care so much that this line appear in GUIDE, 
but it should definitely appear somewhere in our documents.  I'm 
happy to point people at some of the companies that support this 
(present members accepted).

>
>  >
>>  Glad you brought this up.  Let me confirm: should I say explicitly
>>  that the normative OWL XML syntax is RDF/XML? 
>
>This is a good question.  I believe that the normative OWL exchange syntax
>is defined to be whatever the normative RDF exchange syntax is.  In any
>case, I believe that it is not necessary to state what the normative OWL
>exchange syntax is here, as this is a Guide.

For the record, the WG resolved that the normative exchange syntax 
for OWL was RDF/XML.   This was recorded in the minutes of the 
Amsterdam face to face
which reads [2]:

>RESOLUTION: The exchange language for OWL is RDF/XML
>==> 16 in favour

and this has been reconfirmed several times.

>
>>  ----------------------------------------------------------------------------
>>  > REMOVE
>>  >
>>  > This is a conventional
>>  > OWL declaration, required to introduce the OWL vocabulary.
>>
>>  Not true?  Or just not necessary?
>
>Not true.  The declaration is not *required*, as there are lots of other
>ways to talk about the OWL vocabulary, some of which use different
>namespace declarations.

I think we need something, how about

"This is a conventional OWL declaration used to introduce the OWL 
vocabulary" (or ontology if the word vocabulary not correct here)
>
>
>>  ----------------------------------------------------------------------------
>>  > THE HISTORY section is not useful.
>> 
>>  I am agnostic on this.
>
>The Guide is very long.  This section has no relationship to the rest of
>the Guide, and thus deserves to go.

there was strong feeling on the part of the WG that we needed a 
HISTORY section somewhere, and I think this is the best document for 
it.  I'm not too concerned with Guide being long (esp. if this is an 
appendix), because I think by the time people are working through 
Guide they're already interested in using the language.  I'd also be 
happy to move the History section to our Web site somewhere and just 
link to it from GUIDE - that would also be an acceptable solution.

>
>>  ----------------------------------------------------------------------------
>>  > THE TERMINAL UML note is not useful.
>> 
>>  I am agnostic on this.
>
>The question is whether this adds to the utility of the Guide.  I vote a
>very strong NO.
>
>peter

I think that this depends on whether we include the UML syntax 
appendix or not.  If that gets done in time and added to Reference, 
then having this in Guide with a pointer to that is appropriate.  If 
not, then I'd agree w/Peter.  I believe Guus, Masahiro and Evan are 
still working on that document

[1] http://www.w3.org/2001/06/manual/
[2] http://www.w3.org/2001/sw/WebOnt/ftf2.html
-- 
Professor James Hendler				  hendler@cs.umd.edu
Director, Semantic Web and Agent Technologies	  301-405-2696
Maryland Information and Network Dynamics Lab.	  301-405-6707 (Fax)
Univ of Maryland, College Park, MD 20742	  240-731-3822 (Cell)
http://www.cs.umd.edu/users/hendler

Received on Tuesday, 31 December 2002 09:16:21 UTC