This paper describes Bluima, a natural language processing (NLP) pipeline focusing on the extraction of neuroscienti c content and based on the UIMA framework. Bluima builds upon models from biomedical NLP (BioNLP) like specialized tokenizers and lemmatizers. It adds further models and tools speci c to neuroscience (e.g. named entity recognizer for neuron or brain region mentions) and provides collection readers for neuroscienti c corpora. Two novel UIMA components are proposed: the rst allows con guring and instantiating UIMA pipelines using a simple scripting language, enabling non-UIMA experts to design and run UIMA pipelines. The second component is a common analysis structure (CAS) store based on MongoDB, to perform incremental annotation of large document corpora.
Bluima started as an e ort to develop a high performance natural language processing (NLP) toolkit for neuroscience. The goal was to extract structured knowledge from biomedical literature (PubMed1), in order to help neuroscientists gather data to specify parameters for their models. In particular, focus was set on extracting entities that are speci c to neuroscience (like brain regions and neurons) and that are not yet covered by existing text processing systems.
After careful evaluation of di erent NLP frameworks, the UIMA software
system was selected for its open standards, its performance and stability, and
its usage in several other biomedical NLP (bioNLP) projects; e.g. JulieLab [
Once the initial components were in place, an experimentation phase started where di erent pipelines were created, each with di erent components and parameters. Pipeline de nition in verbose XML was greatly improved by the use
of UIMAFit [21] (to de ne pipelines in compact Java code) but ended up being problematic, as it requires some Java knowledge and recompilation for each component or parameter change. To allow for a more agile prototyping, especially by non-specialist end users, a pipeline scripting language was created. It is described in Section 2.2.
Another concern was incremental annotation of large document corpus. For example, when running an initial pre-processing pipeline on several millions of documents, and then annotating them again at a later time. The initial strategy was to store the documents on disk, and overwrite them every time they would be incrementally annotated. Eventually, a CAS store module was developed to provide a stable and scalable strategy for incremental annotation, as described in Section 2.3. Finally, Section 3 presents two case studies illustrating the scripting language and evaluating the performance of the CAS store against existing serialization formats. 2
Bluima contains several UIMA modules to read neuroscienti c corpora, perform preprocessing, create simple con guration les to run pipelines, and persist documents on the disk. 2.1
Bluima's typesystem builds upon the typesystem from JulieLab [
Bluima includes several collection readers for selected neuroscience
corpora, like PubMed XML dumps, PubMed Central NXML les, the BioNLP
2011 GENIA Event Extraction corpus [24], the Biocreative2 annotated corpus
[
For pre-processing, the OpenNLP-wrappers developed by JulieLab for
sentence segmentation, word tokenization and part-of-speech tagging [31] were used
and updated to UIMAFit. Lemmatization is performed by the domain-speci c
tool BioLemmatizer [
Bluima uses UIMA's ConceptMapper [29] to build lexical-based NERs
based on several neuroscienti c lexica and ontologies (Table 1). These lexica
and ontologies were either developed in-house or were imported from existing
sources. Bluima wraps several machine learning-based NERs, like OSCAR4
[
There are several approaches2 to write and run UIMA pipelines (see Table 2). All Bluima components were initially written in Java with the UIMAFit library, that allows for compact code. To improve the design and experimentation with UIMA pipelines, and enable researchers without Java or UIMA knowledge to easily design and run such pipelines, a minimalistic scripting (domain-speci c) language was developed, allowing UIMA pipelines to be con gured with text les, in a human-readable format (Table 3). A pipeline script begins with the de nition of a collection reader (starting with cr:), followed by several annotation engines (starting with ae:)3. Parameter speci cation starts with a space, followed by the 2 Other interesting solutions exist (e.g. IBM LanguageWare, Argo), but are not open source. 3 If not package namespace is speci ed, Bluima loads Readers and Annotator classes from the default namespace. parameter name, a column and its value. The scripting language also supports embedding of inline Python and Java code, reuse of a portion of a pipeline with include statements, and variable substitution similar to shell scripts. Extensive documentation (in particular snippets of scripts) is automatically generated for all components, using the JavaDoc and the UIMAFit annotations. 2.3
A CAS store was developed to persist annotated documents, resume their processing and add new annotations to them. This CAS store was motivated by the common use case of repetitively and incrementally processing the same documents with di erent UIMA pipelines, where some pipeline steps are duplicated among the runs. For example, when performing resource-intensive operations (like extracting the text from full-text PDF articles, or performing syntactic parsing), one might want to perform these preliminary operation once, store these results, and subsequently perform di erent experiments with di erent UIMA modules and parameters. The CAS store thus allows to perform the preprocessing only once, to then persist the annotated documents, and to perform the various experiments in parallel.
MongoDB4 was selected as the datastore backend. MongoDB is a scalable, high-performance, open-source, schema-free (NoSQL), document-oriented database. No schema is required on the database side, since the UIMA typesystem acts as a schema, and data is validated on-the- y by the module. Every CAS is stored as a MongoDB document, along with its annotations. UIMA annotations and their features are explicitly mapped to MongoDB elds, using a simple and declarative language. For example, a Protein annotation is mapped to a prot eld in MongoDB. The mappings are used when persisting and loading from the database. As of this writing, annotations are declared in Java source les. In future versions, we plan to store mappings directly in MongoDB to improve exibility. Persistence of complex typesystem has not been implemented yet, but could be easily added in the future.
Currently, the following UIMA components are available for the CAS store: { MongoCollectionReader reads CAS from a MongoDB collection. Optionally, a ( lter) query can be speci ed; { RegexMongoCollectionReader is similar to MongoCollectionReader but allows specifying a query with a regular expression on a speci c eld; { MongoWriter persists new UIMA CASes into MongoDB documents; { MongoUpdateWriter persists new annotations into an existing document; { MongoCollectionRemover removes selected annotations in a MongoDB collection.
With the above components, it is possible within a single pipeline to read an existing collection of annotated documents, perform some further processing, add more annotations, and store theses annotations back into the same MongoDB documents.
A rst experiment to illustrate the scripting language was conducted on a large dataset of full-text biomedical articles. A second simulated experiment evaluates the performance of the MongoDB CAS store against existing serialization formats. 3.1
Scripting and Scale-Out # collection reader configured with a list of files (provided as external params) cr: FromFilelistReader inputFile: $1 # processes the content of the PDFs ae: ch.epfl.bbp.uima.pdf.cr.PdfCollectionAnnotator # tokenization and lematization ae: SentenceAnnotator modelFile: $ROOT/modules/julielab_opennlp/models/sentence/PennBio.bin.gz ae: TokenAnnotator modelFile: $ROOT/modules/julielab_opennlp/models/token/Genia.bin.gz ae: BlueBioLemmatizer # lexical NERs, instantiated with some helper java code ae_java: ch.epfl.bbp.uima.LexicaHelper.getConceptMapper("/bbp_onto/brainregion") ae_java: ch.epfl.bbp.uima.LexicaHelper.getConceptMapper("/bams/bams") # removes duplicate annotations and extracts collocated brainregion annotations ae: DeduplicatorAnnotator annotationClass: ch.epfl.bbp.uima.types.BrainRegionDictTerm ae: ExtractBrainregionsCoocurrences outputDirectory: $2
Bluima was used to extract brain region mention co-occurrences from scienti c articles in PDF. The pipeline script (Table 3) was created and tested on a development laptop. Scale-out was performed on a 12-node (144-core) cluster managed by SLURM (Simple Linux Utility for Resource Management). The 383,795 PDFs were partitioned in 767 jobs. Each job was instantiated with the same pipeline script, using di erent input and output parameters. The processing completed in 809 minutes (' 8 PDF/s). The MongoDB CAS store (MCS) has been evaluated against 3 other available serialization formats (XCAS, XMI and ZIPXMI). For each, 3 settings were evaluated: writes (CASes are persisted to disk), reads (CASes are loaded from their persisted states), and incremental (CASes are rst read from their persisted states, then further processed, and nally persisted again to disk). Writes and reads were performed on a random sample of 500,000 PubMed abstracts and annotated with all available Bluima NERs. Incremental annotation was performed on a random sample of 5,000 PubMed abstracts and incrementally annotated with the Stopwords annotator. Processing time and disk space was measured on a commodity laptop (4 cores, 8GB RAM).
In terms of speed, the MCS signi cantly outperforms the other formats, especially for reads (Figure 1). The MCS disk size is signi cantly smaller than XCAS and XMI formats, but almost 4 times larger than the compressed ZIPXMI format. The incremental annotation is signi cantly faster with MongoDB, and does not require duplicating or overwriting les, like with the other serialization formats. The MCS could be scaled up in a cluster setup, or using solid states drives (SSDs). Writes could probably be improved by turning MongoDB's "safe mode" option o . Furthermore, by adding indexes, the MCS can act as a searchable annotation database. 4
In the process of developing Bluima, a toolkit for neuroscienti c NLP, we integrated and wrapped several specialized resources to process neuroscienti c articles. We also created two UIMA modules (scripting language and CAS store). These additions proved to be very e ective in practice and allowed us to leverage UIMA, an enterprise-grade framework, while at the same time allowing an agile development and deployment of NLP pipelines.
In the future, we will open-source Bluima and add more models for NER and relationship extraction. We also plan to ease the deployment of Bluima (and its scripting language) on a Hadoop cluster. 20. Natale, D.A., Arighi, C.N., Barker, W.C., Blake, J.A., Bult, C.J., Caudy, M., Drabkin, H.J., D'Eustachio, P., Evsikov, A.V., Huang, H., Nchoutmboube, J., Roberts, N.V., Smith, B., Zhang, J., Wu, C.H.: The protein ontology: a structured representation of protein forms and complexes. Nucleic Acids Res. 39(Database issue), D539{545 (Jan 2011) 21. Ogren, P.V., Bethard, S.J.: Building test suites for UIMA components. NAACL
HLT 2009 p. 1 (2009) 22. Ogren, P.V., Wetzler, P.G., Bethard, S.J.: ClearTK: a UIMA toolkit for statistical natural language processing. Towards Enhanced Interoperability for Large HLT Systems: UIMA for NLP p. 32 (2008) 23. Osborne, J., Flatow, J., Holko, M., Lin, S.M., Kibbe, W.A., Zhu, L.J., Danila, M.I., Feng, G., Chisholm, R.L.: Annotating the human genome with disease ontology.
BMC Genomics 10(Suppl 1), S6 (Jul 2009) 24. Pyysalo, S., Ohta, T., Rak, R., Sullivan, D., Mao, C., Wang, C., Sobral, B., Tsujii, J., Ananiadou, S.: Overview of the ID, EPI and REL tasks of BioNLP shared task 2011. BMC Bioinformatics 13(Suppl 11), S2 (Jun 2012) 25. Rak, R., Rowley, A., Black, W., Ananiadou, S.: Argo: an integrative, interactive, text mining-based workbench supporting curation. Database: the journal of biological databases and curation 2012 (2012) 26. Ramakrishnan, C., Baumgartner Jr, W.A., Blake, J.A., Burns, G.A., Cohen, K.B., Drabkin, H., Eppig, J., Hovy, E., Hsu, C.N., Hunter, L.E.: Building the scienti c knowledge mine (SciKnowMine1): a community-driven framework for text mining tools in direct service to biocuration. malta. Language Resources and Evaluation (2010) 27. Ranjan, R., Khazen, G., Gambazzi, L., Ramaswamy, S., Hill, S.L., Schurmann, F., Markram, H.: Channelpedia: an integrative and interactive database for ion channels. Frontiers in neuroinformatics 5 (2011) 28. Savova, G.K., Masanz, J.J., Ogren, P.V., Zheng, J., Sohn, S., Kipper-Schuler, K.C., Chute, C.G.: Mayo clinical text analysis and knowledge extraction system (cTAKES): architecture, component evaluation and applications. Journal of the American Medical Informatics Association 17(5), 507{513 (2010) 29. Tanenblatt, M.A., Coden, A., Sominsky, I.L.: The ConceptMapper approach to named entity recognition. In: LREC (2010) 30. Thompson, P., et al.: The BioLexicon: a large-scale terminological resource for biomedical text mining. BMC Bioinformatics 12(1), 397 (2011) 31. Tomanek, K., Wermter, J., Hahn, U.: A reappraisal of sentence and token splitting for life sciences documents. Studies in health technology and informatics 129(Pt 1), 524{528 (2006)