RE: CURIEs vs. QNames (was Re: CURIEs, xmlns and bandwidth)

Hi Henry,

> if someAttribute is interpreted as a QName, its value is
> 
>    < "http://example.org/" , "foo" >
> 
> whereas if it's interpreted as a CURIE, its value is
> 
>    "http://example.org/foo"
> 
> which is seriously different.
> 
> Different semantics, please use a different syntax!

The semantics are in fact the same since it's only when:

  { "http://example.org/" , "foo" }

is interpreted by some RDF/A processor that it 'becomes' a URI. This is much
the same as for an RDF/XML parser--you leave things as {URI, local-name} for
as long as possible (conceptually) and only at the last moment interpret
them as a URI.

However, even if they were 'URIs' as such (i.e., even if there is a
difference between 'interpretations' in the way that you describe), this
would still not be going against the TAG finding of March 2004 [1]. I'll
quote what is for me the key section, with my comments interspersed:

  In so far as the identification mechanism of the Web is the URI and QNames
  are not URIs, it is a mistake to use a QName for identification when a URI
  would serve.

Good advice...but just way too many characters. I hope we don't need to
argue too much about that--I think it is sufficient that the major
organisation responsible for standards to do with news mark-up believes that
raw URIs are too long, and will cause a problem for both bandwidth and the
adoption of their techniques. (To put it bluntly, I have argued for quite a
while now that if we do not solve this problem for the IPTC, and therefore
cause them to go their own way, we will have missed a major opportunity to
move the Semantic Web out of its current isolation, and into the
mainstream.)

As it happens, the TAG finding allows some flexibility:

  That said, the TAG recognizes that there are sometimes pragmatic reasons
  for chosing [sic] short, lexical representations of more complex names and
  accepts that QNames are an established mechanism for doing so.

Exactly...we have oodles of pragmatic reasons!

  Further, it must be observed that some things are identified by QNames:
  element and attribute names, types in W3C XML Schema, etc.

Of course. I take this to mean that some things *really are* QNames, and we
should not obscure that. But my main argument for CURIEs was to actually
*protect* QNames for their proper usage, by providing another more liberal
data type that could be used in other situations.

  Where there is a compelling reason to use QNames instead of URIs for
  identification, it is imperative that specifications provide a mapping
  between QNames and URIs, if such a mapping is possible.

I believe we have provided the compelling justifications, and explained the
mechanism.

  Finally, we observe that a whole class of interpretation problems can
  be avoided if the use of QNames can be restricted to contexts where their
  identification is natural and unambiguous (element and attribute names,
  simple content of type xs:QName, etc.) and we encourage developers to
  employ such restrictions wherever possible.

Yes. And as I said, my proposal is that the QName datatype remains
restrictive, and no attempt should be made to use it for anything that is
*not* a QName-proper. In situations where what is actually needed is
something else, then CURIEs should most probably be used (such as RDF/XML,
RDF/A, and so on). And to make it clearer what I am getting at, I would say
that this problem should have been solved long ago for things like XPath
functions, which are defined as QNames [2], yet are just as far removed from
XML attribute and element names.


SUMMARY
1. It is my belief that following the TAG note, there is nothing to stop
QNames being used in the way that we would like--as shortcuts for URIs.
However, the key issue is that it is too restrictive. (The problem for the
IPTC has been clearly elaborated on a number of occasions.)

2. It is a red herring to say that the syntax should be different for a
different concept; first, the concept is the same, even if the rules are
slightly different. And second, the same syntax is already used for other
things like XPath functions, and they are obviously not QNames in any real
sense.


FOOTNOTE
One last thing; I would separate out the square bracket syntax from the
broader notion of CURIEs. That was an attempt to allow CURIEs and URIs to
co-exist in the same attribute values; the TAG note says that there
shouldn't be the possibility of confusion. What mechanism is used to
distinguish the two is not relevant for the IPTC work, and can always be
addressed later.

Regards,

Mark

[1] <http://www.w3.org/2001/tag/doc/qnameids>
[2] <http://www.w3.org/TR/xpath20/#id-function-calls>

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 Friday, 4 November 2005 14:33:49 UTC