Hi Ben,
> I've worked to update the RDF/A specification.
As I said before...great work. I think the examples in particular are really
starting to take shape, and helping to clarify both the syntax, and why it
could be useful to people.
> Please forgive
> the extraneous characters as I had to work from the HTML, not
> the base XML. I'll get those fixed eventually.
Sorry about that. I do still have the base XML though, so we should be able
to sort that out.
> Note that the
> "Motivation"
> section probably needs another look, but it will do for now.
I also think the primer is going to be crucial. Reading RDF/A now, it
appears to be quite complicated, yet in fact there are only a few basic
concepts that are needed to 'understand' it (mainly because it builds on
people's knowledge of metadata in HTML).
> Finally, I'm sure I've got some bugs in there (particularly
> CURIE), so feel free to send corrections.
> http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa-spec
Here are some things that I've noticed:
* Section 4.1
* Now that we treat <link> and <meta> as special, then the list of
what qualifies you as an [RDF/A element] is extended:
any element that has @about, @property, @rel, @rev, @href,
@content, on it, *or* one or more child elements of <link> or
<meta>;
* this obviously changes the notion of an [RDF/A element] only
being able to generate three triples;
* Section 4.3.2
* worth saying that if there is no @about above the statement
then it is about the current document;
* Section 4.3.3
* nice work! Might be worth just adding at the end how you only
need to change the <meta> to a <span> to get the alternative
set of triples again;
* Section 4.4.1
* although we haven't discussed this yet on a call or the list,
myself and Steven played with the idea of automatically
generating an rdfs:label when an [RDF/A element] contains
text, even if there is no @property;
* Section 5.1.1
* now that <meta> and <link> are not the same as other elements,
we might need to favour examples that use ordinary elements;
* we need to explain the @about on <head>, and that this will
probably be provided automatically by XHTML 2.
> And then the examples, which will need to be beefed up into a primer:
> http://www.w3.org/2001/sw/BestPractices/HTML/2005-rdfa
Good stuff, again. One thing I notice is that you have CURIEs in square
brackets inside @rel, @rev and @property, but you don't generally do this in
the updated RDF/A draft. Personally, I prefer this, but there is an issue
related to it that needs resolving on the HTML WG side. A quick summary of
it is that if we use CURIEs in @rel (and the other attributes), then the
implication is that anything *without* square brackets is an ordinary URI.
This means that any 'non-standard' @rel value would be localised, so that
this:
<a rel="writer" href="...">Fyodor Dostoevsky</a>
Effectively maps to this:
<> <writer> <...> .
i.e., another document in the same directory as the current document.
I think that's actually quite good, for two reasons:
* It means that the metadata world is not 'polluted' with lots of stuff
using 'writer' when no-one has actually agreed on what 'writer' means;
* all of the RDF/A-related attributes now behave the same way, i.e.,
@rel, @prev and @property are exactly the same as @href.
The problem though is that when RDF/A is imported into XHTML, the
pre-existing @rel values from HTML would now need to be qualified. As
everyone is no doubt aware, HTML defines relationships like 'next', 'prev',
'stylesheet', and so on, so to use them we would now have to do this:
<link rel="[xh:next]" href="..." />
<> xh:next <...> .
The general feeling from HTML people that this has been discussed with is
that this is too much. Unfortunately, whilst it's understandable, it's
difficult to find a consistent solution based around leaving the syntax
looking just like existing mark-up. To spell that out, if we want to
preserve this syntax:
<link rel="next" href="..." />
but at the same time make it equivalent to this:
<> xh:next <...> .
Then we have to say that unqualified CURIEs in @rel, etc., have as their
'base' an XHTML namespace. That's fine, and there is precedent for that
(although with QNames of course) in other languages. But a problematic
side-effect is that this then implies that this mark-up:
<link rel="writer" href="..." />
will generate these triples:
<> xh:writer <...> .
As is probably obvious, this will create problems when processing today
(since a processor will need to know which values to leave in the XHTML
space and which not), and in the future (since adding new values to the list
will then cause conflict with 'local values' that an author may have
invented for their own use).
My preference would be to stick with the square brackets, and then to make
it up to a processor whether it wants to make these two equivalent:
<link rel="[xh:next]" href="..." />
<link rel="next" href="..." />
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/
b: http://internet-apps.blogspot.com/
Download our XForms processor from
http://www.formsPlayer.com/