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

I will have to edit the

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

file. Danny... as a way to repent your shame:-), would it be possible 
for you to do that? I know you cannot edit it on-site, but if you make a 
copy of the HTML source, edit it, and send it back to me, I can then put 
it back in place...

It is not urgent...

Thanks

Ivan

Danny Ayers wrote:
> 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
>>
> 
> 
> 

-- 

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 Sunday, 14 June 2009 17:20:20 UTC