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

Daniel,

thanks for these comments, and my apologies that it took that long. But
the editors of the document discussed your comments and they are,
essentially, part of

http://www.w3.org/2001/sw/sweo/public/2008/Errata-in-CoolURIs.html

now.

Thanks a lot!

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