Re: CURIEs in OWL/XML

On 14 Mar 2009, at 12:37, Sandro Hawke wrote:
[snip]
>> 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.

Yes, but even there, having this as an option is really useful since  
it's *much* easier to manipulate.

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

Cool.

> 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?

Ambiguity between a CURIE and an IRI. I.e., syntactically there's  
nothing distinguishing:
	ex:foo the CURIE
and
	ex:foo the IRI with an unregistered scheme.

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

Well, you'd have to check the list of registered and unregistered  
schemes to be sure.

I don't think it's a huge problem myself (you could always see if  
there's an inscope prefix binding...though this works better when you  
aren't overloading namespaces). I do think it's moderately easier to  
process if you don't have to check the prefix to determine which is  
which (though, I think it'd be nicer if safe curies looked like  
dc::creator...which I think is nicer than [dc:creator] but anyway).

>  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 think it's harder for the implementor because you have to, at least,  
maintain a list of IRI schemes and/or do some heuristic. With syntax  
to distinguish, it's easier to route things to the appropriate code  
path.

It's very easy to write a schematron rule to check if a curie's prefix  
has a declaration. Rather harder if it could be an IRI as well.

[snip]
>> 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.

Yes, sorry, I meant "XIncluding" or other autogenerating mechanisms.  
E.g.,if you combine two documents in your XSLT or XQuery you could end  
up with multiple bindings.

So it could just be an error.

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

Indeed. I'll start compiling.

Cheers,
Bijan.

Received on Saturday, 14 March 2009 16:11:27 UTC