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

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

From: Ivan Herman <ivan@w3.org>
Date: Sat, 13 Jun 2009 21:21:14 +0200
Message-ID: <4A33FC2A.8040308@w3.org>
To: "Barclay, Daniel" <daniel@fgm.com>
CC: public-sweo-ig@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



Received on Saturday, 13 June 2009 19:35:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 13 June 2009 19:35:39 GMT