W3C home > Mailing lists > Public > www-tag@w3.org > October 2008

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

From: Dan Brickley <danbri@danbri.org>
Date: Fri, 03 Oct 2008 17:55:57 +0200
Message-ID: <48E6408D.1070605@danbri.org>
To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
Cc: RDFa <public-rdf-in-xhtml-tf@w3.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Ed Summers <ehs@pobox.com>

Williams, Stuart (HP Labs, Bristol) wrote:
> 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.

curl -H 'accept: application/rdf+xml' http://lcsh.info/sh85112589
<?xml version="1.0" encoding="UTF-8"?>
   <rdf:Description rdf:about="http://lcsh.info/sh85112589#concept">
     <skos:broader rdf:resource="http://lcsh.info/sh85062913#concept"/>
     <skos:inScheme rdf:resource="http://lcsh.info/"/>
     <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/>
     <skos:altLabel xml:lang="en">Humanities and religion</skos:altLabel>
     <skos:prefLabel xml:lang="en">Religion and the 

Not sure what's up with wget, but curl seems to proke an rdf/xml 
response just fine. Other flavours are available, per http://lcsh.info/
"The server uses content negotiation to determine what representation of 
the concept to send: application/rdf+xml, text/n3, application/json, and 
otherwise application/xhtml+xml."

Am I misunderstanding what you're trying to do with wget?

(re content-location headers -- quite possibly there are issues with 
those, I've not looked at them closely, but it does seem to send 
"Content-location: http://lcsh.info/sh85112589.rdf" ok with the rdf/xml 

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

Uglier things have gotten through ;)

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

Yeah, I like tdb: ...



Received on Friday, 3 October 2008 15:56:41 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:32:59 UTC