RE: CURIEs: A proposal

Hi Stuart, 

> Hello Misha,
>
> FWIW... a colleague suggested the use of '::'  to separate prefix 
> from suffix ie. prefix::suffix
> 
> Rationale:
> 1) Visually/Syntactically distinct from QNames.
> 2) Appealingly similar in appearance to QNames.

I believe that QNames should form a subset of CURIEs.  This implies 
that the same syntax should be used.

> Regarding 7(a-h) below: 
> This seems to me to leave far too many things open for each 
> language using CURIEs to have to specify - making it difficult to 
> conceive of generic libraries for handling CURIEs. In particular:
> 
> 7a) there should only be one set of syntactic constraints;

The IPTC requires numeric suffix values.  Others may not.  Also, I 
believe that QNames should form a subset of CURIEs.  Both of these 
imply that the same constraints cannot apply.

> 7b) see '::' suggestion above 
> 7d) *if* CURIEs are genuinely a compact way of writing a URI, there
> should be a *single* mapping from a CURIE to a URI/IRI.

As I showed in my presentation at the AC meeting, the IPTC requires 
a tuple, *not* (just) a compact way of writing a URI.  Furthermore, 
the IPTC requires that a {prefix, numeric suffix} can be used to 
build a legal (X)HTML URI, complete with fragment ID, eg:
   .../iptc.org/example#_12345
Others require plain concatenation.  Hence, there can't be a single
construction rule.

> 7e) should have a single answer... which probably (regrettably) 
> means a CURIE is a tuple of {prefix, suffix, prefixURI, 
> compactedURI}

Maybe.  But not compactedURI, please.

> 7f-g) seems like normal good practice with URIs applies any CURIE 
> spec should remain silent.

See comments re numerics above.

> 7h) again surely a matter for generic URI/IRI syntax.

See comments re numerics above.

> Fixing all of that would leave solely the matter of establish a
> prefix=>URi mapping on a per language basis (7c), and I would hope 
> there would be a single approach for XML based languages - other 
> non XML based languages (N3 (and friends), SPARQL...) would have 
> to define their own mechanisms.

See above.

> 8b) seems troubling because it risks confusing a Qname with a 
> CURIE.

See above.

Regards,
Misha
------------------- NewsML 2 resources ------------------------------
http://www.iptc.org         | http://www.iptc.org/std-dev/NAR/1.0
http://www.iptc.org/std-dev | http://groups.yahoo.com/group/newsml-2


To find out more about Reuters visit www.about.reuters.com

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 12:33:28 UTC