Re: editorial errors/problems in Cool URIs for the Semantic Web

Thanks for your comments. SWEO has actually finished, so there aren't any
plans to release further versions of the document.

Susie




                                                                           
             "Barclay, Daniel"                                             
             <daniel@fgm.com>                                              
             Sent by:                                                   To 
             public-sweo-ig-re         <public-sweo-ig@w3.org>             
             quest@w3.org                                               cc 
                                                                           
                                                                   Subject 
             02/03/2009 10:16          editorial errors/problems in  Cool  
             AM                        URIs for the Semantic Web           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           




In there will be future version of the Cool URIs for the Semantic Web
document
at http://www.w3.org/TR/2008/NOTE-cooluris-20081203/, here are some
editorial
errors that were noticed:


* 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.

   (The sentence doesn't parse.)


* Section 3 says:

     If we can't use URIs of documents to identify real-world object, ...

    (The word "object" should be plural.)


* Section 4 says:

     When a client wants to retrieve a hash URI, then the HTTP protocol
requires
     the fragment part to be stripped off before requesting the URI from
the
     server.

   Talking about "retrieving a URI" is confusing.  The client already has
the
   URI, so clearly it's not really retrieving the URI.

   Maybe the text should talk about "going to a URI" or "making a request
at a
   URI" (or still use "retrieve" but with something other than "URI").


* Section 4 then says:

     This means a URI that includes a hash cannot be retrieved directly,
and
     therefore does not necessarily identify a Web document. But we can use
     them to identify other, non-document resources, without creating
ambiguity.

   The wording doesn't seem to account for the fact that URI references
with
   fragment identifiers somtimes identify _parts_ of web documents.
Because of
   that, it seems to imply that a URI reference with a fragment identifier
   can only identify a non-document resource.

* Section 4.4 says:

     ... network delay can reduce a client's performance considerable.

* Section 4.7 says:

     A qs value of 1.0 for application/rdf+xml and 0.5 for text/html, would
     mean that ...

   (The comma shouldn't be there.)

* Section 6 says::

     ... the criteria from Section 3, which are to _be on
     the Web_ and _don't be ambiguous_.

   (That doesn't parse.)


* Section 6.2 says:

     These pieces of information should be sufficient to uniquely identify
     a person.

   Saying "an A uniquely identifies a B" seems to be ambiguous.  (It's not
   clear whether it's saying that the an A solely identifies the B (B has
only
   A) or saying that an A identifies a unique B.)






* 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).

   The last part should probably be "... but is a recommended ..."
   (The original "is" doesn't seem to "distribute" over the but because
   "required" and "a recommended ... practice" aren't parallel.)

* Section 2.1 says:

     Instead of a direct answer, the server redirects to another URL ...

   That is also non-parallel.  It should probably be:

     Instead of a given direct answer, the server redirects to another URL
...


* Section 3 says "see What HTTP URIs Identify?" but title of the referred
to
   document does not contain a question mark.


* Section 3.1 says:

     In the next section, solutions are described that allow you to mint
URIs ...

   That would be clearer as

     The next section describes solutions that allow you to mint URIs ...

   (and would avoid the leaving modifier "that allow .." dangling, separate
   from what it modifies ("solutions")).


* Section 4 says:

     Which one to use depends on the situation, both have advantages
     and disadvantages.

   That comma should be a semicolon (or a sentence break).


* Section 4.2 says "first class document."  That should be "first-class
   document."


* 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).



Daniel
--
(Plain text sometimes corrupted to HTML "courtesy" of Microsoft Exchange.)
[F]

Received on Tuesday, 3 February 2009 16:00:03 UTC