http://sepublica.mywikipaper.org/

At SePublica we want to explore the future of scholarly communication and scientific publishing. As we are going through a transition between print media and Web media, SePublica aims to provide researchers with a venue in which this future can be shaped.

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:

• Best Paper Award sponsored by Elsevier: US$ 750+250 for the most innovative and feasible proposal concerning semantic publishing
• Springer LNCS post-proceedings: A selection of revised versions of the best submissions will be published in the “ESWC 2011 Workshop Highlights” LNCS volume.

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?

The CHALLENGE of the Semantic Web is to allow the Web to move from a dissemination platform to an interactive platform for networked information. The Semantic Web promises to “fundamentally change our experience of the Web”. In spite of improvements in the distribution, accessibility and retrieval of information, little has changed in the publishing industry so far. The Web has succeeded as a dissemination platform for scientific and non-scientific papers, news, and communication in general; however, most of that information remains locked up in discrete documents, which are poorly interconnected to one another and to the Web. The connectivity tissues provided by RDF technology and the Social Web have barely made an impact on scientific communication nor on ebook publishing, neither on the format of publications, nor on repositories and digital libraries. The worst problem is in accessing and reusing the computable data which the literature represents and describes.

• Consider research publications: Data sets and code are essential elements of data intensive research, but these are absent when the research is recorded and preserved in perpetuity by way of a scholarly journal article.
• Or consider news reports: Governments increasingly make public sector information available on the Web, and reporters use it, but news reports very rarely contain fine-grained links to such data sources.

QUESTIONS AND TOPICS OF INTEREST

• What does a network of truly interconnected papers look like? How could interoperability across documents be enabled?
• How could concept-centric social networks emerge?
• Are blogs and wikis new means for scholarly communication?
• What lessons can be learned from humanities and social science publishers (i.e. going beyond scientific publishing towards scholarly publishing)?
• How could we move beyond the PDF? How can we embed and link semantics in EPUB and other e-book formats?
• How are digital libraries related to semantic e-science? What is the relationship between a paper and its digital library?
• How could we realize a paper with an API? How could we have a paper as a database, as a knowledge base?
• How is the paper an interface, gateway, to the web of data? How could such and interface be delivered in a contextual manner?
• How could RDF(a) and ontologies be used to represent the knowledge encoded in scientific documents and in general-interest media publications?
• What ontologies do we need for representing structural elements in a document?
• How can we capture the semantics of rhetorical structures in scholarly communication, and of hypotheses and scientific evidence?

AUDIENCE

• researchers from diverse backgrounds such as argumentative structures, scholarly communication, multi-modality in publications, digital libraries, semantics in publications, and ontology engineers.
• practitioners active in the publishing industry, repositories of experimental information and document standards.

IMPORTANT DATES

Paper/Demo Submission Deadline (extended): March 4, 23:59 Hawaii Time
Acceptance Notification: April 1
Camera Ready Version: April 15
SePublica Workshop: May 30

SUBMISSION AND PROCEEDINGS

Research papers are limited to 12 pages and position papers to 5 pages. For system descriptions, a 5 page paper should be submitted. All papers and system descriptions should be formatted according to the LNCS format.

We encourage the submission of semantic documents. LaTeX documents in the LNCS format can, e.g., be annotated using SALT or sTeX. We also invite submissions in XHTML+RDFa or in the format or YOUR semantic publishing tool.

However, to ensure a fair review procedure, authors must additionally export them to PDF.  For submissions that are not in the LNCS PDF format, 400 words count as one page. Submissions that exceed the page limit will be rejected without review.

Depending on the number and quality of submissions, authors might be invited to present their papers during a poster session.

Please submit your paper via EasyChair

The author list does not need to be anonymized, as we do not have a double-blind review process in place.

Submissions will be peer reviewed by three independent reviewers. Accepted papers have to be presented at the workshop (requires registering for the ESWC conference and the workshop) and will be included in the workshop proceedings that are published online at CEUR-WS.

PROGRAM COMMITTEE

• Christopher Baker, University of New Brunswick, Saint John, Canada
• Paolo Ciccarese, Harvard Medical School, USA (SWAN)
• Tim Clark, Harvard Medical School, USA (SWAN)
• Oscar Corcho, Politecnica de Madrid, Spain
• Joe Corneli, Open University, UK (PlanetMath)
• Stéphane Corlosquet, Massachusetts General Hospital, USA (Drupal)
• Henrik Eriksson, Linköping University, Sweden
• Benjamin Good, Genomic Institute, Novartis, USA
• Michael Kohlhase, Jacobs University, Germany
• Sebastian Kruk, knowledgehives.com, Poland
• Thomas Kurz, Salzburg Research, Austria
• Steve Pettifer, Manchester University, UK
• Matthias Samwald, Information Retrieval Facility, Austria
• Jodi Schneider, DERI, NUI Galway, Ireland
• Dagobert Soergel, University of Maryland, USA
• Robert Stevens, Manchester University, UK

ORGANIZING COMMITTEE

• Alexander García Castro, University of Bremen, Germany
• Christoph Lange, Jacobs University Bremen, Germany
• Anita de Waard, Elsevier, USA/Netherlands
• Evan Sandhaus, New York Times, USA

• 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.

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.

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?

Another thing that we should think of in this  arena is to enable some form of RESTful logging facility, so that users can find out what happened to the content. The technology that seems best suited for that seems to be RSS or Atom Syndication (probably the latter). The nice thing is that we could log all the changes to any URI we use in the system. I am not sure under which URL we would address the log, one idea is to just make use of the the mime type application/atom+xml just as for the xhtml presentation as suggested in my last post that would at least alleviate the choice of URL.

What I have talked with Florian about, but maybe not with the OMBase team, is how to integrate presentation. That should be very simple from the interface point of view: we just take the same URLs, but a different HTTP header.

GET /arith1/lcm
Host: cds.omdoc.org
Accept: application/omdoc+xml

gives you the OMDoc file and

GET /arith1/lcm
Host: cds.omdoc.org
Accept: application/xhtml+xml

gives you the presented version (with the standard options). Now, we have written a paper about presentation and submitted it to MKM and Christine has spent a lot of ingenuity on defining user options to the presentation process.This should be easy to integrate with the URI query interface:

GET /arith1/lcm?ext=foo.ntn∫=lang:ntn;style:physics
Host: cds.omdoc.org
Accept: application/xhtml+xml

That should do the trick.

You can find the details here.

Even though I totally buy into their observations, I think that  it would be better to keep the theories as they are and interpret the repair operations as theory morphims. That would be a non-desctructive operation, and the operations would become very natural theory morphisms.

We have been making some progress on the conversion of the arXiv  collection from LaTeX to XHTML+MathML (see the arXMLiv project at KWARC), and I have announced that we have over 50% “success rate”. I have been asked by Aaron Krowne what success rate means and when we are going to reach 100%.  Here is the story.

First I would like to briefly talk about what we are doing. We are using Bruce Miller’s LaTeXML converter over the ca 370 000 documents contained in the arXiv. Heinrich Stamerjohanns has build a test harness for LaTeXML that parses the log files and makes the statistics available on the web. This is a very powerful way of doing things, it has exposed a lot of problems in LaTeXML and has allowed Bruce to make the program much more stable (see e.g. the fatal error development). At 370000 LaTeX documents from all over the world over 15 years, there is almost no error you will not encounter. The other result is that we are sitting on what is probably the largest collection of documents with MathML in them worldwide.

The main technical task of the arXMLiv project is to supply LaTeXML bindings for the (thousands of) LaTeX classes and packages used in the arXiv collections. A group of Jacobs University Undergrads are helping with this. Since we are still in a development mode, we do only download last year’s collection of articles after newyear (about 80000+ new ones in a couple of weeks).

Now, let’s come back to the questions: Technically success means that the LaTeXML program does not throw any, errors, i.e. that all macros are known. Whether the transform is mathematically correct, is another matter, this needs human testers, and organizing that is an interesting problem in itself. We have first ideas in this direction and will try to make progress on this front in the next months.

And now to the percetages:  I am not sure whether we will hit 90% at all. The problem is that this about the number of files that can still be  successfully  by LaTeX, since arXiv does not have a viable package management system.

Furthermore, arXiv papers use about 7000 packages and classes, of which I guess three quarters are used by less than five papers. So we
are only going to bother about giving LaTeXML bindings for the more important ones (following the 80/20 rule). Moreover, the older the papers get, the less likely they are are to be successful, so I guess conversion success rates will go up automatically when we add
the 2007 papers (ca 80000+). Finally, the success rates vary considerably over the different categories of the arXiv. The success rate actually dropped by 10% by to 50% by starting a big new category (we had been at about 60% before).

My personal suspicion is that we will reach 70% in the next three months, then the going will become slower, and I am not sure how much we
will go beyond 80% realistically with the resources (a couple of undergrads) any time soon. To reach this, we would have to take the project global, which I would not mind, but which I am not necessarily seeing as one of my priorities. But you are of course invited to join our little project, so just contact me if you are interested.