Re: Comments for WD-rdf-mt-20030123

>These are minor comments for your "RDF Semantics" Last Call Working
>Draft [1].

Minor? Wow. Many thanks for the close attention. In a former life I 
earned a small living doing copyediting, and I am in awe.

Pat Hayes

Comments and a few questions follow.

>The images are beautiful, maybe the best I have ever seen at W3C.

The secret weapon here is OmniGraffle, which I recommend highly. 
Worth buying a mac for.

>
>Words in the headings and TOC can be capitalized, and the Introduction
>can start with section 1 like the other RDF drafts, for example "1.1
>Specifying a Formal Semantics: Scope and Limitations." TOC number 4.1
>and 4.2 each need a space.
>
>The RFC 2119 key words can be marked up like this:
>http://www.w3.org/2001/06/manual/#RFCs
>
>Please avoid we (see http://www.w3.org/2001/06/manual/#ref-PRONOUNS).

Hmm, that poses a problem. The only acceptable alternative in English 
is the consistent use of the passive voice, which is widely 
deprecated as making mathematical prose unreadably dull.

>
>minor typos, some global:
>s/licence/license/
>s/emphasise/emphasize/
>s/heirachies/hierarchies/
>s/heirarchies/hierarchies/
>s/wellformedness/well-formedness/
>s/constitutents/constituents/
>s/intepretations/interpretations/
>s/Semantics/semantics/
>s/N-triples/N-Triples/
>s/Ntriples/N-Triples/
>s/unicode/Unicode/
>s/graph.(We/graph. (We/
>s/irrelevant.(In/irrelevant. (In/
>s/syntax.( If/syntax. (If/
>s/vocabulary.We/vocabulary. We/
>s/Class Extension/class extension/

That was deliberate, to indicate by capitalization the intended 
acronym. I will use italics to make the point.

>s/other.We/other. We/
>s/web-based/Web-based/
>s/Lemma.If/Lemma. If/
>s/of G ,/of G,/
>s/sk(E).Clearly/sk(E). Clearly/
>s/establishes that the 'if' part/establishes that the 'if' is part/

Again that is deliberate and normal usage in mathematical proofs, but 
I will try to find another way to phrase it.

>s/e.g.between/e.g. between/
>s/entailment(n.)/entailment (n.)/
>s/eg/e.g./
>s/hse/he or she/
>s/(with a:)(ii)/(with a:) (ii)/
>s/M.,Connolly, D.,van Harmelen, F., Hendler, J.,Horrocks, I., 
>McGuinness, D., Patel-Schneider, P.,Stein, L./M., Connolly, D., van 
>Harmelen, F., Hendler, J., Horrocks, I., McGuinness, D., 
>Patel-Schneider, P., Stein, L./
>s/Masinter,L./Masinter, L./
>s/R..circulated/R. Circulated/
>s/Saarela, J../Saarela, J./
>s/McGuinness,D. L./McGuinness, D. L./
>
>Also, s/Qname/QName/ and Namespaces in XML can be a normative reference.
>
>In the Abstract (or wherever they appear first), spell these out: RDF
>and RDFS, "Resource Description Framework (RDF) and RDF Schema (RDFS)."
>
>RDFS and RDF/S are mentioned in the introduction. Nowhere is RDF/S
>defined. It appears again once in the glossary. I think it means RDF
>Schema.

The intention is 'RDF  or RDFS' I will spell this out in each case or 
rewrite to suit.

>You could say "RDF Schema (RDFS)" in the first occurrence, and
>RDFS after that.
>
>Later, RDFS is referred to as being in the future, for example "will be
>central in interpretations of RDFS." Do you mean that the reader is
>going to read RDFS after the present document? (That can't be assumed.)

This uses a convention where the process of reading the document is 
perceived as a narrative or conversation between the writer and 
reader.  I will rephrase this more appropriately.

>     We believe that both of these descriptions, and also the closure
>     rules described in section 4, are all in exact correspondence, but
>     only the directly described model theory in sections 1- 3 should be
>     taken as normative.
>If section 4 isn't normative, maybe you could omit it.

It is apparently widely thought useful as an informative aid, 
particularly for readers not closely familiar with model theory.

>
>This sentence is too long:
>     Notice that one does not, in general, obtain the merge of a set of
>     graphs by concatenating their corresponding N-triples documents and
>     constructing the graph described by the merged document, since if
>     some of the documents use the same node identifiers, the merged
>     document will describe a graph in which some of the blank nodes
>     have been 'accidentally' merged.
>It could read:
>     Notice that one does not, in general, obtain the merge of a set of
>     graphs by concatenating their corresponding N-triples documents and
>     constructing the graph described by the merged document. If
>     some of the documents use the same node identifiers, the merged
>     document will describe a graph in which some of the blank nodes
>     have been 'accidentally' merged.
>
>Re:
>     (In this and subsequent examples we use the greater-than and
>     less-than symbols in several ways: following mathematical usage to
>     indicate abstract pairs and n-tuples; following Ntriples syntax to
>     enclose urirefs, and also as arrowheads when indicating mappings.
>     We apologize for any confusion.)
>You could use emphasis (strong, em), weight, color and italic to make
>distinctions. As a last resort "<", "<<", and "<<<" would work.

I thought it unwise to rely on font distinctions such as (code, TT), 
and the use of color to convey meaning is considered tasteless in 
mathematical circles. But I will experiment with the use of emphasis 
for the (rare) arrow cases.

I presume it would not be appropriate to use exotic mathematical 
markup, even though these work on all recent browsers?

>
>At the end of 3.1:
>     The RDF vocabulary contains several other items. Some of these are
>     omitted because they have no formal semantic meaning, or have a
>     meaning which can only be described using the RDFS vocabulary.
>Can this appear earlier, say in 3?
>
>Does this belong in the beginning of the spec rather then at the end of
>a 3.2 paragraph?
>     We will refer to the complete set of all rdf urirefs, consisting of
>     the RDF vocabulary and all of the reification, container and
>     collection vocabularies and the uriref rdf:value , as the RDF
>     vocabulary, rdfV.

I think so, as the definition is intended only to be used within the document.

>
>     The reason for first is clear, since the reification only asserts
>     that the triple token exists, not that it is true.
>is an incomplete sentence. It could read:
>     The reason for the first is clear. The reification only asserts
>     that the triple token exists, not that it is true.
>
>This sentence is too long:
>     Semantic extensions MAY place extra syntactic well-formedness
>     restrictions on the use of this vocabulary in order to rule out
>     such graphs, and MAY exclude interpretations of the collection
>     vocabulary which violate the convention that the subject of a
>     'linked' collection of three-triple items of the form described
>     above, ending with an item ending with rdf:nil, denotes a totally
>     ordered sequence whose members are the denotations of the rdf:first
>     values of the items, in the order got by tracing the rdf:rest
>     properties from the subject to rdf:nil.
>it could read something like:
>     Semantic extensions MAY place extra syntactic well-formedness
>     restrictions on the use of this vocabulary in order to rule out
>     such graphs. They MAY exclude interpretations in which the subject
>     of a 'linked' collection of three-triple items ending with an item
>     ending with rdf:nil denotes a totally ordered sequence whose
>     members are the denotations of the rdf:first values of the items,
>     in the order got by tracing the rdf:rest properties from the
>     subject to rdf:nil.
>
>In 4.3 "Semantic extensions MAY", the MAY has no special meaning and can
>be lowercase I think. This is an informative section.
>
>In the RDFS Closure Lemma proof, "A full proof would be long but
>tedious" I think means long and tedious.

The usage is common in mathematics where long proofs are sometimes 
considered to be of absorbing interest, but I will make the change.

>
>References should link to dated versions. Some guidelines in progress:
>http://www.w3.org/2001/06/manual/#References
>
>External links within the prose should be links to references:
>http://www.w3.org/2001/06/manual/#linking-within
>
>[1] http://www.w3.org/TR/2003/WD-rdf-mt-20030123/
>
>Best wishes for your project,
>--
>Susan Lesch           http://www.w3.org/People/Lesch/
>mailto:lesch@w3.org               tel:+1.858.483.4819
>World Wide Web Consortium (W3C)    http://www.w3.org/


-- 
---------------------------------------------------------------------
IHMC					(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola              			(850)202 4440   fax
FL 32501           				(850)291 0667    cell
phayes@ai.uwf.edu	          http://www.coginst.uwf.edu/~phayes
s.pam@ai.uwf.edu   for spam

Received on Monday, 24 February 2003 16:55:26 UTC