Re: Review of Best Practice Recipes for Publishing RDF Vocabularies

Ed,

Thank you for your review. Please read my response to your comments below:

Ed Summers escribió:
> Below is my (late) review of the Best Practice Recipes for Publishing
> RDF Vocabularies [1]. In general I think this is a useful document (I
> tried the recipes) for configuring an Apache web server to serve up
> rdf, and combinations of rdf and html. That being said I think there
> are some parts of the recommended practice that are somewhat
> problematic, and I'm not quite sure what the solutions are.
>
> //Ed
>
> ---
>
> Perhaps the title should reflect that the recipes are for the Apache
> webserver? "Best Practice Recipes for Publishing RDF Vocabularies with
> Apache".
>   
IMO, the recipes are not Apache-specific. Only the configuration
examples (i.e.: the yellow boxes) are Apache-specific. However, the
document says otherwise in the introduction:

[[[While the provided Recipes are specific to an Apache HTTP server, the
general principles apply to non-Apache environments as well.]]]

I admit that I missed this while editing the document. Therefore,
instead of changing the title as Ed suggests, I would rephrase the
quoted sentence:

[[[While the provided **configuration examples** are specific to an
Apache HTTP server, the general principles apply to non-Apache
environments as well.]]]

> I recommend that the Requirements section is moved out of an appendix
> and into the introduction, since it's difficult to choose a recipe
> based on hash/slash options before understanding what they mean. I
> think the early the reader is presented with this information the
> better able they will be able to evaluate which recipe is for them.
>   
I do not fully understand what you mean here. Is it possible you might
be referring to Appendix B instead of to the Requirements section? I
think the Requirements are probably too technical for many readers and
they fit better at the end of the document. However, Appendix B explains
the hash/slash option, and therefore it may influence the choice of a
recipe. Actually, the contents of Appendix B were part of the
introduction in the previous draft, but they were moved to an appendix
in response to a comment by Karl Dubost [1].

> Perhaps you all have had discussions about this before, and I
> apologize in advance if I'm raising old ghosts. I imagine I'm not the
> only one that thinks the special rewrite rule for ie6 (and ie7
> incidentally) is kind of unfortunate. I'm not sure if Frederick
> Giasson has emailed anyone in SWD before, but he has blogged about
> problems associated with this rewrite rule [2].
>
> Is it really accepted practice that a web server should serve up
> rdf/xml by default when a given URI has multiple representations
> available (html, rdf/xml, etc)? It seems to me that on the web, when
> multiple representations are available the default should always be
> human readable, and the onus should be on semantic web clients to send
> the appropriate accept headers, rather than covering up for the sins
> of IE. If this were the case I think the rewrite rules for serving up
> html/rdf content would simplify a bit, in that they would test to see
> if the client wants rdf first, and fall through to displaying html,
> without needing to test.
>
> If we plan on keeping the ie/hack rule i think we should discuss it a
> bit more in the text of the recipes document--providing the accept
> headers that ie sends, and demonstrating why they are problematic.
>
> ie6: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/vnd.ms-excel, application/vnd.ms-powerpoint,
> application/msword, application/x-shockwave-flash, */*
>
> ie7: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
> application/x-shockwave-flash, application/vnd.ms-excel,
> application/vnd.ms-powerpoint, application/msword, */*
>   
You are raising at least two different issues here:

1) Do we really want to serve RDF as the default response? From my point
of view, if the client doesn't send an "Accept" header, any
representation is equally valid. The suggestion to use RDF as the
default response reflects the implicit assumption that the vocabularies
are published mainly for their consumption by automatic agents. However,
one might argue that the opposite is valid as well. Anyway, probably
this is a minor issue because the document makes it very clear that no
application should depend on which representation is served by default.

2) Do we want to keep the IE "hack"? I believe we resolved [2] at
Amsterdam to keep the hack in the Recipes, but to rephrase it. Regarding
whether we should paste the actual Accept header sent by IE in the
document, I don't have a strong opinion. On the one hand, they can
justify why the hack is needed. On the other hand, they are a
counterexample of best practices :)

> It is really nice that the examples actually work using the
> isegserv.itd.rl.ac.uk hostname, but are we required to use
> example.[org|com|net] ?
>   
Karl expressed a similar concern some time ago [3]. The optimal solution
would be to move the examples to the w3.org space. If this is not
feasible, I would be in favour of using example.org in order to remove
from Alistair's shoulders the responsability of keeping the examples
available in the long term.

> DBPL appears in the text instead of DBLP.
>   
My fault, sorry.

> "Editors Note: We are not aware at this time of any pre-existing
> libraries to perform content-negotiation..."
>
> RubyOnRails [3] and Java's Restlet [4] are two examples of
> web-framework software that have some support for conneg, there's
> probably more...
>   
Thank you for the references! I will explore them ASAP.

> Case Studies
>
> It's my understanding that d2r provides sparql and linked data
> interfaces to a relational database. pubby [4] on the other hand
> provides a linked data interface to an existing sparql endpoint.
>   
I think you are right. Is it your suggestion that we should clarify this
in the document?
> Minimum Requirements
>
> M2. "HTTP response code" probably should be "HTTP Status Code"
>   
Certainly. RFC 2616 uses "HTTP Status Code".

> Appendix A
>
> I would recommend removing this appendix since the slash examples do
> not conform to httpRange-14 finding, and in large part they just make
> the document longer than I think it needs to be.
>   
I agree with you, but I would like to hear the opinion of the previous
editors. I can imagine that this appendix has its roots in the fact that
there are several vocabularies published under the purl.org namespace.

> Appendix B
>
> Isn't it more appropriate to cite RFC 3896 instead of XML-NS for the
> syntax of fragment identifiers?
>   
(I assume you mean RFC 3986 instead of RFC 3896).

Good catch! Actually, I think that any reference to the XML-NS
Recommendation should be removed from the Recipes. We are dealing with
URIs, not with XML namespaces.

Thank you again. Best regards,

Diego.

[1] http://lists.w3.org/Archives/Public/public-swbp-wg/2006May/0074
[2] http://www.w3.org/2007/10/09-swd-minutes.html#item04
[3] http://lists.w3.org/Archives/Public/public-swbp-wg/2006May/0079

> [1] http://www.w3.org/TR/swbp-vocab-pub/
> [2] http://fgiasson.com/blog/index.php/2007/07/06/content-negotiation-bad-use-cases-i-recently-observed/
> [3] http://api.rubyonrails.org/classes/ActionController/MimeResponds/InstanceMethods.html
> [4] http://www.restlet.org/
> [5] http://www4.wiwiss.fu-berlin.de/pubby/
>
>   
-- 
Diego Berrueta
R&D Department  -  CTIC Foundation
E-mail: diego.berrueta@fundacionctic.org
Phone: +34 984 29 12 12
Parque Cientifico Tecnologico Gijon-Asturias-Spain
http://www.fundacionctic.org

Received on Sunday, 13 January 2008 15:28:31 UTC