Re: [Recipes] roadmap to the next draft

Hi Diego,

Comments inline...

Diego Berrueta wrote:
> Find below my input for the upcoming discussion on these topics:
> 
> El mar, 11-03-2008 a las 15:34 +0100, Diego Berrueta escribió: 
>> 3) Some remarks by TimBL re: the "Cool URIs" are also relevant to the
>> recipes. In particular:
>> http://lists.w3.org/Archives/Public/public-sweo-ig/2008Feb/0031.html
>>
>>   [[Major technical question about the implementation of 303. I know
>> that dbpedia does it the way described, but there are a lot of good
>> reasons to do it by a 303 to a generic URI for the document, which then
>> itself does a conneg to RDF and HTML. 
>>   * It is no more round trips than the dbpedia way
>>   * It gives the client a URI to bookmark which is generic. This is
>> important:
>>        * It allows the user with an RDF-capable client to bookmark the
>> document, and mail it to another user (or another device) which then
>> dereferences it and gets the HTML view. This use of generic resources is
>> important.
>>        * It provides the server with the ability to add representation
>> in new languages in the future.
>>        * It is standard conneg and so probably more supported on servers
>>     Just because client started with the URI of a thing, it doesn't mean
>> that the document involved is not a first class document on the WWW.
>> Best practices for this document apply. One of these is the use of
>> Generic Resources. (See for example
>> http://www.w3.org/DesignIssues/Generic.html and the new ontology ) ]]
> 
> While I fully agree with Tim's proposal, I also think that this will add
> some complexity to some Recipes. Currently, we implement content
> negotiation by means of rewrite rules. As far as I know, to implement
> Recipe 5 according to Tim's proposal we have to use a different method,
> such as Apache TypeMaps, which are difficult to set up.

If I remember rightly, Tim's proposal is actually quite easy to 
implement, because you can use Apache's MultiViews to handle the conneg 
from the generic document URI. You could alternatively use a TypeMap 
file, which provides more control over the conneg but is more work to 
implement.

However, the main reason why we didn't go for this solution (again if I 
remember rightly) was that it requires both the HTML and the RDF content 
to reside on the same server (and I think in the same directory?). Thus 
the solution doesn't generalise to the situation where RDF and HTML 
content are hosted in different locations, which is relevant to both W3C 
and DCMI.

A weaker reason for not going for Tim's solution was that it is 
different from the other recipes. We tried to keep the recipes as 
uniform and as simple as possible.

Based on my current (still limited!) understanding of Apache 
configuration, the only way to solve the problem in general is to use 
conditional redirects. To do conditional redirects based on Accept 
headers, and properly take the q-values into account, is hard work (if 
not impossible) to do using Apache's built in conneg support. For 
example, the pattern I mooted at [1], while handling q-values, still 
doesn't handle partial URL redirects (i.e. redirects based on substring 
or regex pattern matching), which are needed to make configuration of 
slash namespaces maintainable.

If someone where to take an implementation of the conneg algorithm, e.g. 
[2], and tweak it to do partial conditional redirects instead of serve 
content directly, then we might have a complete and generalisable 
solution that was (relatively) easy to install and configure. Until 
then, I support publication of the recipes as-is, because although they 
are incomplete, they are more flexible than Tim's approach.

As a last word, I'm no guru on either Apache or HTTP, so I might easily 
have missed something here.

Cheers,

Alistair.

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2007Oct/0063.html
[2] http://search.cpan.org/~rse/lcwa-1.0.0/lib/lwp/lib/HTTP/Negotiate.pm

> 
>>   [[ The 303 to an encoded SPARQL endpoint is IMHO clumsy and a proxied
>> normal URI would be better. In future, we may have ways of associating
>> whole URI subtrees with a SPARQL server, but we don't yet. ]]
> 
> This comment concerns the second implementation pattern of our Recipe 6.
> As before, I agree with Tim's point, although in my opinion, our current
> solution is easier to deploy than a script that acts as a proxy.
> 
>>   The following comment refers to a paragraph from Cool URIs that is
>> exactly the same in the Recipes (in Section 4.3. Choosing between 303
>> and Hash):
>>
>>  [[ "Note also, that both 303 and Hash can be combined, allowing to
>> spread a large dataset into multiple parts and have an identifier for a
>> non-document resource. An example for a combination of 303 and Hash is:
>> http://www.example.com/bob#thisBob, the person with a combined URI."
>> This is strange. Where is the 303 in this? This (bob#this) is an
>> important way of generating URIs, and deserves a section (insert new
>> 4.3) of its own. For when databases are exposed for example, or other
>> virtual RDF linked data spaces generated from underlying systems. ]]
> 
> Please forget this comment. It is not relevant to the Recipes, and there
> is no coincidence in the text between the Cool URIs and the Recipes. I
> made a stupid mistake, sorry :/
> 
> Best,
> 

-- 
Alistair Miles
Senior Computing Officer
Image Bioinformatics Research Group
Department of Zoology
The Tinbergen Building
University of Oxford
South Parks Road
Oxford
OX1 3PS
United Kingdom
Web: http://purl.org/net/aliman
Email: alistair.miles@zoo.ox.ac.uk
Tel: +44 (0)1865 281993

Received on Tuesday, 18 March 2008 16:33:45 UTC