- From: Danny Ayers <danny.ayers@gmail.com>
- Date: Sun, 14 Jun 2009 03:32:37 +0200
- To: Ivan Herman <ivan@w3.org>
- Cc: "Barclay, Daniel" <daniel@fgm.com>, public-sweo-ig@w3.org
I have to hide my head in shame, I proof-read (being the only native English speaker around), and I missed a lot. Sorry. 2009/6/13 Ivan Herman <ivan@w3.org>: > Thank you Daniel, > > I will pass this on to the editors and store it as an erratum > > Thanks again > > Ivan > > Barclay, Daniel wrote: >> >> For any future editions of the Cool URIs for the Semantic Web document >> currently at http://www.w3.org/TR/cooluris/ : There are a few errors, >> mostly editorial: >> >> >> * Section 2 says: >> ... each of the pages ... are Web documents >> but should say: >> ... each of the pages ... is a Web document >> or: >> ... the pages ... are Web documents >> >> ** Section 2.1, in the example request and 202 response, says: >> GET /people/alice HTTP/1.1 >> and then: >> Content-Location: http://www.example.com/people.en.html >> Was that URI supposed to be the following: >> Content-Location: http://www.example.com/people/alice.en.html >> (as it is in the 303 response)? >> >> >> * Section 2.1 says: >> Note that the URI of this representation is passed back in the >> Content-Location header, this is not required but a recommended >> good practice (see [CHIPS], 7.2). >> That comma should be a semicolon (or a sentence break). >> >> * Section 2.1 says: >> Instead of a direct answer, the server redirects to another URL ... >> That's not quite parallel. It probably should say: >> Instead of returning a direct answer, the server redirects to >> another URL ... >> >> * Section 3.1 says: >> Bob may not like the look of the homepage, but fancy the person >> Alice. So two URIs are needed, one for Alice, one for the homepage >> or a RDF document describing Alice. >> Why two URIs are needed isn't clear. There should probably be an >> intervening sentence that mentions something about representing >> the objects of both of those statements about Bob's likes. >> >> * Section 3.1 says: >> In HTTP, because a 200 response code should be sent when a Web >> document has been accessed, but a different setup is needed when >> publishing URIs that are meant to identify entities which are not >> Web documents. >> Either the "but" must be removed, or something needs to be added at >> the end. >> >> * Section 3.1 says: >> In the next section, solutions are described that allow you to >> mint URIs ... >> That would be much clearer as: >> The next section describes solutions that allow you to mint >> URIs ... >> >> * Section 4.1 says: >> When a client wants to retrieve a hash URI, then the HTTP protocol >> requires ... >> and >> ... a URI that includes a hash cannot be retrieved directly ... >> The document probably should not approximate there (saying that the >> client "retrieves ... the URI," even though it actually does _not_ >> retrieve the URI--clearly, it already has the URI), especially since >> the document is discussing the details of when things are >> retrieved vs. just identified. >> >> * Section 4.1 says: >> The decision which to return ... >> That would be clearer as: >> The decision of which to return ... >> >> * Section 4.2 says: >> By doing this we avoid ambiguity between the original, real-world >> object and the resource that represents it. >> Was that meant to say "the resource that describes it"? >> >> * Section 4.3 says: >> For example, to redirect from http://www.example.com/id/alice to >> http://www.example.com/doc/alice. >> That's not a complete sentence. (It probably should be part of >> the previous sentence. >> >> * Section 4.4 says: >> Any fragment identifier is valid, this in the above URI is a >> suggestion you may want to copy for your implementations. >> That comma should be a semicolon (or a sentence break). >> >> * Section 4.5 says: >> Keep implementation-specific bits and pieces such as .php and >> .asp out of your URIs, you may want to change technologies later. >> That comma should be a semicolon (or a sentence break). >> >> * Section 4.7 says: >> A qs value of 1.0 for application/rdf+xml and 0.5 for text/html, >> would mean ... >> The comma should be elided. >> >> ** Section 5 says: >> http://ontoworld.org/wiki/Special:ExportRDF/Karlsruhe >> RDF description of Karlsruhe >> The URI of the RDF description is less than ideal, because it >> exposes the implementation (php) ... >> Is that last statement correct? There is no ".php" suffix anywhere. >> >> * Section 6 says: >> ... the criteria from Section 3, which are to be on the Web and >> don't be ambiguous. >> That should either say: >> ... the criteria from Section 3, which are to be on the Web and >> not be ambiguous. >> or quote the two phrases italicized in the original. >> >> * Many occurrences of "e.g." (and maybe "i.e.") aren't followed >> by a comma. >> >> * Section 8 says: >> ... Tim Berners-Lee who ... helped us understanding the TAG >> solution ... >> The "understanding" should be "understand." >> >> * Section 8 says "detailled." >> >> >> * Section 1 says "frontpage." Shouldn't that be "front page"? >> >> * Section 2 says "homepage" and section 3 says "home-page." Shouldn't >> those references say simply "home page"? >> >> >> Daniel >> -- >> (Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) >> [F] >> >> >> > > -- > > Ivan Herman, W3C Semantic Web Activity Lead > Home: http://www.w3.org/People/Ivan/ > mobile: +31-641044153 > PGP Key: http://www.ivan-herman.net/pgpkey.html > FOAF: http://www.ivan-herman.net/foaf.rdf > -- http://danny.ayers.name
Received on Sunday, 14 June 2009 01:33:16 UTC