Suggestions for RDFa 1.1

Manu asked me [1] to relay some observations I was making about the
meaning of certain (X)HTML attributes in RDFa [2, 3]. These relate to
existing attributes in the markup intended to carry URIs, specifically
@data in <object> and @cite in <q>, <blockquote>, <ins> and <del>. Now
that I think of it, however, a similar protocol may apply to
attributes like @longdesc in <img>, <frame> and <iframe> and @action
in <form>.

What these attributes have in common is that they follow the pattern
of specifying resource objects like @href or @resource, with the
exception of object/@data which I read to be equivalent to @src (or
@about). While the bulk of them have additional meaning than just a
URI reference (I excluded @usemap because its meaning is extremely
narrow), I am optimistic that they could be used in lieu of
RDFa-specific attributes without any ambiguity. The purpose of doing
so (as I read the purpose of RDFa itself) use a document's existing
data to express additional (not conflicting) semantics.

As such, it would be totally reasonable to say:

<q rel="dcterms:references" cite="#benjamin-franklin"
property="rdf:value">Remember that time is money.</q>

to mean:

<> rdf:value "Remember that time is money."; dcterms:references
<#benjamin-franklin> .

Although it may be convenient that I chose dcterms:references for
@cite, an author could use @resource instead, if @cite was wholly
inappropriate. If both @resource and @cite were present, the former
would be preferred. Consider also the following:

<img src="foo.jpeg" typeof="foaf:Image" rel="dcterms:abstract"
longdesc="foo.html" alt=""/>

This would yield, as one might expect:

<foo.jpeg> a foaf:Image; dcterms:abstract <foo.html> .

Again, what we would expect to find on the other side of a @longdesc
is largely the same as what we would expect as the object of a
dcterms:abstract. (After having typed that second example, I see that
this could also apply to CDATA attributes such as */@title, img/@alt,
table/@summary.)

It occurs to me that plenty of other XML grammars have concepts of
linking and embedding as well as tertiary URI references. One could
traverse the elements and attributes of a given vocabulary, outline
which attributes correspond to @about, @href, @resource, @rel and @rev
(and as noted above, hey, why not @content, @property and @datatype!),
define a pecking order if any, and which attributes ought to be
outright ignored. With a well-defined method, adding RDFa to something
like Atom, DITA, DocBook or SMIL would be a snap, and wouldn't have to
wait on central approval. (It may also make sense to package the
attributes into an RDFa namespace, but I wouldn't want to risk another
XLink.)

Regards,

Dorian

1) http://twitter.com/manusporny/status/3076356271
2) http://twitter.com/doriantaylor/status/3074779699
3) http://twitter.com/doriantaylor/status/3074807318

-- 
Dorian Taylor
http://doriantaylor.com/

Received on Saturday, 1 August 2009 23:25:05 UTC