1. are slightly easier to use for people who don’t understand XML namespaces
   • granted, RDFa’s excessive reliance on XML namespaces makes it hard to parse, and makes it unbearably complex to copy/paste a fragment, which is an important use case for HTML5
2. allow for ad hoc pseudo-semantic markup when you do not use an ontology
   • What’s the point in annotating at all, then?
3. compatible with the non-XML syntax of HTML5 (which should have been ditched IMHO, but, well, in the interest of reactionary users and software, they decided differently)

The fight for the future of RDFa in HTML is going on, but what does that mean to KWARC? We have incorporated RDFa into OMDoc as a means of extending the metadata vocabularies. RDFa, originally designed for XHTML, is prepared for being integrated into any XML language, including OMDoc. HTML5 microdata are an integral part of the HTML5 specification and would not work in other XML languages. OK, but we present OMDoc documents as HTML to make them human-readable. In this output, we want to preserve the semantics of the OMDoc markup, and for that we had always been thinking about using RDFa. (We know exactly how to do it, but just have not yet implemented that step, though.) We could use HTML5 microdata instead, but:

1. RDFa has little software support so far, but microdata have none (beyond proofs of concept)
2. We generate XML-compliant HTML. The non-XML syntax of HTML5 supports embedded MathML, but I doubt that it will support parallel OpenMath markup, where elements from yet another namespace are embedded into the MathML formulae.
3. We generate HTML. The embedded annotations need not be authored manually, so they do not have to be easy to author.
4. We are interested in using well-defined ontologies to express semantics, so we don’t need ad hoc “semantic” markup.

What do you think?

The document “Krextor – An extensible XML→RDF extraction framework.pdf” is no longer available on docstoc.
It has either been removed by the original owner of the document or by the docstoc staff due to copyrighted or inappropriate content.

Isn’t that actually a proof of success, in this new age of the Pirate Party?

Here is where it was stolen from, and here is the paper.

I should have known earlier. I knew it earlier! This paper already existed in my document collection, added on 2007/08/08, and in my ever-growing to-do list there was a neglected entry “read documents added on 2007/08/08”!

For a moment it seemed to me that I had reinvented the wheel, but actually it’s not that bad. While XSDL has a solid formal specification (which Krextor does not have), it seems that it has never been implemented. Krextor has been implemented, as it emerged from a very concrete need to get a concrete task done, and it has been evaluated in various settings. Therefore, I can use XSDL as an inspiration w.r.t. the theoretical background and a nicer declarative syntax.

• pattern matching on XML elements and attributes, using a syntax that is close to literal XML or to XPath (for easily writing extraction rules, which should also be done by other developers in future)
• functional programming (in some way), as the whole idea of mapping XML to RDF (and thus XML nodes to URIs) can be modeled most elegantly using a functional approach. (This is rather a requirement for me implementing the generic core of Krextor, but also for extraction module developers once the XML input language is a bit more complex.)

Having looked a bit into XQuery, Scala, and JavaScript (and a little bit into Haskell), I decided to stick to XSLT for now. Functional programming is awkward but possible, and XML pattern matching is awkward or non-intuitive in most other languages.

It turned out that XSLTdoc is a really nice solution for that: Just put a few additional XML elements in front of every template or function and run a special XSLT to generate the documentation. Works like javadoc and looks nice.