RE: lcsh.info RDFa SKOS and content negotiation - use of RDF-style # IDs in RDFa?

Hello Dan,

> -----Original Message-----
> From: Dan Brickley [mailto:danbri@danbri.org]
> Sent: 03 October 2008 13:50
> To: Williams, Stuart (HP Labs, Bristol)
> Cc: RDFa; www-tag@w3.org WG; Ed Summers
> Subject: Re: lcsh.info RDFa SKOS and content negotiation -
> use of RDF-style # IDs in RDFa?
>
> Williams, Stuart (HP Labs, Bristol) wrote:
> > Hello Dan,
> >
> > Granted that this is not a content-negotiation case, but I
> think that sectiion 3.2.2 of Webarch [1] may be relevant
> here, particularly the 3rd situation described therein.
>
> This is a conneg case; there is RDF/XML and RDFa coming from
> the same URI.

We could quibble (and I will:-) though it doesn't matter wrt to the main point at hand). A few wgets with and without accept header reveals that retrievals on http://lcsh.info/sh85112589 always (seems to) return an application/xhtml+xml representation.

In that sense, only a single representation of  http://lcsh.info/sh85112589 is available and the response is not content-negotiated (between available representations). That you might regard the response as a composite of hypertext and a graph I think is a different thing. Also, that the representation makes reference to other resources which make N3, RDF/XML and JSON representations available is fine. These resource all have different names and may stand in some variant relation to http://lcsh.info/sh85112589 but there is nothing specific in the response that call out that http://lcsh.info/sh85112589.rdf is a variant of http://lcsh.info/sh85112589.

For me accept header driven client-side content negotiation would mean that appropriate accept header influence the representation returned (between say, rdf/xml, n3, json, html and html+rdfa) along with (possible) knowledge that "http://lcsh.info/sh85112589.rdf is a variant of http://lcsh.info/sh85112589" communicated by the presense of a content-location header.

This particular case always returns "Content-location: http://lcsh.info/sh85112589.html" and an identical application/xhtml+xml XHTML+RDFa representation. Ok... I concede that content-negotiation has happened between a generic resource and a specific variant resource.

Also, it is possible, an would be in order, for the site to actually content negotiate between the variants that it actually does have available - it's just that at present it does not appear to do so.

> > The XHTML+RDFa representation returned here does not
> *define* a target for the #concept fragment identifier - were
> the an id="concept" on the div there would be an
> inconsistency. The representation conveys assertions *about*
> http://lcsh.info/sh85112589#concept, wisely IMO avoiding the
> about="#concept" form which would take us into same document
> reference territory.
> >
> > Certainly there's a little squinting going on here - but I
> think that unless one is actually making assertions about
> 'fragments' of the document, then its ok as long as the
> references *do not* resolve to a hypertext anchor in the
> document [aside: I'd also avoid naming things with names that
> look like xpointer expressions too :-)].
>
> I think you've found the best way of wriggling through this mess of
> specs :) It doesn't feel entirely graceful but it should at
> least allow
> us to deploy RDF/XML and RDFa alongside each other in this style.
>
> > I think that the relevant media-type registrations could
> (and probably should) be brought into line.
>
> That would be nice. Is it feasible?

I would have thought it possible. Lurking somewhere in the background once upon a time was an intention to update RFC 3023 (the XML media-type registration) which I'm trying to find out status on. Coordinating updates to that and to any +xml media type registrations that build on its defaults would be essential I would have thought. Updating the application/xhtml+xml media type registration seems to me to fall within the scope of the XHTML2 WG and... (taking a deep breath)... the relationship between XHTML (of any flavor) and the text/html media type is entirely mysterious to me (eg. XHTML+RDFa served up as "text/html"... could/should that happen?).

> I was wondering whether we might also sneak in a common symbol
> '#123412341234' (or something else obscure) meaning "the main thing
> described by this document", so that this common case could proceed
> without risk of unintended clashes (except by those who use that
> hard-to-guess symbol).

I have a horrible feeling that that's a serious suggestion!

I'd prefer tdb:2008:http://lcsh.info/sh85112589 (modulo syntax), with Larry Masinter's tdb: scheme taken through the URI scheme registration process, which is only a stones throw away from Steven's pto: idea. And... lest I forget, http://t-d-b.org/?http://lcsh.info/sh85112589 would also do the trick (modulo being temporally grounded).

>
> cheers,
>
> Dan
>
>
> > Stuart
> > --
> > [1] http://www.w3.org/TR/webarch/#frag-coneg
> >
> > Hewlett-Packard Limited registered Office: Cain Road,
> Bracknell, Berks RG12 1HN
> > Registered No: 690597 England

Cheers,

Stuart
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks RG12 1HN
Registered No: 690597 England

Received on Friday, 3 October 2008 15:03:04 UTC