RE: CURIEs vs. QNames

Dan,

> I don't need a new standardized way to abbreviate URIs.
> There's XML base, &entities; (ugh), relative URI references, 
> and even local short-hands that I can transform via 
> XSLT/GRDDL. So whoever "we" is, count me out.

I'm not with you...are you saying that you are going to stop using in
RDF/XML, SPARQL, or N3, the one mechanism you didn't mention, (so-called)
QNames?

Of course not. And I have to say, that's why this whole discussion is
starting to get rather annoying!

You see, I am proposing a *positive* solution, because my proposal
*reserves* QNames for what they really are (a way of specifying
namespace-qualified elements and attributes). For those situations where we
want to abbreviate URIs, my proposal suggests using something with a
different name (CURIEs) and making it explicit that this is what we are
doing.

This is very different to the rather mixed up approach that we have at the
moment, which glosses over what *real* QNames are, and clouds what exactly
it is that is 'lifted' from the definition of QNames. We have XPath
functions using 'QNames', XML Schema datatypes using 'QNames', alternative
XForms appearance hints and submission types using 'QNames'...RDF/XML using
'QNames'...SPARQL using 'QNames'...and so it goes on.

Except...the problem is that *none* of these languages are really using
QNames. Take SPARQL as a very good illustration (but by no means worse than
the others). In the latest WD [1] we have this example:

  PREFIX  dc: <http://purl.org/dc/elements/1.1/>
  PREFIX  : <http://example.org/book/>
  SELECT  $title
  WHERE   { :book1  dc:title  $title }

How by any stretch of the definition is 'dc:title' a QName? It's neither an
XML element nor an XML attribute. It doesn't even have the merit that XPath
selectors have in that they are being run against an XML DOM which does have
elements and attributes! In the SPARQL case we have a query that is being
run against a set of triples! So why is this abbreviation of a URI, that's
being used in a non-XML language, to run queries against non-XML data being
described in terms of QNames?:

  SPARQL provides an abbreviation mechanism for IRIs. Prefixes can be
defined
  and a QName-like syntax [14] provides shorter forms. Prefixes may be used
  anywhere after they are declared; redefining a prefix causes the new
  definition to be used from that point in the query syntax.

There is not a single point of connection between this and QNames, so why
call it "QName-like"?

And that's where we get to the nub. Because people *want* this simplicity.
It's an incredibly convenient way of expressing a URI, and although it has
been 'misused', it has been 'misused' so much that there is significant
mindshare in what it represents--people just 'know' what you mean when you
express a URI in this more compact way, to the extent that very few people
are aware of what it really means.

And *that*, is my entire point. Let's leverage the mindshare, 'tidy up' the
current uses (i.e., keep QNames for what they were originally designed for)
and devise a new concept that "does what it says on the tin"--abbreviates
URIs.

Regards,

Mark

[1] http://www.w3.org/TR/2005/WD-rdf-sparql-query-20050721/


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 Monday, 28 November 2005 15:14:57 UTC