[Recipes] roadmap to the next draft

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 example.org or to w3.org. We would prefer
w3.org, but someone has to set up the examples in w3.org space.


2) Recipe 6 can be improved as per this post of Joshua Tauberer:


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
       * 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
       * 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 ) ]]

  [[ 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:
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. ]]


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


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

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

Received on Tuesday, 11 March 2008 14:34:56 UTC