W3C home > Mailing lists > Public > www-tag@w3.org > September 2007

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

From: Tim Berners-Lee <timbl@w3.org>
Date: Mon, 24 Sep 2007 17:09:48 -0400
Message-Id: <7CE57FE1-C687-42F5-BFF8-FF857F0D087C@w3.org>
Cc: Norman Walsh <ndw@nwalsh.com>, public-sweo-ig@w3.org, www-tag@w3.org, Richard Cyganiak <richard@cyganiak.de>, Max Völkel <voelkel@fzi.de>
To: Leo Sauermann <leo.sauermann@dfki.de>

On 2007-09 -24, at 12:21, Leo Sauermann wrote:

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

Not sure I understand what you mean.

The #-uri is never fetched, of course.
  once the #.. hs been stripped by the client, then content  
negotiation can of course be done on the remaining document URI.

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

This is tricky.  The Accept header is rarely set to just application/ 
A firefox+tabulator browser will accept HTML or RDF, among many other  
One should so the content negotiation algorithm properly.

The browser sends quality values to put across its own bias in the  
case of ffox+tabr then the browser can really do a good treatment  of  
for things like dbpedia, the original data is just data, and the HTML  
is derived from it, with sokme loss os re-usability of the  
information.  So the server should boas the selection toward RDF.
Suppose the server sets for RDF  qs[rdf] = 1  and qs[html] = 0.5
Firefox sends soemthing like  qc[rdf]=0.9  and qc[html] = 0.9
The multiplatiuon of qs * qc for each gives a fineal    q[rdf] = 0.9  
* 1 = 0.9  and q[html] = 0.9 * 0.5 = 0.45
So the server selects the RDF.
Otherwise, the tabulator never gets the RDF data.  It does a better  
job of displaying the RDF data fro the user than the HTML file can,as  
ait is a local RDF browser.
HTTP has been designed like this to do conneg for many years.

In general, if file A has been generated from file B with any loss of  
functionality, then teher should be a bias toward sending the  
original, B.   This is the case with HTML generated from data. If,  
however, say N3 has been generated from RDF and is smaller but  
contains exactly the same information, then the server could prefer  
the N3 when there is a balance.

(If that is too complicated, you could as a hack do a test fo a  
browser which said anything about Accept: rdf and if so send RDF, in  
a rewrite rule. But that is a kludge, but one worth writing up)

Currently dbpedia does not work with the tabulatpor extension as it  
implements neither of those: it sends wHTML when both are  
acceptable.  I hope it will be fixed soon.

> A question of practice:
> I don't exactly know how to define HTML <a> links that can do  
> content negotiation

What?  Content-negotiation is done in the HTTP protocol, not in HTML.

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

That is *not* the way the architecture works:  Here you are using the  
pair (URI, mediatype) to define the end point. This breaks the  
architecture, in which things are identified by URIs alone.   (For  
example, ho would you bookmark the end of that link? The browser  
bookmarks, like many other things, store only the URI)

In this case just link to the URI of the RDF version:

	<a href="<uri.rdf>" 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 that 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

Why not  just allow /id/bob to content negotiate to either RDF or  
HTML versions.
These can have their own URIs (like bob.rdf and bob.html) which are  
given in te Content-Location: header.

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

No no no!  This would break the architecture, you would no longer be  
using URIs, but (URI, type) pairs, and nothing which uses URIs would  

You seem to be confused here between whether you want a URI for the  
generic resource (content-type independent) or the content-specific  
ones.  In either case, just use the URI.

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

Yes. Some points you might consider:
- use common sense
- a guide would be what you would put in the HTML page
- send incoming links and outgoing ones, with transitive closing of  
bnodes, unless a given link type would have too many links (~1000  
rather than ~10 but no hard numbers)
- if you don't give (eg)   foaf:made give (eg) foaf:pubs to poiint to  
a doc with many foaf:made links.
- Note that classes with a small number of members it is useful to  
list the members of the class  when the class is looked up.  (eg: a  
table with a small number of records)

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

I would note that (a) it doens't need to be standardized except for  
people's understanding, (b) people have suggested that #this makes  
more sense than #it as it sort of connects to the 'this' of some  
object-oriented languages.
(c)   #TBL would be even easier and in fact I wish I had used that  
rather than #i for my FOAF ID.

> [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)

Received on Monday, 24 September 2007 21:09:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:17 UTC