W3C home > Mailing lists > Public > public-rdf-in-xhtml-tf@w3.org > January 2009

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Mon, 26 Jan 2009 06:42:52 -0500
Message-ID: <497DA1BC.7010500@intertwingly.net>
To: Mark Birbeck <mark.birbeck@webbackplane.com>
CC: Dan Brickley <danbri@danbri.org>, Ben Adida <ben@adida.net>, Manu Sporny <msporny@digitalbazaar.com>, RDFa mailing list <public-rdf-in-xhtml-tf@w3.org>, Ian Hickson <ian@hixie.ch>, Henri Sivonen <hsivonen@iki.fi>

Mark Birbeck wrote:
> 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.

I like the above description: it acknowledges that there are no perfect 
solutions, and places an emphasis on optimizing for "well-known" cases.

Henri and Dan have noted that by accepting "xmlns:html='html'" and 
limiting oneself to full URIs you get to the point where you have a 
document which can be processed correctly by many RDF parsers.  It has a 
few nice characteristics (which Henri and Dan have pointed out), and has 
a few not-so-nice characteristics (which you describe above).

What would happen if we repeat that process one more time?  How about if 
we accept xmlns:dc="http://purl.org/dc/elements/1.1/"?  Henri may point 
out that this doubles the number of ways that a given predicate can be 
expressed, which would be a fair point; and you may point out this would 
have to be repeated for foaf and for any uncountable number of other 
namespaces, some of which have yet to be minted.

What other desirable and undesirable social effects would there be by 
identifying a registry for well-known namespaces?

> Regards,
> Mark

- Sam Ruby
Received on Monday, 26 January 2009 11:43:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:02:00 UTC