Tawny-OWL [1] is a library which enables the programmatic construction of OWL [2]. One of the limitations with tawny as it stands is that it did not implement numeric, semantics free identifiers [3]; tawny builds identifiers from the clojure symbols used to describe the class. So, in my pizza ontology, for instance, PizzaTopping gets an iri ending in PizzaTopping. Semantics free identifiers have some significant advantages; the principle one is that the establish an identity for an object which can persist even if the properties (the labels for instance) change, as I have described previously [4].

However, semantics-free identifiers do not come for free; they also have significant disadvantages, mainly that they make the life of developers harder and code less readable [3]. I’ve previously suggested solutions to this problem when it afflicts OWL Manchester syntax [5].

With tawny, the IRIs that are used to identify concepts can easily be separated from the clojure symbols that are used to identify them; the initial link between them was simply one of convienience. So supporting numeric IRIs was possible with very little adjustment of the core owl.clj required one fixed function call to become a call to a first-class function.

One of purposes of tawny is to enable to a more agile development methodology than we have at present, so clearly I did not want the developer to have to manage this process by hand. Moreover, as recent discussions on the OBI mailing list, the issue of co-ordination of identifiers can be a significant difficult. As James Malone has recently described, there the URIgen tool offers a solution to this problem [6]. Simon Jupp who is the primary developer of URIgen kindly discussed the details with me, which has helped me form my ideas about a suitable workflow, and I have borrowed heavily from URIgen (and the protege plugin) for this. While I will probably implement a URIgen client for tawny in the future, my initial approach uses a slightly different idea. In general, with tawny, I have been advocating using standard software development tools, instead of specific ontology ones [2]; rather than co-ordinating developers through the use of a centralised server, it seems to me to make more sense to use whatever version control system. To that end, I have implemented a file based system for storing identifiers; given that most bio-ontologies remain under the 50,000 terms size, I think that this is plausible, especially as it is simply in tawny to modularise the source (if not the ontology which remains a hard research problem). In this case, I have used a properties files, since it is a simple and human-readable format.

This works as follows. First, we define a new ontology, with an iri-gen frame, which use the obo-iri-generate function. Of course, this is generic so it is possible to use arbitrary strategies for generating an IRI.

(defontology pizzaontology
  :iri "http://www.ncl.ac.uk/pizza-obo"
  :prefix "piz:"
  :comment "An example pizza using OBO style ids"
  :versioninfo "Unreleased Version"
  :annotation (seealso "Manchester Version")
  :iri-gen tawny.obo/obo-iri-generate
  )

Next, we need to restore the mapping between names and IRIs. We need to do this before we create any classes. In the first instance, this file will be empty, and will contain no mappings; this is not problematic.

(tawny.obo/obo-restore-iri "./src/tawny/obo/pizza/pizza_iri.props")

Now, we define concepts, properties and so forth as normal.

(defclass CheeseTopping
  :label "Cheese Topping")
(defclass MeatTopping
  :label "Meat Topping")

The difference in how the IRI is created should be transparent to the developer at this point. Behind the scenes were are using this logic.

(defn obo-iri-generate-or-retrieve
  [name remembered current]
  (or (get remembered name)
      (get current name)
      (str obo-pre-iri "#"
           (java.util.UUID/randomUUID))))

Or, in English: if the name (“CheeseTopping”) has been stored in our properties file, use this IRI; or if the name has already been used in the current session use this IRI, failing that, create a random UUID. I have used a UUID rather than autominting new identifiers because tawny is programmatic; it is very easy to create 1000 concepts where you meant to create 10 which would result in a lot of new identifiers. It makes more sense to mint permanent identifiers explicitly, as part of a release process.

This also works for programmatic use of tawny, regardless of whether concepts are added to the local namespace. This code creates many classes all at once, but does not add them to the namespace. Their IDs will still be stored.

(doseq [n (map #(str "n" %) (range 1 20))]
  (owlclass n)
   )

Finally, we need to store the IRIs we have created. Both full IDs and UUIDs are stored; so new classes will get a random UUID, but it will persist over time, providing some interoperability with external users who can use the short-term identifier in the knowledge that it may change.

(tawny.obo/obo-store-iri "./src/tawny/obo/pizza/pizza_iri.props")

At the same time, we report obsolete terms. These are those with permanent identifers, which are present in the properties file, but have not been created in the current file. Currently, these are just printed to screen, but I could generate classes and place them under an “obsolete” superclass.

(tawny.obo/obo-report-obsolete)

Finally, at release point, a single function is called to generate the new IDs. This is done numerically, starting from the largest ID. If there are multiple developers, this step has to be co-ordinated, or it is going to break; but this is little different from a release point of any software project.

(tawny.obo/obo-generate-permanent-iri "./src/tawny/obo/pizza/pizza_iri.props" "http://www.ncl.ac.uk/pizza-obo/PIZZA_")

I think this workflow makes sense, but only use in practice will show for sure. If the requirement for co-ordination over minting of real IDs is problematic, then URIgen would provide a nice solution. I can also see problems with my use of props files; I have sorted them numerically which makes them easier to read (and predicatably ordered), but this has the disadvantage that changes are likely to happen near the end, which is likely to result in conflicts. While these would be relatively simple conflicts, merging is necessarily painful. This could be avoiding by storing permanent IDs in one file, and UUIDs in per-developer files.

This is the last feature I am planning to add to the current iteration of tawny; I want to complete the documentation for all functions (this has already been done for owl.clj, but not the other namespaces), and the tutorial. For the 0.12 cycle, I plan to make tawny complete for OWL2 (basically, this means adding datatypes).

This articles describes a SNAPSHOT of tawny, available on github (https://github.com/phillord/tawny-owl). All the examples shown here, come from (yet another!) version of the pizza ontology, also available on github (https://github.com/phillord/tawny-obo-pizza).

References

1. P. Lord, "Programming OWL", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2214
2. P. Lord, "The Semantic Web takes Wing: Programming Ontologies with Tawny-OWL", An Exercise in Irrelevance, 2013. http://www.russet.org.uk/blog/2366
3. P. Lord, "Semantics-Free Ontologies", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2040
4. P. Lord, "Permalink Semantics", An Exercise in Irrelevance, 2011. http://www.russet.org.uk/blog/1908
5. P. Lord, "OBO Format and Manchester Syntax", An Exercise in Irrelevance, 2009. http://www.russet.org.uk/blog/1470
6. J. Malone, "Keeping it Agile: the secret to a fitter ontology in 4* easy** steps!", James Malone's EBI Blog, 2013. http://jamesmaloneebi.blogspot.co.uk/2013/04/keeping-it-agile-secret-to-fitter.html

Abstract

Semantic publishing can enable richer documents with clearer, computationally interpretable properties. For this vision to become reality, however, authors must benefit from this process, so that they are incentivised to add these semantics. Moreover, the publication process that generates final content must allow and enable this semantic content. Here we focus on author-led or "grey" literature, which uses a convenient and simple publication pipeline. We describe how we have used metadata in articles to enable richer referencing of these articles and how we have customised the addition of these semantics to articles. Finally, we describe how we use the same semantics to aid in digital preservation and non-repudiability of research articles.

• Phillip Lord
• Lindsay Marshall

• http://arxiv.org/abs/1304.7151

Plain English Summary

Academic literature makes heavy of references; effectively links to other, previous work that supports, or contradicts the current work. This referencing is still largely textual, rather than using a hyperlink as is common on the web. As well as being time consuming for the author, it also difficult to extract the references computationally, as the references are formatted in many different ways.

Previously, we have described a system which works with identifiers such as ArXiv IDs (used to reference this article above!), PubMed IDs and DOIs. With this system, called kcite, the author supplies the ID, and kcite generates the reference list, leaving the ID underneath which is easy to extract computationally. The data used to generate the reference comes from specialised bibliographic servers.

In this paper, we describe two new systems. The first, called Greycite, provides similiar bibliographic data for any URL; it is extracted from the URL itself, using a wide variety of markup and some ad-hoc tricks, which the paper describes. As a result it works on many web pages (we predict about 1% of the total web, or a much higher percentage of “interesting” websites). Our second system, kblog-metadata, provides a flexible system for generating this data. Finally, we discuss ways in which the same metadata can be used for digitial preservation, by helping to track articles as and when they move across the web.

This paper was first written for the Sepublica 2013 workshop.

Our original intention with Greycite [1] was to build a tool which can provide bibliographic metadata for any URL, to support my own kcite referencing tool [2]. While it still fulfils this function, it also turns out to be a useful, general-purpose tool for investigating the metadata in various web pages. And this reveals some interesting results. We discovered a nice example of this recently while adding RIS support.

The paper in question comes from EMBO reports [3]. At first sight, the RIS for this page taken from Greycite looks reasonable.

TY - ELEC
UR - http://www.nature.com/embor/journal/v14/n3/full/embor201311a.html
Y2 - 2013-04-18 12:54:54
TI - The economics of creative research
JO - EMBO reports
PY - 2012
DA - 2012-02-08
DO - 10.1038/embor.2013.11
AU - Cou|[eacute]|e, Ivan
ER -

However, something strange is going on with the author; poor old Ivan Couée’s name has been rather broken. So, why is this happening? Looking at the underlying HTML the first thing that hits you is a lot of space; there are over 50 empty lines at the beginning of the file; still, this is only a problem for people strange enough to be reading the HTML.

However, eventually we get to the metadata, first dublin core and what we describe as Google Scholar (since this is where we found it). And there we have it; greycite is reporting the metadata as it is. The author’s name is represented with |[eacute]| as a letter.

<meta name="dc.language" content="en" />
<meta name="dc.rights" content="&#169; 2012 Nature Publishing Group" />
<meta name="dc.title" content="The economics of creative research" />
<meta name="dc.creator" content="Ivan Cou|[eacute]|e" />
<meta name="dc.identifier" content="doi:10.1038/embor.2013.11" />
<meta name="dc.date" content="2012-02-08" />

<meta name="citation_publisher" content="Nature Publishing Group" />
<meta name="citation_authors" content="Ivan Cou|[eacute]|e" />
<meta name="citation_title" content="The economics of creative research" />
<meta name="citation_date" content="2012-02-08" />
<meta name="citation_volume" content="14" />
<meta name="citation_issue" content="3" />
<meta name="citation_firstpage" content="222" />
<meta name="citation_doi" content="doi:10.1038/embor.2013.11" />
<meta name="citation_journal_title" content="EMBO reports" />

As far as we can tell this is an error; HTML attributes or extended character sets are entirely valid, but |[eacute]| does not appear to be a valid representation. Interestingly enough, there also appears to be some slightly buggy code in the PRISM metadata, which I am sure should not be this.

<meta name="prism.issn" content="ERROR! NO ISSN" />
<meta name="prism.eIssn" content="ERROR! NO EISSN" />

My guess is that the problem is at the point of website generation rather than deeper in the bowels of the publishing system; grabbing the metadata for this article from CrossRef by content negotiation [4] shows the correct name.

{"volume":"14",
 "issue":"3",
 "DOI":"10.1038/embor.2013.11",
 "URL":"http://dx.doi.org/10.1038/embor.2013.11","title":"The economics of
        creative research",
 "container-title":"EMBO reports",
 "publisher":"Nature Publishing Group",
 "issued":{"date-parts":[[2012,2,8]]},
 "author":[{"family":"Couée","given":"Ivan"}],
 "editor":[],"page":"222-225",
 "type":"article-journal"}

We emphathise with the publishers here. Getting character sets correct is the bane of everyones life; given the state of computing when multi-lingual character sets appeared, we guess it is not an example of premature optimisation, but an example of an optimisation you wish had never happened. The world would be an easier place if everything that used unicode from the start.

The current metadata for this paper can be seen on greycite or in detail. Hopefully, this will be updated in time!

This post was written by Phillip Lord and Lindsay Marshall

Update

Spelling mistake corrected, bibliography added. Thanks to Christian Perfect for bug report.

References

1. L. Marshall, and P. Lord, "GreyCite", GreyCitehttp://greycite.knowledgeblog.org/
2. S. Cockell, and P. Lord, "KCite Plugin", Knowledge Blog, 2011. http://knowledgeblog.org/kcite-plugin
3. I. Couée, "The economics of creative research", EMBO reports, vol. 14, pp. 222-225, 2012. http://dx.doi.org/10.1038/embor.2013.11
4. . gbilder, "Content Negotiation for CrossRef DOIs | CrossTech", CrossTech, 2011. http://www.crossref.org/CrossTech/2011/04/content_negotiation_for_crossr.html

Much has been said about overlay journals [1]. The idea is simple; the journal essentially becomes a selector, a channel, with the paper itself being hosted elsewhere, such as arXiv.

This holds a certain amount of attraction for me; I already post my new papers on arXiv. I have been posting them here also [2]. This works well, but is hampered by technology. Mostly I write papers in LaTeX, and I have written tools to make these suitable for WordPress [3]; these work well enough to publish an entire thesis [4]. However, the process of doing this is not slick [5]. For instance, when trying to publish one of my own papers, I have had problems as I used a theorem environment [6]. While PlasTeX is a nice tool, the key problem is that it is fundamentally a different interpreter from TeX. Eventually, perhaps, LuaTeX will get an HTML backend, but until this happens the system will always fail in some cases.

So, I wanted to investigate whether it was possible to build Overlay functionality into a personal publication framework, such as the WordPress installation I host these articles on. Well, it turns out combined with the tools that I have written for manipulating metadata [7], it is relatively simple to do so; my first attempt at this is now available for my OWLED 2013 paper [8]. The title, authors (just me in this case), date, abstract and PDF link all come directly from arXiv. Full text is not available from arXiv — anyway it would suffer from all the issues described earlier; in the end, the PDF is probably the best representation of this paper. I have supplemented this with a plain English summary, something that I have wanted to do for years, but have not managed to start. If the reviewers will allow me to do so, I will also attach these when they become available.

The code for this is not quite ready to release yet: however, it will potentially work over any eprints repository, and I have connected it up to Greycite also [9], so it can be used over any source that greycite can interpret.

All a little clunky, but I think that this is the future. The Journal is dead, Long Live the article.

Update

Fixed DOI.

References

1. . gowers, "Why I've also joined the good guys", Gowers's Weblog, 2013. http://gowers.wordpress.com/2013/01/16/why-ive-also-joined-the-good-guys/
2. P. Lord, "Realism and Science", An Exercise in Irrelevance, 2010. http://www.russet.org.uk/blog/1713
3. P. Lord, "Latex to WordPress", An Exercise in Irrelevance, 2010. http://www.russet.org.uk/blog/1740
4. A. Lister, "PhD Thesis: Table of Contents", the mind wobbles, 2013. http://themindwobbles.wordpress.com/2013/01/02/phd-thesis-table-of-contents/
5. . @wordpressdotcom, "Converting a Latex Thesis to Multiple Wordpress Posts", the mind wobbles, 2012. http://themindwobbles.wordpress.com/2012/06/14/converting-a-latex-thesis-to-multiple-wordpress-posts/
6. P. Lord, "An evolutionary approach to Function", Journal of Biomedical Semantics, vol. 1, pp. S4, 2010. http://dx.doi.org/10.1186/2041-1480-1-S1-S4
7. P. Lord, "Kblog Metadata Plugin", Knowledge Blog, 2012. http://knowledgeblog.org/kblog-metadata
8. P. Lord, "The Semantic Web takes Wing: Programming Ontologies with Tawny-OWL", An Exercise in Irrelevance, 2013. http://www.russet.org.uk/blog/2366
9. L. Marshall, and P. Lord, "GreyCite", GreyCitehttp://greycite.knowledgeblog.org/

Abstract

The Tawny-OWL library provides a fully-programmatic environment for ontology building; it enables the use of a rich set of tools for ontology development, by recasting development as a form of programming. It is built in Clojure - a modern Lisp dialect, and is backed by the OWL API. Used simply, it has a similar syntax to OWL Manchester syntax, but it provides arbitrary extensibility and abstraction. It builds on existing facilities for Clojure, which provides a rich and modern programming tool chain, for versioning, distributed development, build, testing and continuous integration. In this paper, we describe the library, this environment and the its potential implications for the ontology development process.

• Phillip Lord

• http://arxiv.org/abs/1303.0213

Plain English Summary

In this paper, I describe some new software, called Tawny-OWL, that addresses the issue of building ontologies. An ontology is a formal hierarchy, which can be used to describe different parts of the world, including biology which is my main interest.

Building ontologies in any form is hard, but many ontologies are repetitive, having many similar terms. Current ontology building tools tend to require a significant amount of manual intervention. Rather than look to creating new tools, Tawny-OWL is a library written in full programming language, which helps to redefine the problem of ontology building to one of programming. Instead of building new ontology tools, the hope is that Tawny-OWL will enable ontology builders to just use existing tools that are designed for general purpose programming. As there are many more people involved in general programming, many tools already exist and are very advanced.

This is the first paper on the topic, although it has been discussed before here.

This paper was written for the OWLED workshop in 2013.

Reviews

Reviews are posted here with the kind permission of the reviewers. Reviewers are identified or remain anonymous at their option. Copyright of the review remains with the reviewer and is not subject to the overall blog license.

Review 1

The given paper is a solid presentation of a system for supporting the development of ontologies – and therefore not really a scientific/research paper.

It describes Tawny OWL in a sufficiently comprehensive and detailed fashion to understand both the rationale behind as well as the functioning of that system. The text itself is well written and also well structured. Further, the combination of the descriptive text in conjunction with the given (code) examples make the different functionality highlights of Tawny OWL very easy to grasp and appraise.

As another big plus of this paper, I see the availability of all source code which supports the fact that the system is indeed actually available – instead of being just another description of a “hidden” research system.

The possibility to integrate Tawny OWL in a common (programming) environment, the abstraction level support, the modularity and the testing “framework” along with its straightforward syntax make it indeed very appealing and sophisticated.

But the just said comes with a little warning: My above judgment (especially the last comment) are highly biased by the fact that I am also a software developer. And thus I do not know how much the above would apply to non-programmers as well.

And along with the above warning, I actually see a (more global) problem with the proposed approach to ontology development: The mentioned “waterfall methodologies” are still most often used for creating ontologies (at least in the field of biomedical ontologies) and thus I wonder how much programmatic approaches, as implemented by Tawny OWL, will be adapted in the future. Or in which way they might get somehow integrated in those methodologies.

In this article, I consider the practical issues with archiving of scientific material placed on the web; I will describe the motivation for doing this, the background and consider the various mechanisms for doing so.

As part of our work on knowledgeblog [1], we have been investigating ways of injecting the formal technical aspects of the scientific publication process into this form of publication. The reasons for this are myriad: if the scientist can control the form, they can innovate in their presentation how they choose; the publication process itself becomes very simple and straight-forward (as opposed to the authoring, which is as hard as it ever way). Finally, it means that scientists can publish as they go, as I have done and am doing on my work with Tawny-OWL. This latter point has many potential implications: firstly, it makes science much more interactive — scientists can publish things that they are not clear on, early ideas and can (and I do) get feedback on this early; secondly, it should help to overcome publication bias as it is much lighter-weight than the current publication process. Scientists are more likely to publish negative results if the process is easy and not expensive. And, lastly, it can help to establish provenance for the work; if every scientists published in this way, scientific fraud would be much harder, as a fraudulant scientist would have to produce a coherent, faked set of data from the early days of the work.

However to achieve this, posts must still be available. The scientific record needs to be maintained. Now, this should not be an issue. I write this blog in Asciidoc [2], and rarely use images, so the source is quite small. In fact, since I moved to WordPress in 2009 [3], it totals about 725k; so it would fit on a floppy, which is a crushing blow to my ego. So, how easy is it to archive your content?

The difficulty here is that there is no obvious person to do this. Like many universities, I have access to an eprints archive. Unfortunately, this is mainly used for REF, and has no programmatic interface. The university also has a LOCKKS box. However, this is not generally available for the work that the University staff has produced, but journals that the University has bought; so I have to give my work away to a paywall publisher, or pay lots to an open access publisher to access this.

Another possibility would be to use Figshare. Now, I have some qualms about Figshare anyway; it appears to be a walled garden, the Facebook of science. Others, however, do not worry about this and are using Figshare. Carl Boettiger [4], for instance archives his note book on Figshare. But there is a problem: consider the 2012 archive; it is a tarball, with Markdown files inside; I know what to do with this, but many people will not. And it is only weakly linked to the original publication link. Titus Brown had the same idea [5], and claiming the added value of DOIs, something I find dubious [6]. Again, though, the same problem; Figshare archives the source. The most extreme example of this comes from Karthik Ram who has published an Git repository; unsurprisingly, it is impossible to interact with as a repo.

Figshare likes to make great play of the fact that it is backed by CLOCKKS — this is a set of distributed copies maintained by some research libraries. Now, it might seem sensible that CLOCKKS would offer this service (at a price, of course) to researchers. Perhaps they do. But the website reveals nothing about this. And, although, I tried they did not respond to emails either. Rather like DOIs, the infrastructure is build around scale; in short, you need a publisher or some other institution involved; all very well, but this contradicts the desire for a light-weight publication mechanism. There is a second problem with CLOCKKS; it is a dark archive, that is, its content only becomes available to the public after a “trigger event”; the publisher going bust, the website going down and so on. Now data which is on the web and, critically, archived by someone other than the author essentially becomes non-repudiable and time-stamped. I can prove (to a lower-bound) when I said something. And you can prove that I said something even if I wish I hadn’t. In a strict sense, this is true if the data is in CLOCKKS; but in a practical sense, it is not, as checking when and what I said becomes too much of a burden to be useful.

So, we move onto web archiving. The idea of web archiving is attractive to me for one main reason; it is not designed for science. It is a general purpose, commodity solution, rather like a blog engine. If one thing scientific publication needs more than anything, it is to move the technology base away from bespoke and toward commodity.

One of the most straight-forward solutions for web archiving is WebCite; the critical advantage that this has is that it provides an on-demand service. I have been using it for a while to archive this site; greycite [7] now routinely submits new items here, if we can extract enough metadata from them. The archiving is quick, rapid and effective. The fly-in-the-ointment is that WebCite has funding issues and is threatened with closure at the end of 2013. The irony is that it claims it needs $25,000 to continue. Set against the millions put aside for APCs [8], or the thousands NPG claims is necessary to publish a single paper [9], or the millions that ACM spends supporting its digital library [10], this is small beer, and it shows the lack of seriousness with which we take web archiving. I hope it survives; if it does, Gunther Eysenbach, who runs it, tells me that the plan to expand the services they offer. It may yet become the archiving option of choice.

I have been able to find no on-demand alternative to WebCite. However, there are several other archives available. I have been using the UK Web Archive for a while now. I first heard about this service, irony or ironies, on the radio. Since I first used it to archive knowledge blog and later used it to archive this site, the process has got a lot easier. No longer do I need to send signed physical copyright permission; first it was electronic (email I think). It now appears that the law is changing to allow them to archive more widely (the BBC covered this in a story, categorized under “entertainment and arts” and which is largely focused on Stephen Fry’s tweets), although this will be a dark archive. Currently, this journal has been archived only once; from my other sites, it appears that they have a six month cycle. So, while this provides good digital preservation, it is a less good solution from the perspective of non-repudiablility; there is a significant gap before the archive happens, and a slightly longer one till the archive is published.

The UKWA is, as the name suggests, is UK specific. Another solution is to use, of course, archive.org, which might be considered to be the elephant in the room for web archiving. Unlike the UKWA, they don’t take submissions, but just crawl the web (although I suspect that the UKWA will start doing this also now). Getting onto a crawl can, therefore, be rather hit-and-miss. Frustratingly, they do have an “upload my data” service, which you can access through a logged in account; but not an “archive my URL” service. Again, a very effective resource from a digital preservation resource, but with similar problems to the UKWA from a point-of-view of non-repudiablilty. The archives take time to appear; in my experience, somewhat longer than the UKWA. I have also contacted their commercial wing, http://archive-it.org. Their software and the crawls that the offer could easily be configured to do the job, but unfortunately, they are currently aimed very much at the institutional level: their smallest package provides over around 100Gb of storage; this blog can be archived in around 130Mb (this is without deduplication which would save a lot); even a fairly prolific blogger comes in at around 250Mb. The price, unfortunately, reflects this. Although, again, it is on a par with my yearly publication costs, so is well within an average research budget.

Of course, these solutions are not exclusive; with greycite we have started to add tools to support these options. For instance, kblog-metadata [11], now supports an “archives” widget which is in use on this page; this links directly through to all the archives we know about. For individual pages, these are deep links, so you can see archived versions of each article straight-forwardly. The data comes from greycite, which we discover by probing; we may move later to using Mementos. greycite itself archives metadata about webpages, so we link to this also. As a side effect, these also mean that each article is submitted to greycite, which in turn causes archiving of the page through WebCite. Likewise, archive locations are returned within the BibTeX downloads, which is useful for those referencing sites.

Finally, greycite now generates pURLs — these are two-step resolution URLs which work rather like DOIs (or actually DOIs operate like pURLs, since as far as I am aware, pURLs predate the web infrastructure for DOIs). These resolve directly to the website in question. With a little support greycite can track content as and if it moves around the web; even if this fails, and an article disappears, greycite will redirect to the nearest web archive.

In summary, there is no perfect solution available at the moment, but there are many options; in many cases, archiving will happen somewhat magically. As we have found with many other aspects of author self-publishing on the web, it is possible to architecturally replicate many of the guarantees provided by the scientific publication industry through the simple use of web technology. Tools like greycite and kblog-metadata are useful in uncovering the archives that are already there, and linking these together with pURLs. Taken together, I have a reasonable degree of confidence that this material will be available in 10 or 50 years time. Whether anyone will still be reading it, well, that is a different issue entirely.

References

1. P. Lord, "Knowledge Blog", Knowledge Blog, 2009. http://knowledgeblog.org/
2. P. Lord, "Posting to a Knowledge Blog in asciidoc", The Knowledgeblog Process, 2011. http://process.knowledgeblog.org/167
3. P. Lord, "New Day, New Blog", An Exercise in Irrelevance, 2009. http://www.russet.org.uk/blog/1175
4. C. Boettiger, "Carl Boettiger", Lab Notebook, 2013. http://www.carlboettiger.info/index.html
5. T. Brown, "Posting blog entries to figshare", Living in an Ivory Basement, 0. http://ivory.idyll.org/blog/posting-blog-entries-to-figshare.html
6. P. Lord, and S. Cockell, "The Problem with DOIs", An Exercise in Irrelevance, 2011. http://www.russet.org.uk/blog/1849
7. L. Marshall, and P. Lord, "GreyCite", GreyCitehttp://greycite.knowledgeblog.org/
8. "RCUK announces block grants for universities to aid drives to open access to research outputs", 2012. http://www.rcuk.ac.uk/media/news/2012news/Pages/121108.aspx
9. A. Jha, "Open access to research is inevitable, says Nature editor-in-chief", the Guardian, 2012. http://www.guardian.co.uk/science/2012/jun/08/open-access-research-inevitable-nature-editor
10. P. Lord, "The Naivete of Scientists", An Exercise in Irrelevance, 2011. http://www.russet.org.uk/blog/1924
11. P. Lord, "Kblog Metadata Plugin", Knowledge Blog, 2012. http://knowledgeblog.org/kblog-metadata

HEFCE is currently asking for feedback on the role of Open Access in the next REF. While I have a a number of technical suggestions, I think that the biggest and best contribution that the next HEFCE could make to the next REF is to state pubically that all journal/conference/venue metadata be removed from papers before they are sent for review.

It is time that we stopped judging books by their cover. It would be a fantastic contribution if HEFCE could take a lead on this. This is my full response.

Expectations for Open Access

I feel that one key issue is missing from this document. Scientists still have problems in some areas (including mine of computing science) in that the “high-impact” journals or conferences often provide no or prohibitively expensive open access options. In this past, I have refused to publish in these journals because I wish my work to remain open access and instead published elsewhere. However this works directly against my own interests in the current REF as the research will be judged less good. The use of journals as a primary indicator of quality, also works against my ability to choose cheaper venues. Few people believe statements that research will not be judged on publication venue; indeed, as an individual academic, I have even been told to directly comment on the venue in my return.

One simple and yet enormous contribution that procedures for the next REF could make to Open Access is to not to coerce, but to remove this enormous barrier. This could happen simply and straight-forwardly by removing all journal and publication venue metadata from papers when presented to reviewers. Of course, this reviewers could work around this (the data is a google search away), but the message sent by such a step would be enormous.

The general expectations for OA publishing seem reasonable. However, I think, I would add a further specific requirement. Currently, it is very hard to find the location of a green OA copy of any article. Making articles available is not enough; they must be discoverable. Therefore, I would suggest that a specific requirement that a primary identifier (DOI, ISSN, ISBN or URL) must be present in the institutional repository, and this must be visible on the web page and present in computational metadata. Finally, making the paper discoverable is also not enough. There must be computational and human-readable metadata making clear the contents of the paper are Open Access; without this form of explicit statement, the only safe course of action for readers to take is assume the copyright default position that you cannot use the material.

Institutional Repositories

Despite the significant investment, our experience is that few people ever retrieve data from institutional repositories. Partly, this is because it is difficult to link between articles on a journal website and articles in institutional repositories. As a second problem, institutional repositories provide an inconsistent experience, both for computational and human access. For instance, the presentation of identifiers such as DOIs is inconsistent. Even when present DOIs are often inaccurate, containing syntactic errors, which prevent their usage.

Ultimately, institutional repositories would be much better if there were a single infrastructure maintained at a national level (or international). In fact, a strong exemplar for this already exists in the form of arXiv. The ability to update the could be devolved to individual institutions. An authentication framework for this is already in place through JE-S.

Linking between institutional repositories and subject repositories unfortunately is likely to be difficult from a social perspective; there are many subject repositories and the institutional repositories are not likely to link to them well, because they are not experts in these repositories. This might be more plausible in a single national repository.

The better solution is to enable authors of papers to perform this linking. Scientists who actually care about the links working and being to the correct place are best place do this. This could be supported in the REF, by making linking to data, software or other subject repositories an explicit criteria in REF; this happens in some disciplines (for example, in bioinformatics a clear statement of if and where software is available and under what conditions is often asked for by reviewers).

Approach to Exceptions

If exceptions are to be for a transitional period, then they any exceptions given should be marked with a “sell-by” date, after which they should no longer be considered valid.

It is worth reiterating that embargoes really only benefit the publishers; ensuring that the REF framework allows academics to choose their publication venue more freely, rather than effectively requiring them to publish in selected “high-impact” venues would enable them to choose venues with short, or no embargo period. The most effective mechanism for achieving this would be to remove all publication venue information from future REF returns. The research would be judged on the basis of the research, and not the publication venue.

Open Data

There is more complexity behind the requirement for open data than for open access, particularly where the data needs to remain confidential for reasons of data protection. Having said all of this, there are many disciplines (again bioinformatics is an obvious example) where the majority of data is open. Making a decision now to rule this out of scope, for a REF which may be a significant distance in future seems premature.

Recently, I was contacted by a Kcite [1] user who had found an interesting problem. They had cut-and-paste a DOI from the American Society of Microbiology article [webcite], and then used this in a blog post. But it was not working. The user actually did identify the problem, which was a strange character in the DOI.

So, I decided to investigate a bit futher. Looking at the source for the page, and the DOI appears mostly fine; it is not formatted according to CrossRef display guidelines [2], but they are hardly alone in this.

<span class="slug-doi">10.1128/​AAC.01664-10
</span>

However, looking a bit further into this at the binary of this source and we see this:

00006260: 2020 2020 2020 2020 203c 7370 616e 2063           <span c
00006270: 6c61 7373 3d22 736c 7567 2d64 6f69 223e  lass="slug-doi">
00006280: 3130 2e31 3132 382f e280 8b41 4143 2e30  10.1128/...AAC.0
00006290: 3136 3634 2d31 300a 2020 2020 2020 2020  1664-10.

The character “e2808b” is “zero width space” in UTF-8. The first time I saw this, my initial inclination was to suggest that it is the publishers being a pain and trying to prevent automatic harvesting of DOIs.

Actually, I suspect that this is not the case, as the DOI is in the page metadata:

<meta content="10.1128/AAC.01664-10" name="citation_doi" />

It is also present in multiple other locations, in their social bookmarking widgets. And there it is unmolested by spaces. So, why have they done this? The answer, I think, is that they display their DOI in a widget which is “cleverly” written to appear static on the screen (well, sort of, but this is a different story). And their widget is not wide-enough; the space is non-joining, so it allows them to control where the line break will happen. None the less, this piece of insanity prevents cutting and pasting of the DOI, and worse does so in a way which is very hard to detect for humans at least. To the extent that this kind of error even gets into institutional repositories, which significantly hinder their usefulness [3]. A quick check suggests this is ubiquitous for the American Society of Microbiology website. Consider:

• http://jvi.asm.org/content/87/7/3903.full
• http://cmr.asm.org/content/26/1/2.full
• http://jcm.asm.org/content/51/4/1066.full

The CrossRef display guidelines are a little bit ambiguous here. Technically, as the zero-width space cannot be seen, it could be considered within the guidelines. I shall write to them to find out.

In case, this article sounds overly pious, I have to raise my hand here in shame, as I have used the same technique for different purposes. An article that I published yesterday on inline citations for kcite [4] uses zero-width joiners to break up a short-code, so that it is displayed rather than interpreted. If the example is cut-and-paste from the article into a new wordpress post, it will not work because of it. I will fix this soon, using unicode entities for the brackets instead.

Update

Thanks to some swift action by Geoff Bilder, CrossRefs display guidelines have now been updated. While it will take a while, the knock-on effects of this change will be significant.

References

1. S. Cockell, and P. Lord, "KCite Plugin", Knowledge Blog, 2011. http://knowledgeblog.org/kcite-plugin
2. "DOI display guidelines"http://www.crossref.org/02publishers/doi_display_guidelines.html
3. J. Cope, "OA DOI resolver status update", eRambler, 2013. http://erambler.co.uk/blog/doi2oa-status-update/
4. P. Lord, "Inline Citations with Kcite", The Knowledgeblog Process, 2013. http://process.knowledgeblog.org/309

Adding metadata to article could be done by many people. This could be the author, and in the ideal world, this would be the author. They know most about the content and are best placed to put the most knowledge into it. But, we have to answer the question, why would they do this? We have previously argued that semantic metadata must be useful to the people who producing it [1]. For this, we need tools that extract and consume this metadata.

I discovered a nice example of this recently while reading an interesting paper from Yimei Zhu and Rob Proctor [2], investigating how PhD students use various tools to communicate. I was interested in citing this paper. The paper can be found on the web at the Manchester escholar site [webcite]. What metadata is in this page? Well, our Greycite [3] tool is designed for this purpose; unfortunately, it suggests that there is very little in the way of metadata.

I contacted the escholar helpdesk, and they confirmed that there really is no embedded metadata; greycite has not just missed it. The strange thing is that, several days later, I managed to get to a very similar page [webcite]. It has a different layout and colour scheme, but it’s clearly the same. The bibliographic metadata fields (not easily extractable, sadly!) appear identical. However, investigating the metadata in this page, and we see a very different story. It is full of Dublin Core. It’s not ideally laid out, but it is all that we need for citation.

Unfortunately, there is no link between the two, nor do I know why Manchester has these two different pages; perhaps one is designed to replace the other. And, of course, from the point of view of reader, there is no reason why they would suspect that one contains metadata and the other does not.

The point here is not to criticise Manchester library services. Instead, it is to raise the question, why are the two locations so different in terms of their metadata? My suspicion is that the real answer is simple: very few people have noticed, and no one really cares. It might be argued that metadata must be correct to be useful. The evidence suggests that the inverse is true: metadata must be useful to be correct.

With tools like Greycite [3] and kblog-metadata [4], making the metadata useful is a key aim. Using kcite, I can now reference any article here in journal, or at bio-ontologies [5]. So now kcite users care about the metadata. From this page you can download a bib file for this article, or even for every article on the site (all 500+). This metadata comes directly from Greycite, which in turn scrapes it from this website. So now the site operator (me!) cares. And, I use the bib files to drive the tools that I use to cite my own work. So, now, the author (also me!) cares.

There is a chicken-and-egg situation here; why write the tools to operate over metadata when no one is using the metadata. Fortunately, with kcite we have had a gradual path: first we used DOIs, then pubmed IDs, then arXiv, and now any URI at all. And with Greycite, we have used a lot of heuristics, and quite a few metadata formats. While it has been a significant amount of work, metadata is now making our lives easier. This is the way that it must be.

Update

Typographical correction.

References

1. P. Lord, S. Cockell, and R. Stevens, "Three Steps to Heaven", SePublica 2012, 2012. http://www.russet.org.uk/blog/2054
2. Y. Zhu, and R. Procter, "Use of blogs, Twitter and Facebook by PhD Students for Scholarly Communication: A UK study", In: 2012 China New Media Communication Association Annual Conference, Macao International Conference ; 06 Dec 2012-08 Dec 2012; Macao . 2012., 2012. http://www.escholar.manchester.ac.uk/uk-ac-man-scw:187789
3. L. Marshall, and P. Lord, "GreyCite", GreyCitehttp://greycite.knowledgeblog.org/
4. P. Lord, "Kblog Metadata Plugin", Knowledge Blog, 2012. http://knowledgeblog.org/kblog-metadata
5. P. Lord, "Table of Contents", Bio-Ontologies SIG, 2011. http://bio-ontologies.knowledgeblog.org/table-of-contents

The Mercurial repository for KnowledgeBlog [1] has been starting to show the strain for a while now. Firstly, when it was created we were all new to mercurial; for instance it contains the trunk directory which is really a Subversion metaphor. The second problem is that it is a single large repository, which maps to the development directory on my hard drive; there is now a lot of experimental software on my hard drive which I don’t want in a public enviroment, so I am now faced with either an enormous .hgignore or more “untracked” files than tracked. Not ideal.

At the same time, I have more recently moved mostly toward using git; actually, I still think Mercurial is nicer than git; the interface to the commands is cleaner, and the functionality is not that different. However, there is a fantastic UI, magit, for Emacs, while the equivalent for Mercurial is not as good. This is important to me. So, I wanted to try and address both of the issues at the same time; splitting the repository upon, and move to git.

The process for achieving this turned out to be relatively simply; mercurial comes with a fantastic extension called convert. This is actually a general purpose extension to convert from other VCS systems into mercurial; however, it will also convert one hg repo to another. It has the ability to both filter the existing repo and rename locations at the same time. To create my new repository I used these commands:

mkdir mathjax-latex-hg
cd mathjax-latex-hg
## create filemap.txt
hg init
hg convert --filemap filemap.txt devel-hg-old/ .

which create a new Mercurial repository, and convert the data from the old, tangled repository. The filemap.txt file contains a couple of lines only:

include trunk/plugins/mathjax-latex
rename trunk/plugins/mathjax-latex .

These filter for just the mathjax-latex plugin and move all its files to top level. This is the only part of the process that needs changing to export different parts of the repo, as I done four times now. This now gives me a Mercurial repository in the right shape. Now, we create a new git repo, and import the untangled Mercurial repo into git. Again, reasonably straight-forward. hg-fast-export is the name of the command on ubuntu which is more sensible than original fast-export which is both overly generic, and a hostage to the future.

cd ..
git init mathjax-latex-git
cd mathjax-latex-git
hg-fast-export -r ../mathjax-latex-hg
git checkout HEAD

Finally, the repo needs to be made publicly available, in this case of github. And all is complete.

git remote add origin git@github.com:phillord/mathjax-latex.git
git push -u origin master

Of course, mathjax-latex does not actually need updating, because it is feature complete and working. However, the WordPress plugin page now includes a nasty warning, so I probably need to update it just to avoid this. Bit of a pain, especially the only way of doing this involves updating the Subversion repository, which I don’t actually use. Slightly painful.

References

1. P. Lord, "Knowledge Blog", Knowledge Blog, 2009. http://knowledgeblog.org/

Today, I recieved an email from a journal, asking me if I would review a paper. The paper in question is by, amoung others, Iddo Friedberg, and can be read on arXiv [1]. I’ve known Iddo Friedberg for a while; he was an earlier user of my semantic similarity work [2], for protein function prediction [3], and was also the editor for our paper on realism in ontology development [4]. I would have liked to review this paper, and I feel a little bad because I know these things are important for the careers of the scientists.

So, why did I decline? Well, nice and simple; the page charges are just too high. There is no real justification for this as it can be done much cheaper [5] — £200 or so seems reasonable; more over, I think it is bad for science because it is one of the factors that cause authors to think very carefully, and often save up work for “a bigger publication”. This can delay publication for years after the work has happened. Scientists have to think carefully about their research, and their work; thinking about whether to publish now or later is one piece of baggage that we could do without [6].

The real irony of the situation though is that the peer-review for this paper is and has already happened. The paper concerns bias in Gene Ontology annotations of protein functions. Iddo posted his work to the various Gene Ontology mailing lists; unsurprisingly, the GO annotation team saw the paper, and Rachael Huntley responded. The academic debate has started, and is in full swing. Others may see and contribute. And, frankly, the quality of the discussion going on there, and the depth of the analysis is higher than I would have given. No journal has been involved; it happened because there is a mailing list which the scientists in question used.

The current peer-review system does not add value; my peers and the scientific debate that does this. And this can, and will happen, regardless of the journals; indeed, in this case, why don’t the journal editors just read the mailing list?

So why do scientists, including myself, continue to publish in this way? It can often be difficult particularly where there are no open access options available [7]. We have to; it’s part, indeed, the main part of our assessment [8]. As I have said before, this is now the only reason I publish in this way [9].

Having said this, I do have my doubts. I feel somewhat guilty toward Iddo Friedberg, for instance. There is also a degree of hypocrisy in this — I will still submit to journals (for my own sake, of course, but also for my PhD students); will people, perhaps, wish to not review my articles? What would happen if everybody thought like this (here, I can use the Yossarian defence: then I’d be a damn fool to think any different). If I set the bar at £200, then who will I review for? Well, I do review for conferences and workshops where I can. Still, I feel that this is not enough; people review my work, I should review theirs. So, I state here, that subject to some time constraints, I will happily review work that is posted either to the web in this form, or to sites such as arXiv. Reviews will be posted here, on this blog.

I have my doubts; but open access is not enough. Publication must get lighter, faster and much, much cheaper. I would welcome alternative courses of action.

Many thanks to the Simon Cockell and James Malone who peer-reviewed this post, and provided helpful comments. I am also grateful to Iddo Friedberg who gave me permission to use the story about his paper in this way. The opinions expressed here are, however, my own.

Update

In response to feedback from Mike Taylor, it is worth pointing out that I do not review for paywall journals, and have not for quite a while.

References

1. A.M. Schnoes, D.C. Ream, A.W. Thorman, P.C. Babbitt, and I. Friedberg, "Biases in the Experimental Annotations of Protein Function and their Effect on Our Understanding of Protein Function Space", arXiv, 2013. http://arxiv.org/abs/1301.1740
2. P.W. Lord, R.D. Stevens, A. Brass, and C.A. Goble, "Investigating semantic similarity measures across the Gene Ontology: the relationship between sequence and annotation", Bioinformatics, vol. 19, pp. 1275-1283, 2003. http://dx.doi.org/10.1093/bioinformatics/btg153
3. I. Friedberg, M. Jambon, and A. Godzik, "New avenues in protein function prediction", Protein Science, vol. 15, pp. 1527-1529, 2006. http://dx.doi.org/10.1110/ps.062158406
4. P. Lord, and R. Stevens, "Adding a Little Reality to Building Ontologies for Biology", PLoS ONE, vol. 5, pp. e12258, 2010. http://dx.doi.org/10.1371/journal.pone.0012258
5. . rmounce, "The Gold OA plot v0.2", Ross Mounce, 2012. http://rossmounce.co.uk/2012/09/04/the-gold-oa-plot-v0-2/
6. P. Lord, "Why academic publishing is like a coffee shop", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2248
7. P. Lord, "Open Access and the Semantic Web", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2157
8. D. Colquhoun, "Is Queen Mary University of London trying to commit scientific suicide?", DC's Improbable Science, 2012. http://www.dcscience.net/?p=5388
9. P. Lord, "Bringing Things to Life", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2170

Tawny OWL, my library for building ontologies [1] is now reaching a nice stage of maturity; it is possible to build ontologies, reason over them and so forth. We have already started to use the programmable nature of Tawny, trivially with disjoints [2], as well as allowing the ontology developer to choose the identifiers that they use to interact with the concepts [3]. However, I wanted to explore further the usefulness of a programmatic environment.

One standard facility present in most languages is a test harness, and Clojure is no exception in this regard. Tawny already comes with a set of predicates for testing superclasses, both asserting and inferred, which provides a good basis for unit testing. So, this example using my test Pizza ontology shows a nice example, essentially testing definitions for CheesyPizza — these should in both a positive and negative definition.

(deftest CheesyShort
  (is (r/isuperclass? p/FourCheesePizza p/CheesyPizza))
  (is (r/isuperclass? p/MargheritaPizza p/CheesyPizza))
  (is
   (not (r/isuperclass? p/MargheritaPizza p/FourCheesePizza))))

While ths is nice, it is not enough in some cases where I wanted to test that things that do not happen. For this I introduce a new macro, with-probe-entities which adds “probe classes” into the ontology — that is a class which is there only for the purpose of a test. In this case, I test the definition of VegetarianPizza to see whether MargheritaPizza reasons correctly as a subclass. Additionally, though, I also check to see whether a subclass of VegetarianPizza and CajunPizza — which contains sausage — is inconsistent. This test could be more specific, as it tests for general coherency, although I do check for this independently. The with-probe-entities macro cleans up after itself. All entities (which can be of any kind and not just classes) are removed from the ontology afterwards; so independence of testing is not compromised).

(deftest VegetarianPizza
  (is
   (r/isuperclass? p/MargheritaPizza p/VegetarianPizza))

  (is
   (not
    (o/with-probe-entities
      [c (o/owlclass "probe"
                     :subclass p/VegetarianPizza p/CajunPizza)]
      (r/coherent?)))))

Of course, a natural consequence of the addition of tests is the desire to run them frequenty; more over, the desire to run them in a clean environment. The solution to this turns out to be simple. Travis-CI integrates nicely with github — so the addition of a simple YAML file of this form enables a Continuous Integration, of both the Pizza ontology and the environment (such as Tawny, for instance).

language: clojure
lein: lein2
jdk:
  - openjdk7

The output of this process is available for all to read, along with the tests for my mavenized version of Hermit, and also tawny itself. This is not the first time that ontologies have been continuously integrated [4]; however, the nice advantage of this is that I have not had to install anything. It even works against external ontologies: so we have both GO and OBI. Currently, these work against static versions of GO and OBI. I could automate this process from the respective repositories of these projects, by pulling with git-svn and pushing again to github.

All in all, though, the process of recasting ontology building as a programming task is turning out to be an interesting experience. Much of the tooling that enables collaborative ontology building just works. It holds much promise for the future.

References

1. P. Lord, "OWL Concepts as Lisp Atoms", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2254
2. P. Lord, "Disjoints in Clojure-owl", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2275
3. P. Lord, "Clojure OWL 0.2", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2303
4. C.J. Mungall, H. Dietze, S.J. Carbon, A. Ireland, S. Bauer, and S. Lewis, "Continuous Integration of Open Biological Ontology Libraries", 2012. http://bio-ontologies.knowledgeblog.org/405

A lot has been said about the scientific publication process, and how the publishers add value. I have commented before on the joys of being asked to pay extra page charges for colour pixels [1], which as a naive scientist [2] I would think costs the same as black and white ones. I am not always convinced of the value that is bought but even I am occasionally surprised by how paleolithic the industry can be. An example is a new article on Clojure for concurrency.

The article itself is fine, and I make no comments on it. But the display is highly interesting. Firstly, it uses a nice Javascript paging interface in case your browser is not equipped with scrollbars. If you manage to defeat this (there is a “Display stuff on one page” button), then scroll down to Figure 2 which is a code listing. It is split into two parts: Figure 2 and Figure 2 (continued) — if anyone can tell me why this is a good idea on the web, I’d be interested. Even better, it’s a GIF. An image, of a piece of code. Not easy to say for sure, but it even looks rather like an image of a print out.

Still, all is saved, because if you scroll to the end, you find that all the code is on github. There is even a URL there which takes you straight to it; or, rather, you can cut-and-paste it into your browser, because it’s not hyperlinked, and neither are any of the others.

A quick check suggests that this is normal practice. All a bit of an epic fail really.

References

1. P. Lord, "Bringing Things to Life", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2170
2. P. Lord, "The Naivete of Scientists", An Exercise in Irrelevance, 2011. http://www.russet.org.uk/blog/1924

I have been working on a Clojure library for developing OWL ontologies [1]. There have been two significant advances with this library recently. First, I have changed its name from clojure-owl to tawny-owl. I was never really happy with the original name; I think it is bad practice to name something after the language it uses (even partly, as the many jlibraries attest), and there was several other libraries around for manipulating OWL in clojure, albeit in different ways. “Tawny” is simple and straight-forward and memorable, I think. At the same time, I moved to Github because I can now just updated readme.md, rather than having to update a separate website.

Perhaps, more importantly, I have put in new code for handling change to external ontologies, which is particularly important for external libraries.

Throughout the development of tawny-owl, I have focused on provided an environment that is easy to use for the developer; so, classes, properties and other entities are represented as lisp symbols [2]. This works well and produces very attractive looking code in, for example, my version of the Pizza ontology. I have also written code so that ontologies only available as OWL files can be treated as first-class citizens: very easy in a highly dynamic language like Lisp.

However, it causes problems when combined with an ontology such as OBI [3]. The difficulty here is that OBI uses semantics-free identifiers [4]. While there are some good reasons for this, would result in Clojure of the form:

(defclass OBI:0034322
     :subclass OBI:0034321)

Clearly, this is not good, and something that I want to avoid. So, instead, we apply a transform function to OBI when importing it; basically, this munges the rdfs:label annotation, turning it into something that is a legal Clojure symbol.

  :transform
  ;; fix the space problem
  (fn [e]
    (clojure.string/replace
     ;; with luck these will always be literals, so we can do this
     ;; although not true in general
     (.getLiteral
      ;; get the value of the annotation
      (.getValue
       (first
        ;; filter for annotations which are labels
        ;; is lazy, so doesn't eval all
        (filter
         #(.. % (getProperty) (isLabel))
         ;; get the annotations
         (.getAnnotations e
                          (owl.owl/get-current-jontology))))))
     #"[ /]" "_"
     ))

All well and good. However, there is a problem. The label in OBI has two characteristics. First, it is human readable, which is good, and the reason why we are using it. Second, however, is does not carry formal semantics; the developers are free to change these labels when ever they like. Of course, any ontology that I build against by tawnyized version of OBI will break, because the label has changed. This is not a problem for a GUI like protege, because, perhaps ironically, GUIs are not WYSIWYG — what you see is actually a view of the underlying datamodel. So, protege shows you the label, but actually you are manipulating the URI. A dependency can change their labels, and when Protege reloads it, this is what the developer will see.

With code, on the other hand, there is no separation at all. If the label changes, I will have to update anything that refers to this, which seems a substantial problem. However, I have now managed to work around this. My new library memorise saves all the mappings into a file, then restores them when OBI is loaded. Any old labels that no longer exist but which point to an IRI that still does exist are generated as duplicate symbols pointing to the same OWL object; however, I have done this in a way that they will emit warnings both when loading, and during use, with a description of the new symbol name. This data would also make automatic upgrading possible, of course, using Clojure to perform a big search and replace on the source code. I think that this is a nicer solution than the denormalisation [5] or “colour cube” solution [4] that I previously suggested for Manchester syntax. It also shows off the advantage of using a programming language, rather than a static format; I, or any other user of the library, can just add this, as I choose, without having to wait for standardisation process, and tool support to catch up.

This will still leave a secondary problem; it is dependent on the IRI which for pre-release versions of OBI is not fixed, as documented. Of course, this problem could go away, if OBI used a tool like URIGen, or alternatively if OBI released more regularly. Still, the data should also allow a reverse lookup — finding out what IRI a label now has.

I think these are the main tools that are needed to build against an external resource. The 0.5 version of Tawny is now available on Clojars and Github.

References

1. P. Lord, "Programming OWL", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2214
2. P. Lord, "OWL Concepts as Lisp Atoms", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2254
3. R.R. Brinkman, M. Courtot, D. Derom, J.M. Fostel, Y. He, P. Lord, J. Malone, H. Parkinson, B. Peters, P. Rocca-Serra, A. Ruttenberg, S. Sansone, L.N. Soldatova, C.J. Stoeckert, J.A. Turner, and J. Zheng, "Modeling biomedical experimental processes with OBI", Journal of Biomedical Semantics, vol. 1, pp. S7, 2010. http://dx.doi.org/10.1186/2041-1480-1-S1-S7
4. P. Lord, "Semantics-Free Ontologies", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2040
5. P. Lord, "OBO Format and Manchester Syntax", An Exercise in Irrelevance, 2009. http://www.russet.org.uk/blog/1470

I have been developing a library written in Clojure, that I can use for building OWL ontologies programmatically [1]. The basic idea behind this library is to give me something that looks like Manchester syntax [2], but which is none the less fully programmatic; it can be extended arbitrarily, both for general use and for one-off, single ontology specific custom code.

This has already shown its worth: for example, adding a syntax for “some and only” closure axioms was straightforward; likewise, I can now express disjoints and subclasses implicitly through bracket placement, rather than through named concepts [3]. Although in its early dates, I have added initial support for ontology design patterns — in this case a value partition, which I think will be extended significantly in future versions. I have used this in my version of the Pizza ontology which seemed as good a demonstrator to start with as any [4]; this also contains some custom “one-off” patterns, for building “named” pizzas. Taken together these where enough to constitute the first (unheralded) 0.1 of Clojure-OWL.

However for 0.2, I wanted one more feature that I think makes this now a usable alternative for developing ontologies. I wanted to be able to address ontologies that were built using other technologies, which were accessibly only as an OWL file. Of course, the library has always had the ability to build classes using URIs as strings; this facility means that it is possible to address another ontology. However, I wanted ontologies read from OWL files to be first-class citizens; classes and properties should be represented as lisp symbols [5], providing a degree of safety to the system — it is not possible to refer to a concept not previously defined, nor use a concept where a property is needed.

This turned out to be reasonably straightforward; Clojure-OWL now maps an individual ontology to a clojure namespace. Reading an ontology in from an OWL file is reasonably simple using the OWL API; finally, as a highly dynamic language, clojure can create new symbols on the fly with ease. To test this out, I needed a reasonably large and complex ontology: I choose OBI [6] for reasons of familiarity.

The process of integrating it into Clojure-OWL starts to show the power of this approach. A basic outline of the code to achieve this is simple enough. It requires a location, prefix and an identifier. The location is generic, including a stream, so could be anything. I have include “obi.owl” as a class resource; I can use a URL, but accessing the network every time I wish to use things is a pain, although this would effective provide a form of continuous integration.

(defread obi
  ;; something that the OWL API can interpret. This includes a stream, so
  ;; it's totally generic.
  :location (IRI/create (clojure.java.io/resource "obi.owl"))
  ;; the prefix that you want to use in this case
  :prefix "obo"
  ;; normally only things from this IRI will be imported
  :iri "http://purl.obolibrary.org/obo/"
  )

On its own though, OBI contains a large number of concepts from many different ontologies. Normally, I filter for only entities whose identifier starts with the IRI above. This fails with OBO ontologies which use a sort of namespacing mechanism and a numeric identifier. So I need to apply a custom filter.

  :filter
  (fn [e]
    (and (instance? OWLNamedObject e)
         (.startsWith
          (.toString (.getIRI e))
          "http://purl.obolibrary.org/obo/OBI"
          ))
    )

I can think of many other uses for this sort of filtering; if I want to include a subset of entities then this would work also.

The next problem is OBIs use of semantic-free identifiers [7]. Even if the reasons behind this decision are good, the resulting numeric atoms (OBI_0000107) are useless — I want to be able to say provides_service_consumer_with. So for this I use a custom transform function. This forms the name of the lisp symbol from the label instead, with a regexp fix to remove characters which are illegal — spaces for obvious reasons, and “/” which clojure uses as a namespace qualifier.

  :transform
  ;; fix the space problem
  (fn [e]
    (clojure.string/replace
     ;; with luck these will always be literals, so we can do this
     ;; although not true in general
     (.getLiteral
      ;; get the value of the annotation
      (.getValue
       (first
        ;; filter for annotations which are labels
        ;; is lazy, so doesn't eval all
        (filter
         #(.. % (getProperty) (isLabel))
         ;; get the annotations
         (.getAnnotations e
                          (owl.owl/get-current-jontology))))))
     #"[ /]" "_"
     ))

The final addition is to add the ability to import an ontology into the current; without this, references to another ontology will share URIs, but not pull the referenced ontology with all its axioms into the current namespace. Without this, reasoning will not work as expected. This is achieved with a single form:

(owlimport obi)

Unfortunately, I have had to disable Hermit functionality — our current mavenized version of HermiT [8] is working, but failing a few tests from incompatibilities with the current OWL API. This will be re-enabled in the new version.

Taken together, I think, clojure-owl now represents a reasonable programmatic environment for OWL. We now have the tools we need to replicate the the essential functionality of a tool like Protege; not that I am trying to replace Protege, as I still use it as a viewer for my generated ontologies. But, more over, I can now extend this functionality. As well as importing an ontology, I can filter the import so that only certain entities are available — an ad-hoc form of privacy. In later versions, I will probably add more explicit support for this. We can now package an OWL ontology in a Jar and publish it to any Maven repository. You may love or hate maven (generally, the latter), but being able to resolve dependencies is a strong point, especially as it brings versioning with it.

Release 0.2 is now available on Clojars or Google Code.

References

1. P. Lord, "Programming OWL", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2214
2. M. Horridge, and P.F. Patel-Schneider, "OWL 2 Web Ontology Language Manchester Syntax (Second Edition)", W3C, 2012. http://www.w3.org/TR/owl2-manchester-syntax/
3. P. Lord, "Disjoints in Clojure-owl", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2275
4. . @wordpressdotcom, "Why the Pizza Ontology Tutorial?", Robert Stevens' Blog, 2010. http://robertdavidstevens.wordpress.com/2010/01/22/why-the-pizza-ontology-tutorial/
5. P. Lord, "OWL Concepts as Lisp Atoms", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2254
6. R.R. Brinkman, M. Courtot, D. Derom, J.M. Fostel, Y. He, P. Lord, J. Malone, H. Parkinson, B. Peters, P. Rocca-Serra, A. Ruttenberg, S. Sansone, L.N. Soldatova, C.J. Stoeckert, J.A. Turner, and J. Zheng, "Modeling biomedical experimental processes with OBI", Journal of Biomedical Semantics, vol. 1, pp. S7, 2010. http://dx.doi.org/10.1186/2041-1480-1-S1-S7
7. P. Lord, "Semantics-Free Ontologies", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2040
8. "HermiT Reasoner: Home"http://hermit-reasoner.com/

I have previously described the difficulty that we have had publishing in semantic web conferences [1]; the two main conferences (ESWC and ISWC) both publish with Springer-Verlag, and so provide no open access option.

Although the contents of the paper has been made available now both through arXiv and here, we decided that in the middle of REF madness, it did not make sense to let the work lie there. So, where to publish?

Well, I was inspired by Ross Mounce post [2] showing the various open access options, showing the entertainingly large gap between the price of open access from different publishers; the gap should only be a surprise to those with little understanding of economics; prices relate to what the market can bear and not what a service costs to provide, I have described previously [3]. At the top left of the graph (most permissive license, cheapest article charges) comes MDPI, although the second version of the plot shows cheaper options [4].

I have never published with MDPI before, but I have recently reviewed a paper for them; I am very selective with reviewing these days, but the paper sounded interesting and I had never heard of Future Internet before. So, this seemed like a reasonable bet. Accordingly the paper has just been published and come complete with [5]; a dubious badge of honour if ever there was one [6].

So, how was the experience? On the whole I think it was very positive. The review period was pretty impressive, with a turn around of relatively few days; they seem to have taken the approach to ask reviewers to say no, if they cannot return within a short time. Ironically, our own response to the reviews was much longer delayed by the start of term work bomb, stretching to well over a month. Type setting was efficient and seems to have be done reasonably; this is not a given as previous experience has shown [7].

There are only two things that I dislike; first they offer full-text only as PDF. I use PDFs only under exceptional circumstances these days; the viewers are all clunky and horrible, and total fail when moving between different screen sizes. Especially, given that MDPI offers an XML download, the lack of full-text HTML is a bit surprising. And slightly ironic for a paper discussing web publication.

Secondly, they seem to have adopted a strange policy with respect to publication/acceptance dates. Our original submission recieved this reply:

Thank you very much for your manuscript:

Manuscript ID: futureinternet-22379
Type of manuscript: Article
Title: Three Steps to Heaven: Semantic Publishing in a Real World Workflow
Authors: Phillip Lord *, Simon Cockell, Robert Stevens
Received: 17 August 2012

Yet, by the time the paper was published our submission date has morphed into 22 September 2012. Now we were told that this might happen — apparently, this is their policy if revisions last over a month. Very strange, and I cannot really think of a good reason for not having a submission date which is the same as the date of the submission.

Of course, this does not worry me that much; the work was “submitted” and published on 12th April here [8]. I consider this to be the canonical version of my work [7]. However, as a mechanism for secondary publication, I think, Future Internet seems a reasonable bet.

References

1. P. Lord, "Open Access and the Semantic Web", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2157
2. . rmounce, "A visualization of Gold Open Access options ", Ross Mounce, 2012. http://rossmounce.co.uk/2012/08/30/a-visualization-of-gold-open-access-options/
3. P. Lord, "Why academic publishing is like a coffee shop", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2248
4. . rmounce, "The Gold OA plot v0.2", Ross Mounce, 2012. http://rossmounce.co.uk/2012/09/04/the-gold-oa-plot-v0-2/
5. P. Lord, S. Cockell, and R. Stevens, "Three Steps to Heaven: Semantic Publishing in a Real World Workflow", Future Internet, vol. 4, pp. 1004-1015, 2012. http://dx.doi.org/10.3390/fi4041004
6. P. Lord, and S. Cockell, "The Problem with DOIs", An Exercise in Irrelevance, 2011. http://www.russet.org.uk/blog/1849
7. P. Lord, "Bringing Things to Life", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2170
8. P. Lord, S. Cockell, and R. Stevens, "Three Steps to Heaven", SePublica 2012, 2012. http://www.russet.org.uk/blog/2054

I was recently described by Duncan Hull as waging a one man war for metadata on the web. There is a degree of truth in this, of course. Since Lindsay Marshall [1] and myself started work on Greycite [2] (Lindsay writes it, then I break it, roles both of us are happy with), there is a degree of truth in this. I have found myself continually amazed by which websites do or do not carry metadata. Often there is none whatsoever, and sometimes it’s just wrong.

What is amazing is that many organisations who you think really should have metadata don’t. Toward this end, I have started to compile two pages: metadata irony and metadata awards. At the moment, these are just some pages, but I might make something better if they get long enough. I guarantee that some of the organisations here will surprise you.

Duncan, incidentally, has reasonably good metadata on this blog. Should probably fix his name though.

References

1. L. Marshall, "Lindsay Marshall's Home Page", Catless, 2012. http://catless.ncl.ac.uk/Lindsay/
2. P. Lord, "Greycite", Knowledge Blog, 2012. http://knowledgeblog.org/greycite

When I started work on Clojure-owl the original intention was to provide myself with a more programmatic environment for writing ontologies, where I could work with a full programming language at to define the classes I wanted [1]. After some initial work with functions taking strings, I have moved to an approach where classes (and other ontological entities), are each assigned to a Lisp symbol [2]. I’m using “symbol” rather than “atom” because its a bit more accurate, especially as Clojure uses “atom” with a different meaning.

This means that I now have something which allows me to write ontological terms looking something like this:

(defclass a)
(defclass b :subclass a)

(defoproperty r)
(defclass d
     :subclass (some r b))

While this is quite nice, and looks fairly close to Manchester syntax [3], ultimately, so far all this really provides me with is a slightly complex mechanism for achieving what I could already do; which raises the questions, why not just use Manchester syntax? Why bother with the Lisp if this is all I am to achieve?

I think I have now got to the point where the advantages are starting to show through, as I have started to create useful macros, which operate at a slightly higher level of abstraction from Manchester syntax. I will explain this using examples, perhaps inevitably, based around pizza [4], which I have started to develop using Clojure-owl.

First I wanted to be able to define several classes at once, rather than having to use a somewhat long-winded defclass form for each; for this I have written a macro called declare-classes — perhaps a slight misnomer, as it also adds the classes to the ontology. This example shows the purpose:

  (declare-classes
   GoatsCheeseTopping
   GorgonzolaTopping
   MozzarellaTopping
   ParmesanTopping)

In practice, this may not be that useful for an ontology builder, as it creates a bare class; no documentation, nothing else. It may be useful for forward-declaration (like Clojure declare).

One slightly unfortunate consequence of the decision to use lisp symbols is I know find myself writing a lot of macros. For those who have not used lisp before, most work is done with functions. Macros are only necessary when you wish to extend the language itself. They tend to be more complex to write and to debug, although fortunately are easy to use. Compare, for example, the definition of declare-classes to that of the functional equivalent which uses strings.

(defmacro declare-classes
  [& names]
  `(do ~@(map
          (fn [x#]
            `(defclass ~x#))
          names)))

(defun f-declare-classes
  [& names]
  (dorun
   (map #(owlclass x) names)))

Even in this case, there is more hieroglyphics in the macro — two backticks, one unquote splice and some gensym symbols although Clojure’s slightly irritating lazy sequences and the resultant dorun mean that the two are nearly as long as each other. I suspect that the macros are going to get more complex, however. In most cases, should not be the user of the library that has to cope though.

While this provided a useful convenience, I also wanted a cleaner method for declaring disjoints. Consider this example:

(defclass a)
(defclass b)
(defclass c)

(disjointclasses a b c)

This is reasonably effective, but a pain if there are many classes, as they all need to be listed in the disjointclasses list. Worse, this is error prone; it is all too easy to miss a single class out, particularly if a new classes is added. So, I have now implemented an as-disjoint macro which gives this code:

(as-disjoints
   (defclass a)
   (defclass b)
   (defclass c))

This should avoid both the risk of dropping a disjoint, as well avoiding the duplication. An even more common from is to wish to declare a set of classes as disjoint children. Again, I have provided a macro for this, which looks like this:

 (defclass CheeseTopping)

 (as-disjoint-subclasses
  CheeseTopping

  (declare-classes
   GoatsCheeseTopping
   GorgonzolaTopping
   MozzarellaTopping
   ParmesanTopping))

Although this was not my original intention, these are actually nestable. This gives the interesting side effect that the ontology hierarchy is now represented in the structure of the lisp. Example below is an elided hierarchy from pizza. Lisp programmers will notice I have rather exaggerated the indentation to make the point.

(as-disjoint-subclasses
 PizzaTopping

    (defclass CheeseTopping)

    (as-disjoint-subclasses
         CheeseTopping

        (declare-classes
            GoatsCheeseTopping))

    (defclass FishTopping)
    (as-disjoint-subclasses
        FishTopping

        (declare-classes AnchoviesTopping))

    (defclass FruitTopping)
    (as-disjoint-subclasses
         FruitTopping

         (declare-classes PineappleTopping)))

Of course, it is not essential to do this. The nested use of as-disjoint-subclasses confers no semantics; but it does allow juxtaposition of a class and it’s children.

Being able to build up macros in this way was the main reason I wanted a real programming language; those described here are, I think, fairly general purpose; so, this form of declaration could also be supported in any of the various syntaxes, although it would require update to the tools. However, some ontologies will benefit from less general purpose extensions. These are never going to be supported in syntax specification.

Still, it is not all advantage. Using a programming language means embedding within this language. And this means that some of names I would like to use are gone; http://clojuredocs.org/clojure_core/clojure.core/some [some] is the obvious example. While Clojure has good namespace support, functions in clojure.core are available in all other namespaces; like all lisps, Clojure lacks types which would have avoided the problem. There are other ways around this, but ultimately clashing with these names is likely to bring pain; for example, I could always explicitly reference clojure-owl functions; but writing owl.owl.defclass rather than defclass seems a poor option; hence, some has become owlsome, and comment has become owlcomment. I have decided to accept the lack of consistency and kept only and label; the alternative, taken by the OWL API to appending OWL to everything seems too unwieldy.

References

1. P. Lord, "Programming OWL", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2214
2. P. Lord, "OWL Concepts as Lisp Atoms", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2254
3. M. Horridge, and P.F. Patel-Schneider, "OWL 2 Web Ontology Language Manchester Syntax (Second Edition)", W3C, 2012. http://www.w3.org/TR/owl2-manchester-syntax/
4. . @wordpressdotcom, "Why the Pizza Ontology Tutorial?", Robert Stevens' Blog, 2010. http://robertdavidstevens.wordpress.com/2010/01/22/why-the-pizza-ontology-tutorial/

I’ve been writing a lot of lisp recently, both to extend my Emacs environment for OWL [1], and with my Clojure OWL library [2]. I have been trying out two new modes to support this. The first is paredit.el which I have managed to miss despite knocking out Lisp for years; it’s a work of insane genius; fantastic when it does the right thing, but sometimes I find myself stuck in a rut. This will probably improve over time, but is only going to work when I am writing a lot of lisp.

My initial solution to this problem was to use the paredit cheat sheet. This is good but unfortunately does not scale as it is only available as an image. I was a bit surprised to find that this cheat sheet is actually build on information that is embedded in the paredit source. Paredit uses this for generating help strings. This also makes it possible to generate a menu with examples as tooltips, which I have now done with paredit-menu.el. Code is available on http://code.google.com/p/phillord-emacs-packages/

My second problem was with show-paren mode. This is very useful for lisp, but I find it irritating in other modes. This is particularly the case because of my own pabbrev.el. This offers abbreviation expansions using sq[uare] brackets; even though this are transitory show-paren highlights which produces a rather annoying flickering on screen. Unfortunately, there is no way of blocking this — adding an overlay which blocks show-paren would be the ideal solution. Worse, show-paren, even though it is a minor mode is global; once it is on, it is on in every buffer. Really, it needs rewriting so that it can be switched on and off on a per-module basis.

My solution to this is to switch the minor mode on and off depending on the current mode. This isn’t worth turning into a package (since it’s a hack), but I put it up here in case anyone finds it useful.

;; show-paren-mode is a minor mode, but it's automatically global. Annoying.
(defun phil-show-paren-mode-check()
  ;; it isn't and it should be
  (when (and (phil-paren-mode-should-be-active-p)
             (not show-paren-mode))
    (show-paren-mode 1))
  ;; it is and it shouldn't be
  (when (and (not (phil-paren-mode-should-be-active-p))
             show-paren-mode)
    (show-paren-mode 0)))

(add-hook 'post-command-hook
          'phil-show-paren-mode-check)

(defun phil-paren-mode-should-be-active-p()
  (memq major-mode phil-paren-mode-active))

(defvar phil-paren-mode-active
  '(clojure-mode emacs-lisp-mode))

References

1. P. Lord, "Ontology Building with Emacs", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2161
2. P. Lord, "OWL Concepts as Lisp Atoms", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2254

With my initial work on developing a Clojure environment for OWL [1], I was focused on producing something similar to Manchester syntax [2]. Here, I describe my latest extensions which makes more extensive use of Lisp atoms. The practical upshot of this should be to reduce errors due to spelling mistakes, as well as enabling me to add simple checks for correctness.

The desire for a simple syntax is an important one. I would like my library to be usable by people not experienced with Lisp, although I am clearly aware that this sort of environment is likely to be aimed at those with some programming skills. I have managed to produce a syntax which, I think, is reasonable straight forward. It has more parentheses than Manchester syntax, but is easier in other ways, especially now that I have learnt a little more about how Clojure namespaces work. For example, this defines a class in OWL.

(owlclass "HumanArm"
          :subclass "Arm" (some "isPartOf" "Human")
          :annotation (comment "The Human arm is an Arm which is part of a human"))

One of my initial desires for the Clojure mode was to enable the use of standard tools that we have come to expect from a modern programming language, which should enable us to build a more pragmatic ontology building methodology [3]. The first of these is a unit testing environment. Clojure already has one of these integrated. So far, I have only used this for testing my own code; so, for example, this is the current unit test for the owlclass function used above.

(deftest owlclass
  (is (= 1
         (do (o/owlclass "test")
             (.size (.getClassesInSignature
                     (#'o/get-current-jontology))))))
  (is (instance? org.semanticweb.owlapi.model.OWLClass
                 (o/owlclass "test"))))

There are, however, some limitations to the approach that I have taken so far. Consider this statement:

(owlclass "HumanArm"
          :subclass (some "isPartOf" "Humn") "Arm"
)

This is broken because I have referred to the class Humn which I probably do not want to exist because I have spelt it wrongly. Unfortunately, as it stands my code does not know this and so will create the class “Humn”. Now, this form of error is not that likely to happen; tools such as Kudu [4] enforce this correctness in the Editor, while pabbrev.el [5] provides “correctness-by-completion”. None the less, these errors will happen and I do not want them to. There are a variety of ways that I could build this form of checking in — generally, this would involve introspecting over the ontology to see if classes already exist.

However, I have taken a different approach, so that I can use the Lisp itself to prevent the problem. To do this, for each class created, I generate a new Lisp symbol; likewise, object property and the ontology itself. The practical upshot of this, I that I can write code like so:

(defclass a)
(defclass b :subclass a)

(defoproperty r)
(defclass d
     :subclass (some r b))

;; will fail as f does not exist
(defclass e
     :subclass f)

;; will fail as r and b are the wrong way around
(defclass e
     :subclass (some b r))

The advantages are three-fold. Firstly, it’s slightly shorter, and there is no need to use quotes all over the place. Secondly, it is no longer possible to refer to a class that has not yet been defined; Clojure will pick this up immediately; from the user perspective, you can test your statements as you go, as soon as you have written them, by evaluating them. Finally, because the atoms carry values which are typed, we can also detect errors such as using a property when a class is necessary.

Of course, the original functions are all still in place; there would be no point defining symbols if the intention was to use the API entirely programmatically. But, my intention for Clojure-OWL is to have environment for humans (well, programmers anyway) to develop ontologies with.

There is a final advantage to this, that I have not yet exploited. Currently, I have generated the name of the OWL class directly from the symbol name. So, in the above example the class a will have a name “a“. There are some problems with this. Not all characters are legal in Clojure symbol names nor in OWL class names, and the set of characters is not the same. So, while this is a useful default, I will formally separate these. At the same time, I think that this will allow me to address a second problem, that of semantics vs semantics free identifiers [6]. I can call a class, ontology or object property anything at all, and refer to it with a easy to remember identifier. I might use something like this:

(defoproperty has_part
   :name "BFO_OOOOO51")

The is still a significant amount of work to do yet; I haven’t made a complete coverage of OWL yet, just the most important parts (i.e. the bits that I use most often). Next, I need to start building some predicates so I can test (asserted) subclass relationships. So far, however, this approach is showing significant promise.

References

1. P. Lord, "Programming OWL", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2214
2. M. Horridge, and P.F. Patel-Schneider, "OWL 2 Web Ontology Language Manchester Syntax (Second Edition)", W3C, 2012. http://www.w3.org/TR/owl2-manchester-syntax/
3. . @wordpressdotcom, "Unicorns in my Ontology", Robert Stevens' Blog, 2011. http://robertdavidstevens.wordpress.com/2011/05/26/unicorns-in-my-ontology/
4. . @wordpressdotcom, "My Own Ontology Projects", Robert Stevens' Blog, 2010. http://robertdavidstevens.wordpress.com/2010/04/24/my-own-ontology-projects/
5. P. Lord, "Ontology Building with Emacs", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2161
6. P. Lord, "Semantics-Free Ontologies", An Exercise in Irrelevance, 2012. http://www.russet.org.uk/blog/2040