RE: CURIEs vs. QNames

Hi Norman,

First I have to apologise; I wouldn't normally reply with such pedantry as
follows, but since one of my main arguments in favour of CURIEs is that we
need a way to abbreviate URIs in a manner that has *already* become
established practice via QNames, then I feel I have to take issue with your
statements about N3. I'll then go on to the main part of the argument, which
is whether there could be a misunderstanding if CURIEs were to 'look like'
QNames.

I wrote:
> | (This *would be* N3, except it isn't, because N3 is another 
> example of 
> | a language that mandates QNames...which sort of makes the 
> point that 
> | I've been trying to argue; when a non-XML language like N3 
> restricts 
> | the way that 'abbreviated URIs' are formed, to that used in 
> | XML+Namespaces element and attribute name formation, you know 
> | something has gone wrong!)

You replied: 
> That argument doesn't hold for N3. N3 is a serialization 
> format for RDF.

Yes, that's right...for RDF, not RDF/XML. There is no reason to import
QNames into N3 since it has nothing to do with XML (just like RDF has
nothing to do with XML).


> RDF has an XML syntax for which N3 is attempting to be an alternate
> serialization.

No. N3 and RDF/XML are *both* alternate serialisations (to each other) for
RDF.


> It seems 
> entirely reasonable in that circumstance that N3 should have 
> more restrictions than are actually, grammatically necessary in N3.

I can't see why. N3 only represents RDF--it has no relationship to XML
whatsoever. You could get rid of RDF/XML tomorrow, and both RDF (the
underlying information) and N3 (one possible serialisation of it) would be
untouched.


That's the pedantry out of the way...so, to summarise, N3 *already* shows
that there is a glaringly obvious need for a way to abbreviate URIs. But
since there was no readily available mechanism to do this, N3 (in common
with others) opted to use QNames. This is particularly bad in general, since
there is no relationship between the URI expressed and an XML+Namespaces
element or attribute name (as indicated in the TAG report). But it is also
particularly bad in the specific context of N3, since this syntax doesn't
even have anything to do with XML.

I feel I have established in many ways now, in many emails, both the need
and the precedent, so hopefully the question now becomes, where do we go
from here?

To recap the argument, my proposal uses the same *mechanism* as QNames, but
produces a wider range of URIs. Your argument is that this is wrong since a
CURIE and a QName could get mixed up, to which I would say:

   * QNames are already being used (inappropriately) as URI abbreviations,
without
     confusion. This is because when the context is a 'real' QName (an
element or
     attribute name with a 'namespace part') the local name and namespace
part are
     never actually combined in the way that has become common practice in
RDF/XML,
     XForms, N3, and so on. In other words, whether x:y maps to { http://x#,
y } or
     http://x#y is already given by context;

   * any situation where a CURIE is valid, a QName (in the *proper* sense)
will
     also be valid, and any situation where a QName *only* is valid, then
only
     CURIEs that conform to a QName will be valid (just in the same way that
only
     numbers that conform to the positive integer pattern match correctly
for a
     positive integer).

As I've said before, the horse has already bolted when it comes to the use
of QNames to represent URIs. My proposal does not seek to make the problem
worse by polluting the *genuine* QName space with relaxed rules for the
local-name part; rather it proposes a new way of representing URIs in
abbreviated form, using the widely understood *mechanism* popularised by
QNames.

One way out of this would be to define the *mechanism* (a namespace prefix,
followed by a colon, followed by a local part) as some sort of standalone
thing. And then to layer onto that, what one does with the bits you end up
with after parsing the abbreviation:

                 /         x:y
                 |          |
 The mechanism: <           |
                 |          |
                 \  { http://x#, y }
                    /         |    \
                   /          |     \
QName:      { http://x#, y }  |      \
                              |       \
XPath function:       { http://x#, y } \
                                        \
URI:                                  http:x#y

The mechanism just converts prefixes and local parts to an 'object'.
QNames-proper leave that object intact and make use of it, as do XPath
functions, whilst CURIEs would add another processing step and convert that
object to a URI. I feel this is *clearer* than current practice, since now
'QNames' really are QNames.

Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/

Received on Tuesday, 8 November 2005 22:04:30 UTC