What does it do?

The dita2rdf DITA OT plugin (a.k.a. the dita2rdf plugin) adds a new transtype to the DITA OT: rdf.

In short, running the rdf transtype on a DITA map or topic runs an extraction of the metadata of the content and stores it in RDF/XML format, a serialization of RDF. The transformation not only extracts the metadata of the input file, it also follows the references (@href and resolved @keyref) to cover the whole documentation set.

Once the metadata is extracted as RDF, you should upload it to an RDF repository. To do so, just follow the instructions. Once the upload is configured, all the RDF output you generate with the rdf transtype will be uploaded to the repository. I will soon add fun things to do with a repository fill of DITA metadata ;-) You'll get updates here.

I will speak about this project it during the DITA Europe conference and the DITA OT day. Let's meet there!

Metadata cascading

The dita2rdf DITA OT plugin only extracts the metadata at the level where it's expressed and not to apply the metadata cascading rules in the resulting RDF. I'd rather extract incomplete metadata than zealous inexact statements. The only metadata that is currently inherited is the language, as per the XML standard. For two reasons:

It is uncommon to mix content from different language in the same documentation set.
In the cases where languages are mixed, people should specify the language of each topic.

I have ideas to distinguish the metadata that genuinely describes a topic or a map from the metadata that is inherited, but I will not apply them until I'm sure it is robust enough.

For my fellow DITA OT hackers

The dita2rdf plugin was developped reusing the methodology of the pdf2 plugin for the build and the customization, as I thought many DITA-OT users would feel more comfortable with a familiar plugin structure.

However, the dita2rdf plugin differs on a couple of points:

The preprocess is 'specialized' to remove the steps that are not necessary for the purpose of this plugin. It also speeded up the processing. More details here.
Though the original intent was to rely on the topicmerge to flatten the structure and have only file to process, it appeared too much information was left behind: mapref and @processing-role="resource-only". Topicmerge was consequently also removed, and the parsing is done by following the @href to jump from file to file (the temp files, not the original ones).

For the long term, I aim at removing the preprocess completely and using as much XSLT as possible to make the code more portable.