Issue 403: new technical paper on CIDOC-CRM URIs NAMESPACE MECHANISM

ID: 
403
Starting Date: 
2018-11-21
Working Group: 
3
Status: 
Done
Closing Date: 
2018-11-28
Background: 

Posted by Chryssoula on 21/11/2018

Dear All

new technical paper is uploaded in http://www.cidoc-crm.org/Event/new-technical-paper-about-cidoc-crm-namespace-mechanism-is-uploaded

 

Current Proposal: 

Posted by Richard Light on 21/11/2018

Chryssoula,

I'm always happy to see a paper on Linked Data, but we should note that this one dates from January 2013.

The RDFS version to which the Linked Data URLs redirect is, however, still the 5.0.4 that the paper mentions.  Shouldn't those redirects be updated to point to the latest published version for which we have an RDFS version (6.2.1)?

Finally, the RDF redirect URLs include a '#' reference at the end (e.g. http://www.cidoc-crm.org/rdfs/5.0.4/cidoc-crm.rdf#E5). However, this is meaningless in the context of the RDF document, since it does not contain any XML Ids.

Posted by Martin on 22/11/2018

Dear Richard, All,

Thank you for spotting the missing redirection!

The question, if we should redirect to the latest draft version, rather the official release, should be discussed in Berlin.

Anybody, who knows better what to do than what this document states, please give us a complete proposal what we should do and better not what's wrong with what we do. It's not a field we at FORTH are particularly interested in, and hope someone on this list is more knowledgeable about.

#E5: I think we point into an XML-RDF file.

 

Posted by Richard Light on 22/11/2018


On 21/11/2018 22:20, Martin Doerr wrote:
> Dear Richard, All,
>
> Thank you for spotting the missing redirection!
>
> The question, if we should redirect to the latest draft version, rather the official release, should be discussed in Berlin.

Sure. I would have thought that the official release would be the better option, but of course we should discuss this and agree on a strategy.

> Anybody, who knows better what to do than what this document states, please give us a complete proposal what we should do and better not what's wrong with what we do. It's not a field we at FORTH are particularly interested in, and hope someone on this list is more knowledgeable about.
I'm broadly happy with the document as it stands.

> #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.

Posted by Martin on 22/11/2018

On 11/22/2018 10:28 AM, Richard Light wrote:
>

>> #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.

Then, what will work?:-) 

Posted by Conal Tuohy on 25/11/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.

https://tools.ietf.org/html/rfc3870#page-4

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 "E5").

 


 

In the 42nd joined meeting of the CIDOC CRM SIG and ISO/TC46/SC4/WG9 and the 35th FRBR - CIDOC CRM Harmonization meeting , the sig assigned to TV, RS to communicate with CG at FORTH to resolve the problem regarding the fragment identifiers’ reference. The outcome of this discussion is to be incorporated in the document “Implementing the CIDOC Conceptual Reference Model in RDF” by MD -related issue 363.

This is issue is closed.

Berlin, November 2018

 

Reference to Issues:

Meetings discussed: