• TeX – the obvious candidate, also used in some examples
• MathML – the obvious candidate when XML is desired.  They give one Presentation MathML example but also mention Content MathML.
• OpenMath – much less expected. Nice to see that here. Oh the other hand, the links to the OpenMath standard are outdated. I should probably report that.
• OMDoc – I didn’t expect that at all.

Only now I discovered several blog posts, which are almost a year old, on the question whether something that is called “Linked Data” must use RDF. In the proposed OpenMath setup, we will primarily publish the OpenMath CDs themselves according to the Linked Data principles. That works, because the CDs and the symbols defined in them have URIs. The XML language, in which the CDs are written, is well known in the OpenMath community. It consists of a thin XML wrapper around the actual objects of interest, the so-called OpenMath objects, i.e. mathematical formulæ in a functional tree structure. When a web service wants to know how to compute, e.g., the Human Development Index of a country, assuming that the auxiliary data points LE, ALI, GEI and GDP are already known, it looks up the definition of the HDI symbol by its URI, e.g. http://example.org/statistics#hdi. It would request the CD as application/openmath+xml, locate the desired symbol, find out that its definition is 1/3 (LE + 2/3 ALI + 1/3 GEI + GDP) (encoded as an OpenMath object), substitute the values it knows for the parameters, and let a computer algebra system do the computation.

Thus, my answers to these previous blog posts are:

• to Paul Miller’s “Does Linked Data need RDF?”: No, it does not. OpenMath CDs also work. Well, in principle, at least for entirely OpenMath-based application scenarios, as sketched above. For making a real contribution, the data should additionally be made available as RDF (which is no problem for us, we have the software for translation), so that RDF-based Linked Data applications don’t get stuck on a link saying, e.g., the function used to compute this entry of our dataset is http://www.openmath.org/cd/arith1#sum.
• to Toby Inkster’s comment on that blog post: Yes, in principle we could convert a whole OpenMath CD to RDF. At the moment, I’m not doing this. I provide the complete structural outline of the CD (i.e. what symbols it contains, what metadata have been given for the CD and its symbols), but so far I have not implemented a translation of OpenMath objects to RDF. Why?
  1. There is no suitable RDF representation of the ordered tree nature of mathematical expressions. Several people have tried it (e.g. [1], [2]), but none of these representations have been adopted by the community, if they have been implemented at all.
  2. RDF-based reasoning engines don’t understand mathematical expressions. They don’t know, e.g., what a bound variable is, so even if we expressed a formula in RDF, it would be useless.
  3. Software that does understand mathematical expressions (e.g. a computer algebra system) can usually either process OpenMath, or a language for which translations from/to OpenMath have been implemented.

  Note that I have been thinking about what information from the OpenMath objects might reasonably be represented in RDF. In my own applications, I do make use of the information about what symbols occur in a formula (regardless of the depth at which they occur and the order), so I represent that information in the RDF I extract from OpenMath CDs. I have seen other applications that care about the symbol at the root of an expressions, such as the “plus” in a+2b², so that could as well be represented in RDF. One could also think about applications making use of OpenMath objects in CDs obtaining them from the RDF representation of a CD, as XMLLiterals. (That could entirely replace the XML-based CD format without losing expressivity, but I’m sure the OpenMath community wouldn’t like that.)

• to Ian Davis’ blog post: I do not agree with the idea that the term Linked Data may only be used together with RDF. I will continue to call what I’m doing with OpenMath “Linked Data”. However, being aware of the ubiquity of RDF and the software supporting it, I will also make RDF data available for the OpenMath CDs, so the difference is a philosophical one.

And a general remark for the RDF community: Most OpenMath users don’t care. The OpenMath community is conservative, and it has tools that work with the OpenMath knowledge model and its concrete XML representation. In fact, both communities are quite similar. Both have their own standard, with useful applications, and they say: “Why should we need any other knowledge model or format? OpenMath/RDF is fine for us. We won’t use RDF/OpenMath. But of course we’d appreciate if you could come up with another real-world use case that uses OpenMath/RDF and shows its superiority.” (BTW, I would be interested in feedback from other communities whose original data you have published as RDF Linked Data. What attitudes to they have?)

I’m creating this blog post to contribute yet another occurrence of the word “Trochenbierenauslese” to the Web. All occurrences that Google currently lists are related to the Wine Ontology. The correct term would be “Trockenbeerenauslese” (literally “selected harvest of dried berries”). “Trochenbierenauslese” seems to be an uncommon misspelling; Google lists a few hits for “trochenbieren” and “bierenauslese” each. (Note that “Bier” in German means “beer” )

Then I wanted to learn where the “Schloss Volrad” and “Schloss Rothermel” wineries are.  The former one is actually named “Schloss Vollrads” (literally “Vollrad’s castle”) and located in the Rheingau region. While “Rothermel” exists as a German surname, “Schloss Rothermel” does not exist except in the Wine Ontology.  This will be likely to frustrate any attempt to geo-tag the Wine Ontology.  Or maybe one of the actual winemakers named Rothermel might want to register that brand?  This one from the Baden region, for example.  (Would be a nice contribution to the Semantic Web community, as that is not far away from Karlsruhe.)

What to do now?  Cool URIs don’t change. So why not showcase yet another feature of OWL in the Wine Ontology?  It would be interesting to deprecate those wrong URIs and see how the multitude of examples using the Wine Ontology handles that.

When I was reading Christine Müller’s Ph.D. thesis that looked a the integration of topic-based and narrative writing styles, I noticed that she says that OMDoc does not have support for topic-style writing. I think that this is wrong. Taking her example (slightly simplified)

<concept id="A.dita">
 <title>Natural Numbers</title>
 <conbody>
 <p>The set of <term>natural numbers</term>
 defined <cite>here</cite> or in <xref href="nat.dita#nat1"/>.
 </p>
 <para conref="topic/p2"/>
 </conbody>
 <related-link>http://example.com/nats.html</related-link>
</concept>

it is obviously directly  expressible in OMDoc as

<omdoc>
 <omgroup type="concept" xml:id="A.dita">
 <metadata>
 <dc:title>Natural Numbers</dc:title>
 <link rel="dita:related-link" resource="http://example.com/nats.html"/>
 </metadata>
 <omgroup type="conbody">
 <omtext&gt
 <CMP>
 <p>The set of <phrase role="term">natural numbers</phrase>
 defined <cite>here</cite> or in <ref type="cite" href="nat.dita#nat1"/>.
 </p>
 </CMP>
 </omtext>
 <ref href="topic/p2" type="include"/>
 </omgroup>
 </omgroup>
</omdoc>

(again slightly simplified; I am leaving out the relevant namespace declarations). It should be directly obvious that we can define an OMDoc sublanguage that is isomorphic to DITA. Indeed I think that this is an exercise that would be worth doing. After all, there was a message from Bryce Nordgren  about opening oup a Math domain in DITA (see http://openmath.org/pipermail/om/2009-February/001203.html for details), which could use this isomorphism as a guiding light.

Of course DITA not only has topics, but also topic maps, let me again use an example from Christine’s thesis.

<map title="title">
 <topichead navtitle="navi-title" audience="math"/>
 <topicref href="A.dita" collection-type="sequence">
 <topicref href="A1.dita"/>
 <topicref href="A2.dita"/>
 </topicref>
 <reltable>
 <relrow>
 <relcell>A.dita</relcell>
 <relcell>B.dita</relcell>
 </relrow>
 </reltable>
</map>

The first part of this map is just what we have always thought of as a narrative structure in our NarCon approach in OMDoc. So we can directly represent it as something like

<omdoc>
 <metadata>
 <dc:title>title</dc:title>
 <link rel="dita:audience" resource="something:math"/>
 <link rel="dita:navtitle" resource="navi-title"/>
 </metadata>
 <omgroup xml:id="A.narrative" type="sequence">
 <ref type="include" href="A1.omdoc"/>
 <ref type="include" href="A2.omdoc"/>
 </omgroup>
</omdoc>

I must confess that I do not really understand what the href on the top-level topicref means, so I have left it out. Note that I am only interested in the general compatibility of the formats and not the details of the translation, which will have to be worked out. That leaves us with the reltable, which (as far as I can understand it a way to specify cross-references that is a better alternative to <related-links>, since it is more portable and attached to DITA maps (which we can think of as discourse-level presentation of the content structure given by the graph of DITA topics). So I would just add the following metadata section to the <omgroup> element:

<metadata>
 <link rel="dita:related-link" resource="http://example.com/nats.html"/>
</metadata>

OK, that ends our little comparison exercise. There are a couple of conclusions I would like to draw from this:

1. OMDoc can do topic-oriented writing quite nicely
2. the OMDoc1.3-style metadata help significantly
3. rather than develop a DITA ontology (hinted at with the dita: namespace prefixes) we should develop ontologies that describe the various aspects of topic-based writing in generality and find the respective markup primitives. For instance dita:audience seems weird, there must be an ontology in the eLearning realm that already formalizes this.
4. The OMDoc-1.6 idea of leaving out the <metadata> element and freely intermixing the metadata <link>, <resource> and <meta> with the OMDoc content will make the translation much simpler and direct, e.g. for the <reltable> and <related-link> elements from DITA which are situated at the end in the original.

OK, that is all I have to say at the moment, please give me feedback.

Property paths

Property paths will make queries both more powerful and easier to write. Some cases resemble XPath/XQuery:

Find the names of people 2 “foaf:knows” links away.

{
 ?x foaf:mbox <mailto:alice@example> .
 ?x foaf:knows/foaf:knows/foaf:name ?name .
}

… whereas others generalize the idea of transitive closures, which is also relevant in our applications that work on RDF extracted from OMDoc or OpenMath (e.g. finding imported theories, computing dependencies, and checking MMT well-formedness):

Find the names of all the people that can be reached from Alice by foaf:knows:

{
 ?x foaf:mbox <mailto:alice@example> .
 ?x foaf:knows+/foaf:name ?name .
}

Update language

Other features to come are an update language, probably inspired by XQuery Update.  That would, assuming a triple store that supports it, e.g. make it easier to integrate Krextor into applications.

Entailment regimes

Besides enhancements to simple queries, the behavior of SPARQL under different entailment regimes (e.g. RDFS or OWL – in practical terms: what happens when you attach a reasoner to your triple store) will be clarified.

Miscellaneous

In the core of the language, certain other goodies will be specified, such as an easier syntax for negation-as-failure and subqueries (nested queries).

• ¬∃knows.TroubleI’veSeen (Spiritual)
• Bier ⊑ ¬∃gibtsAuf.Hawaii ⇒ Ich ⊑ (¬∃fahreNach.Hawaii)⊓(∀bleibe.Hier) (Kuhn, 1963)
• ¬(⋄I ⊑ ∃get.¬“⊨”) (Jagger/Richards, 1965)
• ¬∃ b:Business . b = ShowBusiness (Berlin, 1946)
• I ⊑ ∃shot.Sheriff ⊓ ∀shot.¬Deputy (Marley, 1973)
• ¬(⊥ ⊓ ¬HoundDog) (Presley, 1956)
• ¬∃ ¬Sunshine ← gone(She) (Withers, 1971)
• ∀x ∃y . needs(x, y) ∧ loves(x, y) (Blues Brothers, 1981)
• I ⊑ ∃feel.(Pretty ⊓ Witty ⊓ Gay) (Bernstein/Sondheim, 1961)

(defun bibtex-insert-current-urldate ()
  (interactive)
  (bibtex-make-field
  '("urldate" "" (lambda () (format-time-string "%Y-%m-%d" (current-time))))
  t))

The following line binds it to the keyboard shortcut C-c u:

(add-hook 'bibtex-mode-hook '(lambda ()
			       (define-key
				 bibtex-mode-map [(control c) ?u]
				 'bibtex-insert-current-urldate)))

With the default BibLaTeX style, the urldate field will render as (visited on MM/DD/YYYY).

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?

pdfnup doc.pdf --nup 2x1 --trim "-6cm -6cm -6cm -6cm" --delta "-18cm -18cm" --scale 1.8

Update: Formatting your PDF right

It is even better if you already set the right paper format when creating your PDF. With appropriate printing settings, that gets the print right without the adjustments mentioned above, and it makes screen reading more convenient. Markus Kuhn explains how. However, his measurements didn’t work for me; instead of 92 112 523 778 I had to use 91 71 521 721.

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.