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

Cool URIs for the Semantic Web comments: some errors

From: Barclay, Daniel <daniel@fgm.com>
Date: Fri, 12 Jun 2009 14:26:48 -0400
Message-ID: <4A329DE8.6030909@fgm.com>
To: <public-sweo-ig@w3.org>
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
     ... 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 ...
     ... 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
   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:
       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"?

(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.) [F]
Received on Friday, 12 June 2009 18:27:10 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 12 June 2009 18:27:11 GMT