- 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