RE: [VM] SKOS dereferencing (was: Telecon on Tuesday, 27 September)

Regarding the possibility of frag id collisions if the server sends a redirect location with a hash in it ...

This is what I know so far (fairly sure about this tho could be wrong): apache servers and purl.org servers work differently.  You can't have a hash URI as the location of a redirect with an apache server, becuase redirect rules get percent encoded on the way out.  But purl.org servers you can.

So, e.g. http://purl.org/dc/elements/1.1/title redirects to http://dublincore.org/2003/03/24/dces#title

Interestingly, if you try e.g. http://purl.org/dc/elements/1.1/title#foo then both mozilla and IE drop the #foo after they get redirected to http://dublincore.org/2003/03/24/dces#title - they avoid the potential frag id clash.  I wonder what would happen if there actually was a #title anchor in the document?

But normally mozilla and IE maintain an awareness of the frag id across redirects.  

For example, if you put http://xmlns.com/foaf/0.1/Person#term_Person in mozilla, after the redirect you see http://xmlns.com/foaf/0.1/#term_Person in the URL bar, and you're scrolled to the fragment of the doc.

Interestingly, if you put http://xmlns.com/foaf/0.1/Person#term_Person into IE 6, after the redirect you are scrolled to the right place in the doc, but you see http://xmlns.com/foaf/0.1/ in the URL bar.

I wonder what the TAG & specs have to say about hashes in redirect location URIs, and whether clients should preserve awareness of frag ids across redirects.

Cheers,

Al.

> -----Original Message-----
> From: Ralph R. Swick [mailto:swick@w3.org]
> Sent: 27 September 2005 13:53
> To: Miles, AJ (Alistair)
> Cc: public-swbp-wg@w3.org; public-esw-thes@w3.org
> Subject: RE: [VM] SKOS dereferencing (was: Telecon on Tuesday, 27
> September)
> 
> 
> At 12:47 PM 9/27/2005 +0100, Miles, AJ (Alistair) wrote:
> >To bring into line with FOAF & DCMI, I would like to propose 
> a change to this dereferencing policy.  I propose the following:
> >
> >1. A GET against http://www.w3.org/2004/02/skos/core with 
> 'Accept: application/rdf+xml' redirects (via response code 
> 303) to the latest snapshot of the SKOS Core RDF description 
> (currently http://www.w3.org/2004/02/skos/core/history/2005-03-31).
> >
> >(This ensures that provenance of RDF statements about SKOS 
> Core classes & props is always a historical (date-stamped) 
> snapshot, allowing run-time distinction between 'versions'.)
> 
> nice idea.
> 
> I note the following in 
http://www.w3.org/2004/02/skos/core/history/2005-03-31 :

1. <rdf:RDF xml:base="http://www.w3.org/2004/02/skos/core">
2.   <rdf:Description rdf:about="">
3.     <dc:title xml:lang="en">SKOS Core Vocabulary</dc:title>
4.     <dc:description xml:lang="en">
5.      An RDF vocabulary for encoding simple concept schemes such as thesauri and subject heading lists.
6.     </dc:description>
7.     <dc:creator>Alistair Miles</dc:creator>
8.     <dc:creator>Nikki Rogers</dc:creator>
9.     <dc:creator>Dave Beckett</dc:creator>
10.    <dc:contributor>
11.     Members of the public-esw-thes@w3.org mailing list.
12.    </dc:contributor>
13.    <dct:modified>2005-03-22</dct:modified>
14.    <foaf:homepage rdf:resource="http://www.w3.org/2004/02/skos/core/"/>
15.</rdf:Description>

Line 1 is fine, as it allows convenient relative URIs in the rest of
the document.  However line 2 is suspect as, for example, the
date modified should apply (only?) to this historical version.
I suspect that lines 7-9 probably also should be properties of
a particular historical version rather than the canonical namespace.

-Ralph

Received on Tuesday, 27 September 2005 14:24:34 UTC