W3C home > Mailing lists > Public > public-sweo-ig@w3.org > June 2009

Re: Cool URIs for the Semantic Web comments: some errors

From: Danny Ayers <danny.ayers@gmail.com>
Date: Sun, 14 Jun 2009 03:32:37 +0200
Message-ID: <1f2ed5cd0906131832i415462c3y1e34c8db7574275a@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 14 June 2009 01:33:17 GMT