Proposed comment about CURIEs

www-html-editor@w3.org

Subject: 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 we would like to use) CURIEs.

Unfortunately, the WG has found that the current CURIE spec does not  
meet our 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).

I (Bijan) would like to add that for a long time I, and everyone I  
was talking with, thought that you *couldn't* further restrict the  
syntax of CURIEs. The liberalizing sentence occurs *10* paragraphs  
after the CURIE grammar! Those 10 paragraphs are a mismash of things  
about the *syntax* of CURIEs and things about the *host language*. We  
strongly recommend rewriting that section with (at least) two  
headings "further syntactic stuff" and "host language issues"

Actually, just move the stuff on host language issues into, you know,  
the section on "Incorporating CURIEs into Host Languages", make that  
section informative, and kill all the examples (or move them to,  
y'know, an examples section). While you're at it, merge "usage" into  
examples as well.

C'mon! This is supposed to be a SPECIFICATION and most of it is  
random blathering and examples. The conformance section is a JOKE and  
the normative section, for all its brevity, is a disaster to read.  
Write the spec. Make it tight. And give us a clear pointer to the  
part we're supposed to USE, please.

Furthermore, safe CURIEs have been pretty firmly rejected as too ugly  
and cumbersome.

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 language, 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.

Cheers,
Bijan.

Received on Friday, 3 April 2009 15:54:02 UTC