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

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