openBEB: open biological experiment browser for correlative measurements
© Ramakrishnan et al.; licensee BioMed Central Ltd. 2014
Received: 19 October 2012
Accepted: 11 March 2014
Published: 26 March 2014
New experimental methods must be developed to study interaction networks in systems biology. To reduce biological noise, individual subjects, such as single cells, should be analyzed using high throughput approaches. The measurement of several correlative physical properties would further improve data consistency. Accordingly, a considerable quantity of data must be acquired, correlated, catalogued and stored in a database for subsequent analysis.
We have developed openBEB (open Biological Experiment Browser), a software framework for data acquisition, coordination, annotation and synchronization with database solutions such as openBIS. OpenBEB consists of two main parts: A core program and a plug-in manager. Whereas the data-type independent core of openBEB maintains a local container of raw-data and metadata and provides annotation and data management tools, all data-specific tasks are performed by plug-ins. The open architecture of openBEB enables the fast integration of plug-ins, e.g., for data acquisition or visualization. A macro-interpreter allows the automation and coordination of the different modules. An update and deployment mechanism keeps the core program, the plug-ins and the metadata definition files in sync with a central repository.
The versatility, the simple deployment and update mechanism, and the scalability in terms of module integration offered by openBEB make this software interesting for a large scientific community. OpenBEB targets three types of researcher, ideally working closely together: (i) Engineers and scientists developing new methods and instruments, e.g., for systems-biology, (ii) scientists performing biological experiments, (iii) theoreticians and mathematicians analyzing data. The design of openBEB enables the rapid development of plug-ins, which will inherently benefit from the “house keeping” abilities of the core program. We report the use of openBEB to combine live cell microscopy, microfluidic control and visual proteomics. In this example, measurements from diverse complementary techniques are combined and correlated.
Systems biology aims to identify and quantify the molecular components of dynamic biological networks, determining interactions between the various players and integrating the resulting information into system models . This research necessitates the use of an ensemble of correlative measurement technologies. Ideally, data should be acquired from groups of elementary samples, such as single cells, using high throughput technologies, in order to disentangle biological noise due to the stochastic nature of interaction networks . An experimental environment of this type will generate large quantities of heterogeneous but related data. This presents many challenges, including the key problem of tracking and integrating measurements made on a series of related samples across diverse technological platforms.
A number of software tools are available to handle data originating from high throughput experimental set-ups. These are technique specific. Examples are, Omero for light microscopy , Leginon for electron microscopy (EM)  and PRISM for high-throughput proteomics . Difficulties arise when several instruments and/or complex (automated) preparation steps are required for the research, as is often the case in a micro-fluidic pipeline. One way to create a multi-instrument solution would be to amalgamate the domain-specific software systems. The disadvantage is that combinatorial problems caused by required interaction between and coordination of the individual software packages, will increase rapidly with the number and complexity of the technologies involved. Furthermore, the correlation of individual datasets in relation to space and time will become progressively more difficult.
Flexible data management systems such as openBIS (open Biological Information System)  offer a partial solution, providing scalable data storage and retrieval, metadata integration and searching, and data source tracking. Although the platform-independent, web-based graphical user interface (GUI) of openBIS allows user management, authorization and configurable database browsing, it does not allow in depth data handling and does not support direct instrument control. These shortfalls are overcome by the new software presented in this paper, openBEB (open Biological Experiment Browser).
The requirements to be met become apparent when the following typical example is considered (see also results and discussion): Eukaryotic cells growing in miniaturized Petri dishes and are subjected to pulse chase experiments. During the experiment, the cells are observed by time-lapse light microscopy (LM). At specific time points, individual cells are lysed and prepared for further analysis by EM. Subsequently, specific features of the images, e.g., fluorescence signals detected by LM, are tracked over time. This scenario has three requirements: (i) Data acquisition and instrument control must be tightly integrated. (ii) Various data types must be collected and handled, e.g., image data and time-resolved “wave” data. (iii) The individual steps of the experiment must be correlated in space and time, e.g., EM data of an individual cell must be assigned and correlated to series of time-lapse LM images. OpenBEB provides a flexible, data-type agnostic core framework that performs the tedious “house keeping” tasks demanded, such as data management and the creation and maintenance of a unified hierarchical coordinate (HC) system. The latter establishes the relationships between experimental results that have to be retained in multi-scale space and time, a fundamental requirement for any correlative measurement. Furthermore, openBEB provides a plug-in manager that supports plug-ins for data-type specific tasks and instrument control. An internal macro system allows the control and coordination of these individual technology-specific modules. Furthermore, plug-ins can be used to connect openBEB to databases such as openBIS, facilitating data storage and synchronization.
OpenBEB furnishes the end-user with an environment for instrument control, data acquisition, visual inspection, advanced visualization, annotation, information correlation and metadata management. Of advantage for the developer, the software architecture allows the rapid integration of new instrument-specific modules, facilitating the use of correlative methods for systems biology, e.g., complex micro-fluidic set-ups.
Central goals of openBEB are to provide both an environment allowing the fast integration of correlative measurements and a platform allowing the rapid development of control-software. The extensible openBEB framework is implemented in LabView using object-oriented “loose coupling” principles. The latter is achieved via a plug-in structure. The programming language, G, makes it possible for researchers with little or no programming experience to develop their own extensions with minimal effort. The extensive libraries of the LabView environment for instrument control, data acquisition and signal processing are optimal for the implementation of the automatic data acquisition essential to realize high throughput.
A queued message state machine drives the core program (Figure 1). The central message queues can receive commands from several sources, such as the GUI, the macro-parser or the application server via a TCP based protocol. The latter allows platform-independent communication with other software packages or remote instrument controllers and computers (details are provided on the application home-page). Complex operations can be controlled by text-based macros that are located in the application support folder and can be adjusted by users if needed (Macro and Cron server). The data manager organizes the import and management of data in a data-agnostic manner and can handle arbitrary types of data. The data-types themselves are defined in plug-ins as described below. Furthermore, the data manager of the core program maintains one or more local containers for data and metadata called “bundles”. Bundles rely on a hierarchical file structure and can be directly accessed by any program without the need of the openBEB software. To avoid conflicts with automated processes, access to bundles or data collections they contain via the GUI can be blocked. Data-management tasks are performed centrally by the data-manager, which can be reserved by a process, e.g., a macro (see below). The data manager calculates MD5 checksums during data import as a control measure to check the integrity of the raw data. OpenBEB never changes the raw data. Furthermore, the data manager allows transparent, lossless data compression by the ZIP algorithm . The metadata manager organizes the metadata, which are stored in an xml format. The metadata includes the embedded metadata of the raw data, which can be quite extensive for some data types. In addition, the metadata manager supports pre-defined metadata annotations called “protocols”, based on a controlled vocabulary. These predefined protocols are located in the application support folder. This support folder is automatically updated by the update manager during openBEB start-up, keeping all components, e.g., plug-ins and protocol definition files, up-to-date with a server-side repository. Last but not least, a central error handler and logging system monitors all activities of both the openBEB core program and the plug-ins.
Macro control and modules
OpenBEB includes a simple macro interpreter, which also allows unified control of the modules provided by plug-ins. The macro language is primarily an inter-module processing and coordination system. It supports both the use of variables and branching and looping, provides primitives for graphical user interaction (dialogs and user input), and supports communication between modules. A TCP based application server is integrated to handle applications of greater complexity or to provide an interface to existing software.
Importantly, the macro interpreter has an open modular architecture. Every plug-in can provide one or several modules that can be addressed by the macro interpreter. Every module implicitly consists of a queued state-machine architecture and runs independently; this is particularly important for instrument control. A module is associated with a name and must follow specific rules for command and error handling. Furthermore, a minimum set of commands, e.g., for process coordination, must be supported. The coordination of different modules is achieved using synchronization primitives that are available in the macro language.
OpenBEB maintains a local repository for raw-data, metadata and cache files. This is accessible by standard tools of the operating system. Standard formats are used, except for the instrument dependent raw-data and the cache files. The local repository can be browsed by a file-browser, such as the Macintosh Finder or Windows Explorer, therefore, the entire contents are accessible to 3rd party software.
Note, that the collection hierarchy of a bundle does not necessarily reflect the workflow of experiments. However, the workflow is preserved in the database system, e.g., openBIS . A bundle is a work-snapshot and can combine collections from different spots in the workflow, e.g., a bundle can contain collections of original data obtained by different techniques and collections that amalgamate the results.
Annotating metadata, hierarchical coordinate system and graphical annotations
Metadata entries can be added in various ways, e.g., by using the GUI (see Results and discussion). Automatic annotation is of importance for high throughput measurements and can be performed either by directly accessing the XML metadata-files through openBEB, or by writing an attribute file to accompany the raw data. The latter allows the transfer of embedded metadata information from the raw-data file into the explicit metadata of a dataset.
The metadata file also contains a description of the dataset properties. These data properties are very flexible and support an arbitrary number of dimensions. They are designed to describe equally spaced data, but are not limited to this. A dimension contains a name, a type (e.g., numeric or index), a unit, a start and spacing (only for equally spaced data) and a length (number of data points in the direction of the axes). The data elements themselves are described by the data-type; consisting of a name, unit and type (e.g., numeric or category) and a precision that indicates the memory structure of the data, e.g., 64 bit floating point.
Hierarchical Coordinate (HC) fields
Boolean. True if this entity is the coordinate system root.
x, y, z
Cartesian. Internally the coordinates are stored as picometer (pm) values in a signed 64-bit integer. These coordinates are relative to the parent coordinates (i.e., for collections, the parent collection; for datasets, the containing collection).
Multiplication factor for Cartesian coordinates; for better readability, e.g., set the scale to 1000 if nanometer values should be displayed.
dx, dy, dz
Estimated standard error of Cartesian coordinates (in pm).
Time stamp in seconds since 1.1.1904 00:00:00 Universal Time ignoring leap seconds. The time stamp is represented in a 128-bit fixed-point number with a 64-bit radix. The first 64 bits are a signed integer for the seconds, the second 64 bits are unsigned fractions of a second.
Estimated standard error of the time stamp (in fractional seconds).
Description of the coordinate system (string); field to provide additional, ‘human readable’ information.
The experiment-specific functionality of openBEB is provided by plug-ins. A plug-in can provide functionality to the core program in two ways: (i) By using functions to override standard core routines, e.g., importing a dataset by an importer. (ii) By using so called “modules”, i.e., a queued state machine that can be addressed by the macro interpreter as described above. Plug-ins are instantiated during program start-up and destructed when openBEB quits. Before loading, a plugin.ini file is read to confirm compatibility and provide plug-in descriptions for the user. The plug-in is then initialized, e.g., standard settings are read from the file-system or plug-in-specific modules are started. Note that either plug-ins that function as stand-alone programs or plug-ins that call other 3rd party software can be written for instrument control. The homepage of openBEB provides specific information and tutorials on how to write plug-ins. The available plug-ins are distributed together with their source code and can thus easily be studied or changed locally.
List of plug-in types
Provides a data-type definition and also a library containing routines allowing specific manipulations to be carried out for the defined data-type. Are loaded first.
Libraries; can be dependent on ViewportTypes. Are loaded immediately after ViewportType definitions.
Data visualization plug-ins. A specific data-type (defined in the viewportType) can have multiple viewports. Viewports are presented in the main window (see Figure 13A).
Plug-in for data import or instrument control.
Small subprogram. Can be invoked with the tool menu in the main window (Figure 13B).
Plug-in for database connection. The standard plug-in synchronized with openBIS .
Plug-in providing a module (commands) for the macro-interpreter.
Results and discussion
The use of openBEB is first demonstrated for administrators and plug-in developers. A typical scenario describing how openBEB is used to combine live cell microscopy, microfluidic control and a new approach for visual proteomics called “spread and lyse” [8, 9], is then presented.
Installation, administration and plug-in development
Installation and update
Protocols are managed by a GUI provided by the administration plug-in (Figure 11). Protocols are created in two steps: First, a controlled vocabulary library is defined; the same vocabulary is used for all protocols. Second, the protocols are assembled from the controlled vocabulary. An entry in a protocol can be modified; the parent title can be changed as well the standard value of the entry. Note, that every vocabulary entry is associated with a unique identifier, which allows protocols to be automatically updated if a controlled vocabulary entry is changed.
To create a plug-in, a LabView project is created including the openBEB core and any other openBEB library required. A plug-in must provide a minimal set of override functions, which are called during execution. The specific functions that must be present depends on the type of plug-in (see the development section of the openBEB software home-page).
Example: Live cell imagining and “Lyse and spread” visual proteomics
The use of openBEB together with our recent hardware developments that connect micro-fluidics to EM for visual proteomics [8, 10] is reported. In the demonstration experiment adherent eukaryotic cells are cultured, and monitored by time-lapse LM throughout. At specific time points, pulse chase investigations are performed and, after a chase time, individual cells are lysed by electroporation . Subsequently, the cell lysate is transferred into a microcapillary, prepared for EM and imaged for analysis by “lyse and spread visual proteomics” [8, 9]. The presentation focuses on the application of openBEB using the GUI, and demonstrates some typical aspects of the program.
Main window of the openBEB GUI
Creating and managing collections, instrument control and data acquisition
Bundles and collections are managed using the management panel of the metadata tab control (Figure 13, C7 and 8). Figure 6 depicts the user interface that allows a new collection to be initiated (A). A typical workflow combining cell culturing, time-lapse LM imaging and visual proteomics by EM is shown (B). The responsible plug-ins are indicated (C), and the resulting collection hierarchy is depicted (D). The plug-in controlling live cell imaging and sample preparation for EM, is shown as an example (E).
Note, coordination between the different measurement domains is crucial, and is achieved by the HC system: As an example, the cell culture defines a (root) coordinate system in x and y and the LM images can be calibrated accordingly. Subsequently, an individual cell imaged by LM is selected for further experiments, e.g., lysis. The new data is stored in a sub-collection (e.g., Single cell lysis, Figure 6D). The data from this analysis define a sub-coordinate system; this sub-coordinate system depends on the root coordinate data of the mother collection (here the cell culture). Together, this defines a HC system as described above. In other words: To find the soccer stadium, latitude and longitude “GPS” coordinates are reasonable, to find a player on the soccer field, a rectangular coordinate system with the origin at a corner is better suited. The two systems define a HC system.
Data browsing and visualization
Various viewport plug-ins are available for data visualization. The type required depends on the data-type. Data types are defined in so-called viewportType plug-ins (Table 2).
Three viewport plug-ins are currently provided for the visualization of scientific greyscale images (Figure 8A-C). The first visualizes images in real space and allows the addition and adjustment of a look-up table as well as the visualization of the greyscale histogram (A). The second calculates and displays the power-spectrum of the image data. This is useful to evaluate the contrast-transfer function of the imaging device (B). The third uses the data values as height information and draws an interactive surface plot representation (C). Note, that viewport data visualization profits from the rich libraries provided by the LabView environment, facilitating the development of such plug-ins.
Data annotation and metadata management
OpenBEB includes a comprehensive metadata management tool. Metadata can be assigned to collections, datasets and, depending on the data-type, to frames of a dataset stack, e.g., time series. Annotations can be created or modified using the GUI (Figure 5A-F). Individual annotations can be written to collections (A) and dataset files (B). If supported by the importer, the metadata embedded in the raw-data file is displayed (C). Furthermore, the data visualization provided by the different viewports can be stored as “views” (D) that can also be graphically annotated if required (E). A batch-annotation tool facilitates changes to the metadata of selected data series (F).
Database synchronization with openBIS
OpenBEB supports database synchronization plug-ins; a standard plug-in to synchronize with an openBIS database is presented here. This plug-in lets openBEB transparently store a user’s local work on a server, which has several benefits: (i) It makes the user’s work accessible to other team members or collaborators. (ii) It protects against data loss. Having a second copy of the data on a server enables data recovery in the event of hardware failure or loss. The server, which is managed by a system administrator, is typically configured to make a nightly back up. (iii) Synchronization with a server ensures that work remains accessible beyond the duration of a PhD (unfortunately still the typical lifetime of scientific data). Storing the data on a server, along with any required contextual metadata, makes it possible for future team members to understand and build upon the results of present or previous team members. (iv) It further increases the scalability of the overall system as only recent data has to be kept locally in openBEB, while older data can be offloaded to openBIS.
Limitations and comparison to other software
The functionality of openBEB depends on the available plug-ins. Currently, two viewportType families are provided, each defining a data-type; one is for greyscale images (as presented above), the other is for “wave” data providing support for equally spaced measurements, e.g., a time resolved signal. Further, to a certain degree available plug-ins for hardware control are inherently tied to the hardware and communication protocols of a local set-up. Accordingly, the instrument and data-acquisition control system presented in Figure 6 is directly linked to specific hardware developed in-house, and limited to this specific setup. However, the extensive libraries for data acquisition, processing and visualization of LabView make it easy to develop new plug-ins, and openBEB hardware integration via library plug-ins allows a high degree of code re-usage. Furthermore, the core system of openBEB facilitates the integration of independently developed modules.
To our knowledge, openBEB is the only data-agnostic browser that has both developers and the end-user in mind. It complements “single domain” software solutions [4, 5]. Use of openBEB can provide the unified control and tight integration essential to maintain the temporospatial relationship of correlated experiments. Combining the data-type independent housekeeping tools offered by the openBEB core program with the flexibility of the plug-in system makes this possible.
OpenBEB is a tool for correlative experiments in systems biology. It allows instrument control and provides a bridge between biological experiments, annotation and synchronization with databases. The software is (i) for end-users performing automated (biological) experiments and (ii) for developers requiring a framework to write instrument control and data-registration plug-ins. The latter inherently benefit from the “house-keeping” data-management and annotation tools of the openBEB core program. The plug-in based, loose coupling and the open modular architecture of the macro subsystem make openBEB highly flexible and scalable. Further data-type plug-ins will be implemented in the future, e.g., to directly access mass-spectrometry data.
Availability and requirements
The openBEB core program has the following requirements and is available as indicated:
Project name: openBEB
Project home page: http://www.openBEB.org
Operating system(s): Mac OS X, Windows XP, 7; will be compiled on Linux
Programming language: G (LabView), JAVA
Other requirements: LabView runtime 2012, JAVA. Minimal screen-size of 1024 × 720 pixel
License: Apache license (http://www.apache.org/licenses/LICENSE-2.0)
Any restrictions to use by non-academics: no restriction, however restrictions may apply for specific plug-ins.
open Biological Information System
open Biological Experiment Browser
Graphical user interface
Hierarchical coordinate system
Network time protocol.
We thank Stefan Arnold, Christoph von Arx, Benjamin Bircher, Dominic Giss, Simon Kemmerling (C-CINA, University Basel) for testing the openBEB software. We thank Christophe Salzmann (EPFL, Lausanne, Switzerland) for providing the LabView Quicktime libraries. The project is supported by the SystemsX.ch initiative (CINA, granted to HS), the SNF (200020_146619, granted to TB) and the SNI PhD school.
- Aderem A: Systems biology: its practice and challenges. Cell. 2005, 121: 511-513. 10.1016/j.cell.2005.04.020.View ArticlePubMedGoogle Scholar
- Newman JRS, Ghaemmaghami S, Ihmels J, Breslow DK, Noble M, DeRisi JL, Weissman JS: Single-cell proteomic analysis of S-cerevisiae reveals the architecture of biological noise. Nature. 2006, 441: 840-846. 10.1038/nature04785.View ArticlePubMedGoogle Scholar
- Allan C, Burel JM, Moore J, Blackburn C, Linkert M, Loynton S, MacDonald D, Moore WJ, Neves C, Patterson A, Porter M, Tarkowska A, Loranger B, Avondo J, Lagerstedt I, Lianas L, Leo S, Hands K, Hay RT, Patwardhan A, Best C, Kleywegt GJ, Zanetti G, Swedlow JR: OMERO: flexible, model-driven data management for experimental biology. Nat Methods. 2012, 9: 245-253. 10.1038/nmeth.1896.View ArticlePubMed CentralPubMedGoogle Scholar
- Suloway C, Pulokas J, Fellmann D, Cheng A, Guerra F, Quispe J, Stagg S, Potter CS, Carragher B: Automated molecular microscopy: the new Leginon system. J Struct Bio. 2005, 151: 41-60. 10.1016/j.jsb.2005.03.010.View ArticleGoogle Scholar
- Kislinger T, Rahman K, Radulovic D, Cox B, Rossant J, Emili A: PRISM, a generic large scale proteomic investigation strategy for mammals. Mol Cell Proteomics. 2003, 2: 96-106. 10.1074/mcp.M200074-MCP200.View ArticlePubMedGoogle Scholar
- Bauch A, Adamczyk I, Buczek P, Elmer FJ, Enimanev K, Glyzewski P, Kohler M, Pylak T, Quandt A, Ramakrishnan C, Beisel C, Malmstrom L, Aebersold R, Rinn B: openBIS: a flexible framework for managing and analyzing complex data in biology research. BMC Bioinforma. 2011, 12: 468-10.1186/1471-2105-12-468.View ArticleGoogle Scholar
- ZIP File Format Specification. http://www.pkware.com/documents/casestudies/APPNOTE.TXT,
- Kemmerling S, Ziegler J, Schweighauser G, Arnold SA, Giss D, Müller SA, Ringler P, Goldie KN, Goedecke N, Hierlemann A, Stahlberg H, Braun T: Connecting µ-fluidics to electron microscopy. J Struct Biol. 2012, 177: 128-134. 10.1016/j.jsb.2011.11.001.View ArticlePubMedGoogle Scholar
- Engel A: Chapter 9 - Scanning transmission electron microscopy: biological applications. Advances in Imaging and Electron Physics. Edited by: Hawkes PW. 2009, Amsterdam: Elsevier Inc, 159: 357-386.Google Scholar
- Kemmerling S, Arnold SA, Bircher BA, Sauter N, Escobedo C, Dernick G, Hierlemann A, Stahlberg H, Braun T: Single-cell lysis for visual analysis by electron microscopy. J Struct Biol. 2013, 183: 467-473. 10.1016/j.jsb.2013.06.012.View ArticlePubMedGoogle Scholar
This article is published under license to BioMed Central Ltd. This is an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creativecommons.org/licenses/by/2.0), which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly credited.