Re: CURIEs: A proposal

On Tue, 27 Jun 2006 16:28:28 +0200, Misha Wolf <Misha.Wolf@reuters.com>
wrote:
>> It is not the case that XML Namespaces dictates a particular method
>> for building the IRI corresponding to an item in a namsepace.
>> Indeed, XML Namespaces does not require that any such method exists
This is exactly the point of my previous e-mail in this thread: It is
logically impossible for CURIEs to be in a superset of QNames, because
CURIEs are "abbreviations for URIs" and QNames are *not* abbreviations
for URIs in the general case. QNames merely use a URI to disambiguate
local names, and at this task they work fine. Even if one *assumes
concantentation* as a default rule for constructing URIs out of QNames
(which is not in the QName spec at all), then as abbreviations for all
possible URIs, they are poor - but that wasn't their intended purpose.
So, part of the problem is that CURIEs are advertising themselves as
replacements or fixes for QNames. I think this reveals a misreading of
QNames and this only detracts from the quite good case CURIEs can make
for themselves.

I think most people agree that something like CURIEs are a Good Thing,
but the problem is that by using the ":" character, in any given
document, one cannot tell if one is using a QName or a CURIE, which is
problematic as CURIEs license (re Steve Pemberton) a concat, while
QNames do not. If QNames should have this default concat behavior, then
the QName spec needs to be changed, and then maybe CURIES could be a
superset of QNames.

So, I recommend either (and this is just assuming that CURIEs stick to
plain concats instead of some language-specific rules)

1) CURIEs remain language-specific. I.e. CURIES in XHTML mean one thing,
CURIEs in RDF/XML mean another, and there is no CURIE mechanism in general.

2) CURIEs become general for XML, but say quite clearly how to
distinguish themselves from QNames. This could be done by using a
different character other than ':', or by saying that element names are
QNames, but CURIEs work for attribute values. Again, this might break
something, but not sure.

3) Post-hoc change the QName spec to say that a default concat rule
should be applied. This might break something, but maybe not. The things
that it breaks might not be that serious.

        cheers,
            harry




-- 
		-harry

Harry Halpin,  University of Edinburgh 
http://www.ibiblio.org/hhalpin 6B522426

Received on Tuesday, 27 June 2006 23:03:15 UTC