W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > August 2011

some more thoughts on the rdfa-sem issue

From: Ivan Herman <ivan@w3.org>
Date: Tue, 9 Aug 2011 21:00:21 +0200
Message-Id: <4BCF3F15-BA0F-4FEA-A40A-080100FD77E0@w3.org>
To: W3C RDFWA WG <public-rdfa-wg@w3.org>
I spent my day on transforming my pyrdfa implementation into a version without profiles (except the default) and the management of the vocabs as we discussed. It of course works. From an implementer's point of view, working on a pure one pass DOM implementation the difference in complexity is not that high: the most complex part, in my view, is the implementation of a proper caching of profile or vocab... But I understand the other issues, so that is fine.

However, one thought. My code has an option to expand the default graph with the result of the vocab processing. However, other implementations may not want to that. Which is fine. But... let us suppose implementation A only produces the "simple" graph from RDFa. How can another application do the rdfs extension? That application does not have access to the vocab data any more. The only possibility would be to do a full expansion to all vocabularies, and that might be an overkill.

Hence the idea. Why not requiring that the rdfa processor would add that information to the default graph? The set of triples may be very simple, something like:

<uriofrdfasource> a rdfa:source;
   rdfa:vocab <uri1> ;
   rdfa:vocab <uri2> .

with this extra info any subsequent processor can add the extr triples that processor A chose not to add.



Ivan Herman
Tel:+31 641044153
Received on Tuesday, 9 August 2011 18:57:26 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:05:25 UTC