Re: Review of Best Practice Recipes for Publishing RDF Vocabularies

Diego, Ralph: thank you both for taking the time to unpack and respond
to my review of the Best Practice Recipes for Publishing RDF
Vocabularies draft [1]. More inline below:

On Jan 14, 2008 12:42 PM, Ralph R. Swick <swick@w3.org> wrote:
>
> At 04:27 PM 1/13/2008 +0100, Diego Berrueta wrote:
> >Ed Summers escribió:
> >[[[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'd be happy with that too. I hadn't thought having Apache in the
title of the document would drive people away, I was thinking about
the reverse effect ... but that's a bias I clearly don't share.

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

You and Diego have convinced me. It makes sense that the intended
audience for this document is not someone looking to create a
vocabulary, but someone who has an existing vocabulary and would like
to make it available on the web.

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

Yes, I hadn't considered that there were that many to worry about that
couldn't quickly be fixed to do the right thing.

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

I agree, my statement was overly general--and in hindsight, wrong.

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

I don't understand completely. I only wanted to point out that if
these recipes are followed, a developer who changes their browser
accept headers to prefer application/rdf+xml when it is available,
will never get it. This seems unfortunate to me, but perhaps it's
enough of a corner case to not matter that much?

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

Ok, whatever you think is easiest. To me it seems easiest to just
change them to example.com and not worry about them actually living
anywhere.

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

I like PURLs as well. Is it generally ok to recommend practices that
are discouraged in other w3c publications, as long as there is a note
to that effect? If you don't think it's a big deal then I'm ok with
it. I guess once the PURL software is upgraded to support 303
responses (currently underway) the note about compliance w/
httpRange-14 can be removed.

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

Aren't we also talking about HTML, which isn't always XML?

//Ed

[1] http://lists.w3.org/Archives/Public/public-swd-wg/2008Jan/0017.html

Received on Monday, 14 January 2008 21:16:59 UTC