Re: [OEP] The n-ary relations draft is ready for outside review

At 03:27 PM 6/20/2005 -0700, Natasha Noy wrote:

>There is a new editor's draft of the n-ary relations note at [1]  
>(linked from the OEP page). 
...
>At this point, we would like to propose that this note moves to the  
>review of WG members outside the TF in order to move it to a Second  
>WD status. We will decide on this at the OEP telecon on Thursday.  
>After that, we will ask for volunteers to review. If there are any,  
>please let us know (I think Ralph was one).
>
>Natasha
>
>[1] http://smi-web.stanford.edu/people/noy/nAryRelations/n- aryRelations-2nd-WD.html

OK, here are my comments.  Point-by-point response not needed.

http://www.w3.org/2001/sw/BestPractices/OEP/n-aryRelations ->
http://smi-web.stanford.edu/people/noy/nAryRelations/n-aryRelations-2nd-WD.html
Editor's Draft 20 June 2005

Technical:

Overall, very good and useful.  A definite improvement over the
first draft.

Readers who know of RDF reification might start wondering early-in
about the relationship between that and issue 1 and use cases 1
and 2.  This is finally acknowledged once pattern 1 is introduced.

I think it might be useful to mention RDF reification much earlier;
perhaps with a brief sentence at the end of General Issues something
like "These patterns avoid using RDF reification for reasons
discussed in the final section."

Considerations when introducing a new class for a relation
3rd bullet, "Each of the properties participating in the n-ary
relation should have ...".  In what sense is the word "should"
meant here?  Is this intended to be a statement about characteristics
of a well-formed ontology defining all inverses or a comment about
special considerations when defining properties for use with this
pattern?

N-ary relations and reification in RDF

This section is good, and makes an important but subtle point about
Statements vs. relations.  I almost wish the section weren't left
to the end.  The final sentence could be amplified.  The use cases
demonstrate that the intent is to talk about instances of a
relation, not about statements about such instances.

Editorial:

Front matter

In Previous Version you should feel free to cite the current
public Working Draft.  (We'll need to add that before publishing
anyway.)  Some editors have found it convenient to use an
automatically-updated content management system tag, such
as $Date$ in the 'This Version' field of editors drafts.
(We'll replace this with a static URI at the time of publishing.)

Status of this Document

On behalf of those who are religious about such things, I suggest
saying "is intended to [be part of]" rather than "will [be part of]";
i.e. avoid making promises about the future.

Representation patterns

This is a nit that applies to the first draft as well.
The graphical notation is different in the first three figures
from the remainder of the figures.  In the first three figures
(or at least figures 2 and 3), 'P' is a label for an instance
of a relation, whereas in the remainder the similar text
names the predicate portion of the relation.  Perhaps a small
dotted rectangle around P in figures 2 and 3 would suffice to
demark that that use of the notation is not the same as the
conventional RDF circles-and-arrows notation.

Somewhere around Use Case 1 where we start using Turtle/N3 syntax
it would be good to cite a reference for this syntax.  The SPARQL
Working Drafts set a precendent for this; see
http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/#docDataDesc

Use Case 3:
Some readers might find it helpful if it were pointed out that
OWL Restrictions are themselves an example of this use case.
(After writing this I noticed that Dan Connolly made a
similar comment in
http://lists.w3.org/Archives/Public/public-swbp-wg/2005Feb/0077.html )

Considerations when introducing a new class for a relation:
It might be helpful to comment on why an is_amount_for inverse
relation makes little sense, as it is omitted from the figure.

Pattern 2:
4th paragraph; suggest including links for OWL Full and OWL-DL; e.g.
http://www.w3.org/TR/2004/REC-owl-features-20040210/#s1.3

Is there a simple reference to cite for why using rdf:List with
pattern 2 makes the result no longer OWL-DL?

In the (Turtle) illustration of the argument list for the flight
sequence, either use elipses to denote that the rest of the list
has been omitted or simply include the rest of the list, as it's
short enough and helps to make the point in bullet 2 following
thta "this technique uses a lot more triples".

Typos:

Abstract:
s/multple/multiple/

Vocabulary for n-ary relations:
first instance of "n-ary relations" should be singular.

Suggest "A note on this vocabulary ..." rather than "The note ...".

Pattern 1:
2nd paragraph, s/areften/are often/
Suggest "in this document" rather than "in the document" in the
final sentence of 2nd paragraph.

Use Case 1:
3rd paragraph, plaintext reference to note 2 should be to note 3
(the hypertext reference is ok).

4th paragraph; plaintext reference to note 3 should be to note 4
(the hypertext reference is ok).

final paragraph (before the definition of Person), the reference
to Diagnosis_1 should be Diagnosis_Relation_1.

Use Case 3:
2nd figure; the "birthday_gift" instance should be capitalized
as "Birthday_Gift" as it is in the Turtle/N3 following and the
linked OWL code example.  The same capitalization should appear
in the derived figure in "Considerations when introducing a new
class for a relation".

The (Turtle) illustration of the definition of the class Purchase
omits the has_amount restriction.  Either include it or note in
the preceeding text to see the OWL code for the complete definition.

Considerations when introducing a new class for a relation:
next-to-last paragraph; s/restict/restrict/

Pattern 2:
3rd paragraph; s/RDFSis/RDFS is/

Notes (at end)
2. s/play and important/plan an important/
4. Suggest inserting "The" at the front of the sentence
   "RDF specification encourages..."
4. Something is wrong with the last sentence of this point.
   I'm not sure what the sentence is trying to emphasize so I
   can't propose a fix ("... we made diagnosis_value a subproperty
   ... instead of diagnosis_value property...".)
6. s/simply number/simple number/

[end]

Received on Monday, 1 August 2005 20:22:04 UTC