> From [log in to unmask] Mon Jun 2 21:33 MET 2003
> X-RAL-MFrom: <[log in to unmask]>
> X-RAL-Connect: <pat.bath.ac.uk [126.96.36.199]>
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> X-Priority: 3 (Normal)
> X-MSMail-Priority: Normal
> Importance: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
> Date: Mon, 2 Jun 2003 20:37:43 +0100
> From: Pete Johnston <[log in to unmask]>
> Subject: URI fragment IDs, MIME types and DCMI PURL redirects
> To: [log in to unmask]
> This question came up in an off list discussion, and I admit I find the
> area pretty confusing, so I'm not quite sure whether (a) my
> understanding is correct or (b) there's a problem here or not...
> DCMI uses PURLs for the URIs for all the DCMI terms, and issuing an HTTP
> GET of such a PURL generates a redirect by the OCLC resolver to a
> http://dublincore.org/... URI. Those dublincore.org URIs include
> fragment identifiers. So e.g.
> http://purl.org/dc/elements/1.1/title redirects to
> According to section 4.1 of http://www.ietf.org/rfc/rfc2396.txt
> the optional fragment identifier, separated from
> the URI by a crosshatch ("#") character, consists of additional
> reference information to be interpreted by the user agent after the
> retrieval action has been successfully completed.
> The semantics of a fragment identifier is a property of the data
> resulting from a retrieval action, regardless of the type of URI used
> in the reference. Therefore, the format and interpretation of
> fragment identifiers is dependent on the media type [RFC2046] of the
> retrieval result.
> So, for example, RFC2854 http://www.ietf.org/rfc/rfc2854.txt
> specifies that for a document with MIME type text/html:
> the fragment identifier
> designates the correspondingly named element; any element may be
> named with the "id" attribute, and A, APPLET, FRAME, IFRAME, IMG and
> MAP elements may be named with a "name" attribute.
> For text/xml, RFC3023 http://www.ietf.org/rfc/rfc3023.txt says
> As of today, no established specifications define identifiers for XML
> media types. However, a working draft published by W3C, namely "XML
> Pointer Language (XPointer)", attempts to define fragment identifiers
> for text/xml and application/xml. The current specification for
> XPointer is available at http://www.w3.org/TR/xptr
Some change happened here: XPTR in March 2003 was made W3C Recommendation.
> However, at present the document http://dublincore.org/2003/03/24/dces
> appears to be served with MIME type text/plain. I'm not clear whether
> fragment identifiers are defined at all for text/plain, but it doesn't
> seem like it?
> So is that a problem for using the redirect of
> http://dublincore.org/2003/03/24/dces#title ?
DCMI doesn't use fragments for it's vocabulary.
> The recent W3C RDF draft specs suggest the use of a MIME type
Fragments in RDF have to be interpreted in a way presuming (!) one had done a
retrieval on a gadget of MIME type application/rdf+xml.
> This spec explicitly says rdf:ID and rdf:about attributes
can be used to define.
In the case at hand rdf:about isn't used that way.
> fragments. The served document does have an attribute
> But even if the document was served as application/rdf+xml, this doesn't
> quite seem to address the problem of what is designated by
> Does it actually matter?! I'm really not sure! If someone tells me
> authoritatively it doesn't, then I'll go away happy(ish)...(maybe!)
> It just seems there _may_ be a problem somewhere there at the moment in
> that the use of the URIref http://dublincore.org/2003/03/24/dces#title
> doesn't seem to "fit" very well, either with a MIME type of text/plain
> (as at present) or of application/rdf+xml (as the recent specs suggest).
The document you get when de-referencing the RDF namespace URIreference is
also MIME typed text/plain.