Review of Reference Document

here is my detailed review of the Reference document.  As I said 
previously, the Reference is much improved, and this long list of 
comments only talks to the editorial issues - technically the 
document is now quite strong.
  -JH

general typographical note -- some language features appear in mixed 
upper lower case font others appear in "small capital" font.  Editors 
should pick one or the other and make these consistent.


Sect 1.1 Purpose of the document -

1st paragraph copyedit:
  should end "for a more narrative description and examples of the use 
of the language.

3rd pp:
  would be best if you mentioned all documents - you should include a 
mention of use cases and Test.

Section 1.2 (and throughout) -- you are uneven in your use of links 
to other documents.  You should make sure that all mentions of 
Overview, Guide, etc. are linked.

3rd paragraph (optional)
  this would be a good place to say something about Owl "flite" -- 
that is to mention that Owl Lite is a vocabulary useful in two ways - 
as a subset of the Full Owl and as a subset of DL, and that we will 
use the term "Owl Lite" for the latter.

1.3 copyedit
  Thus, it is allowed => Thus, it is allowable

final sentence copyedit
  and is therefore perfectly allowed => and therefore would convey the 
same meaning.


1.4 - editing suggestion
I think this section needs to be longer, and we need to discuss more 
specifically the upgrade path from RDF(S) to OWL -- we have to 
address the fact that RDFS with OWL is not usually going to be OWL 
Lite, otherwise we will get adverse comments (cf. CG discussions at 
www-semweb-cs@w3.org - member only)

1.5 annotations
Now that we have a solution, we need to add it here.  This will be 
the primary place where it is discussed.  We also have to make it 
clear how reference to other ontologies (without imports) works -- 
that is, do these need to be types as annotations or not?

1.6
change second paragraph to (copyediting):

The examples in this document are meant to serve as illustrations of 
the use of OWL language constructs.  They do not form one consistent 
ontology.  For an extended example the reader is referred to the 
Guide Document [ref].

2.0 intro -- this needs to be reorganized -- some of it belongs back 
in section 1.  I'd suggest creating a section that describes the 
appendices of this document, and then put the rest in 2.0 where it 
belongs.  Thus, I suggest the following becomes section 1.7, and then 
section 2.0 is the rest. (about rdf:RDF etc.)

------------ HTML FOR CHANGES TO SECTION 2.0------------
<h3><a name="AppendixList">1.7 Appendices to this Document</a></h3>

<p>
This document has a set of appendices containing additional information.
Links in the text attached to definitions of
language constructs provide access to the
OWL Abstract Syntax and Semantics
[<cite><a href="#ref-abstract-syntax">OWL AS&amp;S</a></cite>].
<a href="#appA">Appendix A</a> contains a
systematic set of links for each language construct to the
corresponding sections in the Guide and the AS&amp;S documents.</p>

<p><a href="#appB">Appendix B</a>
contains an RDF schema for the OWL language constructs.
This schema defines the OWL language constructs in terms of RDF Schema
classes and properties.
This schema
provides the basis for the RDF/XML syntax of OWL. Conventionally, classes
have a leading uppercase character; properties a leading
lowercase character. Thus, <code>owl:Ontology</code> is a class, and

<code>owl:imports</code> is a property.
</p>
<p>
<a href="#appC">Appendix C</a> gives a tabular overview of all
OWL language constructs in
terms of the built-in OWL classes and properties (the latter
with their domain and
range).</p>

<p>
The <a href="http://www.w3.org/2001/sw/WebOnt/charter"> Web Ontology 
Working Group Charter </a>  states that
<blockquote cite="http://www.w3.org/2001/sw/WebOnt/charter">
The Working Group shall start by evaluating the technical solutions 
proposed in the DAML+OIL draft. If in this process the Working Group 
finds solutions that are agreed to be improvements over solutions 
suggested by DAML+OIL, those improved solutions should be used.
</blockquote>
Thus, the <a href="http://www.w3.org/TR/daml+oil-reference">DAML+OIL 
(March 2001) Reference Description</a> provided the basis for OWL.
For readers familiar with DAML+OIL, <a href="#appD">Appendix D </a> lists the
changes between DAML+OIL and OWL.</p>

------------ End of HTML FOR CHANGES TO SECTION 2.0------------

2.1 As well as talking about the name space we need to say something 
about Mime type.  We seem to have lost this as an appendix, but not 
suggested it as a separate document ... something needs to happen in 
the WG, and be reflected here.

3.0  copyedit
   owl:Ontology
    a ontology => an ontology

suggestion
  the ontology header uses the example "owl:imports ..." and imports 
the owl namespace doc.  I suggest we use a different example or do 
two imports, to make it clearer that any ontology can be imported, 
not just the name space.

owl:imports - reword
The text as written is confusing.  I suggest instead

Note that the importing a document is different than creating a 
namespace reference.  owl:imports do not set up a shorthand notation 
for names as does a namespace reference.  On the other hand, the 
namespace reference does not imply that all (or even any) ontological 
terms from that namespace are being imported.  Therefore, it is 
common to have a corresponding namespace declaration for any ontology 
that is imported.


owl:versionInfo - there is an "@@" in here, should be removed

last sentence in owl:backwardCompatibleWith - copyedit
  and thus has also => and thus also has

section 4 - classes

there is a missing example (the @@) - I'm not sure an actual example 
is needed here, suggest deleting.  However, I think we need some test 
in here that explains when to use owl:class -- doesn't have to be 
technical, just something that makes it clear.  For example, could be 
as simple as

In OWL Lite and OWL DL, owl:class must be used for all class 
definitions.  In OWL Full, owl:class and rdfs:class are synonyms and 
either one can be used in a class definition.

4.1 - copyedit
...which satisfy the property restriction (3rd type) => ...which 
satisfy the particular property restriction (3rd type)

4.1.2 property restrictions, sentence about owl:Restriction --
it says "c.q. cardinality restriction ..."  - I think c.f. is better 
here, but whichever you use, make sure it is in italics to indicate 
that this isn't a typo.

end of section 4.1.2 says "see the section on properties" -- this 
needs to be a link.

4.1.2.2 cardinality restrictions

it reads "The default cardinality of properties is "any".
that is unclear, but more importantly this is an important point that 
needs to be made.  How about

In OWL, it is assumed that any instance of a class may have an 
arbitrary number (zero or more) of values for any property.  To make 
a property required (at least one), to allow only a specific number 
of values for that property, or to insist that a property must not 
occur, cardinality restrictions must be used.   OWL provides three 
constructs for restricting the cardinality of properties (locally) 
within a class context.

owl:maxCardinality
I'd like to suggest not using two parents in both example -- why not 
make the first example "at least one parent"

I'd also suggest we end that section by adding a sentence which reads

Note that an owl:minCardinality of one or more means that a value for 
the property is required of any instance of the class.

owl:intersectionOf
the WG decision to include owl:intersectionOf in Lite is not 
reflected in this section - it
appears in a note in a later section (on axioms for complete 
classes).  I'd suggest that we introduce a note in this section that 
simply says

NOTE: OWL Lite is restricted in its use of owl:intersectionOf.  This 
is discussed later in this document, see section (appropriate 
name/link)




There is a NOTE about the unique names assumption that occurs in this 
section (4.1.3 in owl:intersectionOf).  I think the discussion of the 
unique names needs to be moved elsewhere (probably with 
allDifferentList) and this should just point at that.

owl:unionOf and owl:complementOf
these are not available in OWL Lite, this should be noted.

example of owl:complementOf - since you are reconsidering anyway, I 
think it would be less confusing to use a simple example of just "not 
meat" and use a hasValue instead of a collection.   Mixing the union 
and the complement blurs this example anyway

rdfs:subclassOf

There is an @@ asking whether to add a note about rdf:about v. rdf:id 
-- I would suggest NOT adding that - no reason for it here.

I would suggest removing the discussion of multiple subclass axioms 
for the same class defining an intersection-- and take out the 
example of the two semantically equivalent definitions of Opera. 
This stuff is in Guide, and doesn't seem to be needed here.

owl:equivalentClass  has an @@ that should be removed

The note at the end of the section on owl:equivalentClass - copyedit

As OWL should be usable in a distributed environment,
this may be a useful feature. => As OWL is usable in a distributed 
environment, this can be a useful feature.

Axioms for complete classes without using equivalentClass

the note at the end of this section about OWL Lite mentions the use 
of intersectionOf.    this is the note that should be referred to in 
the intersectionOf section (see above)

the @@ asks whether to add a guideline on explicit v. implicit form 
of complete classes -- I wouldn't add anything else at this point, so 
that could be deleted.

SECTION 5  - Properties

remove the parenthetical remark about a possible better term for 
object properties -- silly for a reference to say "there's a better 
name, but we didn't use it"

copyedit - characteristics of a properties => characteristics of a property

sentence following
<owl:ObjectProperty rdf:ID="hasParent" />
copyedit -- say "this defines a property with the restriction (by 
default) that"   (i.e. add the "by default")
NOTE at end of rdfs:subproperty  says "in OWL DL the range and domain 
... should be either both ..." but that should be "must be either 
both"  as this is mandated in the design

(optional)
I wonder if the section on subproperties might be a good place to 
mention that owl's use of local property restrictions adds power -- 
i.e. in rdfs it is easy to say that hasMother is a subproperty of 
hasParent, but very hard to say that if the class is "Kitten," then 
hasMother is restricted to be of class "cat" -- might be worth just 
pointing to local properties here and saying that sometimes local 
properties can be used to avoid creating artificial subproperty 
hierarchies (i.e. having to create KittensMother subproperties)

rdfs:range
there is a note at the end that rdfs:range restrictions should be 
used with care.  I believe the same is true of rdfs:domain 
restrictions (although maybe less so) - consider a similar note in 
the domain section   (Optional)

owl:equivalentProperty

I don't see a need for an example in this section, the concept is 
clear.  I'd suggest just dropping the @@ add example.

owl:inverseOf - there is an @@ for a note that does, indeed, still 
need to be added.

owlFunctionalProperty

there is a sentence which reads "This corresponds to the notion of 
"optional" value encountered in many data-modeling notations" - maybe 
I'm dense, but I don't see the relation between functional property 
and optional value.  This should either be deleted or explained 
better for dummies like me.

owl:inverseFunctionalProperty

you use the example of social security number, but that's not a 
really good one as it is a one-one relation -- I'd like to suggest an 
example where it isn' t  one to one.  possibiltiies would be the 
mapping from children to mothers -- i.e. "BiologicalMother" is 
inversefunctional -- cannot have BiologicalMother(Mary,Jim), 
Biological Mother(Jane, Jim)   - however, My mother can (and does) 
have several biological children - so this is an example of an 
inverseFunctional property that is not also functional (which is the 
problem with SocSec #)

owl:SymmetricProperty - copyedit
change first sentence to
"The OWL property class owl:SymmetricProperty is also a subclass of 
owl:ObjectProperty.

note: is this true?  Could we have a property in OWL that is 
symmetric but has datatypes for range and domain?  Mathematically 
this would be useful (i.e. the class abelian group is a subclass of 
group for which certain symmetry properties between members, which 
must be datatypes, hold).  If we don't allow it in Lite or DL, do we 
allow it in Full?

6.0 individuals

We should state explicitly that individuals are typically defined 
using RDF and that the examples we provide are just for additional 
clarity and to show how OWL can be used to add some additional 
expressivity to the RDF.    Add a sentence to that effect in section 
6.0, and then go to 6,1 (individual axioms" and it would be much 
clearer.

6.2
owl:sameAs and owl:sameIndividualAs

it would be worth adding a sentence at the end contrasting these to 
equivalentClass.  i.e. the example of football team being same as 
soccer team could be contrasted to

<:footballTeam owl:equivalentClass us:soccerTeam />

to make clearer the difference between denoting same thing and 
denoting same extension.

owl:AllDifferent
I think we need to emphasize that owl:distinctMembers has no meaning 
outside the context of owl:AllDifferent.  (add a NOTE to this 
effect?)  - explanation of how to add to the list is important - 
should be added (or referred to if Guide adds it)

7.2 enumerated datatypes
we need to keep an eye on RDF for this one.  I, and possibly others, 
have raised it in their comments list.  If they decide to allow 
datatypes in collections, then we will have a nicer syntax for this 
powerful feature.

8.0 the section refers to an "informal" description.  Let's make that 
"informative" which is still true, but less pejorative sounding as 
this is  now the only place in our non-normative documents where we 
really discuss this stuff, particularly the implication that OWL Lite 
vocabulary in Full might be a useful subset

8.1 might be a good place to mention that RDFS documents will 
generally be in OWL Full unless they are specifically constructed to 
be in DL /Lite

8.3 the discussion of OWL Lite doesn't mention that there is a 
complexity class reason for it as well.  This section also doesn't 
discuss compatibility with RDFS.  I think these are easily fixed:
  i. add a sentence at the end of the paragraph starting "The idea 
behind the OWL Lite expressivity limitations..."  which states
  In addition, the limitations on OWL Lite also place it in a lower 
complexity class than OWL DL.  This can have a positive impact on the 
efficiency of complete reasoners for OWL Lite.

  ii. drop the first sentence of the last paragraph (the one which 
starts Owl Lite is constrained to be a subset of Owl DL" because it 
is redundant.  Start  the paragraph with the following sentence with 
the word "Implementations" (i.e. delete "In addition" from the start 
of that sentence.

  iii. add RDFS models to the list of things Lite (without DL) could 
be used for -- i.e.
in providing interoperability of OWL systems with RDFS models, databases, ...

iv. change the very last sentence to
  "The Web  Ontology Working Group has not provided a name for this 
potentially useful subset."

9, Class and property deprecation - copyedit
delete the words "Once again" from the second to last sentence in the 
first paragraph of this section

Appendix A
We don't list the rdf/rdfs constructs used in OWL -- this makes sense 
because this is a linking table to our own documents -- but maybe add 
a sentence that just says "for any feature from RDF or RDF Schema 
please see the appropriate documents" with a link to our references 
which in turn link to their documnts

Appendix D
Something probably needs to be said in here about the fact that we 
have changed the semantics to a large degree, and also that we added 
the three sublangauges with D+O being most like Owl DL.














-- 
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, 18 February 2003 16:31:18 UTC