"Cool Uris" is a working draft - addressed issues

Dear TAG and SWD members,

some time ago we asked you to review the document "Cool uris for the 
semantic web", which is edited by the SWEO IG.

Thanks again for your feedback, which you have given here:
http://lists.w3.org/Archives/Public/www-tag/2007Sep/0090.html
http://www.w3.org/2006/07/SWD/wiki/ReviewCoolURIs

We incorporated the feedback into the document, which is now a working 
draft:
http://www.w3.org/TR/2007/WD-cooluris-20071217/

The document is now open for comments
Please send comments about this document to public-sweo-ig@w3.org 
<mailto:public-sweo-ig@w3.org> (with public archive 
<http://lists.w3.org/Archives/Public/public-sweo-ig/>). Publication of 
this document as an Interest Group Note is planned for 1 February 2008, 
comments should possibly be sent until 21 January 2008.

Some issues are left open (they are marked @@ in the document), other 
were consciously not taken into the document.

I created changed versions of above feedback document and an overview on 
our editing here:
http://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/feedback/index.htm
http://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/feedback/ReviewCoolURIs_SWD.htm
http://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/feedback/Feedback_2007_09_19_TAG.html

These are the issues not addressed (marked up within these documents):

from SWD review:
LEO: NO, will not address this.In Sec. 1, between the paragraph 3 and 4 
there seems to be a logical break, IMHO.
LEO: NO, will not address this. In Sec. 4.2 the Fig. 4 seems a bit lost. 
Please provide more explanation and put in context.
Sec. 4.6 would definitely benefit from references and some more details 
... LEO: uh-oh....any ideas how to describe implementation or what to 
reference?
In addition to seeing the use of <link> to to allow agents to discover 
RDF associated with an HTML document, it would be useful to see a 
similar example using RDFa and GRDDL. Does the fact that RDFa isn't a 
recomendation yet preclude it from being used in this document? LEO: as 
this document is about URIs, and mainly about 303 redirects VS # uris, 
the RDFa question is bit side-scoped. We should mention RDFa and GRDDL 
in one sentence here but not go into details. ..Will not be addressed, 
we have now a link to RDFa in the beginning of section 4 and the scope 
here is not on RDFa and GRDDLable documents but URIs.
p. 10, section 5: I would like to see dbpedia <http://dbpedia.org/> 
included since it uses the 303 redirect technique to link directly to a 
SPARQL query, and it is such a rich and evolving dataset. It would also 
be useful to be referred to a good hash URI real world example. LEO: we 
should add a # example, but not DBPEDIA, too much for now.
The note about public archive in the fifth paragraph of the "Status of 
this document" section is perhaps not needed - the reader who is 
familiar with the W3C mailinglists will know that, others will be 
notified anyway when sending an e-mail there. LEO: NO, the link can't hurt
Leo: This is a good point, but as said, philosophical (and part of my 
related research, but not this time). The following comment about the 
last note in Section 6.2 about personal URIs is rather "philosophical". 
Even though the note comes out from a strongly backed opinion;), it is 
really questionable how to actually establish such personal URIs in an 
ideal, practical and systematic way. Imagine creating URI of John Smith 
in a company XYZ - we can use company's dedicated namespace to 
distinguish among this John Smith and other John Smiths around the 
world. But what if more John Smiths are in a company? We can use perhaps 
a namespace or URI prefix according to the departments these guys work 
in. But what if they work in the same department? So maybe we can use a 
time-stamp or a respective slashed namespace inferred from the date when 
they joined the company. Etc... Such situations may of course rarely 
occur in practice for persons, but we should have a recommended way how 
to solve them, since similar problems may be encountered also with names 
of products, services and so on. Thus, the document should either 
propose a recommended way of how to deal with such problems, or be a 
little more "careful" and avoid such potentially questionable strict 
statements.


from TAG review:
to my knowledge, all was addressed.

(the difference between the TAG and the SWD review is also that SWD 
gives much more detail, which we could not address within our time 
constraints)

best
Leo

-- 
____________________________________________________
DI Leo Sauermann       http://www.dfki.de/~sauermann 

Deutsches Forschungszentrum fuer 
Kuenstliche Intelligenz DFKI GmbH
Trippstadter Strasse 122
P.O. Box 2080           Fon:   +49 631 20575-116
D-67663 Kaiserslautern  Fax:   +49 631 20575-102
Germany                 Mail:  leo.sauermann@dfki.de

Geschaeftsfuehrung:
Prof.Dr.Dr.h.c.mult. Wolfgang Wahlster (Vorsitzender)
Dr. Walter Olthoff
Vorsitzender des Aufsichtsrats:
Prof. Dr. h.c. Hans A. Aukes
Amtsgericht Kaiserslautern, HRB 2313
____________________________________________________