Review of Best Practice Recipes for Publishing RDF Vocabularies

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.



Perhaps the title should reflect that the recipes are for the Apache
webserver? "Best Practice Recipes for Publishing RDF Vocabularies with


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.


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/, application/,
application/msword, application/x-shockwave-flash, */*

ie7: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/,
application/, application/msword, */*


It is really nice that the examples actually work using the hostname, but are we required to use
example.[org|com|net] ?


DBPL appears in the text instead of DBLP.


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


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.


Minimum Requirements

M2. "HTTP response code" probably should be "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.

Appendix B

Isn't it more appropriate to cite RFC 3896 instead of XML-NS for the
syntax of fragment identifiers?


Received on Tuesday, 8 January 2008 16:30:52 UTC