- From: pat hayes <phayes@ai.uwf.edu>
- Date: Mon, 24 Feb 2003 15:55:14 -0600
- To: Susan Lesch <lesch@w3.org>
- Cc: www-rdf-comments@w3.org
>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