Re: CURIEs in OWL/XML

> Right now, the only canonical ways of abbreviating an IRI in OWL/XML  
> are to use entities or to use relative IRIs resolved against a base.  
> The first is suitable for hand authoring, while the second is not  
> (it's like having only one namespace prefix). The second is 'ok' for  
> manipulation by XPath (thus XSLT and XQuery) the former is not  
> (indeed, entities aren't really supported at all by XPath). Finally,  
> entities require a document type declaration which are very much out  
> of vogue.
> 
> Language like HTML simply expand the set of predefined entities, which  
> obviously won't work for us.
> 
> We could use QNames, but, blargh! (Note that this use would not have  
> the consequences it has in RDF/XML, since we *could* use an IRI  
> anywhere we can use a QName).
> 
> We use CURIEs elsewhere, so we perhaps should use them here.
> 
> There are, conceptually, two changes that need to be made:
> 	1) We need a prefix binding mechanism.
> 	2) We need a way to indicate the use of a CURIE.
> 
> In each case, there are two, more or less canonical and obvious  
> mechanisms:
> 
> 	1.1 We overload the XML Namespace binding mechanism (i.e., xmlns)
> 	1.2 We introduce a new element/attribute/whatever, e.g.,
> 		<curieprefix prefix="" iri=""/>
> 	(Which follows RELAX NG and Schematron.)

I hear you preferring (below) option 1.2, which sounds good to me
architecturally.  The only reason to go with the first is if CURIE keeps
mandating it; then going with the second one is just extra work for
implementors.

> 	2.1 We use "safe CURIEs" in the IRI attribute, i.e., [dc:creator]
> 		<http://www.w3.org/TR/curie/#s_syntax>
> 	2.2 We use a new attribute "curie", e.g.,
> 		<Class curie="dc:creator"/>

Again, I hear you you preferring the second one.  I'm very mildly with
you on this, too.

I know the CURIE spec says you shouldn't just use "dc:creator" in the
IRI spot, but while we're on the subject, do you happen to know what the
real problem with that is?  I've seen industrial pre-CURIE software do
it, and found myself unable to talk them out of it, because I couldn't
come up with a case where it did much harm.  (Obviously it's bad if you
use the same text as a CURIE prefix and a URI schema, but since you pick
your CURIE prefixes, you can avoid that.  It seems like the worst
problem is that in hand-authoring content, if someone accidentally
leaves out the CURIE definition, they might have a different document,
with no error.)  Letting CURIEs look just like IRIs which expand to
other IRIs is in some ways easier for the author and implementor.

> I have a very strong preference for 1.2 (and forbidding 1.1) and some  
> preference for 2.2.
> 
> The CURIE spec currently requires XML host langauges to support 1.1  
> even if they support 1.2. I think this is horrifically bad practice  
> and have written them a comment to that effect. I think that even if  
> they do not change that, that we should ignore it. It's hard to  
> overestimate how painful the namespace variant is for processing as  
> well as continuing the confusion that CURIEs help alleviate (i.e.,  
> about XML namespaces). I'm surprised that they don't define a  
> canonical alternative method, but oh well.
> 
> I think having a CURIE attribute is somewhat less tedious and  
> errorprone than requiring safe CURIEs in IRIs.
> 
> The last issue is how to handle multiple declarations of the same  
> prefix, esp. when they diverge (say in an imports). The simplest  
> solution is to forbid multiple bindings of a prefix in a single  
> ontology and scope bindings to the file they appear in. Or even  
> simpler is just to forbid multiple bindings.

This confuses me.  An OWL/XML document can import an RDF/XML one which
can important an Manchester one, etc, right?  So I'd like things like
CURIE-expansion would be all over and done before the import mechanism
came into play.

> I think it would be nice to have a file by the working group that had  
> a standard set of common bindings available for xinclusion.

Sounds find to me.  We can use it in examples, and have it generally
available.

     -- Sandro

Received on Saturday, 14 March 2009 12:37:55 UTC