Various issues with using CURIEs in OWL

The OWL Working Group had intended to delegate our URI abbreviation  
mechanisms both for in-spec and in-concrete-syntax use. OWL has a  
number of different concrete serializations (including 2 XML based and  
2 non-XML based), all of which use (or I would like to use) CURIEs.

Unfortunately, while trying to use the CURIE spec, I (and others) have  
found that the current CURIE spec does not meet the WG needs even  
putting aside concerns about the ultimate disposition of the document:

1) For non-XML host language: The CURIE spec provides no mechanism  
(although it provides permission) for excluding characters from the  
syntax of the local part of CURIEs. This means that in host languages  
which use symbols like ")" or "[" as part of their syntax, we run into  
parsing ambiguities. Note that safe CURIES do not solve this problem  
as the safe CURIE delimiters are common host language delimiters.

PROPOSED FIX: Ideally, there would be a "mimimalistic" CURIE profile,  
ideally something like SPARQL's abbreviation mechanism. Even QNames  
would be fine (though we'd recommend the spec point out that to cover  
all URIs there should be a non-abbreviated form).

Note that *permission* to make a subset isn't all that helpful. I  
mean, then we're just doing our own thing, yeah?

EDITORIAL NOTE: Many of us found the organization of the spec, and  
especially of the normative parts, very confusing. See:
    <http://www.w3.org/mid/943ED7DE-FBC9-4110-B17B-AF9F8043A0A1@cs.man.ac.uk 
 >

I suggest that "Usage" and "Examples" be consolidated, and that there  
are two normative sections, "Syntax" and "Incorporating CURIEs into  
Host Languages" which contain the respective constraints. The second  
section could usefully be broken down into "XML host languages" and  
"Non-XML host languages".

2) For XML host languages: The requirement to support the XML  
namespace based prefix declaration mechanism, even when an alternative  
mechanism is supplied, is simply a non-starter. Many in the XML world  
are hostile to the namespace based overloaded (even for proper QNames!  
see RELAX NG and Schematron). But being forced to support *two*  
mechanisms, especially when one of them isn't desired, is  
unnecessarily restrictive and leads to the second mechanism not being  
used:
    <http://www.w3.org/mid/29397.1237034265@ubehebe>

3) For XML host languages: There's no reason not to have a standard  
prefix declaration mechanism in the XML namespace. What value is there  
in letting XML host languages coin a bunch of different ones?

For example, <xml:Prefix name="" IRI=""/> is (basically) the syntax  
we're adopting, except with Prefix in the OWL namespace.

4) Processing: In some languages, multiple declarations of a prefix  
have an overriding behavior. In OWL we chose to make that a syntax  
error. The CURIE spec should make clear the processing model.

To sum, I, personally, don't think the CURIE spec helps either with  
implementation interop or with spec factoring, though I think it could  
be made to. Thus, in its current form, there's no point in citing it  
and, thus, no real point in it being a recommendation. The minimal  
necessary changes from my pov are:
	A) A proper XML mechanism with no requirement to suport xmlns
	B) Sensible profiles (I suggest, QName/RDF, SPARQL, and ALL)
	C) A processing model
C could maybe be dropped. A is totally required. I just won't adhere,  
or recommend anyone adhere, to the requirement to use xmlns. It's a  
nonstarter. Thus I won't use or recommend people use the CURIE spec  
(in its current form) for XML based host languages.

I won't use or recommend citing the CURIE spec without B for non-XML  
host languages. If you are happy with this being "using curies" then  
ok :)

Hope this helps.

Cheers,
Bijan.

Received on Thursday, 9 April 2009 22:27:23 UTC