Danny Ayers has another excellent post on Content Management and Data Mining with RDF, XPath, XHTML and the rest... (which he wrote in response to Simon Wilson's Using XPath to mine XHTML). I generally agree with Danny's XML DB vs RDF vs relational point of view.

For the iCite net, I didn't feel that using RDF/XML as the base data structure was the right way to go, so I am experimenting with a somewhat traditional relational (table) data structure, but where each column maps to either a RDF namespace property or something that is a similar concept (iCites have a less formal namespace-like system that can also map to formal RDF and XML namespaces).

I am storing the structure of iCites as simple XML files (e.g., with tags indicating rows and columns) and experimenting with XPath as the base query language.

What I hope to produce is a way to generate RDF out of essentially relational stores, but also allow those stores to be directly accessible via XML tools and XML data interchange protocols, including transformed into XHTML. I also will do a "verbose" XML output that replaces generic row and column tags with their full property names, so it can look like a decent XML format as well.

I realize that RDF alone can be something like all of this, and probably the main difference I can highlight at this point about this aspect of iCites is that they can be a lot less formal than RDF data. In general, it would take assembling several iCites together to make a decent RDF document (but, I hope to make such assembly very easy and common, just not required).

The worse case scenario is that my approach results in a system wherein the benefits of each of the relational, RDF, and XML data structures and their corresponding tools are crippled! The best case scenario is that it leverages the benefits of all three, and any user (which I assume will be both computer agents and people viewing XHTML, text, etc.) can negotiate which format(s) they need for their processing / viewing pleasure.