[Crm-sig] new technical paper

Conal Tuohy conal.tuohy at gmail.com
Sun Nov 25 03:20:21 EET 2018

> #E5: I think we point into an XML-RDF file.
> Yes, that's the intention, but it will only work if there is an element in
> that file with attribute xml:id="E5" to act as the target for the link.
> This strategy works fine for the links into the HTML expression of the RDF,
> but not for the RDF/XML expression.

I don't think that's correct, actually.

The issue of how to resolve URI fragment identifiers is a complicated one,
since a URI as a whole refers to a resource (in the Web Architecture
sense), while the interpretation of the fragment identifier part of the URI
is dependent on the media type of the *representation* of the resource, and
of course a single HTTP URI may correspond to many different media types,
if the web server supports content negotiation for that resource.

So while It's true that fragment identifiers used with XML documents in
general (i.e. "application/xml" media type) refer to elements by the value
of their xml:id attribute (or other attribute whose type is ID), this
interpretation is over-ridden in the case of RDF/XML (the
"application/rdf+xml" media type). The registration document for
"application/rdf+xml" says that the fragment identifier should be
interpreted as corresponding to the rdf:about and rdf:ID attributes.


On the other hand, it certainly is true that redirecting from
http://www.cidoc-crm.org/cidoc-crm/E5_Event to
http://www.cidoc-crm.org/html/5.0.4/cidoc-crm.html#E5 is a mistake. The
redirect location should be
http://www.cidoc-crm.org/html/5.0.4/cidoc-crm.html#E5_Event (since
"E5_Event" is the value of the rdf:about attribute in the RDF/XML, not

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ics.forth.gr/pipermail/crm-sig/attachments/20181125/c8afbbc2/attachment.html>

More information about the Crm-sig mailing list