Re: Discussion with Ian and Henri about HTML5+RDFa (part 2/2)

Hi Dan,

> Earlier you were sounding like
> everything is finished and frozen, but as I understand it the @prefix design
> is still being worked out.

I don't think Ben was saying that @prefix was frozen. The earlier
parts of his comments were in relation to the way that you seem to be
thinking that CURIEs can simply vanish. I think he is quite rightly
saying that this is a non-starter, for a number of reasons.

But leaving those reasons to one side for a moment, I'd like to put
the URI issue into some context for the discussion, since you seem to
be thinking that the issue has only just come up, or perhaps that the
alternatives were never considered properly.

There were long discussions about how to express URIs in RDFa, and
whilst QNames was the most obvious candidate for adoption, we didn't
go that route without a struggle to find something better. (And in
fact even when we went the nominally QNames route, we devised
something more appropriate in the form of CURIEs.)

The key issue was always how to provide extensibility for new
documents, whilst preserving backwards-compatibility for old ones.

If you have a document that has @rel="next" you need to preserve the
fact that this is a well-know HTML relationship. Similarly, if you
have @rel="foo" you don't want to simply assume that it's a
relationship in the HTML namespace.

But at the same time, you also need to allow authors the possibility
of adding their own terms.

So, with these requirements, there are many ways you could go about this.

The QNames (and then CURIEs) approach is to say that "next" is using a
default prefix that is bound to the XHTML namespace. I.e., "next" is
short for "xhv:next". The problem though is that this makes "foo" an
abbreviation for "xhv:foo". So you'll notice that CURIEs allows for
the possibility of processing well-known tokens first, before cracking
open the "a:b" syntax. In that model, "next" works, "a:b" works, and
"foo" is simply ignored.

The other model that was considered was that @rel contains a URI. In
this case @rel="next" is actually a relative path, and we would
hard-code the fact that it's relative to a 'base' that is the XHTML
vocabulary. Unfortunately that puts @rel="foo" also into the XHTML
vocabulary, and it also means that for authors to add their own values
they need to express them as full URIs, which is quite laborious and
error-prone.

Yet a further model that was considered was a 'merge' of both
approaches, and to use the safe CURIE syntax in @rel; this would give
us both @rel="[dc:title]" and @rel="http://purl.org/dc/terms/title".
However, it would then mean that 'next' has to be expressed as
@rel="[next]", and that @rel="foo" would be a term that was local to
the current document, since it's a relative path (as of course would
be @rel="next").

I actually favoured this last approach, but lost the argument. :) On
balance, I'm glad that I did lose, because the legacy markup issue is
a big one; my approach essentially said that all uses of legacy @rel
values were *local* to the document, and authors would have had to
explicitly update their documents to use safe CURIEs if they wanted to
use XHTML vocabulary terms in their documents.

None of this is to say that we can't continue to improve the ease with
which RDFa can be marked up, and the discussions around @prefix and
@profile demonstrate that this is now a priority for us. But the way
that discussion is moving forward, is by looking at how we can build
on RDFa; we're certainly not throwing into question some of the
fundamental underlying architecture.

Regards,

Mark

-- 
Mark Birbeck, webBackplane

mark.birbeck@webBackplane.com

http://webBackplane.com/mark-birbeck

webBackplane is a trading name of Backplane Ltd. (company number
05972288, registered office: 2nd Floor, 69/85 Tabernacle Street,
London, EC2A 4RR)

Received on Monday, 26 January 2009 10:54:44 UTC