I am a chair of the following workshop (and Michael is on the PC), which is closely related to KWARC’s research interests (specifically KWARC-relevant topics highlighted below):
1st International Workshop on Semantic Publication (SePublica 2011)
at the 8th Extended Semantic Web Conference (ESWC 2011)
May 30th, Hersonissos, Crete, Greece
Keynote by Steve Pettifer, Manchester University, UK: “Utopia Documents and The Semantic Biochemical Journal experiment”
SUBMISSION DEADLINE (extended) March 4
Highlights:
The MISSION of the SePublica workshop is to bring together researchers and practitioners dealing with different aspects of Semantic Technologies in the Publishing Industry. How is the Semantic Web impacting the publishing industry? How is our experience of publications changing because of Semantic Web technologies being applied to the publishing industry?
I am currently pursuing the integration of OpenMath Content Dictionaries (CDs) into the Web of Data. (Here is the agenda, which I will present and discuss at the upcoming OpenMath workshop.) The motivation is that mathematical knowledge is currently underrepresented on the Web of Data, but that it is needed for certain use cases, such as dealing in a reasonable way with all those numbers in statistical datasets published by governments.
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:
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.)
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?)
Today I saw another Semantic Web application that used the Wine Ontology from the OWL 1 Guide as an example, and once more I – coming from a German wine producing region – stumbled upon the strange “German” wines listed in that ontology: SchlossRothermelTrochenbierenausleseRiesling and SchlossVolradTrochenbierenausleseRiesling. The ontology itself traces back to a 1991 publication on the CLASSIC knowledge representation system by Peter F. Patel-Schneider, Deborah L. McGuinness, and Alex Borgida.
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.
W3C’s new SPARQL working drafts bring a lot of nice features that I soon hope to be widely supported, because our applications would also greatly benefit from them.
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 .
}
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.
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.
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).
Only today I became aware of microdata, the proposed way of embedding semantic annotations into HTML5. (Yes, they adopted the syntax that Michael also prefers for OMDoc, and which I personally hate, but I will get used to it.) Microdata are not to be confused with microformats, a poor man’s way of annotation that (ab)uses CSS classes and thus is compatible with HTML 4. Microdata are something like RDFa but
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:
What do you think?
When researching into related work for Krextor, I discovered this paper about XSDL (XML Semantics Definition Language). (Note that by XSDL the authors do not mean the new name of W3C XML Schema, as the latter has only been renamed recently.) XSDL is a language that allows for solving very similar problems as Krextor – extracting RDF in terms of some ontology from XML documents. I had always been looking for a nice declarative way of doing so, and there it is.
This description of the Music Ontology provides an excellent and easy to understand example of how existing ontologies were reused, and other small ontologies designed, to contribute to the development of a larger, integrated ontology. A similar case as in our current development of a versioning ontology for OMDoc, which we are specifying at the moment and which will be made up of a versioning ontology, a change ontology, an event ontology (the one that is part of the music ontology), and an ontology for people.