I am pleased to announce that as part of my work on knowledgeblog (http://www.knowledgeblog.org/), we now have two new tools — Greycite and kblog-metadata — and have extended kcite, our citation engine (http://knowledgeblog.org/kcite-plugin). I will just give a brief overview here of the functionality here. Subsequent articles will describe these tools in more detail, explaining the rationale behind them.

The kcite engine, which you can see in use in this article, produces a nicely formatted bibliography list, generated using only identifiers to these articles: DOIs, Pubmed IDs or arXiv IDs. One obvious absence from this list, however, is the ability to directly cite URLs. We have now started to address this, through our two new tools.

Unlike other identifiers, we lack a centralised resource capable of delivering bibliographic metadata about a URL. To enable this, my colleague, Lindsay Marshall (http://www.ncl.ac.uk/computing/staff/profile/lindsay.marshall), has developed Greycite (http://greycite.knowledgeblog.org/), which went live earlier this week. Greycite allows you to search for bibliographic metadata about a given resource. So, for instance, you can view the metadata for my article on realism (http://www.russet.org.uk/blog/2010/07/realism-and-science/). Probably more usefully than this view, however, is that you can also retrieve this metadata computationally: currently, we support JSON suitable for citeproc-js (http://bitbucket.org/fbennett/citeproc-js), and bibtex (http://www.bibtex.org/). Obviously, we can support further formats if we choose; fortunately, the metadata for a URL is, in general, very simple (date, title, website or “container” title).

Greycite must, however, get its metadata from somewhere. As we wanted greycite to be both an automated and authoratitive source, we have decided to take metadata only from the URL being referenced (or referenced from the URL). Anything else would have required an authentication step, to prove that metadata was being provided by the owner of the content. I will describe this in more detail later; we support COiNS (http://ocoins.info/), OGP (http://ogp.me/) and Google Scholar Metatags (http://scholar.google.com/intl/en/scholar/inclusion.html). In practice, this combination of sources allows us to provide rich references to many URLs. Where not, we fallback gracefully.

Unfortunately, formal metadata on the web is not heavily controlled or pre-defined. If you are using WordPress to publish your articles, it is largely dependant on your theme as to whether there is any metadata on your articles. I have started to address this with kblog-metadata (http://wordpress.org/extend/plugins/kblog-metadata/). Again, I will describe the functionality in greater detail later, but essentially, this plugin adds metadata in all three of the formats mentioned above in the document headers, and provides a good deal of flexibility about where that metadata comes from.

Finally, I have extended kcite to query for metadata from greycite for each URL cited. The data coming back is used directly for rendering, so this should have reasonable performance; moreover all data is cached in the WordPress database, limiting outgoing network traffic from the webserver for each reference.

Work is not complete yet, and there is much more to do. However, I have been using development versions of these tools now for a month or so, and the experience is rather good. The metadata is useful during authoring, as it can be used to find the correct reference. While we cannot capture metadata from all sources, a surprisingly large number of them do work. And the development of greycite means that this metadata can be served efficiently and without adding too much complexity to kcite. In short, while it may not be a complete solution, these enhancements represent a substantial step toward making academic URLs formally citable, as others have recently called for (http://michaelnielsen.org/blog/is-scientific-publishing-about-to-be-disrupted/).

Addendum

2012-05-09: I have already published an initial article (http://www.russet.org.uk/blog/2012/03/kblog-metadata/) about kblog-metadata, which should have been referenced here.

Bibliography

In this article, we will describe the rationale behind our new service, Greycite, that we have developed in general enable more formal citation of URLs, and specifically to back up the kcite citation engine.

Authors

Phillip Lord and Lindsay Marshall
School of Computing Science
Newcastle University

Introduction

As has been recently announced (http://www.russet.org.uk/blog/2012/05/kcite-greycite-and-kblog-metadata/), the kcite citation engine (http://www.russet.org.uk/blog/2011/12/kcite-the-next-generation/), now supports URLs directly, as can be seen in this sentence. While it can do this trivially, by simply putting a URL in the reference, we wanted something better; where possible, we wanted URLs to be referenced in a similar manner to arXiv (http://arxiv.org/) or PubMed (http://www.ncbi.nlm.nih.gov/pubmed/) IDs — with full bibliographic metadata where possible.

To achieve this, we have created the Greycite service, which captures metadata from a URL and then presents this back to kcite. In this short article, we describe the rationale behind the creation of this service.

Discovering the metadata

The kcite citation engine allows WordPress users to reference an article through the use of a shortcode, of the form [‌cite]10.1371/journal.pone.0012258[/cite‍] which is rendered as (http://dx.doi.org/10.1371/journal.pone.0012258). The rendering uses metadata from a third party service, in this case provided by CrossRef (http://www.crossref.org/CrossTech/2011/04/content_negotiation_for_crossr.html), to generate the bibliography reference. Other identifiers are handled similarly, using other services.

We wished to achieve something similar with an arbitrary URL. However, there is no centralised service where authors are required to lodge their metadata for any URL. We considered the possibility of providing such a service where content authors could lodge their metadata — author, date, title and so on, about a URL. However, it seems unlikely that this would succeed for two critical reasons. First, and most importantly, few authors would be likely to go the extra effort: why would they bother, and if they did why use our service rather than some other. Second, it would require a authentication step to ensure that metadata genuinely came from the person controlling the URL. We also considered the possibility of deliberately allowing third party addition of metadata, but this raises the question of conflicts in the metadata.

As a result, in practice, we feel that the only sensible cause of action is to extract the metadata directly from the resolvable contents of the URL, as this ensures that we have taken metadata from what is (quite literally) the authoratitive source. The significant drawback to this is that if the author does not provide this metadata, no one else is able to do so. In a sense, though, this is correct: if authors provide no metadata, then this is how their works should appear, as this is their choice. Moreover, as we have argued previously (http://www.russet.org.uk/blog/2012/04/three-steps-to-heaven/), if authors or their readers are worried by this, it may provide the motivation to add bibliographic metadata to their work which is a benefit to everyone.

The immediate problem here is the lack of single standardised bibliographic metadata on the web; however, there are a number of systems which are currently in use, namely, COinS (http://ocoins.info/), Open Graph Protocol (http://ogp.me/) and Google Scholar tags (http://scholar.google.com/intl/en/scholar/inclusion.html). We also have also considered a fourth option which is RSS/Atom feeds which, perhaps ironically, are structured enough to provide bibliographic metadata. At the moment, we do not have accurate statistics on the prevelance of each of these types of metadata — of course, we could crawl the web to gather these statistics, but we are not really interested in the web in general, but in the academic sector of it which is hard to determine a priori. However, our initial experiences suggest the following:

• COinS metadata is not widespread. We suspect that this follows from our experience that the specification is hard to find and incomprehensible when you do (http://www.russet.org.uk/blog/2012/03/kblog-metadata/).
• Google Scholar tags are much more widespread, although there is some variation (the use of name vs property for instance, or multiple authors represented in a single tag vs each author on their own).
• OGP appears reasonably widespread, including in articles which are not academic (or not solely so) but likely to be cited, such as BBC News, or anything hosted on WordPress.com.
• RSS/Atom worked fairly well, however normally only contain metadata for recent articles; we tried to track RSS feeds, but this resulted in 1000s of URLs very quickly.

Over time, we should be able to get clearer statistics as to real usage of these systems, based on the data in greycite.

Greycite as a service

Greycite is currently packaged as a service, rather than embedded within WordPress, which would also have been possible. The reasons for this were several. First, gathering metadata involves a reasonable amount of parsing, and putting this all into a WordPress plugin seemed unnecessarily heavy. This is particularly so, given that server load is already an issue with kcite, and adding further to this did not seem sensible.

Second, we wanted to maintain a database of the metadata gathered from around the web. This allows us to deal with problems of resources changing or disappearing. We want the user to be able to cite a URL and for this citation to not break if the URL disappears and becomes 404. We also wish to be able to cite a URL at a specific date, and have the citation show the metadata for that time. Placing this load on the individual wordpress database backend does not really make sense. Moreover, with greycite, there is a reasonable likelihood that others will have cited a particular article, thereby sharing the load.

Third, Greycite is also useful outside of WordPress. So, for instance, Greycite also provides bibtex so can be used with a bibliographic manager, which is very useful at authoring time, as we can use this metadata to search over a list of relevant URLs, and then to select between then.

Finally, we wanted to be able to add additional functionality, which may require upgrading the database periodically, which is harder to do within a plugin. For example, we have already added links through to the UK Web Archive (http://www.webarchive.org.uk/ukwa/), for those resources which are archived. We will add the Internet Archive (http://www.archive.org/), and Web Cite (http://www.webcitation.org/) in time also. This means that not only should citations remain displayed correctly if resources disappear or change, it should still be possible to get to their contents in many cases.

The article as a linked data

The existence of Greycite allows us to turn a blog post into a linked data, academic article. The reader of an article sees as well as the content directly generated by the author, data gathered from all the outgoing links. The reference list, therefore ceases to be a mechanism for finding secondary sources, and becomes a usability tool; readers can understand what sources are being relied on, without having to remember URLs or click through to them. Likewise, the authors can use the linked data environment outside of a web browser to help enable authoring. Metadata that is useful to readers is, unsurprisingly, also useful to authors (who tend to be the first person to read an article anyway!).

Discussion

With Greycite, we were interested in adding more formal citation to the web in general, and more specifically supporting kcite (http://www.russet.org.uk/blog/2011/12/kcite-the-next-generation/). We believe that we have achieved this in part with a relatively light-weight service. Greycite is useful for article display, and for authoring.

In addition, we start to address the issues of link breakage, by building on the back of existing archiving services. Articles will be able to still display article metadata if an article disappears. Future versions of kcite will also redirect links to the nearest web archive when this happens. We have done this without the recourse to secondary identifiers such as a DOI or PURL, which we believe represents a better user experience. Building on the back of existing web archives also addresses a critically scalability issue; the Greycite database needs only to store bibliographic metadata which is likely to remain tractable. From a legal perspective, we also side-step issues of copyright, as gathering metadata alone is likely to be covered by fair dealing clauses.

By depending only on metadata present in the URL itself, we can guarantee that metadata is authoratitive (not, of course, that it is “correct”, as in reflects the authors intentions, but it does match what they said). It also means that we do not control the metadata; it has not been entered into greycite; it is out there, available on the web, free for anyone to gather. We wish to be part of the semantic web, not a walled garden within it.

Finally, we have started to build a linked data environment for academic publishing. Bibliographic metadata is, of course, only the start. It is not a suitable way to present all kinds of information; for instance, Chemicalize (http://www.chemicalize.org/) provide a nice plugin which transforms chemical names into something richer. But by harnessing the power of the web, and building on existing resources, we should be able to build a rich and full featured environment for presenting scientific knowledge.

Bibliography

I have a PhD studentship available for anyone wishing to work on using the Semantic Web and linked data to improve the process of scientific publishing.

I want to expand on the work that we have done with Kcite (http://www.russet.org.uk/blog/2012/02/kcite-spreads-its-wings/), which links between different articles, and consider how we would link to and from both raw data and ontological resources. We will do this in a practical, real-world environment: we will be extending WordPress server-side; all the tools that we generate we will be released as we go into the “wild”; we will be active at supporting users so that we can incorporate feedback. We will be targetting the academic blogosphere, in addition to working with the content on http://knowledgeblog.org.

If you are interested, please feel free to email me directly. The full details of the advert are below.

Advert

http://www.ncl.ac.uk/postgraduate/funding/search/list/cs024

The linked data initiative seeks to increase the machine computability of the web, but it is hard for authors to generate linked-data. We will investigate ways of publishing scientific knowledge where authors, readers and computational agents all gain advantage from additional semantics and machine computability. We will investigate representation of graph data and deep linking to ontological resources.

This project will feed into Knowledgeblog (http://knowledgeblog.org) which is both a high traffic (100k+ page reads) academic site in its own right, as well releasing its software for third party use by the academic blogosphere. Combined with exemplars using real data where possible, this will provide two valuable routes to evaluate and assess the representations in a real-world environment.

Value of the Award of Eligibility

Depending on how you meet the EPSRC criteria (http://www.epsrc.ac.uk/funding/students/pages/eligibility.aspx.) you may be entitled to a full or partial award. A full award covers tuition fees at the UK/EU rate and an annual stipend of £14,790 (2012/13). A partial award covers fees at the UK/EU rate only. The studentship is not available for candidates from outside of the EU.

Person Specification

You should have either a First class honours degree in Computing Science, Mathematics, or other relevant science or engineering subject, or a or 2.1 in Computing Science, Mathematics or other relevant science or engineering subject and a distinction level Masters degree in a related subject. Equivalent experience will also be considered.

How to Apply

Apply through the University’s online postgraduate application form insert the reference CS024 and select ‘PhD COMP’, with programme code 8050F, as programme of study. Mandatory fields need to be completed and a covering letter, CV and (if English is not your first language) a copy of your English language qualifications attached. The letter must state the title of studentship, quote reference CS024 and describe how your research interests fit with the topic of the research projected outlined (max. 2 pages). If you already have published research papers a list of these providing bibliographic details should be included in the letter.

You should also send your covering letter and CV to the Postgraduate Secretary at cs.pg@ncl.ac.uk.

Further Information

For further details, please contact Phillip Lord (phillip.lord@newcastle.ac.uk), 0191 222 7827

Bibliography

1 Introduction

The publishing of both data and narratives on those data are changing radically. Linked Open Data and related semantic technologies allow for semantic publishing of data. We still need, however, to publish the narratives on that data and that style of publishing is in the process of change; one of those changes is the incorporation of semantics (http://dx.doi.org/10.1109/MIS.2006.62)(http://dx.doi.org/10.1087/2009202)(http://dx.doi.org/10.1371/journal.pcbi.1000361). The idea of semantic publishing is an attractive one for those who wish to consume papers electronically; it should enhance the richness of the computational component of papers (http://dx.doi.org/10.1087/2009202). It promises a realisation of the vision of a next generation of the web, with papers becoming a critical part of a linked data environment (http://dx.doi.org/10.1109/MIS.2006.62),(http://dx.doi.org/10.4018/jswis.2009081901), where the results and naratives become one.

The reality, however, is somewhat different. There are significant barriers to the acceptance of semantic publishing as a standard mechanism for academic publishing. The web was invented around 1990 as a light-weight mechanism for publication of documents. It has subsequently had a massive impact on society in general. It has, however, barely touched most scientific publishing; while most journals have a website, the publication process still revolves around the generation of papers, moving from Microsoft Word or L^aT_eX (http://www.latex-project.org), through to a final PDF which looks, feels and is something designed to be printed onto paper (this includes conferences dedicated to the web and the use of web technologies). Adding semantics into this environment is difficult or impossible; the content of the PDF has to be exposed and semantic content retro-fitted or, in all likelihood, a complex process of author and publisher interaction has to be devised and followed. If semantic data publishing and semantic publishing of academic narratives are to work together, then academic publishing needs to change.

In this paper, we describe our attempts to take a commodity publication environment, and modify it to bring in some of the formality required from academic publishing. We illustrate this with three exemplars—different kinds of knowledge that we wish to enhance. In the process, we add a small amount of semantics to the finished articles. Our key constraint is the desire to add value for all the human participants. Both authors and readers should see and recognise additional value, with the semantics a useful or necessary byproduct of the process, rather than the primary motivation. We characterise this process as our “three steps to heaven”, namely:

• make life better for the machine to

• make life better for the author to

• make life better for the reader

While requiring additional value for all of these participants is hard, and places significant limitations on the level of semantics that can be achieved, we believe that it does increase the likelihood that content will be generated in the first place, and represents an attempt to enable semantic publishing in a real-world workflow.

2 Knowledgeblog

The knowledgeblog project stemmed from the desire for a book describing the many aspects of ontology development, from the underlying formal semantics, to the practical technology layer and, finally, through to the knowledge domain (http://www.russet.org.uk/blog/2011/06/ontogenesis-knowledgeblog-lightweight-semantic-publishing/). However, we have found the traditional book publishing process frustrating and unrewarding. While scientific authoring is difficult in its own right, our own experience suggests that the publishing process is extremely hard-work. This is particularly so for multi-author collected works which are often harder for the editor than writing a book “solo”. Finally, the expense and hard copy nature of academic books means that, again in our experience, few people read them.

This contrasts starkly with the web-first publication process that has become known as blogging. With any of a number of ready made platforms, it is possible for authors with little or no technical skill, to publish content to the web with ease. For knowledgeblog (“kblog”), we have taken one blogging engine, WordPress (http://www.wordpress.org), running on low-end hardware, and used it to develop a multi-author resource describing the use of ontologies in the life sciences (our main field of expertise). There are also kblogs on bioinformatics (http://bioinformatics.knowledgeblog.org) and the Taverna workflow environment (http://taverna.knowledgeblog.org)(http://dx.doi.org/10.1093/nar/gkl320). We have previously described how we addressed some of the social aspects, including attribution, reviewing and immutablity of articles (http://www.russet.org.uk/blog/2011/06/ontogenesis-knowledgeblog-lightweight-semantic-publishing/)

As well as delivering content, we are also using this framework to investigate semantic academic publishing, investigating how we can enhance the machine interpretability of the final paper, while living within the key constraint of making life (slightly) better for machine, author and reader without adding complexity for the human participants.

Scientific authors are relatively conservative. Most of them have well-established toolsets and workflows which they are relatively unwilling to change. For instance, within the kblog project, we have used workshops to start the process of content generation. For our initial meeting, we gave little guidance on authoring process to authors, as a result of which most attempted to use WordPress directly for authoring. The WordPress editing environment is, however, web-based, and was originally designed for editing short, non-technical articles. It appeared to not work well for most scientists.

The requirements that authors have for such ‘scientific’ articles are manifold. Many wish to be able to author while offline (particularly on trains or planes). Almost all scientific papers are multi-author, and some degree of collaboration is required. Many scientists in the life sciences wish to author in Word because grant bodies and journals often produce templates as Word documents. Many wish to use L^aT_eX, because its idiomatic approach to programming documents is unreplicable with anything else. Fortunately, it is possible to induce WordPress to accept content from many different authoring tools, including Word and L^aT_eX (http://www.russet.org.uk/blog/2011/06/ontogenesis-knowledgeblog-lightweight-semantic-publishing/)

As a result, during the kblog project, we have seem many different workflows in use, often highly idiosyncratic in nature. These include:

Word/Email:

Many authors write using MS Word and collaborate by emailing files around. This method has a low barrier to entry, but requires significant social processes to prevent conflicting versions, particularly as the number of authors increases.

Word/Dropbox:

For the taverna kblog (http://taverna.knowledgeblog.org), authors wrote in Word and collaborated with Dropbox (http://www.dropbox.com). This method works reasonably well where many authors are involved; Dropbox detects conflicts, although it cannot prevent or merge them.

Asciidoc/Dropbox:

Used by the authors of this paper. Asciidoc (http://www.methods.co.nz/asciidoc) is relatively simple, somewhat programmable and accessible. Unlike L^aT_eX which can be induced to produce HTML with effort, asciidoc is designed to do so.

Of these three approaches probably the Word/Dropbox combination is the the most generally used.

From the readers perspective, a decision that we have made within knowledgeblog is to be “HTML-first”. The initial reasons for this were entirely practical; supporting multiple toolsets is hard, particularly if any degree of consistency is to be maintained; the generation of the HTML is at least partly controlled by the middleware – WordPress in kblog’s case. As well as enabling consistency of presentation, it also, potentially, allows us to add additional knowledge; it makes semantic publication a possibility. However, we are aware that knowledgeblog currently scores rather badly on what we describe as the “bath-tub test”; while exporting to PDF or printing out is possible, the presentation is not as “neat” as would be ideal. In this regard (and we hope only in this regard), the knowledgeblog experience is limited. However, increasingly, readers are happy and capable of interacting with material on the web, without print outs.

From this background and aim, we have drawn the following requirements:

1. The author can, as much as possible, remain within familiar authoring environments;

2. The representation of the published work should remain extensible to, for instance, semantic enhancements;

3. The author and reader should be able to have the amount of “formal” academic publishing they need;

4. Support for semantic publishing should be gradual and offer advantages for author and reader at all stages.

We describe how we have achieved this with three exemplars, two of which are relatively general in use, and one more specific to biology. In each case, we have taken a slightly different approach, but have fulfilled our primary aim of making life better for machine, author and reader.

3 Representing Mathematics

The representation of mathematics is a common need in academic literature. Mathematical notation has grown from a requirement for a syntax which is highly expressive and relatively easy to write. It presents specific challenges because of its complexity, the difficulty of authoring and the difficulty of rendering, away from the chalk board that is its natural home.

Support for mathematics has had a significant impact on academic publishing. It was, for example, the original motivation behind the development of T_eX (http://en.wikipedia.org/wiki/TeX), and it still one of the main reasons why authors wish to use it or its derivatives. This is to such an extent that much mathematics rendering on the web is driven by a T_eX engine somewhere in the process. So MediaWiki (and therefore Wikipedia), Drupal and, of course, WordPress follow this route. The latter provides plugin support for T_eX markup using the wp-latex plugin (http://wordpress.org/extend/plugins/wp-latex/). Within kblog, we have developed a new plugin called mathjax-latex (http://wordpress.org/extend/plugins/mathjax-latex/) From the kblogauthor’s perspective these two offer a similar interface – differences are, therefore, described later.

Authors write their mathematics directly as T_eX using one of the four markup syntaxes. The most explicit (and therefore least likely to happen accidentally) is through the use of “shortcodes” (http://codex.wordpress.org/Shortcode).

These are a HTML-like markup originating from some forum/bulletin board systems. In this form an equation would be entered as [latex]e=mc^2[/latex], which would be rendered as “\(e=mc^2\)”. It is also possible to use three other syntaxes which are closer to math-mode in T_eX: $‍$e=mc^2$‍$, $latex e=mc^2$, or \‍[e=mc^2\‍].

From the authorial perspective, we have added significant value, as it is possible to use a variety of syntaxes, which are independent of the authoring engine. For example, a T_eX-loving mathematician working with a Word-using biologist can still set their equations using T_eX syntax; although Word will not render these at authoring time but, in practice, this causes few problems for such authors, who are experienced at reading T_eX. Within an L^aT_eX workflow equations will be renderable both locally with source compiled to PDF, and published to WordPress.

There is also a W3C recommendation, MathML for the representation and presentation of mathematics. The kblog environment also supports this. In this case, the equivalent source appears as follows:

 <math>
 <mrow>
<mi>E</mi>
 <mo>=</mo>
 <mrow>
<mi>m</mi>
 <msup>
 <mi>c</mi>
<mn>2</mn>
 </msup>
 </mrow>
 </mrow>
</math>

One problem with the MathML representation is obvious: it is very long-winded. A second issue, however, is that it is hard to integrate with existing workflows; most of the publication workflows we have seen in use will on recognising an angle bracket turn it into the equivalent HTML entity. For some workflows (L^aT_eX, asciidoc) it is possible, although not easy, to prevent this within the native syntax.

It is also possible to convert from Word’s native OMML (“equation editor”) XML representation to MathML, although this does not integrate with Word’s native blog publication workflow. Ironically, it is because MathML shares an XML based syntax with the final presentation format (HTML) that the problem arises. The shortcode syntax, for example, passes straight-through most of the publication frameworks to be consumed by the middleware. From a pragmatic point of view, therefore, supporting shortcodes and T_eX-like syntaxes has considerable advantages.

For the reader, the use of mathjax-latex has significant advantages. The default mechanism within WordPress uses a math-mode like syntax $‍latex e=mc^2‍$. This is rendered using a T_eX engine into an image which is then incorporated and linked using normal HTML capabilities. This representation is opaque and non-semantic; it has significant limitations for the reader. The images are not scalable – zooming in cases severe pixalation; the background to the mathematics is coloured inside the image, so does not necessarily reflect the local style.

Kblog, however, uses the MathJax library (http://www.mathjax.org) this has a number of significant advantages for the reader. First, where the browser supports them, MathJax uses webfonts to render the images; these are scalable, attractive and standardized. Where they are not available, MathJax can fall-back to bitmapped fonts. The reader can also access additional functionality: clicking on an equation will raise a zoomed in popup; while the context menu allows access to a textual representation either as T_eX or MathML irrespective of the form that the author used. This can be cut-and-paste for further use. Kblog uses the MathJax library (http://www.mathjax.org) to render the underlying T_eX directly on the client.

Our use of MathJax provides no significant disadvantages to the middleware layers. It is implemented in JavaScript and runs in most environments. Although, the library is fairly large (>100Mb), but is available on a CDN so need not stress server storage space. Most of this space comes from the bit-mapped fonts which are only downloaded on-demand, so should not stress web clients either. It also obviates the need for a T_eX installation which wp-latex may require (although this plugin can use an external server also).

At face value, mathjax-latex necessarily adds very little semantics to the maths embedded within documents. The maths could be represented as $‍$E=mc^2$‍$, \‍(E=mc^2\‍) or

<math> <mrow> <mi>E</mi> <mo>=</mo>
<mrow> <mi>m</mi>
 <msup>
<mi>c</mi><mn>2</mn> </msup>
 </mrow>
</mrow> </math>

So, we have a heterogenous representation for identical knowledge. However, in practice, the situation is much better than this. The author of the work created these equations and has then read them, transformed by MathJax into a rendered form. If MathJax has failed to translate them correctly, in line with the author’s intention, or if it has had some implications for the text in addition to setting the intended equations (if the T_eX style markup appears accidentally elsewhere in the document), the author is likely to have seen this and fixed the problem. Someone wishing, for example, to extract all the mathematics as MathML from these documents computationally, therefore, knows:

• that the document contains maths as it imports MathJax

• that MathJax is capable of identifying this maths correctly

• that equations can be transformed to MathML using MathJax (This is assuming MathJax works correctly in general. The authors and readers are checking the rendered representation. It is possible that an equation would render correctly on screen, but be rendered to MathML inaccurately).

So, while our publication environment does not result directly in lower level of semantic heterogeneity, it does provide the data and the tools to enable the computational agent to make this transformation. While this is imperfect, it should help a bit. In short, we provide a practical mechanism to identify text containing mathematics and a mechanism to transform this to a single, standardised representation.

4 Representing References

Unlike mathematics, there is no standard mechanism for reference and in-text citation, but there are a large number of tools for authors such as BibTeX, Mendeley (http://www.mendeley.org) or EndNote. As a result of this, the integration with existing toolsets is of primary importance, while the representation of the in-text citations is not, as it should be handled by the tool layer anyway.

Within kblog, we have developed a plugin called kcite (http://wordpress.org/extend/plugins/kcite/). For the author, citations are inserted using the syntax:[‍cite]10.1371/journal.pone.0012258[‍/cite]. The identifier used here is a DOI, or digital object identifier and, is widely used within the publishing and library industry. Currently, kcite supports DOIs minted by either CrossRef (http://www.crossref.org) or DataCite (http://www.datacite.org) (in practice, this means that we support the majority of DOIs). We also support identifiers from PubMed (http://www.pubmed.org) which covers most biomedical publications and arXiv (http://www.arxiv.org), the physics (and other domains!) preprints archive, and we now have a system to support arbitrary URLs. Currently, authors are required to select the identifier where it is not a DOI.

We have picked this “shortcode” format for similar reasons as described for maths; it is relatively unambiguous, it is not XML based, so passes through the HTML generation layer of most authoring tools unchanged and is explicitly supported in WordPress, bypassing the need for regular expressions and later parsing. It would, however, be a little unwieldy from the perspective of the author. In practice, however, it is relatively easy to integrate this with many reference managers. For example, tools such as Zotero (http://www.zotero.org) and Mendeley use the Citation Style Language, and so can output kcite compliant citations with the following slightly elided code:

 <citation>
    <layout prefix="[‍cite]" suffix="[‍/cite]"
         delimiter="[‍/cite] [‍cite]">
      <text variable="DOI"/>
    </layout>
  </citation>

We do not yet support L^aT_eX/BibTeX citations, although we see no reason why a similar style file should not be supported (citations in this representation of the article were, rather painfully, converted by hand). We do, however, support BibTeX-formatted files: the first author’s preferred editing/citation environment is based around these with Emacs, RefTeX, and asciidoc. While this is undoubtedly a rather niche authoring environment, the (slightly elided) code for supporting this demonstrates the relative ease with which tool chains can be induced to support kcite:

(defadvice reftex-format-citation (around phil-asciidoc-around activate)
  (if phil-reftex-citation-override
      (setq ad-return-value (phil-reftex-format-citation entry format))
    ad-do-it))

(defun phil-reftex-format-citation( entry format )
  (let ((doi (reftex-get-bib-field "doi" entry)))
    (format "pass:[‍[‍cite source='doi'\\]%s[‍/cite\\]]" doi)))

The key decision with kcite from the authorial perspective is to ignore the reference list itself and focus only on in-text citations, using public identifiers to references. This simplifies the tool integration process enormously, as this is the only data that needs to pass from the author’s bibliographic database onward. The key advantage for authors here is two-fold: they are not required to populate their reference metadata for themselves, and this metadata will update if it changes. Secondly, the identifiers are checked; if they are wrong, the authors will see this straightforwardly as the entire reference will be wrong. Adding DOIs or other identifiers moves from becoming a burden for the author to becoming a specific advantage.

While supporting multiple forms of reference identifier (CrossRef DOI, DataCite DOI, arXiv and PubMed ID) provides a clear advantage to the author, it comes at considerable cost. While it is possible to get metadata about papers from all of these sources, there is little commonality between them. Moreover, resolving this metadata requires one outgoing HTTP request per reference (in practice, it is often more; DOI requests, for instance use 303 redirects), which browser security might or might not allow.

So, while the presentation of mathematics is performed largely on the client, for reference lists the kcite plugin performs metadata resolution and data integration on the server. A caching functionality is provided, storing this metadata in the WordPress database. The bibliographic metadata is finally transferred to the client encoded as JSON, using asynchronous call-backs to the server.

Finally, this JSON is rendered using the citeproc-js library on the client. In our experience, this performs well, adding to the readers’ experience; in-text citations are initially shown as hyperlinks; rendering is rapid, even on aging hardware, and finally in-text citations are linked both to the bibliography and directly through to the external source. Currently, the format of the reference list is fixed, however, citeproc-js is a generalised reference processor, driven using CSL (http://citationstyles.org/). This makes it straight-forward to change citation format, at the option of the reader, rather than the author or publisher. Both the in-text citation and bibliography support outgoing links direct to the underlying resources (where the identifier allows — PubMed IDs redirect to PubMed). As these links have been used to gather metadata, they are likely to be correct. While these advantages are relatively small currently, we believe that the use of JavaScript rendering over a linked references can be used to add further reader value in future.

For the computational agent wishing to consume bibliographic information, we have added significant value compared to the pre-formatted HTML reference list. First, all the information required to render the citation is present in the in-text citation next to the text that the authors intended. A computational agent can, therefore, ignore the bibliography list itself entirely. These primary identifiers are, again, likely to be correct because the authors now need them to be correct for their own benefit.

Should the computational agent wish, the (denormalised) bibliographic data used to render the bibliography is actually available, present in the underlying HTML as a JSON string. This is represented in a homogeneous format, although, of course, represents our (kcite’s) interpretation of the primary data.

A final, and subtle, advantage of kcite is that the authors can only use public metadata, and not their own. If they use the correct primary identifier, and still get an incorrect reference, it follows that the public metadata must be incorrect (or, we acknowledge, that kcite is broken!). Authors and readers therefore must ask the metadata providers to fix their metadata to the benefit of all. This form of data linking, therefore, can even help those who are not using it.

4.1 Microarray Data

Many publications require that papers discussing microarray experiments lodge their data in a publically available resource such as ArrayExpress (http://dx.doi.org/10.1093/nar/gkg091). Authors do this placing an ArrayExpress identifier which has the form E-MEXP-1551. Currently, adding this identifier to a publication, as with adding the raw data to the repository is no direct advantage to the author, other than fulfilment of the publication requirement. Similarly, there is no existing support within most authoring environments for adding this form of reference.

For the knowledgeblog-arrayexpress plugin (http://knowledgeblog.org/knowledgeblog-arrayexpress), therefore, we have again used a shortcode representation, but allowed the author to automatically fill metadata, direct from ArrayExpress. So a tag such as:[‍aexp id="E-MEXP-1551"]species[‍/aexp] will be replaced with Saccharomyces cerevisiae, while:[‍aexp id="E-MEXP-1551"]releasedate[‍/aexp] will be replaced by “2010-02-24”. While the advantage here is small, it is significant. Hyperlinks to ArrayExpress are automatic, authors no longer need to look up detailed metadata. For metadata which authors are likely to know anyway (such as Species), the automatic lookup operates as a check that their ArrayExpress ID is correct. As with references (see Section ), the use of an identifier becomes an advantage rather than a burden to the authors.

Currently, for the reader there is less significant advantage at the moment. While there is some value to the author of the added correctness stemming from the ArrayExpress identifier. However, knowledgeblog-arrayexpress is currently under-developed, and the added semantics that is now present could be used more extensively. The unambiguous knowledge that:[‍aexp id="E-MEXP-1551"]species[‍/aexp] represents a species would allow us, for example, to link to the NCBI taxonomy database (http://www.ncbi.nlm.nih.gov/Taxonomy/).

Likewise, advantage for the computational agent from knowledgeblog­-array­express is currently limited; the identifiers are clearly marked up, and as the authors now care about them, they are likely to be correct. Again, however, knowledgeblog­-array­express is currently under developed for the computational agent. The knowledge that is extracted from ArrayExpress could be presented within the HTML generated by knowledgeblog­-array­express, whether or not it is displayed to the reader for, essentially no cost. By having an underlying shortcode representation, if we choose to add this functionality to knowledgeblog­-array­express, any posts written using it would automatically update their HTML. For the text-mining bioinformatician, even the ability to unambiguously determine that a paper described or used a data set relating to a specific species using standardised nomenclature (the standard nomenclature was only invented in 1753 and is still not used universally) would be a considerable boon.

5 Discussion

Our approach to semantic enrichment of articles is a measured and evolutionary approach. We are investigating how we can increase the amount of knowledge in academic articles presented in a computationally accessible form. However, we are doing so in an environment which does not require all the different aspects of authoring and publishing to be over-turned. More over, we have followed a strong principle of semantic enhancement which offers advantages to both reader and author immediately. So, adding references as a DOI, or other identifier, ‘automagically’ produces an in text citation and a nicely formatted reference list: that the reference list is no longer present in the article, but is a visualisation over linked data; that the article itself has become a first class citizen of this linked data environment is a happy by-product.

This approach, however, also has disadvantages. There are a number of semantic enhancements which we could make straight-forwardly to the knowledgeblog environment that we have not; the principles that we have adopted requires significant compromise. We offer here two examples.

First, there has been significant work by others on CiTO (http://dx.doi.org/10.1186/2041-1480-1-S1-S6) – an ontology which helps to describe the relationship between the citations and a paper. Kcite lays the ground-work for an easy and straight-forward addition of CiTO tags surrounding each in-text citation. Doing so, would enable increased machine understandability of a reference list. Potentially, we could use this to the advantage to the reader also: we could distinguish between reviews and primary research papers; highlight the authors’ previous work; emphasise older papers which are being refuted. However, to do this requires additional semantics from the author. Although these CiTO semantic enhancements would be easy to insert directly using the shortcode syntax, most authors will want to use their existing reference manager which will not support this form of semantics; even if it does, the author themselves gain little advantage from adding these semantics. There are advantages for the reader, but in this case not for both author and reader. As a result, we will probably add such support to kcite; but, if we are honest, find it unlikely that when acting as content authors, we will find the time to add this additional semantics.

Second, our presentation of mathematics could be modified to automatically generate MathML from any included T_eX markup. The transformation could be performed on the server, using MathJax; MathML would still be rendered on the client to webfonts. This would mean that any embedded maths would be discoverable because of the existence of MathML, which is a considerable advantage. However, neither the reader nor the author gain any advantage from doing this, while paying the cost of the slower load times and higher server load that would result from running JavaScript on the server. More over, they would pay this cost regardless of whether their content were actually being consumed computationally. As the situation now stands, the computational user needs to identify the insert of MathJax into the web page, and then transform the page using this library, none of which is standard. This is clearly a serious compromise, but we feel a necessary one.

Our support for microarrays offers the possibility of the most specific and increased level of semantics of all of our plugins. Knowledge about a species or a microarray experimental design can be precisely represented. However, almost by definition, this form of knowledge is fairly niche and only likely to be of relevance to a small community. However, we do note that the knowledgeblog process based around commodity technology does offer a publishing process that can be adapted, extended and specialised in this way relatively easily. Ultimately the many small communities that make up the long-tail of scientific publishing adds up to one large one.

6 Conclusion

Semantic publishing is a desirable goal, but goals need to be realistic and achievable. to move towards semantic publishing in kblog, we have tried to put in place an approach that gives benefit to readers, authors and computational interpretation. As a result, at this stage, we have light semantic publishing, but with small, but definite benefits for all.

Semantics give meaning to entities. In kblog, we have sought benefit by “saying” within the kblog environment that entity x is either maths, a citation or a microarray data entity reference. This is sufficient for the kbloginfra-structure to “know what to do” with the entity in question. Knowing that some publishable entity is a “lump” of maths tells the infra-structure how to handle that entity: the reader has benefit from it looking like maths; the author has benefit by not having to do very much; and the infra-structure knows what to do. In addition, this approach leaves in hooks for doing more later.

It is not necessarily easy to find compelling examples that give advantages for all steps. Adding in CiTO attributes to citations, for instance, has obvious advantages for the reader, but not the author. However, advantages may be indirect; richer reader semantics may give more readers and thus more citations—the thing authors appreciate as much as the act of publishing itself. It is, however, difficult to imagine how such advantages can be conveyed to the author at the point of writing. It is easy to see the advantages of semantic publishing for readers, as a community we need to pay attention to advantages to the authors. Without these “carrots”, we will only have “sticks” and authors, particularly technically skilled ones, are highly adept at working around sticks.

Bibliography

In my previous articles, I have talked about general problems with DOIs (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/), about architectural issues with capturing metadata (http://www.russet.org.uk/blog/2012/03/dois-and-content-negotiation/), and finally, about specific problem DOIs (http://www.russet.org.uk/blog/2012/03/a-problem-doi).

I have also described part of the difficulty is that it is hard to determine the registration agency associated with a specific DOI — there are actually different kinds of DOI and they respond in different ways.

I have, however, finally found a way to discover who is a responsible for a given DOI. One of my own papers (http://www.jbiomedsem.com/content/1/S1/S7) declares its DOI to be 10.1186/2041-1480-1-S1-S7. Unfortunately, refering to this paper using Kcite (http://www.russet.org.uk/blog/2012/02/kcite-spreads-its-wings/) shows, at the time of writing, an error message (http://dx.doi.org/10.1186/2041-1480-1-S1-S7), nor does the DOI resolve. As this may later be fixed, the error message looks like this:

The DOI you requested --

10.1186/2041-1480-1-S1-S7

-- cannot be found in the Handle System.

Possible reasons for the error are:

    the DOI has not been created
    the DOI is cited incorrectly in your source
    the DOI does not resolve due to a system problem

On filling in the “this DOI does not work” form, the error page redirects to, the another URL at http://notfound.doi.org/DoiError/servlet, which says:

The DOI and comments (if provided) have been logged by CrossRef and forwarded
to the publisher to correct the problem. Possible reasons for the error are:

    the DOI has been created but has not been registered by the publisher
    (this could be an error or it could be a timing issue and the DOI will be
    registered in the next few days)
    the DOI is cited incorrectly in the source
    the DOI does not resolve due to a system problem

Maintaining the integrity of DOIs is very important to CrossRef and we
appreciate your help.

Which suggests to me clear this DOI (should have) been registered with CrossRef. Unfortunately, this only works with DOIs that do not resolve in the first place. Directly accessing the link returns “nothing to see here”.

A little bit of poking around, and I have discovered a few other problematic DOIs, all from the same “special issue”.

• (http://dx.doi.org/10.1186/2041-1480-1-S1-S1)
• (http://dx.doi.org/10.1186/2041-1480-1-S1-S2)
• (http://dx.doi.org/10.1186/2041-1480-1-S1-S4)
• (http://dx.doi.org/10.1186/2041-1480-1-S1-S5)

I might take this personally, as this includes another paper of mine, although, strangely, two of the DOIs from the same issue do work which also includes one of mine.

• (http://dx.doi.org/10.1186/2041-1480-1-S1-S3)
• (http://dx.doi.org/10.1186/2041-1480-1-S1-S6)

All of this demonstrates an advantage of our Kcite tool (http://knowledgeblog.org/kcite-plugin). By actually using primary identifers as part of the authoring process, I have discovered five DOIs, several of which have been on my website for a long time, that are broken. Possibly, the Journal of Biomedical Semantics should take a leaf out of my book. From their web page:

Journal of Biomedical Semantics 2010, 1(Suppl 1):S7 doi:10.1186/2041-1480-1-S1-S7

The electronic version of this article is the complete one and can be found
online at: http://www.jbiomedsem.com/content/1/S1/S7

At the time of writing, the DOI is not displayed as http://dx.doi.org/10.1186/2041-1480-1-S1-S7, although this is a hard requirement from CrossRefs display guidelines (http://www.crossref.org/02publishers/doi_display_guidelines.html). Ironically, CrossRef says “CrossRef DOIs should always be displayed as permanent URLs in the online environment.” This seems to miss the requirement that, in the online environment, DOIs should be hyperlinked, so the Journal of Biomedical Semantics cannot be faulted there. It is a shame, though. If they were hyperlinked by now a web crawler would have discovered the 404.

Update (14/05/2012)

Since I wrote this post, three out of four of the errorneous DOIs that I reported have been fixed. One of them (http://dx.doi.org/10.1186/2041-1480-1-S1-S2) is still broken. As I am using kcite to refer to these DOIs, the references have now automatically updated.

Bibliography

In this article, I consider the problems of semantics-free identifiers in OWL and suggest another (possible) solution to the problem.

The problems of identifiers and their semantics are not new. I have written about these problems previously in the context of: blog permalinks (http://www.russet.org.uk/blog/2011/05/permalink-semantics/); and with conversion between OBO format and Manchester syntax (http://www.russet.org.uk/blog/2009/09/obo-format-and-manchester-syntax/). The basic issue is one of choosing your compromise. Identifiers with semantics in them (which this blog uses although I wish it did not) are considerably more human readable, but are not resiliant to change, as the semantics in the identifiers can become out of date with respect to the content they describe. But neither compromise is entirely satisfactory; we need a more pragmatic approach (http://robertdavidstevens.wordpress.com/2011/05/26/unicorns-in-my-ontology).

Recently, I was looking at the move of the OBI ontology (http://dx.doi.org/10.1186/2041-1480-1-S1-S7) from BFO 1.0 to BFO 2.0. I have commented extensively on BFO before (http://dx.doi.org/10.1371/journal.pone.0012258), (http://www.russet.org.uk/blog/2010/07/realism-and-science/) (http://www.russet.org.uk/blog/2010/09/the-status-quo-farewell-tour-on-realism/), and I was interested in what changes have been made for BFO 2.0.

Unfortunately, it is not that easy to work out. While diffs have never been the most human readable of output, the OBI diffs raise this to a new level Consider this change:

svn diff -r 3424:3425 https://obi.svn.sourceforge.net/svnroot/obi/trunk/src/ontology/branches/obi.owl

@@ -204,7 +197,7 @@
     <owl:ObjectProperty rdf:about="http://purl.obolibrary.org/obo/OBI_0000107">
         <rdfs:label>provides_service_consumer_with</rdfs:label>
         <rdfs:domain rdf:resource="http://purl.obolibrary.org/obo/OBI_0001173"/>
-        <rdfs:subPropertyOf rdf:resource="http://www.obofoundry.org/ro/ro.owl#has_part"/>
+        <rdfs:subPropertyOf rdf:resource="http://purl.obolibrary.org/obo/BFO_0000051"/>
     </owl:ObjectProperty>

Also available here for those without access to a local subversion. The resource previously known as has_part has become the rather more obscure BFO_OOOOO51. In short, BFO has become semantics-free.

In general, I think that this is a good thing. The use of semantics in the identifiers for this blog is generally not helpful, although I have never carried through my year-old threat (http://www.russet.org.uk/blog/2011/05/permalink-semantics/) to change the identifier scheme as I am not sure older links will be maintained. But the total unreadability of the OBI diff demonstrates a problem. One answer is that we should not be reading OWL source in the first place, but using tools. These tools exist (http://www.ebi.ac.uk/efo/bubastis/), in fact, but they are not a replacement for a diff, but a supplement to it. Source code must be in a readable syntax because line-orientated syntax is the lowest common denominator; semantic diffs are nice, but next we would need an OWL aware versioning tool, as versioning depends on diffing. Then OWL aware regexp search and replace tools for when syntactic alterations were needed. Eventually, we would end up replacing an entire software stack and, no doubt, doing it badly, since tools such as versioning software have a long heritage and are now very functional (and incredibly complex!).

My previous, minimal suggestion was to use a denormalisation, by adding a new comment character. So

ObjectProperty http://purl.obolibrary.org/obo/BFO_0000051

would become

ObjectProperty http://purl.obolibrary.org/obo/BFO_0000051[has_part]

The denormalisation here — presenting the same information as an opaque string and as a text string, fulfils both requirements. However it would require significant effort to keep the two in sync.

My new idea would be to use a similar idea to a Colour Lookup Table (http://en.wikipedia.org/wiki/Colour_look-up_table). These are used to define a palette of colours selected from a much larger colour space. We could use a similar approach here. Essentially the idea is to put semantics free IDs at the top of the file, then meaningful ones in the middle. The idea is also similar to the use of abbreviations for namespaces in XML; for instance,

<owl:ObjectProperty rdf:about="http://purl.obolibrary.org/obo/OBI_0000107">

the rdf: prefix actually refers to “http://www.w3.org/1999/02/22-rdf-syntax-ns#”. The letters rdf could be replaced by anything at all, so long as we update the namespace declaration without changing semantics.

In Manchester syntax, we could address this with an addition of an alias keyword. So:

ObjectProperty http://purl.obolibrary.org/obo/OBI_0000107
   Annotations: rdfs:label="provides_service_consumer_with"
   Domain: http://purl.obolibrary.org/obo/OBI_0001173
   SubPropertyOf: http://purl.obolibrary.org/obo/BFO_0000051

would become

Prefix: obo: http://purl.obolibrary.org/obo/
Alias: obo:OBI_0000107 "provides_service_consumer_with"
Alias: obo:OBI_0001173 "service"
Alias: obo:BFO_0000051 "has_part"

ObjectProperty provides_service_consumer_with
   Annotations: rdfs:label="provides_service_consumer_with"
   Domain: service
   SubPropertyOf: has_part

In this case, because we are defining a term and attaching a label we get the same string twice, but there is no formal link between the two. With this system in place, moving the identifiers for BFO would have required an update to only the Alias table at the top. Now an obvious place for the strings to come from would be the source ontology (so “has_part” would come from RO (http://dx.doi.org/10.1186/gb-2005-6-5-r46), or now BFO); this would, in fact, serve as a useful check. If I reference an external ontology and it’s labels do not match with my Alias definitions, I may wish to check to see whether the concepts I have imported still have the semantics that I intended.

The same approach could be directly translated into the XML representation without change, I believe, with the use of XML entities which are defined at the start of an XML document. Of course, this is entirely horrible, and changing the OWL schema would make more sense. Extending Manchester syntax is straight-forward as I think I have shown here. Likewise, for OBO format. And the practical upshot would be a significant increase in the readability of many ontologies without eschewing the good practice of semantics free identifiers.

Bibliography

Previously, I described the additions that we have made to the kcite plugin (http://www.russet.org.uk/blog/2012/02/kcite-spreads-its-wings/), which now supports multiple different types of identifiers. This includes the subset of DOIs (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/) that come from either CrossRef (http://www.crossref.org) or DataCite (http://www.datacite.org), arXiv (http://arxiv.org/) or Pubmed (http://www.ncbi.nlm.nih.gov/pubmed/). However, rather embarrasingly, one of the identifiers that we do not support well are URLs. Slightly ironic as one of the purposes behind (http://www.russet.org.uk/blog/2011/06/ontogenesis-knowledgeblog-lightweight-semantic-publishing/) is to demonstrate that it is possible to replicate the publication experience using the web.

The main reason for this is the lack of an active source of metadata. The various identifiers that we have supported all come with a standardised source of metadata, which is not so straightforward with a generic URL. This is one of the reasons for my new plugin, kblog-metadata (http://wordpress.org/extend/plugins/kblog-metadata/). This currently consists of three pieces of functionality: kblog-headers, kblog-authors and kblog-table-of-contents.

For a long time now, I have added COinS metadata (http://ocoins.info/) to both this blog and kblog (http://www.knowledgeblog.org/). But, from my perspective, COinS is a dreadful specification. It involves embedding a NISO 1.0 Context Object (http://www.niso.org/standards/standard_detail.cfm?std_id=783) into a span tag. The reference here is from the COinS specification (http://ocoins.info/), but is, unfortunately 404 at the time of writing. It uses a URL encoded query string — in short, a microsyntax inside HTML which needs it’s own independent parsing. Key strings are confusing at best (rft_val_fmt and rft.auinit for example — why both underscores and dots?). And there is a degree of randomness about things: first authors can be split into first name, last name, initials, while subsequent authors cannot. More over, I could not find a processor to test whether my COinS implementation was actually correct. I wanted something that was a bit easier, and also in wider use. So, while we still use COinS metadata, we have now also added meta tags as recommended by Google Scholar (http://scholar.google.com/intl/en/scholar/inclusion.html); ironically, on a page with, as far as I can see, no meta tags at all. Finally, we also have Open Graph Protocol (http://ogp.me/). Fortunately their website does use their own advice. Kblog-headers includes all of these formats, as can now be seen on this page.

Since the inception of Kblog, one of the difficulties we have had is with multiple authors. When adding metadata, for instance, we need to ensure that all the authors are represented. We have used plugins such as co-authors-plus (http://wordpress.org/extend/plugins/co-authors-plus/) to enable multi-author work. However, these plugins come with a lot of extra baggage, namely the requirement for all authors to have a WordPress login (either WordPress.com, or on the local installation). Essentially, aside from the first workshop (http://www.russet.org.uk/blog/2010/01/the-ontogenesis-tutorial/), we have never seen anyone collaboratively edit documents on WordPress. Where multiple authors have worked together (which we have seen a lot) they have done so using Word, LaTeX, Google docs or asciidoc, collaborating with DropBox or email. Only the communicating author needs an account. The problem was accentuated with sites like Bio-Ontologies, where all of the articles were posted by either myself or Simon Cockell (http://blog.fuzzierlogic.com/), but were authored by neither. From my perspective, we need the ability to separate these two roles — posting and authoring. Kblog-authors achieves precisely this. New authors can be added either using short codes within the document content, or through the WordPress edit page (the GUI is a little primitive, but functional). These authors do not need WordPress accounts, with the posting account being used if no authors are explicitly given.

Finally, I have rewritten kblog-table-of-contents, and am combining it with kblog-metadata. This provides a new shortcode [kblogtoc] which can be used to embed a table of contents showing all posts — ideal for searching over. For more computational use it is also possible to get a line separate text file (http://www.russet.org.uk/blog/?kblog-toc=txt) or approximately the same thing as HTML (http://www.russet.org.uk/blog/?kblog-toc=html), which can be cut and paste without having to view source. A more readable and searchable form can be seen embedded in a normal WordPress page (http://www.russet.org.uk/blog/table-of-contents/). This has also enabled us to finally fix the Bio-Ontologies contents page (http://bio-ontologies.knowledgeblog.org/table-of-contents) which now shows the correct authors, with all of the posts advertising their authorship.

All three of these plugins require further work. At the moment, they provide better metadata, but they do not give the author and reader enough utility to encourage people to install them, of which more in the future. Despite this, however, I think they are already proving useful, and should help to solve a long standing problem that we have had within WordPress for an academic environment.

Erratum

2012-05-09: Corrected typographical error which meant the kblogtoc shortcode was displaying incorrectly.

Bibliography

In my previous article, I discussed my ongoing struggles with DOIs and their metadata (http://www.russet.org.uk/blog/2012/03/dois-and-content-negotiation/). The article discussed the difficulties with implementing content negotiation for kcite (http://knowledgeblog.org/kcite-plugin); in particular, getting metadata for a given DOI and understanding that metadata once it had been fetched. Here, I discuss these two issues again!

Accessing the Metadata

I have previously described the implementation of Content Negotiation for DOIs in Kcite. In the examples given, I used libcurl which has the flexibility to perform content negotiation. One difficulty with this approch is that libcurl is not a standard requirement for WordPress at least on Ubuntu. So, adding this requirement, forces users to make an additional step when installing the plugin.

Following on from the previous article, I have decided to update all of the resolution mechanisms in Kcite to use libcurl, as it made little sense to have several different mechanisms in place. Ironically, in the process, I found that the direct use of libcurl was unnecessary anyway. The reason for this is that WordPress has its own HTTP API (http://codex.wordpress.org/HTTP_API), and it is possible to use this instead of libcurl. Underneath, it uses one of several transport mechanisms, including libcurl which is probably the fastest, but also pure PHP solutions which make life a bit easier.

Most of my criticisms of content negotiation, however, still remain. Unlike libcurl WordPress’ API automatically follows 303 See Also redirect messages which http://dx.doi.org returns. However, content negotiation is not directly supported, so I still need to set the HTTP headers manually. The format of these did not appear to be documented, but I discovered them through hacking the WordPress core of my test installation. The core of my code for Kcite now looks as follows:

      $url = "http://dx.doi.org/{$cite->identifier}";

      $params = array(
                      'headers' =>
                      array( 'Accept' =>
                             "application/x-datacite+xml;q=0.9, application/citeproc+json;q=1.0"),
                      );

      $wpresponse = wp_remote_get( $url, $params );

      if( is_wp_error( $wpresponse ) ){
          return $cite;
      }

      $response = wp_remote_retrieve_body( $wpresponse );
      $status = wp_remote_retrieve_response_code( $wpresponse );
      $headers = wp_remote_retrieve_headers( $wpresponse );
      $contenttype = $headers["content-type"];

      // it's probably not a DOI at all. Need to check some more here.
      if( $status == 404 ){
          // kcite code
      }

      if( $contenttype == "application/citeproc+json" ){
          // crossref DOI
      }

      if( $contenttype == "application/x-datacite+xml" ){
          //datacite DOI
      }

Which registration agency

Having updated Kcite to use the HTTP API for all of its metadata resolution methods, I thought it would be wise to check all of my test cases to see that they were working correctly. I found one DOI which was and, in fact, always has been behaving incorrectly, returning the wrong metadata.

The reason for this was a slightly dubious piece of logic in Kcite, put in place when we have less understanding of DOIs. Where we could not find metadata from CrossRef about a DOI, we were free text searching Pubmed for the DOI, and using Pubmed metadata instead. Unfortunately, the free text search of Pubmed is not fuzzy, and it was this that was resulting in erroneous metadata. I have now removed this code from Kcite which may result in some DOIs that appeared to work previously now failing.

Once again, we see the difficulty in being unable to determine the registration agency for a given DOI. I can only conclude that the DOI in question was not allocated by either CrossRef or DataCite, as neither returned metadata for this DOI; a conclusion on negative data, however, is not a strong one. It could (and has) also be the case that either CrossRef or DataCite metadata services are not working properly.

I tried investigating the DOI Registration Agency (http://www.doi.org/registration_agencies.html) page from the International DOI foundation (IDF). None of these seemed obvious candidates. It appears that the IDFs web page is incorrect.

The DOI in question? This is http://dx.doi.org/10.1000/182. This DOI is the identifier for the “DOI Handbook”. And the registration agency missing from the IDFs page. That would be the International DOI Foundation.

Demonstration

At the time of posting, this blog is using a released version of Kcite, hence a link to the DOI (http://dx.doi.org/10.1000/182) actually appears as a link to a Pubmed paper (http://www.ncbi.nlm.nih.gov/pubmed/21785971). The current (unreleased) development version of Kcite now reports the absence of metadata for this DOI which this post will (or may already) display once I update.

The underlying HTML source, it should be noted, still contains the correct link (to the DOI handbook), so a computational agent consuming this page would still detect the authors original intention, even with the error from Kcite.

Update

Fixed broken links!

14/05/2012: My blog has been updated, so 10.1000/182 now shows up as metadata missing, which is correct behaviour from kcite.

Bibliography

With the release of Kcite 1.5 (http://wordpress.org/extend/plugins/kcite/), we now support multiple forms of citation (http://www.russet.org.uk/blog/2012/02/kcite-spreads-its-wings/). There have also been some changes to the implementation layer, however, that I will describe in this article. I have previously written critically about DOIs and their problems (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/). One of my criticisms is the inability to access metadata about a DOI in a standardised way. In this article, I will consider the addition of content negotiation and whether this improves the situation. From this, I will draw a number of conclusions about the DOI system.

Background

DOIs offer a single point of entry mechanism for refering to a paper. A DOI such as “10.1371/journal.pone.0012258″ refers to one of my papers (http://dx.doi.org/10.1371/journal.pone.0012258). It can be transformed into a URL by the additional of http://dx.doi.org to the front, giving http://dx.doi.org/10.1371/journal.pone.0012258. The DOI proxy service takes this URL and redirects the user to the “real” URL which contains the content in question. DOIs themselves are assigned by a registration agency. The majority of DOIs that refer to academic papers have been assigned by CrossRef (http://www.crossref.org). However, they are not the only registration agency — DataCite provides a similar service for, intuitively enough, data sets (http://www.datacite.org). The actual content — the papers or the data sets — are stored elsewhere. Both DataCite and CrossRef simply forward the user of these URLs to the publisher or data repository.

Our previous article (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/), discussed a number of problems including the difficulty in accessing metadata about a given DOI. As well as being an issue of general concern, it is also a specific problem for the development of Kcite (http://knowledgeblog.org/kcite-plugin). This wordpress plugin generates reference lists from identifiers, including DOIs; it is active on this article. To do this, it captures metadata about each reference from a variety of different metadata servers.

CrossRef have recently announced the addition of Content Negotiation to their list of services (http://www.crossref.org/CrossTech/2011/04/content_negotiation_for_crossr.html). This provides a mechanism to access metadata about a DOI, at least for those DOIs where CrossRef is the registration agency. This mechanism became more attractive with the announcement that it is now also supported by datacite (http://www.crossref.org/CrossTech/2011/10/datacite_supporting_content_ne.html). Finally, partly following a request of mine, CrossRef also now releases its metadata in JSON (http://www.crossref.org/CrossTech/2011/11/turning_dois_into_formatted_ci.html) ready for Citeproc-js (http://bitbucket.org/fbennett/citeproc-js). This format is used internally by Kcite, which required parsing from CrossRef unixref XML. Retrieving JSON directly had obvious advantages.

Accessing the metadata

Here, I describe the implementation of content negotiation for Kcite. The complete source of Kcite is available from Mercurial although not all of the changes described here were checked in (http://code.google.com/p/knowledgeblog/source/browse/trunk/plugins/kcite/kcite.php).

My original implementation for gathering CrossRef metadata used the file_get_contents method in PHP. Despite its name, this also works with URLs, providing a simple and straight-forward implementation path.

   $url = "http://www.crossref.org/openurl/?noredirect=true&pid="
            .$crossref."&format=unixref&id=doi:".$cite->identifier;
   $xml = file_get_contents($url, 0);

There are a number of issues with this implementation, not least the lack of any significant error handling. More over, the file_get_contents is not very adaptable; it performs a simple HTTP GET request. So, I decided to use PHP libcurl (http://php.net/manual/en/book.curl.php). The translation from file_get_contents is reasonably straight-forward.

$url = "http://dx.doi.org/{$cite->identifier}";
$ch = curl_init();
curl_setopt ($ch, CURLOPT_URL, $url );
$response = curl_exec ($ch);

curl_close($ch);

Initially this failed to work. I normally build and test my code on Ubuntu and, unfortunately, PHP libcurl is not installed with either WordPress, PHP or Apache. A search and aptitude install solve this problem. Now strange things happen. It turns out that the default behaviour of libcurl is to embed the retrieved content into the output — that is the outgoing web page. So, I need to add an option to the libcurl calls.

      $url = "http://dx.doi.org/{$cite->identifier}";

      // get the metadata with negotiation
      $ch = curl_init();
      curl_setopt ($ch, CURLOPT_URL, $url );
      curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true );

The code was still not working, and nothing appears to be returned though. Debugging a black box is never easy, so I need to get more information before going further. So, I added code to dump curl verbose information to a log file.

      // debug
      $fh = fopen('/tmp/curl.log', 'w');
      curl_setopt($ch, CURLOPT_STDERR, $fh );
      curl_setopt($ch, CURLOPT_VERBOSE, true );

A quick perusal of the HTTP requests show the problem. By default, a call to http://dx.doi.org returns a 303 See Other response. By default, libcurl does not follow this. Another command line option is required to fix this.

      $ch = curl_init();
      curl_setopt ($ch, CURLOPT_URL, $url );
      curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true );
      curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, true );

Finally, we need to use content negotiation. The PHP libcurl library does not support this directly, so we need to set the HTTP headers for ourselves.

        curl_setopt ($ch, CURLOPT_HTTPHEADER,
                   array (
                          "Accept: application/citeproc+json;q=1.0"
                           ));

And I now have a solution. Kcite needed reworking, but mostly this involved removing the XML parsing layer, all was looking good. Except that while looking through my regression tests, I found that DataCite support has been broken. I was, at that time, accessing DataCite using a different interface.

    $url = "http://data.datacite.org/application/x-datacite+xml/"
         . $cite->identifier;

The difficulty was that previously I was accessing CrossRef directly to resolve DOIs. Asking CrossRef about a Datacite DOI resulted in an unknown DOI response. Kcite resonded to this response by trying DataCite next; unfortunately, there is no way that I know of to distinguish syntactically a DataCite and CrossRef DOI. With the new method, the content negotiated call to http://dx.doi.org succeeds, although DataCite does not know of the requested citeproc+json MIME type, so returns HTML. So, again, we need to extend the our DOI resolution, checking for the returned content type.

      $response = curl_exec ($ch);
      $status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
      $contenttype = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);

      // it's probably not a DOI at all. Need to check some more here.
      if( curl_errno( $ch ) == 404 ){
          curl_close($ch);
          return $cite;
      }

      curl_close ($ch);

      if( $contenttype == "application/citeproc+json" ){
          // crossref DOI
          //kcite specific logic follows.
      }

I should now be able to achieve a single call to resolve a DOI by modifying the headers once again. Here we request citeproc+json if possible or x-datacite+xml if it is not.

    curl_setopt ($ch, CURLOPT_HTTPHEADER,
               array (
                     Accept: application/citeproc+json;q=1.0, application/x-datacite+xml;q=0.9
                          ));

Unfortunately this fails also. While CrossRef returns citeproc+json, DataCite still returns HTML. Discussions with Karl Ward from CrossRef cleared up the problem. The content negotiation implementation of both CrossRef and DataCite was imperfect. DataCite’s implementation always tried to return the first content type; but it doesn’t know about citeproc+json, hence the HTML. Meanwhile CrossRef returns only the highest q value, rather than all types. Ironically, the problem was solved by doing this:

    curl_setopt ($ch, CURLOPT_HTTPHEADER,
               array (
                     Accept: application/x-datacite+xml;q=0.9, application/citeproc+json;q=1.0
                          ));

Crossref now returns JSON (because it has the highest q value), while datacite returns XML because it comes first. The final, complete and functioning method now appears as follows:

      $url = "http://dx.doi.org/{$cite->identifier}";

      // get the metadata with negotiation
      $ch = curl_init();
      curl_setopt ($ch, CURLOPT_URL, $url );
      curl_setopt ($ch, CURLOPT_RETURNTRANSFER, true );
      curl_setopt ($ch, CURLOPT_FOLLOWLOCATION, true );

      // the order here is important, as both datacite and crossrefs content negotiation is broken.
      // crossref only return the highest match, but do check other content
      // types. So, should return json. Datacite is broken, so only return the first
      // content type, which should be XML.
      curl_setopt ($ch, CURLOPT_HTTPHEADER,
                   array (
                          "Accept: application/x-datacite+xml;q=0.9, application/citeproc+json;q=1.0"
                          ));

      // debug
      //$fh = fopen('/tmp/curl.log', 'w');
      //curl_setopt($ch, CURLOPT_STDERR, $fh );
      //curl_setopt($ch, CURLOPT_VERBOSE, true );

      $response = curl_exec ($ch);
      $status = curl_getinfo($ch, CURLINFO_HTTP_CODE);
      $contenttype = curl_getinfo($ch, CURLINFO_CONTENT_TYPE);

      // it's probably not a DOI at all. Need to check some more here.
      if( curl_errno( $ch ) == 404 ){
          curl_close($ch);
          return $cite;
      }

      curl_close ($ch);

      if( $contenttype == "application/citeproc+json" ){
           // crossref DOI
           // kcite application logic
      }

      if( $contenttype == "application/x-datacite+xml" ){
          //datacite DOI
          // kcite application logic
      }

Using the metadata

Although we now have a single point of entry for accessing the metadata about a DOI, the metadata itself is still not standardised. Although CrossRef has returned metadata in (nearly!) the form that we are going to use, DataCite has returned XML conforming to their own schema. We still need to parse this XML. Fortunately, this is relatively easy in PHP, using the SimpleXMLElement class and xpath. The full code is available, so here I just show the sections involving xpath, for example, to retrieve the publisher and the title.

    $journalN = $article->xpath( "//publisher");
    $titleN = $article->xpath( "//title" );

Initial testing suggested this works, sometimes. Unfortunately, I discovered that this failed for some DataCite DOIs. More solicitous debugging shows the problem; DataCite returns more than one form of XML. At first sight, the xpath should work, since the relevant elements are still in the same place. However, the default namespaces have changed — DataCite kernel 2.0 XML does not have a default namespace, while 2.1 and 2.2 do, which breaks the xpath. The situation is resolved by searching for namespaces, then parameterising the xpath queries.

       $namespaceN = $article->getNamespaces();
       $kn = "";
       if( $namespaceN[ "" ] == "http://datacite.org/schema/kernel-2.2" ){
           $kn = "kn:";
           $article->registerXpathNamespace( "kn", "http://datacite.org/schema/kernel-2.2" );
       }

       if( $namespaceN[ "" ] == null ){
           // kernel 2.0 -- no namespace
           // so do nothing.
       }

      $journalN = $article->xpath( "//${kn}publisher");
      $titleN = $article->xpath( "//${kn}title" );

I now have a system capable of gathering bibliographic metadata from a DOI.

Discussion

In our original post (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/), we compared the situation with bioinformatics identifiers to DOIs. A Uniprot ID, for instance, such as http://www.uniprot.org/uniprot/P08100, resolves to a protein record while http://www.uniprot.org/uniprot/P08100.fasta returns the equivalent protein sequence. Content negotiation offers the possibility of achieving something similar with DOIs, at least with respect to the metadata if not the actual content.

My experience in practice shows that content negotiation does work and is useful, however, I am unconvinced that it is an ideal solution. From a theoretical stand point, the use of Accept headers seems nice. But in practice, it is painful because it is not commonly used. PHP does not support it, while even PHP with libcurl support requires me to set headers by hand, as there are no standard methods for doing so. Likewise, with curl on the command line, as shown in this example from CrossRef (http://www.crossref.org/CrossTech/2011/04/content_negotiation_for_crossr.html) which retrieves RDF metadata.

curl -D - -L -H   "Accept: application/rdf+xml" "http://dx.doi.org/10.1126/science.1157784"

I would expect a similar experience within Perl, Python or Java; the tools of choice for a bioinformatician. I cannot email people a link to the metadata for a paper; I have no idea how you could access the RDF if you were using a desktop browser, or on a phone. From a personal perspective, I much prefer the approach offered by DataCite which uses URLs of the form http://data.datacite.org/application/x-datacite+xml/10.5524/100005 which is genomic data about Emperor Penguins (http://dx.doi.org/10.5524/100005). Content negotiation is hard work because although it is standard, being part of the HTTP specification, it is not common. The fact that neither DataCite nor CrossRef got their implementation right suggests to me that these are not my problems alone.

Of course, the DataCite approach is limited to DataCite DOIs, so http://data.datacite.org/application/x-datacite+xml/10.1371/journal.pone.0012258 returns a failure message. However, this mechanism implemented at http://dx.doi.org would add a valuable and additional interface; it is actually very easy to implement, with a simple call to the content negotiated stack; a form of the PHP described in this post would perform the task well.

My original criticisms of DOIs included the enormous variety of entities that DOIs actually resolve to: the article in HTML or PDF, an abstract and a picture, author biographies, or an image of a print out of the front page (http://www.russet.org.uk/blog/2011/02/the-problem-with-dois/). Unfortunately, the experience is replicated at the metadata level. With two registration agencies, I have to deal with 4 different types of schema, although I am grateful to CrossRef to adding support for the one that I wanted. If I can managed to do an, admittedly, half-hearted job at integrating this data by blackbox resolution of a set of DOIs, it would be nice if the International DOI Foundation could do the job for me. Failing this, a single point of entry to the documentation for the different registration agencies would help.

Finally, the fact that DOIs provide a single, unified identifier at the metadata level turns out to be a disadvantage. There is, in reality, no such thing as a DOI; there are multiple different types of DOI. KCite supports two of them, that is CrossRef DOIs and DataCite DOIs. But there are 8 registration agencies (http://www.doi.org/registration_agencies.html). It is, therefore, not possible to know what content types if any will be returned before hand.

The more general problem is for a given DOI, to my knowledge, there is no way of knowing which registration agency is responsible, at least not at the level of a http://dx.doi.org URI (at the Handle level there must be, or the system would not work). For the average user, therefore, there is no way of knowing who is responsible for a given DOI. Strictly, this is true for a URL also. But if http://www.uniprot.org/uniprot/OPSD_HUMAN fails to resolve as I think it should do, there are a number of steps I can take. I can email webmaster@uniprot.org. I can browse from http://www.uniprot.org looking for a contact. I can type whois uniprot.org. For a DOI, I have none of these tools (or rather everything points to the International DOI Foundation).

This problem was exemplified a few days after completing the work on KCite described here. I noticed that PDB has DOIs for its records, which should have worked with KCite. However, they were failing to resolve. Consider this (elided) output from curl.

> curl -D - "http://dx.doi.org/10.2210/pdb3cap/pdb"
HTTP/1.1 303 See Other
Server: Apache-Coyote/1.1
Location: ftp://ftp.wwpdb.org/pub/pdb/data/structures/divided/pdb/ca/pdb3cap.ent.gz

> curl -D - -L -H  "Accept: application/citeproc+json" "http://dx.doi.org/10.2210/pdb3cap/pdb"
HTTP/1.1 303 See Other
Server: Apache-Coyote/1.1
Location: http://data.crossref.org/10.2210%2Fpdb3cap%2Fpdb

HTTP/1.1 404 Not Found
Date: Mon, 27 Feb 2012 13:58:39 GMT

Unknown DOI

The DOI resolves but the metadata does not. What was more confusing was this result which shows that some PDB DOIs did resolve.

> curl -D - -L -H   "Accept: application/rdf+xml" "http://dx.doi.org/10.2210/rcsb_pdb/mom_2012_2"
HTTP/1.1 303 See Other
Server: Apache-Coyote/1.1
Location: http://data.crossref.org/10.2210%2Frcsb_pdb%2Fmom_2012_2

HTTP/1.1 200 OK
Date: Mon, 27 Feb 2012 14:01:18 GMT
Content-Type: application/rdf+xml

In this case, it is possible to guess who the registration agency was (CrossRef) from the location of the RDF metadata, but this is undocumented and may not work for all registration agencies. Too much guesswork or specific knowledge of the DOI is involved. Thankfully, in this case, Karl Ward of CrossRef fixed the problem rapidly and now I can cite both the crystal structure of Opsin (http://dx.doi.org/10.2210/pdb3cap/pdb) and the Aminoglycoside Antibiotics (http://dx.doi.org/10.2210/rcsb_pdb/mom_2012_2).

Conclusions

DOIs are and remain problematic. The addition of content negotiation at first sight appears to be a considerable improvement, but it usage is more complex than it should be. I offer here three suggestions based on my experience:

• An alternative based on simple HTTP GET URIs should be provided
• A standardised metadata schema for all DOIs, or at least a single point of entry to the documentation for all DOIs.
• For a given DOI, there must be a standard mechanism to discover which registration agency is responsible. Without this, it is hard to discover which documentation and which schema applies.

Despite this, KCite actively uses content negotiation; with it, I have dropped the number of HTTP requests I need to make to resolve the metadata for a DOI and this is a good thing. It is good to see the system getting more usable; I hope that this trend continues.

Bibliography

Today, I was pleased to release version 1.5 of kcite. Follwing in my tradition of being unable to get the WordPress plugin release process to work correctly, shortly after I released 1.5.1 which is the same thing, but with the correct metadata.

I’m quite pleased with this release. There have been some underlying changes to the technology which I will describe in another post, but for now I want to focus on what I feel represents a substantial improvement on previous versions in terms of functionality. The previous release added support for client-side rendering, which made things look nicer and will add more functionality into the future. However, from an authoring perspective this did not provide much advantage.

For the 1.5 release, I wanted to add new forms of identifier. Kcite started with the ability to cite digitial object identifiers to papers, as this reference to one of my papers shows (http://dx.doi.org/10.1371/journal.pone.0012258). As a bioinformatician, references to PubMed also seemed like a good idea (http://www.ncbi.nlm.nih.gov/pubmed/21414991), even if, in most cases a doi could be used also.

However, for this release, I wanted to expand into two new areas. Kcite has come from the kblog project where we have been trying to improve the formality of publication using a blog engine, so that it can become an recognised part of the scientific literature. Organisations like arxiv have done much the same thing (with far greater success!) with preprint. It makes sense then that kcite can now also link straight through to here also (http://arxiv.org/abs/1109.4518). Likewise, we wanted to support the push to data citation, which we have achieved courtesy of datacite. It is now possible to reference data sets also (http://dx.doi.org/10.5524/100005).

And, finally, I have tidied up the presentation. Every item now has a visible URI in the reference list. I have made it visible because these identifiers should be public and present, not just providing an underlying link structure, although they do this as well now. In text citations link through to the bibliography, but also provide an outlink, direct to the resource also. Before processing, the underlying text citation displays the URI which should aid machine interpretability. This link will also be correct, since it is used to gather the metadata for the citation, rather expecting authors to tack a URI to a citation that already appears correct to them.

As always, new forms of publication raise questions and this release is no exception. We have, for instance, found that kblogs are useful for publishing grey literature such as bio-ontologies. But at the moment, rather embarrasingly, there is no way to reference these articles (or indeed this article itself!) with KCite. And, second, there is an issue of provenance. For instance, the notice describing the 1.4 release of kcite is now formatted with 1.5. It’s changed since it’s original publication because I have upgraded Kcite, as in turn will the presentation on this article change with the next release. I am hoping to address both of these issues in the near future.

Bibliography

We’ve been working for sometime now on our lightweight semantic publishing environment, kblog. Near the beginning of the last academic year, unfortunately, we were compromised through a zero-day vulnerability. With the press of academic life and teaching, it has taken me a long, long time to get the show back on the road. However, finally, I think we have achieved this. The main cause for the delay was, simply, that I didn’t have time — at other stages of the year, it would not have been so much of a problem, but in October there is very little give in my working week. However, an additional problem has been that restoring kblog was a lot more effort than it should have been.

If you are only interested in kblog itself, well, it should be up now. The rest of this post is going to be a technical write-up.

First, we decided to take the opportunity to move kblog over to a larger machine. It was running on a small virtual machine previously. In general, this coped well with the traffic, but we wanted something with a bit more memory — it was a little stretched while we held workshops, and lots of people were authoring at once. We have also secured the machine up further than before. I wont go into too many details here, for obvious reasons, but I think it is less like to get hacked in future, although the risk is still there.

Kblog started out as an experiment: both a development machine for the knowledgeblog environment and a service for people to read. This is not really a tenable situation; in future, we’ll only upload new kblog plugins after a while longer testing. I’ve also removed some of the third party plugins — I want to move knowledgeblog to being run under wordpress DEBUG without warnings. For a while, this is like to result in a few missing pieces of functionality: gravatars and versioning being the most obvious examples. The server will not ONLY be for the web. Mailing lists and such like will move onto Google code; why host something we do not have to?

To restore cleanly, we have decided to use a from fresh install. No PHP from wordpress has been maintained from the old site; everything has been checked out anew. We have also been through the database, and as far as we can tell, there is no malicious content there, although we cannot discount the possibility.

The restoration itself was much harder than expected, for historical reasons. Kblog was originally a WordPress MU installation — the multisite version of wordpress. Since WordPress 3.0 came out, however, this has not been an independent install; we ported over to a being a standard Network installed WordPress 3.0 a while back. However, this historical baggage was a substantial impediment to restoration. It turns out that the standard install and restore process doesn’t work under these circumstances. Essentially, we got the infamous “Error establishing a database connection”. With some help from the forums, I tried testing the MySQL connection (it worked), the privileges (which were correct), a clean installation in the same database (by swapping the table prefixes and installing anew). After a minor diversion with my rewrite rules, I could still find no problems or mistakes with my install.

At this point, I resorted to a full debug of the WordPress load. The error started in wp-settings.php, at the call to wp_not_installed() Chasing down a bit further, got me to is_blog_installed. This checks for the options table, which appeared to not exist, and then for other WP tables which DID exist, at which point it calls dead_db(). Despite having just connected to the database, WordPress prints the entirely unhelpful “Error establishing a database connection” message at this point.

After much poking around, I found the cause. Rather than using a normalised schema in its database, wordpress use duplicate tables. So, rather than having WP_POSTS, with a blog id column, each blog has an independent set of tables, as well as a few which are shared between all blogs, a sort of “psuedoschema”. Between WPMU and WP3 this psuedoschema changed — the tables for the first blog were prefixed wp_1_ in MU, but are now just wp_. Subsequent blogs are wp_2_, wp_3_ and so on. Not ideal, but I guess is simplifies the SQL, as most of WordPress deals with only a single blog at a time.

Now, normally, wordpress copes with this. Something in the wp_config.php tells WordPress to look for wp_1_ rather than wp_, when this wp_config.php has resulted from an upgraded WPMU installation. Unfortunately, I had done a fresh install. Now, I realised that this was a risk, but I decided that “fixing” the database was the best option. It already appears that having an ex-WPMU database had caused problems now, and into the future this is only going to get worse. So, I renamed the tables with a bit of SQL.

This worked, problem solved? Well, nearly. However, all the users from my first blog (served now from the wp_ tables, previously from wp_1_ tables) had disappeared, as had all my roles. Again, more forum searching found the problem. Not only does WordPress use a psuedoschema, it stores table names in the database. So, wp_options had a line with a “option_name” called “wp_1_user_roles”. Again, more SQL.

update wp_options set option_name = "wp_user_roles" where option_name = "wp_1_user_roles";

and back came my roles, but still no users. In the end, I greped through the database dump (I am sure that this is not how databases are supposed to work) for “wp_1″. The culprit was the wp_usermeta table. This SQL revealed the problem.

select * from wp_usermeta where meta_key like "wp_1\_";

With a bit of Emacs hacking and Perl, I generated the 10 statements of this form…

update wp_usermeta set meta_key = "wp_capabilities" where meta_key = "wp_1_capabilities";

which finally solved the issue, and voila, users are back.

So, all a bit messy really. In the end, I can see why WordPress decided to go for a psuedoschema approach, but then putting the database table names into two tables as well? To me, this goes to far, and is not a great design solution. Combined with the entirely unhelpful error message; well, it has cost me 3 or 4 days of hacking, time which could have been better spent. Combined with no straight-forward way of forcibly resetting the passwords for a network install (more Emacs, Perl and SQL!), I don’t think that wordpress has been overly helpful here.

Regardless, the situation now appears to have been resolved. While I may be slightly irritated with WordPress, it does show the strength of free software; as is often the case, the community were very helpful in providing me with the pointers I needed, and where they could not help, I did have the option of reading, altering and debugging the code. It may be the nuclear option, and one rather avoided, but it is there if you need it.

In the meantime, I have been playing around with kcite. I was going to make it cleverer for the next release, but in the end, I have decided to focus on making it broader. I now have preliminary support for both arXiv and datacite IDs and metadata. Neither was a great deal of effort, but are strategically important: data and preprints being considered to be first class citizens. Next up, support for refering to Kblog URLs directly.

I started to write this post a long time ago in October; unfortunately before I finished I got hit with the start of teaching. I considered just ditching the post, as it is now so out-of-date and I am not usually a zombie poster. However, in this case, I shall post as a) it helps my mind to move back toward research after so long away and b) it will be my first of 2012, so I can check my makefiles work!

A couple of follow ups from my previous post.

Nicolas Le Novere commented via twitter on even the highest level assertion of that radioactivity is a dependent continuant.

@phillord fluorescence and radioactivity are occurrent not continuant. Freeze time to check.

@phillord hence the unit of radioactivity: per second (Becquerel)

— Nicolas Le Novere

In my original post, I suggested we needed Radiation, Radioactive or Radioactivity; in hind-sight, perhaps I should have used Radioactive rather than Radioactivity, which may have circumvented this issue. However, I think it is worth considering this a little further.

I would nearly agree with Nicolas that radioactivity is a process; actually, I would say that radioactive decay is a process, while radioactivity is a property of this process. However, in my last post, I was looking at a model which was “BFO-like” as OBI is based on BFO. For BFO, that radioactivity is a rate, is measured per second does not mean that it is an occurrent; any more than velocity which is also measure per second is an occurrent. Actually, in BFO land, radioactivity would be a quality of the atoms which are decaying and not a measurement of the process. This is because, as Pierre Grenon says, properties of processes do not exist.

In fact, if we look more at this more closely still, BFO would also claim that radioactive decay is not, as it might appear, a Process, because processes are continuous. This is not true for radioactive decay, even for a bulk of radioactive material. An atom decays, then there is a pause, then another decays. This makes radioactive decay a processual entity, which can contain discontinuities.

I am not arguing that BFOs treatment of processes is correct — in fact, I think it is nonsensical. However, it is this line of arguing that I was using in my previous post.

David Sutherland rather takes me to task about whether realism does what I suggest.

I agree completely, but what realist principle says you need to give something the most detailed classification you can come up with?

— David Sutherland

It’s a good question, but I would turn it around. I don’t think that realism requires you do this, although this quote from Barry Smith does rather distinguish between simplifications (i.e. not the most detailed classification you can come up with) and reality.

I am beginning to suspect that for you everything is a simplification (model) — for me, functions are part of reality; they are not simplifications; I am not interested in simplifications.

http://groups.google.com/group/bfo-discuss/msg/865e601864fbc2dc
— Barry Smith

The problem, though, is that realism elevates “reality” above all else. I think that this is wrong. Of course, in any scientific discipline, we should by aiming to model the experimental data that we have. But this is not all we need to do. As any statistician will tell you, models are compromises. It is very easy to build a model that perfectly represents the data that you have; you just build a model with as many variables as data points. The model will fit perfectly to the data, but ultimately the model is useless, since it lacks explanatory power. We need use cases, we need simplifications and sometimes we will need multiple representations of the same thing; there are examples galore in my paper (http://dx.doi.org/10.1371/journal.pone.0012258). In fact, Chris Mungall gives a good example when he talks about dispositions and their status as being real:

In fact, I have a particular problem with dispositions being “real” – BFO asks me to believe there are an infinite number of real but unrealized and perhaps wildly improbable dispositions floating around me every second

— Chris Mungall

And later he gives the solution.

taking a hard-headed pragmatic approach – e.g. avoid weirdo classes that don’t correspond to a term a normal scientist would use; introduce distinctions that give you the desired results to queries and inferences)

— Chris Mungall

In otherwords, reality is important. But we also need use cases, we need community norms, and we need applications. If ontologies do not fit with these, then can be as “real” as you like, but they are still wrong.

Bibliography

Well, I am pleased to say that we have now released the new version of kcite. It’s been a while in coming — I had the difficult bit of the code working about 5 months ago, but then got caught up in teaching. Kcite is our bibliography manager which enables citations such as this one (http://dx.doi.org/10.1371/journal.pone.0012258), using DOI or PubMed IDs.

Kcite now uses the marvellous citeproc.js to render the bibliography on the client. The main advantage of this for this release is that the biblography formatting is slightly more regular than before. We’ve also switched to name-author style as the default. There is also a disadvantage which is that the browser has to do lots of Javascript execution client-side; I’ve made efforts to ensure that this is not too onerous; on my desktop, I have been rendering 200-300 item bibliographies, which is much more than most people will use in practice.

In future versions, however, I feel the use of citeproc-js will really come into it’s own. We should be able to enable the user to select their own citation style (currently this is the choice of the authors which makes little sense). We can also add any semantics to the HTML that we choose — CiTO will come properly, for instance. I can also clean up the “unresolved” and “timed out” references. However, first thing on the list is to make the call back for the bibliographic data asychronous. Client-side this should be easy, as we are already using jquery. Server-side requires rewrite rules which I haven’t done before, but I think should not be too hard.

On a separate track, now that I have kcite on what I think is a stable technological footing, I can start to extend in other ways, the most obvious being additional forms of identifiers, critically including WordPress posts with kcite enabled. I’m also pleased that Cross-Ref have recently added the ability to drag metadata in citeproc format (JSON), which means I can skip an integration step.

However, before all of that, we need to restore kblog. We’ve taken the opportunity to move it to a better technological footing, and have started to prepare the new machine that it will be hosted on. This has taken a long time, due to a busy start to the (academic) year. Hopefully, getting hacked is not something we will repeat soon.

The current release of kcite is 1.4.1. This fixes two bugs, one reported by Carl Boettinger (so that now the Javascript only loads when necessary) and another I found which writing this post which made editors appears as authors.

Bibliography

It has been a long, long time since my last gig review. As this blog is mostly professional now, this is perhaps not such a bad thing. I did half write a review of Roy Harper and Joanna Newsome in Sept last year, but it never got posted. Don’t think I have been to gig since then. Still onwards.

I’ve been a fan of June Tabor for a long time, particularly her album with Martin Simpson even if it does have terrible cover art. Despite this, and the fact that she lives pretty close to my home town, I’ve never seen her live. Her music is dark and eclectic, her voice rich. Combined with the Oysterband’s tendency to do strange adaptations folk-style it was destined to be an interesting gig. The music is something like gothic folk if that is not a contradiction in terms. While singing, June Tabor comes as a foreboding presence on stage. Between songs though, she’s entertaining, witty and light, which was a bit of a relief.

The gig was fantastic. Her voice is as excellent live as on record, with adding prescence. She adds to the music by, erm, explaining what it is all about (this can be something of a problem otherwise). The evening was well managed, moving from gentle and quieter music to end-of-evening barnstormers. It was good to be listening to live music again.

But one thing I didn’t understand. Why does Ray Cooper stand on a box while playing bass? He’s already the tallest.

I once had cause to refer, somewhat mischievously, to “a kind of pasta from Tuscany, which is almost identical to spaghetti, but slightly different”; this was on a mailing list that was used by many Italians. It provoked the expected response; an offended Tuscan responded “I don’t know what you are talking about; but if you mean pici”, which I did, “it’s nothing like spaghetti”.

Recently, on the OBI mailing list, there has been much discussion about labels, markers or tracers. What ever you wish to call it, the basic idea is the same; a molecule which is easily detectable, is used to trace something else. This can involve adding a small amount of a radioactive isotope (P³²). This makes it possible to follow the molecule (which is otherwise hard) by tracing the radiation (which is generally easy).

So, how do we model this? As with many parts of ontology building, it turns out to be not straight-forward; during this discussion, an email from Philipee Rocca-Serra which left me asking the question, are we being too specific? I will work through an example to show what I mean. Feel free to skip to the punchline if you choose.

Consider, for example, the following models; these are not directly taken from OBI, as I want to reduce the complexity for this article; rather they are in the general spirit of the models which raised these questions.

A label, or something that has been labelled is clearly part of an experimental design. It is not intrinsic to this entity, rather it appears to be a role that the entity is playing in the experiment. So:

Class: Label
       SubClassOf:
          Role

There are, of course, labels of many sorts. The main types that I can think of are radioactive, fluorescent and what I call adherent. So, we might add the following, with a few subclasses of adherent as explanation.

Class: RadioactiveLabel
       SubClassOf:
          Label

Class: FluorescentLabel
       SubClassOf:
          Label

Class: AdherentLabel
       SubClassOf:
          Label

Class: BiotinilaytedLabel
       SubClassOf:
           AdherentLabel

Class: AntigenicLabel
       SubClassOf:
           AdherentLabel

So far so good. However, for a label to be useful, it needs to be manufactured (often in a bespoke fashion, depending on the experiment being performed) and it needs to be detectable. So, we might add classes like so:

Class: LabellingProcess
       SubClassOf:
           Process
           has_output some Label

Class: LabellingDetectionProcess
       SubClassOf:
           Process
           has_input some
                  Sample contains some Label

Now we have three classes for every label type. We can deal with this by generating a cross-product, either at development time, or at the time of use if we are using OWL. However, we need something to tie together these classes. We need a concept to know that we need a RadioLabellingProcess to produce a RadioLabel which we detect in a RadioLabellingDetectionProcess. In short, we need a concept of Radiation, Radioactive or Radioactivity.

Class: RadioactiveEntity
    SubClassOf:
        IndependentContinuant,
        bears some Radioactivity

Class: RadioactiveLabel
    SubClassOf:
        Role,
        RadioactiveEntity

Class: RadiationDetector
    SubClassOf:
       detects some Radioactivity

Class: RadioactiveLabelProductionProcess
    SubClassOf:
       has_input some RadioactiveEntity

This is where the situation gets difficult. What kind of thing is Radioactivity? Taking the realist approach, we need to consider this carefully, determining what this universal is. So, starting from the top, it is fairly obvious that we have a Continuant. Next question, do we have a Dependent or IndependentContinuant. Again, this is fairly clear: radioactivity cannot exist without something to be radioactive, hence Radioactivity is a DependentContinuant.

We have a set of DependentContinuant‘s that Radioactivity could be. The concept Role does not fill well; this is usually ascribed by socially or, in this case, experimentally determined behaviour. Perhaps, Disposition would be better. However, this does not really fit either, as a Disposition is realised “under specific circumstances”. Now this is not true of radioactivity. Either something is radioactive or it is not, and if it is, then it is, to the best of our knowledge, radioactive under all circumstances. It appears, then, that Radioactivity is a Quality, because “it is exhibited if it inheres in an entity at all”.

If we follow the same logic with our other label types, initially, we come to the same conclusions. However, Fluorescence is not exhibited under all circumstances. It only happens when the label is illuminated with the right kind of light. So, Fluorescence appears to be a Disposition. Following a similar logic, this is also true of Adherent. So the best we can say about the property of the substance that makes it usable in labelling is that it is a RealizableEntity.

Having Radioactivity stand out in this way is a little unsatisfying. Let’s consider the logic again. One classic experimental form is the pulse-decay experiment. I can, for example, feed a rat with, say, radioactive phosphorus briefly. After this, you can trace the course of phosphorus. Now during the course of this experiment, the rat becomes radioactive and then ceases to be radioactive again. But, it is notably, the same rat. So, perhaps, the statement that things are either radioactive or not is wrong. Perhaps, it is not a Quality at all. The flaw in the logic is the assumption that because an atom is either radioactive or is not, therefore anything made up from atoms must be so. But an entity can have its atoms totally replaced and still be the same entity. In this case, what is true of a rat, is also true of its DNA. We can replace the atoms in a sample of DNA with other ones and still, have the same DNA. So, maybe, Radioactivity is a Quality at an atomic level of granularity, but is, after all, a Disposition at others.

Thinking further, however, maybe it is not a Quality at all. A mass of P³² is always radioactive, but a single atom? Perhaps not, since it only displays this when it decays. So, perhaps, it is a Disposition after all. However, this makes no sense, because dispositions are displayed under “specific circumstances”. Now, to the best of our knowledge, radioactive decay is stochastic — it is so random, that radioactivity is often used to generate randomness. We cannot specify the circumstances under which it happens, it just does. More over, after it displays the radioactivity, what has happened to the atom? Using the same argument as before, we could say that, like the rat, the atom still exists, it’s just that (some of) the elementary particles that make it up have changed. But this way, surely, madness lies, as “being phosophorus” would become some sort of dependent continuant, which the atom displays during its decay, while it happens to have the right number of protons. So, probably it makes more sense to say that, the decay process represents the end of the existence of the phosophorus atom and the beginning of a new atom (and a radioactive particle). In which case, even our original decision that Radioactivity is DependentContinuant is wrong. It’s not a DependentContinuant at all, it’s only a process which over as soon as it begins.

So, what have we achieved? Well, I would argue, not a great deal, except for a lot of discussion. More over, we have ended discussing very detailed issues about the physical properties of matter, when we started discussing an ontology of biomedical investigations. This might be entertaining, or it might be very dull, depending on your point-of-view. But, what we have failed to produce is a specific conclusion.

The problem here is realism. A realist ontology represents portions of reality, that is classes of things that really have instances. We have to ask these questions to try and determine whether Radioactivity exists and what kind of thing that it is. We can set realism against pragmatism. Previously, Robert Stevens has described the problems that this causes by preventing the ontologist from modelling “unicorns“, such as Newtonian mechanics, or canonical anatomies. The unicorn principle says, if it is useful to model a concept in an ontology, then often we should. Here, I introduce what I call the “Pici principle” — if it is not useful to model a concept then we should not. As a British native, pasta is pasta; it all tastes much the same to me. Generally, I do not need the ability to be able to distinguish pici and spaghetti, unless I want to provoke a response from an over-excitable Tuscan. The sensible course is not to get involved in the discussion in the first place.

The same applies in this instance. There is a clear use case for the concept of Radioactivity; without it, we cannot say that a radio-label is radioactive, or that a fluorescence detector is not going to work detecting it. But to achieve this use case, we do not need to understand very deeply what Radioactivity is. Describing it as a DependentContinuant is enough, and it will fulfil the use cases. It will not enable us to ask questions about which kind of labels detect qualities and which detect dispositions. But in the absence of a use case, this is not an issue.

A chemist may care, and may want to classify radioactivity further. This is fine; as with pasta, we can safely leave these issues to someone else, in the knowledge that they are probably better qualified to give an answer anyway. So long as they decide that Radioactivity is a DependentContinuant, it does not matter to us what kind of DependentContinuant; we have said nothing incorrect. So, our ontology will integrate with theirs, without change to either. By being as vague as our use cases allow us, we have actually increased the ability of our ontology to integrate with others.

In short, the pici principle encapsulates the idea that deciding what we should not model in an ontology is as important as what we should model. And this decision comes from use cases, not reality.

While I am currently spending a significant amount of my time promoting the idea that blog technology can be, and should be used for serious scientific material, I thought I would make a post of a different and perhaps more traditional vein: that is, a light-weight idea, with no serious research behind it, but Years ago now, I created an Energy Wiki full of daft ideas for making energy. I last revisted this in 2009, with an idea for storing energy at sea. I’d actually forgotten that part of the reason for this was to try out Inkscape, which is part of the reason for this post. I wanted to try a bit of multi-media, that is, a blog post with an image in it. High tech.

So, the idea. One form of renewable is the Solar Updraft Tower, also known as a solar chimney. This works straightforwardly enough: you build a large greenhouse in a desert, with a very large chimney in the middle. The top of the chimney is in cold air, the bottom in hot, and an updraft results; stick a turbine in or at the base of the chimney, and you get energy out.

The problem is to work at all efficiently, you need a big temperature differential, so a tall chimney. This in turn means a wide chimney, both to support a substantial updraft, and for mechanical reasons. Tall means 500m or more. The bottom line of this is that a pretty significant capital expenditure is required, followed by a relatively long pay-back period, which in turn means that the biggest single expense of the project is likely to be interest charges, rather than anything else.

So, my idea, is to use an inflatable chimney instead. Initially, I thought about some kind of helium lifting scheme, but then I realised that this makes no sense; why not use hot air, which after all is what the whole system is designed to generate. Consider, for instance, the following organisation:

Essentially, it’s a traditional balloon with a hole in the middle. Obviously the whole system is stackable — a second balloon could be placed on top of the first and so on. The whole structure could be assembled or dissassembled as desired. Unfortunately, though this would probably take quite a bit of work.

My second thought came from the idea that, while most designs for solar chimneys have the chimney in the middle of the greenhouse, it doesn’t really need to be. A horizontal pipe to the middle would be enough. The chimney could be outside of the greenhouse. The advantage that this brings is that the tower could be raised or lowered in-situ, without the risk of it falling on, and damaging the greenhouse. So my second idea was to build the chimney as a two cylinders, with the gap between the serving as the inflatable, buoyant structure. By pleating the cylinders in opposite directions like so:

the whole structure should concertina up and down. By inflating from the top and deflating from the bottom, it should be possible to raise or lower the entire system by opening and shutting vents at the bottom or top of each section to the inside of the chimney.

One advantage with this system, is that as the chimney gets higher, the temperature differential between the inside and the outside gets greater, which should mean that the taller the tower, the more bouyant the sections get; this should help to keep the entire thing as upright as possible, as will the air travelling through the middle, like some gigantic party blower.

Another addition that cames to mind would be to add inflatable half-toroids around the chimney at regular intervals. With a curve on the top, and a flat bottom-side, the entire thing should operate like an aerofoil, lifting the tower up; so, the windier it gets, the greater the lift, which is just what is needed to keep it as upright as possible. This should mean that the chimney can operate in relatively high wind levels.

This kind of system could even work in concert with a fixed chimney — extending the height by 500m say, and increasing it’s efficiency. It could also act as a supplement — operating only on very hot days when the greenhouse has excess capacity. Or, finally, it could operate while the main chimney was being built, meaning that a plant can start generating income earlier, which should reduce the cost of interest payments.

Of course, this all comes with drawbacks: the ongoing running costs are likely to be a significant; wind will remain a significant factor regardless; and, finally, inflating the tower will using hot air, which will reduce the efficiency of the whole system. Are these flaws significant? Well, as I said, this post is light-weight with no serious research behind it. I have no idea, nor any really clear idea about how to work out these costs. Answers on a postcard please.

I have been pushing the idea of Kblogs — scientific publishing using commodity software — for a year or so know. Our main site, Knowledgeblog.org has got around 100 articles now, and has had about 50k page views (or about 4x the number of raw page hits) and has generated a certain presence on the internet. While this is generally good, the price of fame is that we have moved somewhat up the list of potential hack targets. Unfortunately, this has resulted in two compromises on the machine; they were probably not disconnected, although we have no evidence to link the two at the moment.

The first was through the timthumb zero day vulnerability. It involved a code injection into a WordPress installation using a thumb nail generator with a dodgy bit of PhP in it. We cleaned the system up as well as we are able and went from there. Sadly, a couple of days ago, we had a second break in. This was a more serious and directed attack (the timthumb was scripted, and we were one of several thousands of sites to be hit). In this case, the machine has been root compromised, and the web server used to gather username/passwords in a phishing expedition. We do have backups and all of the content. There were a number of things that we could have done to secure the machine further, at least one of which may have prevented the hack, but there are only so many hours in the day.

So, where does this leave us? Is the whole idea of knowledgeblog broken? Personally, I do not think so. While I have been critical of the cost associated with academic publishing, I am aware that it cannot happen for free. Running and maintaining a web server takes money; it is something that we have been doing on a shoe-string for a while, especially since our JISC money ran out. In the couple of years that we have run knowledgeblog, I think that we have learned and shown a lot. As well as page views and content, we have shown that scientific publishing can be easy for the author; that we can generate attractive articles this way; that we can start to embed computational accessible knowledge into these articles. We have shown that we can do peer-review, if we need. We have shown we can archive and preserve for the future. We have shown that knowledgeblog is good for grey literature. We have added DOIs. Multiple authors. Good looking maths. We even have some preliminary stats on how much publication costs from Word doc to website.

At the moment, though, we do not have a business model. It is clear that if we are to move this forward, it needs to be run as a service, managed, and looked after, something which is neither my expertise or desire. The analogy that I have made earlier with Wikipedia is, I think, a good one; it would be good to move this into a foundation status.

The path from here to there is a long one, however. For the moment, we will restore knowledgeblog, and it will re-emerge, although at this time of year, it will take a while. But we look to the future as well.

My first visit to Oslo was in 2006. That time, it was for work and we were some distance away from town. I remember the flight in gave a dramatic impression, and I remember sitting in the conference centre, looking over the hill side, breathing in the thick scent of pine watching the sun slowing crawl toward the horizon at about 11pm. I only got into town the once, on the last night, and saw little of it which I was disappointed about. My second visit to Norway was to Trondheim and I enjoyed that as well.

So I was looking forward to visiting Oslo again, for a few days, doing the tourist thing. But I am afraid that I have been disappointed again; this city has not really grabbed me. The architecture is impressive at points, but there is a random, thrown-together quality about the city overall; nothing to rival the magnificence that is Grainger Town in Newcastle. And some of the signature buildings are, again, just okay; the Opera House has a roof you can walk up, but that seems to be it. The night time is subdued to say the least, and the food is okay at best. The only stand out feature seems to be an extra-ordinary number of sculptures — mostly bronzes, and often not famous people. Lots of nudes in heroic poses; the number involving seals is also distinctly above the average.

Of the two best things I have seen are, first the Sculpture Park. Very classically laid out garden, but with some really very good sculpture, full of character and life. And seals. And second, the folk museum, which shows Norweigian life and buildings at different stages of history. I have to admit, though, that I was at a loss to see the difference, because over the last 4-500 years, this seems to basically have involved making robust, timber buildings on stilts. While the museum is good, I think, having less buildings, but better explained would improve it. When you get down to it, one wooden farmhouse looks very like another, especially when you can see it only from the outside.

Perhaps the biggest surprise though has been the accessibility for pushchairs. In Oslo, this is never an afterthought; they just have not thought about it at all. The tram doors slam on you if you take too long, which may happen if, say, you are struggling to get a heavy, unwieldy, pram-shaped object through a narrow door. My visit to the Opera House was limited to walking around the lobby, as walking up a sloping roof, with nothing but “slippery when wet” signs to break a clear run to the fjord is not my idea of fun. My visit to the National Gallery involved 20 steps to get in, to discover that the pushchairs are banned in the exhibition area; still, hey, you can visit the shop. Looking through the door of the National Museum (only 10 stairs up) and I could see a line of buggies next to the security guard. I didn’t even bother.

Although in some disciplines, it is relatively uncontentious, the rise of open access publishing has produced a lot of comment in others. In one of my two disciplines, computing science, this form of publication is still the minority, and still raises comment. For instance, Michel Beaudouin-Lafon has commented suggesting this scientists are highly naive about the costs of publishing. He argues that scientific publishing is intrinsically expensive, and that open access will have negative implication for science as a whole.

Over the years, commercial STM publishing has become a cutthroat business with cutthroat practices and we, the scientific and academic community, are the naive lambs, blinded by the ideals of science for the public good-or simply in need of more publications to advance our careers.

— Michel Beaudouin-Lafon

Personally, I think that “naive” is the wrong word; scientists are often not good at operating in a co-ordinated way. Although, we work together in small groups, and sometimes in large groups, in general, we are still very much a cottage industry; at any one time the number of scientists working in a distinct discipline is not that large, even on a world-wide basis. Of course, this works pretty well for scientific advance; we are not a production industry, but researcher. No one knows the best way forward, and we need to experiment to find out. But it does mean that we often play second fiddle to those capable of more co-ordinated action; compare for example, scientists to the medical community with its tightly controlled professional bodies. Or, of course, the STM publishing industry, particularly as it has become focused in fewer and fewer competing publishers.

For example, ACM spends several million dollars every year to support the reliable data center serving the Digital Library

— Michel Beaudouin-Lafon

Clearly, it is true that the cost of data centres and storage are not trivial. But the cost of servicing data has plummeted over recent years. Scientific papers largely consist of storing words and figures; these do not take up much space. The laptop I am working on has a copy of my email directory; it’s not complete but it carries most of my outgoing email since 1994 and a lot of the incoming; this is a lot of words! But the total size is now less than 5G, which will fit on a 3 pound pen drive, or my phone. Now if ACM were storing research data, then it would be a totally different issue; the costs here are significant, problematic and rising. But they do not.

The ACM might spend several million dollars a year, but the bottom line here is that this does not account for the cost of publishing. The Wikimedia foundation which supports Wikipedia spends around 10 million dollars a year, in total, on one of the top ten websites in the World. This is about the daily cost of the whole scientific publishing industry.

The quality of a journal is typically measured by its impact factor

— Michel Beaudouin-Lafon

And a very bad measurement of journal quality it is too. As someone who works in two disciplines at once, I constantly get hit by this: my best computing publications have laughable impact factors when compared to my bio publications; when judged against computer scientists, however, my bio publications have such high impact factors, that they have to be ignored as outliers.

At $5,000 per publication, my lab is broke.

— Michel Beaudouin-Lafon

It is not clear where the $5,000 figure comes from, as most open access is less than this. But, anyway, this argument makes no sense. Our labs are already paying a vast amount of money for publications; usually this is squirrelled away in overheads, taken from our budgets before we see the money. And, although it doesn’t happen so much in computing, many journals levy significant page charges.

They are the big pharmaceutical labs and the tech firms who publish very little but rely on the publication of scientific results for their businesses. With author-pay, research will pay so that industry can get their results for free. Is this moral?

— Michel Beaudouin-Lafon

Open access on its own is not enough. we also need public disclosure about the process. Perhaps the examples of the pharmaceutical funding journals directly are unusual. It is not so easy to tell at the moment. In this context, it could be argued that the last thing we need is the pharmaceutical industry paying for the results of science. Of course, conversely, the pharmaceutical industry could argue that they already do pay for the (publically funded) research by way of taxation.

While they are interesting, all of these arguments really miss the point: the pharmaceutical industry already get their results for free, as their subscription fees do NOT pay for the research just its publication. The publishing industry also get the results that they depend on for free or with page-charges by charging the authors. And for every paper that researchers publish for free, they pay more to read someone elses.

So, we are already in the situation that we are told is not moral.

It is important to understand that the scientific community is largely at fault

— Michel Beaudouin-Lafon

There is some truth in the idea that scientific community has let itself walk into the situation, but ultimately I feel, that this is like blaming the financial crises on those recieving subprime mortgages. It is true that it is scientists who submit their best work to expensive closed publishers; but, especially in early and mid “career”, we do this to safe-guard our futures.

The problem with the subscription model is not the model but the fees.

— Michel Beaudouin-Lafon

Quite the opposite. Ultimately, I don’t pay the fees, so how much do I really care? But the subscription model prevents re-purposing, it limits access, it prevents competition. I work at a university as a scientist because I value the ability to be able to swap and discuss my work. I want the general public to be able to access my research. Dissemination of knowledge should be part of my job; I think it is reasonable that I, or my employers, should pay for it.

Which is not to say that the level of fees are fine; they are not. They are far to expensive under any model.

The added value provided by publishers is twofold: reputation (the value of the imprimatur), and archiving (the guarantee that the work will be available forever).

— Michel Beaudouin-Lafon

And this is it? Is this all that we are getting, given the costs? Especially the the reputation comes from the work, not the journal, and the archiving should be a rapidly decreasing cost.

Actually, in practice, I think the current publishing industry brings more value; selection of reviewers, sometimes copy-editing and, critically, advertising of the content. But, again, times have changed, and publishing practice in these areas has not.

The only other area in publishing where authors pay to get published is called the vanity press. Do we really want to enter that model?

— Michel Beaudouin-Lafon

This is a low blow, nor is it true. Many people pay for their own publishing costs. The government pays to publish election results; health service pay to publish public health information; companies pay to publish product safety recalls. All circumstances where the value to the author of public awareness of their content far exceeds the income they would recieve from charging. And the biggest example of this is the advertising industry.

Nor is the implication that this will necessarily result in low quality true. Consider the blogosphere; of course, there is much junk, the standard of science journalism is very high; frankly, when ever respecting sources like the BBC start talking about pixie dust, it’s probably at least as high-standard the as mainstream media.

All this aside, what do I, as a scientist, actually care about? Some of these leap to mind:

• Stable location and content.
• archiving
• peer review
• discovery and selection

Open access was built on the basis of replicating the existing publication. PLoS for example did this precisely so that it did not challenge both the business model and the publication procedure at the same time. How much of the costs stem from this? I think that we, as authors and readers, should know. How much of the millions the ACM spends on it’s data centre is involved in managing access controls, for example? How much on advertising? How much at booths at meetings?

Open access has opened the door, but now we need to challenge and change the process. Hosting data is not free nor is archiving. And, yet, I can find own my website from 2002 and enjoy it’s gaudy colour scheme all again. If this blog post is so exciting to the world, that the load brings the server down, you will be able to read it on coral cache. The peer review is expensive and time-consuming; I know because I’ve organised enough of it for BioOntologies. But then I did not get paid for this and how many of the real costs of peer-review do publishers bear? And discovery and selection? Well, we have google, and I follow my peers on twitter.

Author fees are not a solution. […] Finally, nonprofit publishers should take advantage of their unique position to experiment with sustainable evolutions of their publishing models.

— Michel Beaudouin-Lafon

And on this, I could not agree more. Our experiment with Knowledgeblog suggests that we can get 90% (or 80% or 70% depending on who you ask) with commodity software. It’s only a small start, but then I was on the mailing list that saw the first email about the creation of wikipedia, and that wasn’t long ago.

This is a paper we wrote for STLR2011 also published directly on Knowledgeblog

Abstract

Authors

Phillip Lord Newcastle University Newcastle-upon-Tyne, UK

Simon Cockell Newcastle University Newcastle-upon-Tyne, UK

Daniel C. Swan Newcastle University Newcastle-upon-Tyne, UK

Robert Stevens University of Manchester Manchester, UK

Introduction

The Web was invented around 1990 as a light-weight mechanism for publication of documents, enabling scientists to share their knowledge, in the form of hypertext documents. Although scientists and later most academics, like the rest of society, have made heavy use of the web, it has not had a significant impact on the academic publication process. While most journals now have websites, the publication process is still based around paper documents or electronic representations of paper documents in the form of a PDF. Most conferences still handle submissions in the same way¹. Books on the web, for example, are often limited to a table of contents.

For the authors (certainly from our personal experience), the process is dissatisfying; book writing is time-consuming, tiring and takes a number of years to come to fruition. If the book has one or a few authors, it tends to reflect only a narrow slice of opinion. Multi-author collected works tend to be even harder work for the editor than writing a book solo. Books do not change frequently; they are therefore out-of-date as soon as they are available. Authors feel a greater pressure for correctness, as they will have to live with the consequences of mistakes for the many years it takes to produce a second edition; most scientists welcome feedback, but being asked to justify something you wish you had not said becomes tiresome, especially if you are waiting to update it.

For the consumer of the material (either a human reader, or a computer), the experience is likewise limited. Books on paper are not searchable, not easy to carry around, are often not cheap to buy and more commonly very expensive to buy. For the computer, the material is hard to understand, or to parse. Even distinguishing basic structure (where do chapters start, who is the author, where is the legend for a given figure) is challenging.

All of this points to a need to exploit the Web for scientists to publish in a different way than simply replicating the old publishing process. Here, we describe our experiment with a new (to academia!) form of publishing: we have used widely-available and heavily used commodity software (WordPress [7]), running on low-end hardware, to develop a multi-author resource describing the use of ontologies in the life sciences (our main field of expertise). From this experience, we have built on and enhanced the basic platform to improve the author experience of publishing in this manner. We are now extending the platform further to enable the addition of light-weight semantics by authors to their own papers, without requiring authors to directly use semantic web technologies, and within their own tool environment. In short, we believe that this platform provides a ‘cheap and cheerful’ framework for semantic publishing.

The requirements

The initial motivation for this work came from our experience within the bio-ontology community3. Biomedicine is one of the largest domains for use of ontology technology, producing large and complex ontologies such as the Gene Ontology [28] or SNOMED [27].

As an ontologist, one of the most common questions that one has is: ‘where is there a book or a tutorial that I can read which describes how to build an ontology?’. Currently, there is some tutorial information on the web, there are some books; but there is not a clear answer to the question. Many of the books are collections of research-level papers, or are technologically biased. Currently many ontologists have learned their craft through years reading mailing lists, gathering information from the web and by word of mouth. We wished to develop a resource with short and succinct articles, published in a timely manner and freely available.

We wished, also, however to retain the core of academic publishing. This was for reasons both pragmatic, principled and political. Consider, for example, Wikipedia, that could otherwise serve as a model. Our own experience suggests that referencing Wikipedia can be dangerous: it can and does change over time meaning critical or supportive comments in other articles can be ‘orphaned’. Wikipedia maintains a ‘neutral point-of-view’ which, many are of the opinion, makes it less suitable for areas where knowledge is uncertain and disagreement frequent. Finally, Wikipedia is relatively anonymous in terms of authorship: whether this affects the quality of articles has been a topic of debate [17], but was not our primary concern; pragmatically, the promotion and career structure² for most academics requires a form of professional narcissism; they cannot afford to contribute to a resource for which they cannot claim credit. Of course, our experiences may not be reflective of the body academic overall; there has, for example, been substantial discussion of the issues of expertise on Wikipedia itself [8]. Although the reasons may not be clear, it is clear that academics largely do not contribute to Wikipedia, and that Wikimedia sees this as an issue [16].

We also had an explicit set of non-functional requirements. We needed the resource to be easy to administer and low-cost, as this mirrored our resource availability; authors should be offered an easy-to-use publishing environment with minimal ‘setup’ costs, or they would be unlikely to contribute; readers should see a simple, but reasonably attractive and navigable website, or they would be unlikely to read.

The Ontogenesis experience

Our previous experience with the use of blog software within academia was limited to ‘traditional’ blogging: short pieces about either: the process of science (reports about conferences, or papers for example); journalistic articles about other peoples research; or, personal blogging, that is articles by people who just happen to be academics. Although we wished to develop different, more formal content, this experience suggests that many academics find blogging software convenient, straight-forward enough and useful.

To test this, we decided to hold a small workshop of 17 domain experts over a two day period, and task them with generating content, conduct peer-review of this content and publish it as articles on a blog.

Terminology and the Process

Like many communities, the blogosphere has developed its own and sometimes confusing terminology. To describe the process we adopted we first describe some of this terminology. A blog is a collection of web pages, usually with a common theme. These web pages can be divided into: posts that are published (or posted) on an explicit date and then unchanged; and pages that are not dated and can change. Posts and pages have permalinks: although they may be accessible via several URLs, they have one permalink that is stable and never changes. Posts and pages can be categorised – grouped under a predefined hierarchy – or tagged – grouped using ad hoc words or phrases defined at the point of use. A blog is usually hosted with a blog engine, such as WordPress that stores content in a database, combines it with style instructions in themes to generate the pages and posts. Most blog engines support extensions to their core functionality with plugins. Most blogs also support comments or short pieces of content added to a post or page by people other than the original authors. Most blog engines also support trackbacks which are bidirectional links: normally, a snippet from a linking post will appear as a comment in the linked to post. Trackbacks work both within a single blog and between different distributed blogs. Many blogs support remote posting: as well as using a web form for adding new content, users can also post from third party applications, through a programmatic interface using a protocol such as XML-RPC or even by email. Posts and pages are ultimately written in headless HTML (that part of HTML which appears inside the body element), although the different editing environments can hide this fact from the user.

Our initial process was designed to replicate the normal peer-review process, with a single adjustment, that peer-review was open and not blind: papers would be world-visible once submitted; the identities of reviewers would be known to authors; all reviews would be public. We adopted this approach for pragmatic reasons. WordPress has little support for authenticated viewing and none for anonymisation. The full process was as follows:

• Authors write their content and publish using which ever tooling they find appropriate.

• The author posts their content, categorising it as under review.

• An editor assigns two reviewers.

• Reviewers publish reviews as posts or comments. Reviews link to articles, resulting in a trackback from article to review.

• The author modifies the post to address reviews.

• Once done to the editors satisfaction, the post is recategorised as reviewed.

Our expectation was that following this process, articles would not be changed or updated; this is in stark contrast to common usage for wiki-based websites. New articles could, however, be written updating, extending or refuting old ones.

Reflections on the Ontogenesis K-Blog

Our initial meeting functioned to ‘bootstrap’ the Ontogenesis K-Blog. This was useful to acquire a critical mass of content, but also, on this first outing, to explore the K-Blogprocess and technology. The setup for the day was the vannilla WordPressinstallation. The day started with a short presentation on the K-Blogmanifesto [22] and an overview of the process, including authoring and reviewing. The guidelines to authors were to write short articles on an ontology subject (a list of suggestions was offered and authors also made their own choices) and to produce the article in whatever manner they felt appropriate. There was a certain level of uncertainty among authors as to the K-Blogprocess (partly because one of the objectives of the meeting was to ‘force out’ the process) and this, naturally, pointed to the need to document the K-Blogprocess so that authors could have the typical ‘instructions to authors’.

This first meeting produced a set of 20 completed and partially completed articles. Some even had reviews. Even on the day itself there was some external interest seen from Twitter. The first external blog post (outside of those produced by attendees) happened during the meeting [19] with a second shortly after [18].

We also held a second content provision meeting and together these generated a collection of articles that felt like an academic book in terms of content, but generated with considerably less effort. This experience was also sufficient to gather requirements on how to improve the K-Blogidea. A useful K-Blogon the K-Blogprocess itself was produced by Sean Bechhofer [13]. There is also a K-Bloglooking back on the first year of the Ontogenesis K-Blog [23].

Several requirements emerged with respect to authorship. The principle of the short, more or less self-contained article was attractive (though the audience were somewhat self-selecting). Authoring directly in the editor provided by WordPress was felt to be poor by those that tried it. Authoring in a favourite editing tool and then publishing via WordPress worked reasonably well for most authors. There were, however, a variety of issues with the mechanism of this style of publishing; referring to articles that will be, but have not yet, been written. To some extent this was an artefact of the day (many articles being written simultaneously), but authors needed to refer to glossaries and articles in progress.

One stylistic issue was the habit of putting full affiliations at the top of an article. The ontogenesis theme presents the first few lines when displaying many articles, but in many cases this was simply showing the title and author affiliation; where it would be more useful to have the first sentence or so of the article itself.

For the whole K-Blog, a table of contents was felt to be important. This would give an overview of contents and a simple place for navigation about the K-Blog. This raised the issue of attribution; the table of contents needed to expose the authors, including multiple, ordered authors. This is not an unsurprising need, as the authors’ scientific reputation is involved. In this vein, making K-Blogarticles citable by issuing of Digital Object Identifiers (DOI) was requested.

For scientific credibility, the ability to handle citations easily was an obvious requirement. Natively, WordPresshas little or no support for styling citations and references. The ability to cite via DOI and, in this field, PubMed identifiers to automatically make links and produce a reference list was felt to be important. Also, having the Ontogenesis K-Blogarticles in PubMed would also be attractive to authors.

The last authorship issue was the mutability of articles. One aim of K-Blogis to enable articles to change in the light of experience and scientific development, as well as a procedural requirement for updates following review. There was felt to be a conflicting need for articles not to change, so that comments and links from other documents work in the longer term.

The last significant issue was the reviewing of articles. The aim was to have this managed by authors choosing reviewers (with editorial oversight). On the Ontogenesis K-Blogday this could work with authors calling across the room for a review. This is, however, not a sustainable approach. WordPress, however, lacks tracking facilities to manage the reviewing process, whether this is done by an author or an editor. The realisation that such management support is needed is not the greatest insight ever gained, but the requirement is there even in a light weight publishing mechanism.

Improvements to the technology

Our initial experiment with the ontogenesis K-Blogsuggested a significant number of issues with the use of WordPressfor scientific publication. In this section, we describe the extensions that we have made or used to the publication process, documentation or to WordPressitself. Following our initial experience with Ontogenesis, we have started to trial these improvements, including through another workshop which resulted in a new K-Blog [12], describing the scientific workflow engine Taverna [24]; work is also in progress on the use of a K-Blogfor bioinformatics [1], and another for public healthcare [3].

Currently, we have 11 plugins extending the basic WordPressenvironment. For completeness, all of these are shown in Table 1. Our theme is also extended in some places to support the plugins. In general, the plugins are orthogonal and will work independently of each other. One advantage of using WordPressis that many of these plugins are freely available, written and maintained by other authors; while other academic publication environments, such as the Open Journal System [5] exist and are relatively widely-used, but WordPress is used to host perhaps 10% of the web, making the plugin ecosystem extremely fertile.

Reviewing: The initial process was self-managed and required two reviews per article; this was found to be cumbersome. We have addressed this in two ways; first, we have defined a number of different peer-review levels (public review, author review, editorial review [15]), including a light-weight process now being used for Ontogenesis; authors now select their own reviewers, and decide for themselves when articles are complete. Second, we have added software support. Initially, we attempted to use RequestTracker – an open source ticket system, but found the user interface too complex for this purpose. We are now using the EditFlow plugin to WordPress that was designed for managing a review process—albeit a hierarchical rather than peer-review process.

Authoring Environment: The standard WordPresseditor was found impractical by most authors, even for short articles. WordPressdoes provide ‘paste from word’ functionality, but this removes all formatting which defeats the point. While the lack of a good editing environment could have been a significant problem, our subsequent experimentation has shown that it is possible to post directly from a wide variety of tools, including ‘office’ tools such as Word, Google Docs, LiveWriter and OpenOffice. This is in addition to a variety of blog-specific tools and text formats (such as asciidoc), which are suitable for some users. We have added documentation to a kblog (http://process.knowledgeblog.org) to address these. In practice, only L^aT_eX proved problematic having no specific support. To address this, we have produced a tool called latextowordpress; this is an adaptation of the plasT_eX tool, a python based T_eX processor, to produce simplified HTML appropriate for WordPresspublishing. Our experience with using the tools is that while none are perfect, sometimes requiring ‘tweaking’ of HTML in WordPress, most reduce publishing time to seconds.

Citations: We have addressed the lack of support for citations within WordPresswith a plugin called kcite. This allows authors to add citations into documents as shortcodes with either a DOI or Pubmed ID (other identifiers can and are being added to kcite). Shortcodes are a commonly used form of markup of the form: [tag att=”att”]text[/tag]; they are often found where a simplified HTML-like markup is desired. A bibliography is then generated automatically on the web server. Requiring authors to add markup to otherwise WYSIWYG tools is damaging to the user experience. We believe that this is soluable, however, by extending bibliographic tools, by developing a ‘kcite’ style-file or template; we have a prototype of this (using CSL [10]) for Zotero and Mendeley, and another for asciidoc with bibtex. It is also possible to just use native tool support in Word or L^aT_eX, and convert bibliographies to HTML; the disadvantage with this approach is discussed later.

Archiving and Searching: Archiving is primarly a social, rather than technological, problem. A blog engine is fully capable of storing content in the long-term, but authors and readers have to believe that it will do so. As a novel form of academic publishing, K-Blogis not automatically archived by as a scientific journal. However, we have taken advantage of its web publication; the main K-Blogsite is now explicitly archived by the UK Web Archive, as well as implicitly by other web archives. We have enhanced the website with an ‘easy crawl’ plugin–that is a single web page pointing to add articles classified as reviewed. We now support the (technical) requirements for LOCKSS and Pubmed. Simultaneously, this also enhances the searchability of K-Blog, fulfilling the requirements for Google scholar.

Non-repudiability: The K-Blogprocess does not allow authors to make semantically meaningful changes after an article has been reviewed. Unfortunately, it is hard to define ‘semantically meaningful’ computationally, so we have made no attempt to address this by locking articles; rather, all versions of articles are now accessible to the reader (WordPressprovides this facility to the authors by default). This enables community enforcement of a no-change policy.

Multiple Authors: We believe that authoring is best done outside WordPress. This also means that we do not support multiple-authorship; we have made no attempt to add collaborative features to WordPress. However, we did need articles to carry a byline attributing the articles to multiple authors; although not critical to the functioning of a K-Blog, it is socially critical to appease the professional narcissism (see Section ) of scientists. Fortunately, this is a common requirement, and a suitable WordPressplugin existed.

Identifiers: WordPress already supports permalinks; although we believe that URLs are entirely fit for purpose technologically while DOIs do little other than introduce complexity [11], K-Blogrequired DOIs for professional narcissism. We considered becoming an DOI authority, but this proved impractical. Instead, we have used DataCite [2]. This has required a small extension to WordPress to extract appropriate metadata and to store the DOIs once minted.

Metadata: K-Blognow uncovers various parts of its metadata in a number of ways; unfortunately, there appear to be a large number of (non-)standards in use, each with its own application. K-Blogcurrently provides: COiNS, enabling integration with Zotero and Mendeley; meta tags for Google Scholar; and Dublin Core tags for no specific reason than completeness. We are in the process of providing bibtex export (for bibtex!), and a JSON representation to support citeproc-js [14] in the second generation of kcite.

Mathematics and Presentation: We have also provided several pieces of technology that did not stem from concrete requirements arising from the initial Ontogenesis meeting. We have improved parts of the presentation system by adding, for example, syntax highlighting to code blocks. Additionally, we have created the mathjax-latex plugin enabling the use of T_eX(or MathML) markup in posts that are then rendered in the browser using scalable fonts. WordPresshas native math-mode T_eX support, but using image fonts which do not scale and have an ugly pixelated display.

Discussion

We have been motivated by a lack of enthusiasm for traditional book publishing to devise another mechanism by which we can achieve the same ends. We wished to avoid the downsides of an ‘all or nothing’ approach to creating a ‘static’ paper document that is read by relatively few people due to price. The K-Blogapproach allows authors to publish in a piecemeal fashion; writing only that which they are motivated to write using a mechanism that avoids a third party making arbitrary decisions on formatting with peculiar time-scales.

To avoid all this, the K-Blogis a light-weight publishing process based on commodity blogging software. We have taken an approach of writing short articles around a theme of ‘ontology in biology’; the Ontogenesis K-Blog. At the time of writing we have 26 articles and page viewing numbers that are pleasing (see Figure 1). These statistics are generated by WordPressdirectly, and represent (an approximation of) ‘real’ page reads, with robot and self-viewing removed. This is confirmed by the ten most read articles (Table 2) that reflect our expectations – ‘What is an ontology’ being first. In this sense, we consider the K-Blogprocess to be a success, especially when considered against the circulation of an equivalent book.

Figure 1: Month page view statistics for the Ontogenesis K-Blog.

The social processes with K-Blogare largely similar to traditional publishing, with one exception – reviewing is public. While we may have been interested in experimenting with this for principled reasons, in practice we adopted it because we did not know how to support blind anonymous review with WordPress. Open review is not a new idea: Request For Comments are common in standards processes; both Nupedia [4] (the fore-runner of Wikipedia) and H2G2 [6] (which predates Nupedia) use public peer-review. It is still, however, unusual in academia. In our experience from Ontogenesis, it raised no worries from among our contributors, except that reviewers often wanted to be more involved in the proofing, a role normally played by authors low down the author list; open review processes blurs these lines somewhat.

One open area for the discussion is the extent to which authors can, should be and wish to change articles after publication. While the ability to update is inherent in the web, the desire for non-repudiability was considered to be important; the contradiction here appears fundamental, and we do not feel we have reached a good compromise yet. In one sense, our use of the post-revision display plugin solves this problem; even if the article changes, it is still possible to refer to a specific version. However, like all automated versioning tools, many versions get recorded often with very fine-grained changes, which makes selection of the ‘right’ version hard to impossible. We could replace this with an explicit versioning tool, similar to a source code versioning system; but these systems are hard-to-use for those unused to them, as well as being difficult to implement well. An environment like K-Blog, however, does allow rapid publication of and bi-directional linking with articles; combined with typed linking with CiTO, the ability to publish erratum, addendum and second editions may be a better solution.

Our experiences with K-Blog, we think, are useful in understanding how semantic web technology can and will impact on the publication and library process. Both from our initial work with Ontogenesis, and subsequent work with http://taverna.knowledgeblog.org, it has become obvious that good tool support is critical. ‘Good’ in this sense can be straight-forwardly interpreted as ‘familiar’ that in general can be interpreted as MS Word. Our choice of a blogging engine here was (unexpectedly) well-advised, as this form of publication is already supported by many tools. It is also clear that there are many other tools that could be added; while Ontogenesis has the content, for example, that might be found in an academic book, it does not currently have the presentation of the book. Articles are already available as ePUB, and more recent work has used our Table of Contents plugin to provide a single site-wide ePUB of all articles [25]. Pre-existing tools such as Anthologize [9] may also be useful for adding organised collections of articles gathered from the whole.

This has a direct implication on the addition of further semantics to content. On the positive side, the use of WordPress makes semantic additions plausible in a way that many conventional publishing processes do not. For example, the publication of our (PWL, RS) recent paper [20] required conversion from the LaTeX source to PDF (by latex), to another PDF, to a MS Word file (by hand), to XML before arriving at the final HTML form. This process took many weeks, required multiple interactions between the authors and publisher. It still failed to preserve the semantic use (to humans) of Courier font highlighting in-text ontology terms and requiring post-publication correction. The equivalent blog post [21] gave us nearly instantaneous feedback on the final form, allowing us to check that the semantics was present and correct.

The requirements for semantics have, however, to be light. We have concentrated throughout K-Blog on the ease of delivery of content; even with this focus, it is hard. In most cases, asking for more work, for more semantics than authors are used to giving in papers is problematic. For example, I (PWL) attempted to add microformat-based markup to Ontogenesis, again, identifying ontology terms. So far, all article authors have ignored this markup (including, embarrasingly, myself).

One solution to this issue is to ensure that authors themselves benefit directly from extra semantics. For example, the Mathjax-Latex plugin allows WordPressto present mathematics in T_eX or MathML markup in the final document, which is more semantically meaningful than the default WordPress behaviour of rendering an image. From the authors perspective, it also enables the use of T_eX markup in Word, and the end product scales and looks less ugly on the web page.

With Kcite, we allow the user to embed DOIs or Pubmed IDs; this can be achieved at no cost to the user, if they already use a bibliography tool, as it can transparently produce citations for them using Kcite shortcodes. Development versions of Kcite already allow easy switching of bibliographic style that we hope will become at the option of the author (rather than the website or publisher as is currently the case), and/or the reader. With this additional information, we can also embed more semantics into the end document at no additional cost to the author, using for example the least specific CiTO cites term. However, further use of CiTO that will require the author to decide which term to use, with relatively little gain to themselves, and may require extension to bibliographic tools if we are to maintain transparency of Kcite shortcodes; even if the tools are present, it is unclear whether authors will use them. We note that semantics useful to domain authors is likely to be domain-specific; mathematicians are more likely to care about maths presentation, but less likely to care about Pubmed IDs. We need to be able to extend the publishing model and environment for different journals to cope.

From a technological perspective, we have found the use of shortcodes to be a good mechanism for readers to add semantics. They are simple and relatively easy to understand. In some cases they can be hidden from the user entirely; forcing users to add markup to otherwise WYSIWYG environments such as MS Word is best avoided. Although the direct use of a more standard XML markup would seem more sensible, in practice it requires tool support, as XML markup will be escaped by helpful remote posting tools. Extension of remote posting tools is hard (for tools like MS Word) or impossible (for cloud tools such as Google Docs or LiveWriter). A blogging engine such as WordPress makes it trivial to replace shortcodes both with a presentation format and machine interpretable microformat; for example, the development version of Kcite transforms DOI short codes ([cite]10.232/43243[/cite]) into in-text citations (Smith et al, (2002)) embedded in a span tag (<span kcite-id="10.232/43243">Smith et al, (2002)</span>) that are subsequently transformed into final presentation form within the browser using Javascript. The presentation form can also support additional semantic markup such as CiTO [26].

Although we believe that additional semantics are a good thing, we will not enforce a requirement for additional semantics on authors. If authors choose not to use kcite, then this is their choice. We need to show that they are useful. Our experience with many (non)standards such as CoINS, DOIs, OAI-ORE, LOCKSS is that they are not simple, speaking primarily to publishers or librarians. For a semantic web approach to work, it must focus on authors and readers, as they produce and consume the content. Extracting even light-weight semantics even from authors who are ontology experts is hard. For other domains, the situation may be worse.

Current publishing practices make use of semantic web technology impractical; semantics added by authors are unlikely to be represented correctly if the end product is a PDF typeset by hand. More over, we can see little point adding semantics to individual articles if this is done in a bespoke way. With K-Blog, we have focused on providing both content, and a full process, with review, using existing tools and workflows, adding semantics secondarily or incidentally where we can. As a result, the level of semantics that we have achieved is light-weight. However, we believe that K-Blog and WordPress combined with associated tooling provides all the basic requirements for a publishing process, and that it provides an attractive framework on which to build a semantic web.

Acknowledgements

We would like to acknowledge the contribution of the authors of articles for both the Ontogenesis and Taverna K-Blog, whose feedback was essential for this process. K-Blogis currently funded by JISC.