Re: [Recipes] roadmap to the next draft


Some quick notes on the decisions made during the meeting...

On Mar 11, 2008, at 10:34 AM, Diego Berrueta wrote:

> I've discussed the pending changes to the Recipes with Jon, and we  
> have
> come with the following list. Shall we open issues in the tracker for
> each item?
> ****
> 1) Move the examples to or to We would prefer
>, but someone has to set up the examples in space.

You and I will coordinate with Ralph (and probably Alistair?) on  
moving Alistair's example files to

> ****
> 2) Recipe 6 can be improved as per this post of Joshua Tauberer:
> 20Data&msgId=23498

We need to open an issue for this and it should be on the discussion  
agenda for next week (Ralph has reservations)

> ****
> 3) Some remarks by TimBL re: the "Cool URIs" are also relevant to the
> recipes. In particular:
>   [[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
> and the new ontology ) ]]
>   [[ 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. ]]
>   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:
>, 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. ]]

Thank you so much for this analysis! This will be on the telecon  
agenda for discussion next week.

> ****
> 4) Comment by Ian Davis:
>   [[ It's good to see this document being moved forward and I  
> appreciate
> all the hard work put into it. I'd like to ask for a clarification in
> terminology though. The draft uses the term "vocabulary URI" in many
> places without defining it. I think there's potential for confusion
> between the URI of the vocabulary and the URI of the document  
> describing
> the vocabulary. My sense is that the draft uses the term "vocabulary
> URI" to refer to the URI of the RDF document describing the  
> vocabulary.
> I suggest that is made explicit by using a term like "vocabulary
> document URI" ]]

Ralph suggests that we insert a note near the beginning of the  
document noting that we we say 'vocabulary uri' throughout the  
document that we really mean 'vocabulary namespace uri'. Maybe with a  
link to a fuller explanation of 'namespace uri'

> ****
> 5) Current list of issues:
>   * ISSUE-17, ISSUE-18, ISSUE-19, ISSUE-20, ISSUE-21, ISSUE-22,
> ISSUE-23: these should be closed, they were addressed in the last
> Editor's draft
>   * ISSUE-16: Ralph has a pending action on this issue
>   * ISSUE-24: As far as I know, this issue hasn't been addressed yet
>   * ISSUE-58: Jon proposes 2 alternatives:
>       [[ 1. We can say that an effective solution is beyond the  
> scope of
> the recipes -- a 'correct' recipe requires the use of rewritemap.  
> Since
> the recipes operate on the basic assumption that the implementor does
> not have the ability to alter httpd.conf and rewritemap requires this,
> it's out of scope.
>          2. Add an "If you can edit httpd.conf" alternative recipe  
> that
> provides an httpd.conf-specific recipe that includes the rewritemap
> command, modifies the recipe for httpd.conf (including the rule
> changes), and supplies a sample map file.
>         I personally prefer #2 but unfortunately I don't immediately
> have the time to work on it. (...) But I also think that #1 would be
> perfectly acceptable. ]]

The wg agreed on proposal #1. Ralph suggested that we also go into a  
bit more detail about a potential solution using maps and provide an  
example of a request that wouldn't be handled by the recipes but  
could be handled by a rewrite map, while still stating that actually  
providing a recipe for this was beyond our scope.

> -- 
> Diego Berrueta
> R&D Department  -  CTIC Foundation
> E-mail:
> Phone: +34 984 29 12 12
> Parque Científico Tecnológico Gijón-Asturias-Spain

Received on Tuesday, 11 March 2008 17:00:02 UTC