W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2010

vocabularies, token bundles, profiles (on ACTION-4)

From: Ivan Herman <ivan@w3.org>
Date: Fri, 26 Feb 2010 09:44:51 +0100
Message-ID: <4B878A03.9020400@w3.org>
To: Mark Birbeck <mark.birbeck@webBackplane.com>, W3C RDFa WG <public-rdfa-wg@w3.org>
Hi Mark,

On ACTION-4...

I have read through[1] and I try to compare it with Manu's earlier
document[2] on RDFa vocabularies to see where the differences are. I
have the impression that the two approaches are almost the same (though
I may miss something here). Which is great because I think (I hope:-) we
all agree that some sort of a mechanism in this direction (one can just
look at the examples in your blog) is absolutely essential...

What I see as a general mechanism (with the differences) in both cases
is as follows.

1. An RDFa attribute is defined whose values are URI-s for vocabulary
management.

[1] uses @profile, [2] uses @vocab. If the proposal on '@profile
everywhere' gets through in the HTML5 world[3] then @profile might be
indeed a better choice, otherwise we may have to stick to an RDFa
specific attribute, because @profile will then vanish from HTML5... But
I guess this is a detail for now.

2. By dereferencing that URI, one gets to a document that describes a
number of keyword->URI mappings (let me call this a 'keyword definition
document', a.k.a. KDD:-). From that point on, those keywords can be used
anywhere where CURIE-s can be used in the original RDFa document.

Document [2] does not specify the syntax of the KDD. Instead, it
describes some RDF terms, ie, RDF triples, that specify the keyword->URI
mappings and you are supposed to get through dereferencing.

My understanding, on the other hand, is that [1] defines the keywords in
terms of xmlns statements in the KDD which the user can define in HTML
and/or JSON.

(3. Note that, as a small additional step that I referred to in [4], I
think that extending [2], ie, the RDF triples, to also define namespace
prefixes additionally to keywords is a trivial step to do and can be
added to [4] easily. That would obviously make the life of authors
easier: one could define both keywords and namespaces at will.)

First of all, is it correct that the few differences between the two are
the one above? If so, I have a question and a comment

- Presumably [1] relies on the approach that the namespace declarations
in the KDD are 'taken over' to the startup RDFa document as if they were
defined there. Ie, to use your example, the fact that xmlns:Person is
defined in the KDD means that the original RDFa document inherits those
CURIE prefixes. But, as far as I know, the current RDFa spec disallows
the usage of CURIE-s without ':', except for the predefined XHTML
keywords. In other words,

<span xmlns:prefix="blabla" rel="prefix"/>

is not kosher in RDFa 1.0, and that should be modified. Would not that
create backward compatibility issues?

The approach in [2] does not seem to require a modification of the
current RDFa, but, instead, an add-on to the current RDFa processing.

- I must admit I am uneasy with the introduction of JSON in the picture.
From the point of view of non-Javascript implementers Json (though of
course manageable from most languages these days) represents a different
file syntax that the implementation has to understand for that
particular purpose. Even if it _is_ simple, it is an additional
mechanism...

In other words, I would have to have two different parsers at disposal
to do the same job (namely extract the namespace declarations and add
them to the ones valid for the node that is just being processed.)

I find this as a drag...:-(

My personal, favourite approach (and that also addresses the missing
syntax issue in [2]) is to restrict the syntax of KDD to RDFa.
Implementations already have a mechanism to parse RDFa:-), and that
should be enough.

Note that, though it is true that defining a vocabulary, mainly in
approach [2], is a little bit more complicated in RDFa than in JSon, I
do not think that matters too much. 90% of the authors will not define
KDD-s, they would just use those that will be defined by CC or Google,
or, well, W3C.

Ivan

P.S. B.t.w., just because that was raised as a plan for next week's
meeting, this discussion is very relevant to ISSUE-11. Indeed, if either
[1] or [2] (or a mixture thereof) is adopted, then a solution to
ISSUE-11 is to define a number of namespaces in a default KDD as
provided by W3C or the spec or somebody else...

[1]
http://webbackplane.com/mark-birbeck/blog/2010/02/vocabularies-token-bundles-profiles-rdfa
[2] http://rdfa.digitalbazaar.com/specs/rdfa-vocab-20100111.html
[3] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0055.html
[4] http://lists.w3.org/Archives/Public/public-rdfa-wg/2010Feb/0053.html
-- 

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



Received on Friday, 26 February 2010 08:45:01 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:05 GMT