attempting to merge the 'vocab' and 'profile' documents

Hi guys,

as I said yesterday on the call, I wanted to try to reconcile, as much
as possible, the 'vocab'[1] (a.k.a. Manu's) and the 'profile'[2] (a.k.a.
Ben's) approaches. I did so, taking also into account some of the
discussion yesterday. The result, obviously tainted by me personal
preferences:-) is in [3]

Before you jump on reading:-), a few comments...

- This merge revealed that the two approaches were even closer than I
thought. Indeed, I mistakenly claimed in[4] that the 'vocab' proposal
did not cover for prefix declarations. In fact, it did: the processing
steps modifications in [3] (that is almost verbatim the same as [1])
describe the modification of [local list of URI mappings] and a
modification of the CURIE processing, and those modifications equally
apply to prefix declarations as for terms. And, in fact, the very same
processing modification reflect, I believe, what Ben describes in [2].

- I have taken over the JSON version of Mark but... after some thoughts
I decided to make the JSON encoding a little bit more complicated:-(.
Indeed, the fundamental idea in [1] (and which I took over) is that the
processing is defined in terms of RDF triples and the two (RDFa and
JSON) serializations are there to encode those triples. The simple JSON
definition of Ben's blog[2] of course do that, but I wonder whether we
should not stick more closely to RDF. So I used an RDF encoding in JSON
that the community is considering at the moment[5]. That may give us
more flexibility if we want to add other things into that profile file
(see next item), though obviously more convoluted. I do not have very
strong feelings about this, though, so we may decide to fall back on a
simple, albeit closely tailored JSON definition (if we decide that we
should keep JSON, that is).

- There is a possible complication that, I believe, I raised at some
point in December (or early January) but we did not fully discuss yet.

The definition of terms as we have now allows us to define, say, the
term 'name' to be used instead of http://xmlns.com/foaf/0.1/name. That
means that we can use, say, @rel="name".

But we already have a bunch of terms for XHTML that we can use, like
'next', 'previous', etc, see [6]. Ie, what we have here is a
generalization of [6]. Which is good because, for example, in RDFa1.1
Core the terms defined in [6] would not make sense, but we can define
RDFa1.1+XHTML in terms of RDFa 1.1 Core, the general vocabulary
definition mechanism, and a predefined default vocabulary for XHTML (and
HTML5, I presume).

There is a hiccup, though. Indeed, [6] defines terms that are usable for
@rel and @rev only. Ie, in RDFa 1.0, property="next" is not expanded to
a URI. Ie, the mechanism we are discussing is, in fact, _not_ a
generalization:-(

So how do we handle that? I see two ways:

  1. We do as described above and we accept that, in RDFa1.1+XHTML,
property="next" becomes 'legal'. Ie, no restriction on @rel/@rev any more

  2. The general mechanism that we describe for vocabularies also
specifies that a specific term->URI mapping is valid for a specific set
of RDFa attributes only. This is doable, but complicates things: there
should be a stricter separation between defining a prefix or a term, the
RDF vocabulary becomes more complicated, and the modification of the
RDFa processing steps becomes a little bit more convoluted, too. Nothing
terribly complicated but should be done.

I do not have strong feeling as for which approach to go for, although I
have a mild preference for #1.

That is it. Now you can start reading:-)

Cheers

Ivan


[1] http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html
[2]
http://webbackplane.com/mark-birbeck/blog/2010/02/vocabularies-token-bundles-profiles-rdfa
[3] http://www.w3.org/2010/02/rdfa/drafts/2010/ED-vocab-20100305/
[4] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0090.html
[5] http://n2.talis.com/wiki/RDF_JSON_Specification
[6] http://www.w3.org/TR/rdfa-syntax/#relValues

-- 

Ivan Herman, W3C Semantic Web Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
PGP Key: http://www.ivan-herman.net/pgpkey.html
FOAF   : http://www.ivan-herman.net/foaf.rdf
vCard  : http://www.ivan-herman.net/HermanIvan.vcf