- From: Dan Brickley <danbri@danbri.org>
- Date: Fri, 03 Oct 2008 17:55:57 +0200
- 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:RDF xmlns:dcterms="http://purl.org/dc/terms/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:skos="http://www.w3.org/2004/02/skos/core#" > <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/"/> <dcterms:modified rdf:datatype="http://www.w3.org/2001/XMLSchema#dateTime">1986-02-11T00:00:00</dcterms:modified> <rdf:type rdf:resource="http://www.w3.org/2004/02/skos/core#Concept"/> <skos:altLabel xml:lang="en">Humanities and religion</skos:altLabel> <dcterms:created rdf:datatype="http://www.w3.org/2001/XMLSchema#date">1986-02-11</dcterms:created> <skos:prefLabel xml:lang="en">Religion and the humanities</skos:prefLabel> </rdf:Description> </rdf:RDF> 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 above) >>> 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: ... cheers, Dan -- http://danbri.org/
Received on Friday, 3 October 2008 15:56:41 UTC