RE: CURIEs: A proposal

Hi Henry,

> My initial reaction is similar to Stuart's -- there's a lot to 
> agree with here, but
> 1) I think we do better to keep QNames (shorthand for an *expanded
>    name* which is a pair of an absolute IRI and an NMTOKEN local
>    name) and CURIEs (shorthand for an IRI) clearly distinguished
>    conceptually;
> 2) We think seriously about an alternative to the ':' as the
>    separator for CURIEs.

I seem to be having a real problem contesting the accepted reality
that a CURIE is a shorthand for an IRI.  As I explained in my 
Edinburgh presentation, what the IPTC requires is a {prefix, suffix} 
tuple, associated with two IRIs:
  -  one corresponding to the prefix,
  -  one corresponding to some combination of the prefix and the 

As you and others pointed out in Edinburgh, the most obvious way
of combining prefix and suffix would yield illegal fragment IDs, 
given that many of the suffix values are numeric.  The available 
solutions appear to be:

S1.  Define a new media-type, which allows numeric fragment IDs.  
     This approach would prevent the use of HTML or HTML/RDF pages 
     for documenting taxonomies.

S2.  Don't use numeric suffix values.  This approach to reality was, 
     I'm pleased to say, recognised as ostrich-like when the W3C and 
     the IETF accepted IRIs as real-world constructs and URIs as 
     mangled IRIs, to be used in those environments which can't cope 
     with IRIs.

S3.  Define a construction rule which avoids these problems, eg:
        <prefixIRI> & "#_" & <suffix>

This reminds me that simple concatenation:
     <prefixIRI> & <suffix>
would be broken as we would have to end the <prefixIRI> with a "#".
This would mean that the page corresponding to a taxonomy as a whole 
would be identified by, eg:
My reading of the relevant specs suggests that this would be wrong.

------------------- NewsML 2 resources ------------------------------         | |

To find out more about Reuters visit

Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd.

Received on Tuesday, 13 June 2006 13:04:43 UTC