Re: Review of Best Practice Recipes for Publishing RDF Vocabularies

At 04:27 PM 1/13/2008 +0100, Diego Berrueta wrote:
>Ed Summers escribió:
...
>> 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.

I hope our intent is that these recipes be described in enough
detail that others can adapt them to their particular situations.

Putting "Apache" explicitly in the title might suggest to some
readers that they should not read the document at all.  I think
that would be a mistake.

>... 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 prefer this rewording over changing the document title.

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

This is certainly one of those questions where we try to guess
the knowledge level of the target readers.

I believe we've said this document is primarily for those who
already have a chosen namespace name.  We're trying to tell
those readers what "best" to do now, particularly given the
newer understandings around httpRange-14.

I prefer the current ordering, particularly as there are numerous
references to the Requirements section in the preceding material.

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

Much of Frederick's comments have to do with old (poor)
practices, some of which predate the application/rdf+xml
MIME type registration.  It's understandable that not everything
on the Web is fixed within a short time after a better practice
is documented.   I view Frederick's blog as generally in the
same direction we are trying to take with Recipes.  (And
the new conditional rewrites fix the most eggregious case
of Priority that Frederick and TimBL complained about, but
we still don't know how to handle ;q= in a simple way.)

>> 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)?

So, here are the constraints as I see them:

1. Make Semantic Web apps work, some of which forgot to include
    Accept headers.

2. Allow humans to get a rendered view of a vocabulary description
   rather than an (XML) source dump or a "what action do you want
   me to take with this (unknown) file type?" dialog popup.

3.  Respect Web Architecture best practices as described in TAG findings.

Originally we (that is, the SWBPD WG) gave #1 higher priority than #2.
We didn't want to break *any* existing SemWeb apps even if they did
not themselves conform to best practice.

We may, however, have more influence over those SemWeb apps
than over browsers who Accept: */* in place of enumerating text/html
or application/xtml+xml.

>> It seems to me that on the web, when
>> multiple representations are available the default should always be
>> human readable,

I respectfully disagree.  The default can be whatever the URI owner
believe best serves the needs of his specific community.

>> ... and the onus should be on semantic web clients to send
>> the appropriate accept headers, rather than covering up for the sins
>> of IE.

I do, however, agree with this point.  If there were an IE-specific
user agent string I'd be inclined to continue showing vocabulary
publishers how to take advantage of it.  The broad-brush
^Mozilla/ pattern is indeed painful for many clients.

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

Or describe why our conditional rewrites aren't sufficient to
fully implement the HTTP spec.

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

yep.  So we chose the representation that wouldn't break
older SemWeb apps.

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

I'm not sure I'd agree with that.  At least, I wouldn't want to use it
as a justification for future actions.  With the current recipes and
with GRDDL and RDFa we're trying to accommodate both humans
and machines.

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

yes, let's move them to w3.org.  Let's not make this move a
prerequisite for publishing the next WD, however.

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

Yes, the SWBPD WG wanted to acknowledge that the well-known
Dublin Core namespace(s) use PURL and therefore to say
something about them.  Personally, I think PURL is a reasonable
idea and I like that our WD suggests they are an option.

The *a recipes are, however, so similar to the non-PURL recipes
that I suspect it would make the document appear simpler if we
described just the differences from the non-PURL directives
rather than give complete sets of directives.

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

I disagree.  We're talking about RDF/XML here, not fragments
in general.   For better or worse, RDF Class and Property names
are currently restricted to NCNames.

http://www.w3.org/TR/rdf-syntax-grammar/#rdf-id

>[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/

Received on Monday, 14 January 2008 17:43:25 UTC