Re: Comments on "Cool URIs for the Semantic Web"

Dear TAG, SWEO, norm.

Thank you for taking your time to consider the document again and 
providing this feedback.
We have received the comments and will incorporate them into the document.
Hopefully, all this leads towards establishing a best practice, enabling 
more users to benefit from the semantic web.

all comments are valid input and help improving the document.

I copied your feedback mails to our SVN server, to have everything at 
hand at one place (for us authors ), including a contrasted version of 
your photo here:
http://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/feedback/TAGReview_2007_09_pic.html

A question of understanding:
I assume that content-negotiation is also active with #-uris,
and that its ok to return a HTML representation when answering a plain 
HTTP GET request.
We would recommend to only return RDF when the Accept-header is set to 
application/rdf+xml,
to improve usability for end-users that enter the URI into a normal web 
browser (=they want to see the HTML).

A question of practice:
I don't exactly know how to define HTML <a> links that can do content 
negotiation - it seems current browsers (my firefox) don't support 
embedding content-negotiation directions into an URI using <a 
href="<uri>" type="application/rdf+xml">link to rdf version</a>

(I tested it here: http://www.dfki.uni-kl.de/~sauermann/dada/test.php)

It seems my user agent (firefox) doesn't use the type attribute as 
Accept-Header parameter for the GET call. And I know of no way to embed 
this into an <a href> link.

Therefore, I conclude that, additional to the #-uri, we need a second 
URI to allow linking (from plain html pages) to RDF and HTML versions, 
because it seems taht content negotiation can not be used for <a href> 
links. URIs can embed this into parameters or the path, as such:

http://www.example.com/id/bob#it   -- thing
http://www.example.com/data/bob    -- rdf version of the page

I think this is a problem, of not being able to embed the "Accept" 
header into a clickable <a> link tag, as we would still need multiple 
URIs to allow browsers to show either html or rdf. If this is the case, 
I would recommend to change future versions of HTML so that the 
accept-type of a link can be set, for example using the "type" 
attribute, at the moment [1] is only an advisory hint but is not passed 
to the server when calling a GET.

NOTES:
Preferring # uris over 303 redirects is an improvement of performance.
I think we will add some recommendations how to distribute a large 
database amongst many URIs, to keep the download portions small.
(like timbl's #i uri, which is a hash URI, but the document returned by 
the information resource is rather small in size and a good portion)
http://www.w3.org/People/Berners-Lee/card#i

We will then suggest something like #it as the identifier for the 
abstract concept, on the graph I see you proposed "#it",
but this identifier is random and not standardized.

For the cool uri article, a # URI would then look like this:
http://www.example.com/id/bob#it

[1] 
http://www.w3.org/TR/1999/REC-html401-19991224/struct/links.html#adef-type-A

kindest regards,
Leo, (for the authors Richard Cyganiak and Max Völkel and SWEO)

It was Norman Walsh who said at the right time 19.09.2007 15:56 the 
following words:
> Dear SWEO,
>
> The TAG has been reviewing "Cool URIs for the Semantic Web"
> at https://gnowsis.opendfki.de/repos/gnowsis/papers/2006_11_concepturi/html/cooluris_sweo_note.html
>
> Below are some of our comments on Section 3. Comments on other
> sections are underway.
>
> First para of Section 3:
>
>   "On the Semantic Web" suggests that the end state is two
>   separate webs; in fact, the end state is a single web with
>   a wider range of capabilities. Consider rephrasing:
>
>     "With the advent of semantic web technologies, the web
>     is extended so that (http:?) URIs can identify not just
>     web documents but also ...
>
> Second para of Section 3:
>
>   s/description for a URI/description of the identified resource/
>
> Throughout the text:
>
>   You must only use "example.com" in your example URIs. W3C
>   policy will not support the continued use of acme.com.
>
> Figure 1:
>
>   Please replace the diagram with the diagram in
>   http://lists.w3.org/Archives/Public/www-archive/2007Sep/0061.html
>
>   Note that the shapes in the diagram distinguish between
>   URIs and resources.
>
> Last para of Section 3:
>
>   We'd prefer to be quoted more carefully. WebArch says that
>   an "information resource" is where "all its essential..."
>   We don't speak of "Web documents".
>
>   Perhaps gloss "information resource" and "Web document"
>   somewhere in the document.
>
> Also:
>
>   The recommendation to "err on the side of caution" is not
>   well motivated; for example, we think many relational
>   tables are "information resources" but people would not
>   consider them "Web documents", and so this recommendation
>   would result in unnecesary redirections. We suggest that
>   you add motivation for the recommendation or soften it.
>
> Section 4:
>
>   We suggest that the "hash" solution should precede the
>   "303" solution because it can be implemented without
>   server configuration and does not impose a second
>   round-trip on the network.
>
> First paragraph of Section 4.1:
>
> Saying that 303 "distinguishes" is too strong. We suggest
> instead something along these lines:
>
>   Web architecture tells you that for a non-information
>   resource it is inappropriate to return a 200 because there
>   is, in fact, no suitable representation for those
>   resources. However, it is useful to provide information
>   about those resources; therefore we propose a solution
>   that is to direct you to a different (information)
>   resource which can be well represented and can give you
>   the information that you want. By doing this we avoid
>   ambiguity between the original, non-information resource
>   and the resource that describes it.
>
> Consider how this position is outlined in
> http://lists.w3.org/Archives/Public/www-tag/2007Sep/0017.html
>
> Diagram in Figure 2:
>
> We note again that 303 is not directly related to variant
> representations and content negotiation.
>
> See earlier comment about replacing diagrams.
>
>                                         On behalf of the TAG,
>                                           norm
>
>   


-- 
____________________________________________________
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
____________________________________________________

Received on Monday, 24 September 2007 16:22:23 UTC