some more thoughts on the rdfa-sem issue

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.

Thoughts?

Ivan

----
Ivan Herman
Tel:+31 641044153
http://www.ivan-herman.net

Received on Tuesday, 9 August 2011 18:57:26 UTC