- From: Richard Cyganiak <richard@cyganiak.de>
- Date: Fri, 3 Oct 2008 17:26:50 +0100
- To: "Williams, Stuart (HP Labs, Bristol)" <skw@hp.com>
- Cc: Dan Brickley <danbri@danbri.org>, RDFa <public-rdf-in-xhtml-tf@w3.org>, "www-tag@w3.org WG" <www-tag@w3.org>, Ed Summers <ehs@pobox.com>
Not sure if that's the cause of the problem you observe, but the server should add a "Vary: Accept" header, otherwise intermediate caches will become confused and might send wrong responses to clients. This missing header is a frequent problem with servers that implement content negotiation, everyone seems to get this wrong the first time. Richard On 3 Oct 2008, at 17:13, Williams, Stuart (HP Labs, Bristol) wrote: > > Hi Dan, > >> Not sure what's up with wget, but curl seems to proke an rdf/xml >> response just fine. > > Probably user error or proxy failre on my part, though I can't for > the life of me see what I'm doing wrong. Transcript below, but happy > to concede that it's my mistake. > > Stuart > -- > Hewlett-Packard Limited registered Office: Cain Road, Bracknell, > Berks RG12 1HN > Registered No: 690597 England > > skw@williams-s-2 ~/play > $ wget -d --header="Accept: application/rdf+xml" http://lcsh.info/sh85112589 > Setting --header (header) to Accept: application/rdf+xml > DEBUG output created by Wget 1.11.3 on cygwin. > > --2008-10-03 17:07:45-- http://lcsh.info/sh85112589 > Connecting to proxy:8088... connected. > Created socket 3. > Releasing 0x006ab9f8 (new refcount 1). > > ---request begin--- > GET http://lcsh.info/sh85112589 HTTP/1.0 > User-Agent: Wget/1.11.3 > Accept: application/rdf+xml > Host: lcsh.info > > ---request end--- > Proxy request sent, awaiting response... > ---response begin--- > HTTP/1.1 200 OK > Date: Fri, 03 Oct 2008 16:07:01 GMT > Server: Apache/2.2.8 (Ubuntu) DAV/2 SVN/1.4.6 PHP/5.2.4-2ubuntu5.3 > with Suhosin-Patch mod_wsgi/1.3 Python/2.5.2 > Content-location: http://lcsh.info/sh85112589.html > Content-Type: application/xhtml+xml; charset=UTF-8 > Content-length: 2720 > Connection: close > Age: 139 > > ---response end--- > 200 OK > Length: 2720 (2.7K) [application/xhtml+xml] > Saving to: `sh85112589.6' > > 100% > [= > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > = > ==================================================================>] > 2,720 --.-K/s in 0s > > Closed fd 3 > 2008-10-03 17:07:45 (27.4 MB/s) - `sh85112589.6' saved [2720/2720] > > > >> -----Original Message----- >> From: Dan Brickley [mailto:danbri@danbri.org] >> Sent: 03 October 2008 16:56 >> 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, >>> >>>> -----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-1 >> 1</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 16:27:32 UTC