PKP 2011 Hackfest

Today there was the kick-off of the hackfest at the PKP 2011 conference. Not many people turned up, but I had the chance to spend some quality (coding) time with PKP developers and to have a sort of personal code sprint  on a side project, that is developing a plugin to integrate a Named Entity Recognition (NER) web service into an OJS installation (see here and there for a more theoretical background).

At the end of the day what I got done was:

• setup a local instance of OJS (version 2.3.6) using MAMB;
• give a quick try to the OJS Voyeur plugin, which unfortunately for me is working only with version <=2.2.x;
• create the bare-bone of the plugin, whose code is up here (for my personal record rather than for other’s use, at least at this early stage);
• write a PHP class to query a web service (that I’m developing) to extract citations of ancient works from (plain) texts;
• come up with two possible scenarios for further implementation of the plugin, to happen possibly earlier than next year’s PKP hackfest

The idea of this post, indeed, is to comment a little on these two possible scenarios.

1. Client-side centric

The first scenario looks rather heavy on the client-side. The plugin is packaged as an OJS plugin and what it does is essentially as follows:

1. after an article is loaded for view, a javascript (grab.js) gets all the <p> elements of the HTML article and send them over ajax to a php page (proxy.php);
2. a php class act as a proxy (or client) for a 3rd party NER web service;
3. the data that are received from via the ajax call are passed on to the web service via XML-RPC;
4. the response is returned by the web service as JSON or XML format…
5. … and then processed again by the JS script, ideally using a compiled template based on jquery’s template capability. Finally, the citations that were extracted are display as a summary box alongside the article.

2. Server-side centric

Instead, in the second scenario that I envisaged most of the processing happens on the server-side.

1. before being displayed, the article is processed to extract <p> elements;
2. the main plugin class (plugin.php) takes care of sending the input to and receiving a response from the NER service;
3. the response is then ran through a template (template.tpl) by exploiting OJS’s templating functionalities;
4. the formatted summary box is injected into the HTML which is now ready to be displayed to the user.

All in all, I think that I came up with (1) mainly because my PHP is rather rusty at the moment . Therefore, although I’m quite reluctant to admit so, I might decide to go for (2). However, a good point to opt for the former is the case where the user can decide for each paper whether to enable this feature or not.

Idea for an OJS plugin

I have been meaning for quite a while to find some time to code a plugin for the Open Journal System (OJS) platform. Unfortunately it didn’t happen yet. However, the good news is that the chance somehow came to me, since this year’s PKP conference will be held in few weeks days in Berlin, that is where I recently moved and now live.  And at the same time as the PKP conference there will be a PKP hackfest where I hope to have the chance to push forward my idea for an OJS plugin and eventually get some coding done.

The idea it’s quite simple, but my knowledge of OJS’ is not (yet) such to allow me to have a clear idea of how to implement it. The plugin should enable the detection and markup of certain bits and pieces (read “named entities”) of articles from an OJS installation. Although my application of the plugin is (originally) targeting a specific type of named entities, citations to ancient texts, to be found mainly in Classics journals, it’d possible to generalise the idea for a wider application. Indeed, the plugin could be thought of as applicable to any named entities contained in journal articles, provided that a web service for that is available.

As an example, let’s suppose to have an existing installation of OJS, where an article contains the following paragraph (which is actually taken from a real world article appeared in Greek, Roman, and Byzantine Studies):

Thus, in the paragraphê speeches ([Dem.] 37.58–60, 38.21–22), a binding settlement is sometimes described as a “boundary marker (horos); in an inheritance dispute (40.39), the binding decision is a telos or peras.

The text in bold contains two references to Demosthenes’ works, respectively (1) a reference to lines 58-60 of the speech Against Pantaenetus and (2) another to lines 21-22 of the one  Against Nausimachus and Xenopeithes. The plugin would parse each paragraph and then produce a result somewhat similar to this, where the cited texts are displayed alongside the text article. All in all the whole idea is not much different from OJS’s citation markup assistant, although at the same time it can be generalised to cover other kind of named entities (people, organisations, etc.).

Some aspects that I believe are important for the implementation of such a plugin are:

• client/server architecture: the plugin should act as a client with respect to the Named Entity Recognition web service; I have already a working prototype for a web service (based on XML-RPC) performing the extraction of citations as described above;
• the markup of the extracted named entities should be customisable, ideally based on a template rewrite system, and should allow one to output RDFa or microformatted markup.
• being able to review, correct and therefore store the output of the automatic extraction will be a plus (possibly including interaction with authority lists to which the named entities can be linked to).

So, this is the idea in a nutshell. I’m looking forward to discuss it together with interested OJSers next week in Berlin and I hope there will be a follow-up post with some updates on the hackfest’s outcome.

XML and NLP: like Oil and Water? [pt. 2]

This is the second part of a series (see pt. 1) about XML and NLP, and specifically about how it’s not really handy to go back and forth from the former to the latter. Let me sum up what I was trying to do with my XML (SGML actually) file: I wanted to 1) process the content of some elements using a Named Entity Recognition tool and then 2) be able to reincorporate the extracted named entities as XML markup into the starting file. It sounds trivial, doesn’t it?

But why is this actually not that straightforward and worth writing about it? Essentially because to do so we need to go from a hierarchical  format (XML) to a kind of flat one (BIO or IOB). During this transition all the information about the XML tree is irremediably lost unless we do something to avoid it. And once it’s lost there is no way to inject it back into the XML.

I am aware of the existence of SAX, of course. However SAX is not that suitable for my purpose since it allows me to keep track of of the position in the file being parsed just in terms of line and column number (see this and that). [I have to admit that at this point I did not look into other existing XML parsers.] Instead I just wanted to access for each node or text element its start and end position in the original file. The solution I found it’s probably not the easiest one but at the same time it’s quite interesting (I mean, in terms of the additional knowledge I acquired while solving this technical problem). The solution was to use ANTLR (ANother Tool for Language Recognition).

An explanation of what is ANTLR and how does it work it’s out the scope of this post. But let’s put it simple: ANTLR is a language to generate parsers for domain specific languages (see also here). It is typically used to write parsers to process programming languages and it’s based on few core concepts: grammar, lexer, parser and Abstract Syntax Tree (AST). Therefore, it is possible to write an ad-hoc XML/SGML parser using this language. To be honest, the learning curve is pretty steep, but one of most rewarding things to ANTLR is that it’s possible to compile the same grammar into different languages (like Python and Java in my case) with just few (and not substantial) changes, with consequent great benefits in terms of code reusability.

The parser I came up with (source code here) is based on some other code that was developed by the ANTLR community. Essentially,I did some hacking on the original to allow for tokenising the text element on the fly while parsing the XML. During the parsing process, the text elements in the XML are tokenised by space characters and split into tokens of which the start and end positions are kept.

My ANTLR XML/SGML parser does on the fly another couple normalisations in order to produce an output that is ready to be consumed by a Named Entity Recogniser:

1. resolving SGML entities into Unicode;
2. transcoding BetaCode Greek into Unicode;
3. tokenising text by using the non-breaking space (&nbsp;) in addition to normal spaces: this task in particular, although it may seem trivial, implies recalculating the position of the new token in the input file and it required a bit more thinking through;

The result of running the parser over an SGML file is a list of tokens. I decided to serialised the output into JSON, for the time being, and a snippet of the result looks pretty much like this:

[{"start": 2768, "end": 2778, "utext": "\u0153uvre", "otext": "œuvre"},
{"start": 2780, "end": 2782, "utext": "par", "otext": "par"},
{"start": 2784, "end": 2790, "utext": "Achille", "otext": "Achille"}]

Start and end indicate (not surprisingly) the byte position of the token within the file, whereas otext and utext contain respectively the original text and the text after the resolution of character entities.

To sum up, the main benefit of this approach is that, once named entities have been automatically identified within the text of an XML/SGML file (e.g. “Achille” in the example above), we can trasform this newly acquired NE annotation into XML markup and pipe it back into the original file.

Feet on the ground, DB on the cloud

This quick post is just to say how much the UK NGS did save my day today, and probably even a lot more.

For my research project I’m digging into the JSTOR archive via the Data for Research API. And I realised soon to what extent scalability matters when trying to process all the data contained in JSTOR related to scholarly papers in Classics. There are ~60k of them.

The workflow I decided to go for basically consists in retrieving the data from JSTOR, making them persistent via Django (+ MySQL database backend) and then processing iteratively the data. The automatic annotation about those data (mainly Named Entity Recognition) that I’ll be producing is to be stored in the same Django DB.

After having ran the first batch to load my data into my Django application the situation was as follows: 7k documents processed and DB size of ~600MB. By the end of my data loading process the DB will grow up to approximately 6GB (just the data, without any annotation). And it’s at this stage that the cloud (or the grid) comes in handy.

I run my process locally but the remote DB is somewhere on the NGS grid (in my case it’s on the Manchester node). This is of great relieve to my and my machine of course in terms of disk space, speed in accessing the DB and system load. Whenever I need I can dump the DB and installing it locally in case I find myself in the need of accessing it and without an internet connection. Not to mention the fact that the batch processed to load the data could be ran from the grid. Finally, to give public access to the data I’m using  the same django application that pulls out the data from the remote MySQL db.

Having free access to the national grid as UK researcher is absolutely essential, also for someone – like me – who does not work in one of those fields that are known to be benefitting most from grid infrastructure. Even if digital I’m nevertheless still a humanist.

XML and NLP: like Oil and Water? [pt. 1]

XML is great, really. Most of (*)ML formats are great, included the old fashioned SGML. However, have you ever tried to perform some NLP tasks on an XML-encoded text or, even worse, to do some automatic tagging on an existing (*)ML document? It’s all but easy and straightforward. And this seems to prove the “inadequacy of embedded markup for cultural heritage texts” as D. Schmidt has persuasively argued not long ago.

But it’s lot of fun though and finding a technical solution is doable. This post is to share problems, ideas and solutions about this technical aspect of doing NLP on (*)ML-encoded texts and will be in two parts.

Materials

A little while ago I was given an SGML file (~12MB) to process. My idea was to try out on it a Named Entity Recogniser that I have been working on, which extracts standard references to ancient Classical (Greek and Latin) texts. My recogniser is written in Python and accepts as input a file encoded in the IOB format (a format used for the CoNLL-2003 shared task on language-independent named entity recognition). In the IOB format instances are separated by blank lines. Each instance is then tokenised and the resulting tokens are written one per line. Each line contains a number of space-separated column: in the example above the first contains the token itself whereas the second contains a label (category) assigned to the token. *-CRF indicates that a given token is part of a given Named Entity, in this case CRF is used to indicate the presence of a Canonical ReFerence.

This is what an example instance looks like:

this	O
is	O
a	O
canonical	O
reference:	O
Hom.	B-CRF
Il.	I-CRF
1,	I-CRF
Hom.	B-CRF
Il.	I-CRF
1,	I-CRF
477;	I-CRF
24,	I-CRF
788;	I-CRF

This format is used both to store the training sets and as output of the recogniser. In other words, the recogniser takes as input an IOB-encoded file where each token is initially assigned the label O (Other) and outputs the same file but with the new labels properly assigned.

Now, the main problem I was faced with is how to tag in the original SGML file those tokens that my recogniser had identified as being part of a named entity. In order to be able to do so, one needs to keep track of the token position within the XML file.

To sum up, these are the steps that I wanted to be able to perform:

1. parse the XML and keep only the text content of some elements;
2. tokenise the text extracted from the XML (while keeping a reference to the token position within the file): the result will be a list of instances (the text content of given elements) where each instance is a list of tokens;
3. the list of instances is then processed by the Named Entity Recogniser which assigns each token one of the following labels [ O | B-CRF | I-CRF ];
4. the original XML is then re-processed: the subsequent tokens that were previously labelled as B-CRF or I-CRF are to be included within a new XML element;
5. the resulting new XML file (i.e. the original document plus the automatically tagged information) is written to the memory.

[To be continued...]