Laboratory protocols

Several on-line resources are available for retrieving information about life-science protocols and experiments. Since 1997, the Science Advisory Board (SAB) [12] has been working to improve communications between biomedical scientists and suppliers of laboratory products and services. SAB also maintain an extensive database of protocols divided by techniques.

Protocol-Online [13] appeared in 1999 on the web as a database resource for research protocols in a variety of life science fields such as cell biology, molecular biology, developmental biology, and immunology.

In 2004, the Nature Publishing Group (NPG) launched Nature Methods [14], a monthly research journal on novel methods and significant improvements to laboratory techniques in the life sciences and related areas of chemistry. In addition, Nature Methods includes a Protocols section describing established methods written using 'bench terms'.

In 2006, JoVE [15] started to publish on-line video-protocols. The user is not required to read through a written protocol but can simply watch a video. Each video article includes step-by-step instructions for an experiment, a demonstration of equipment and reagents, and a brief discussion, with experts describing possible technical problems and modifications [16].

In the same year, Nature Protocols [17], became available as a cutting-edge on-line journal for biological and biomedical protocols. Protocols, written in natural language, are organized into logical categories in order to be easily accessible to researchers. They are presented in a 'recipe' style providing step-by-step descriptions of procedures that users can take to the lab bench and immediately apply to their own research.

As an example of a protocol for in silico experiments, Huang et al. [18] describe how to use the DAVID bioinformatic resources for the analysis of large gene lists derived from high-throughput genomic experiments, including how DAVID modules are able to help users to extract biological meaning from the given gene list and how individual modules should be used either independently or jointly. The reader can find the procedure easier to follow to reproduce the study.

The approach used for describing a computational procedure is also adopted for laboratory protocols. For instance, the protocol suggested by Fiegler [19] is organized into several sections; first, a list of materials used in the experiment including equipment, materials and their set up is provided. The second section is a step-by-step description of the methodology used. Critical steps that must be performed in a very precise manner and all toxic or harmful chemicals are highlighted. These warnings are tagged by the heading

Ontologies

Recently, we have seen an explosion of interest in ontologies as models to represent human knowledge. Ontologies are now extensively used in applications related to areas such as knowledge management, natural language processing, e-commerce [22], web services [23], intelligent information integration, bioinformatics [24], education, life sciences [25] and medicine [26], and in widely adopted technologies such as the Semantic Web [27]. There are several reasons for this large scenario of applications. Ontologies provide a common terminology, over a domain, necessary for communication between people and organizations and also provide the basis for interoperability between systems. They can be used for making the content in information sources explicit and serve as an index to a repository of information [28]. The growing interest in ontologies, triggered the development of Ontological Engineering, a novel field concerned with the ontology development process, the ontology life cycle, the methods and methodologies for building ontologies, and the tool suites and languages that support them [29, 30].

Despite the cited advantages, the choice of ontologies and formal representations incurs considerable costs for the retooling and upgrade of resources, and for the training of ontology developers. One serious problem is that differing ontologies may be developed and applied for the representation of the same domain. However, the mere use of ontology obviously does not warrant the elimination of heterogeneity; instead it can raise heterogeneity problems to a higher level. Ontology alignment, or ontology matching [31], a process that determines correspondences between concepts in different ontologies, can help to overcome those problems. In biology the heterogeneity of ontologies represents an emergent issue. In this respect, the OBO Foundry initiative [32] engages developers of science-based ontologies in the pursuit of a set of common principles for ontology development, with the goal of creating a suite of orthogonal interoperable reference ontologies in the biomedical domain.

The use of the word ontology within biology is relatively recent. Initially, computer scientists recognized in biological data a domain in which ontologies were needed in order to solve problems of heterogeneity. The second phase saw the adoption of bio-ontology by the biological community itself as a mean to consistently annotate different features, from genotype (e.g nucleotide sequences, proteins) to phenotype (e.g. diseases) [33]. Later, with the beginning of genome-scale sequencing projects and the diffusion of high-throughput experiments the amount of accessible biological data started to grow exponentially. Data are now dispersed throughout several different databases and their interpretation and analysis require sophisticated tools for data management and information processing. Organized in this way biological information is encapsulated within database schemes and is not easily available to scientist. Instead knowledge can be better captured and made available to both humans and computers thanks to ontologies Bio-ontologies are indeed fundamental components in biological data integration and annotation. In the last decade, several groups have been developing controlled vocabularies and descriptors mainly for the annotation of this kind of data. For instance, the Metabolomics Standards Initiative (MSI) ontology working group is developing an ontology to facilitate the consistent annotation of metabolomics experimental data [34]. Besides the well known Gene Ontology [24] there are many other initiatives focused on standardization and ontology development that may be cited, such as MIAME [35] and PRIDE [36]. These are mainly centred on the development of ontologies and bioinformatic tools for biological data annotation. However, only a few projects have been developed for the representation and formalization of the experimental protocols and the automatic operations producing such experimental data. A formal definition of scientific experimental design, laboratory entities and operations is undoubtedly important, also in the case of manually executed experiments. The development of an ontology of experiments is a fundamental step in the formalization of science, since experimentation is one of the most characteristic feature of science.

In this regard, the EXPO ontology of scientific experiment has been developed to formalize generic knowledge about scientific experimental design, methodology and representation of results [37]. The Ontology for Biomedical Investigations (OBI) addresses the need for controlled vocabularies not only for the experimental data annotation but also for the representation of investigations in the Biological and Biomedical Sciences [38]. Ontology represents the design of an investigation, the protocols and instrumentation used, the material used, the data generated and the type of analysis performed.

EXACT [39] is an ontology of experimental actions that can be used as a formalism suitable for a structured representation of laboratory protocols. The core of this structured vocabulary is a hierarchical classification of experimental actions based on goals of actions: the goal of separation, the goal of transformation and the goal of combination.

Exploiting the properties of EXACT in representing protocols, we expand and then combine its formalism with another, that of workflows to define a strategy that can be more expressive and efficient in protocol formalization.

Workflows

In the workflow context, a process can be considered as the set of activities performed by different entities and their execution ordering through different constructors, which permit flow of execution control (e.g. sequence, choice, parallelism and join synchronization). An elementary activity is an atomic piece of work [40].

A workflow is therefore the structured definition of a process used for the automatic management of particular activities. The formalization of a process (workflow schema) involves the definition of activities, the specification of their order of execution (i.e. the routing or control flow) and of the responsible actors. Other features should be taken into account too, e.g. the data flow [40] or the various ways in which resources are represented and utilized in workflows [41].

There are three well established formalisms applied for the specification/modelling of processes: Business Process Execution Language (BPEL), Business Process Modelling Notation (BPMN), XML Process Definition Language (XPDL).

BPEL [42] is an execution language based on XML specification for the formal description of business processes based on Web Services.

BPMN [43] is a graphical notation based on intuitive flowcharts for the definition of business processes. Originated from the Business Process Management Initiative, in 2005 it was merged into OMG [44] and in 2007 the version 1.1 became a standard.

XPDL [45] is a markup language created to ensure interoperability among different workflow management tools in order to handle workflow processes. It was designed to permit the exchange of process definitions, addressing both the graphical and the semantic notations of the relevant workflow. Born as a support for serialization of BPMN constructs, it also incorporates also information relating to the graphical representation (e.g. the position of blocks in the workflow). XPDL was developed by the Workflow Management Coalition (WfMC) [46], a consortium formed to define standards for the interoperability of workflow management systems.

In the last few years the interest for workflow development has seen a considerable growth in the scientific community [47]. Scientific workflows can be considered as the executable description of scientific processes [48]. Similar in nature to business workflow, they have the distinct characteristic of operating on large amounts of heterogeneous data. In particular, they are generally data-flow oriented instead of being event-based, and very versatile in composing flows of execution. In bioinformatics, in particular, workflows are extremely valuable for programming the steps of in silico experiments in a visual intuitive manner. However workflows are still not commonly adopted in the formalization of protocols for biological laboratory experiments.

There are several available tools for workflow design and enactment [49], for instance JPEd [11], an open-source visual editor for general-purpose workflows. Taverna [50], developed by the myGrid project, is the workflow platform most commonly used for the systematic analysis of vast amounts of data, but it does not allow description of laboratory experimental procedures. Taverna workflows can be shared among the scientific community thanks to Web 2.0 initiatives like myExperiment [51]. This social web site enables scientists to publish their workflows and in addition to execute, reuse and share workflows of other groups. In this way myExperiment contributes in reducing time-to-experiment, in sharing knowledge and expertise and in avoiding reinvention [52].

The proposed approach

We propose to combine ontologies and workflows for formalizing protocols used in biological laboratories. Workflows permit an intuitive representation of protocols, allowing the synchronization of different executors. Our workflow specifications can be stored and shared using the XPDL standard interchange language [45]. By means of ontologies, laboratory knowledge can be directly embedded into the workflow model and shared using the standard OWL model, the Ontology Web Language [53]. In this manner the precise constraints defined in the ontologies are transferred to the protocol building blocks.

To allow the integration of workflow and ontologies we have developed the COW tool, an add-on for the JPEd workflow editor that permits an easy and intuitive design of "ontologized" workflows. This allows a formal representation of laboratory protocols dealing with specific equipment and operations.

Combining Ontologies and Workflows

Our starting point is the EXACT ontology. We advocate its intrinsic value for describing protocols in a precise and unambiguous way and compared to OBI, it seems to be a better choice. The former describes the most typical entities of biomedical investigations undertaken by humans and not directly relevant to protocols. The latter is designed to specifically define experimental actions that can be performed by both scientists and machines and therefore it is more suitable for automation. Relying on ontologies, laboratory domain knowledge can be effiectively shared among the scientific community including scientists, computers and robots. The value of clearly describing protocols is demonstrated by the ability to exchange and compare them [39]. Ontologies provide the human and machine-understandable universal language for such a shared understanding. Using the EXACT vocabulary, the protocols become unambiguous and key elements of actions are precisely identified. For instance in an EXACT Move action, "what is moved?", "from where?" and "to where?" can be precisely defined.

On the other hand, defining protocols only by means of formal ontologies presents important limitations. Fully formalized protocols usually span many pages of text and the production of such descriptions by hand results labour intensive, error-prone and uninspiring [39]. The modular structure of laboratory processes is not well identified, and this does not facilitate the reuse of well defined "building blocks". Furthermore, in our case the command actions currently defined by EXACT are minimal not allowing loops and other complex constructs.

It would be very problematic and almost impossible, for human users to read and fully understand protocols defined only in formal languages. A synthetic description in natural language of each activity should remain associated with its formal description. This would make each step understandable at first sight also to non-ontology experts. In general for human scientists it would be desirable to have a tool that permits a visual overview of the whole protocol. This would allow an easy identification of the constituting blocks, of the flow of execution and of the executors of each activity. In addition the tool would permit the retrieval of detailed information for each single block (i.e. parameters of an action or the structure of a subprotocol).

Therefore we developed a domain-specific language (DSL) [54], together with software supporting it, that allows laboratory protocols to be expressed more clearly than the pre-existing languages presently allow. Keeping the advantages of ontologies, we adopt a more expressive formalism able to describe different aspects of laboratory protocols (i.e. execution flow and error handling). Among the existing models we opted for workflows which combine higher expressivity at the flow control level with higher comprehensibility for human beings. The combination of ontologies and workflows gave us the possibility of defining laboratory protocols in terms of workflows enriched with ontological knowledge.

Among the various standards available in the workflow community, we adopted XPDL which is the standard defined to facilitate interoperability between business processes and to promote serialization of the graphic BPMN notation.

We chose the EXACT ontology because it defines precise semantics for laboratory activities, while workflows are mainly designed to orchestrate them. In the literature, there was no evidence about methods specifically developed for building workflows based on ontologies. Our idea consists in taking elements of the EXACT Action class as building blocks (i.e. activities) of workflows, and using the EXACT Equipment class as parameters of the actions. Actions are executed using XPDL Applications (ranging from a text editor to custom built applications) to execute the whole protocol.

For integrating these two formalisms we applied the principles of model driven engineering (MDE) [55]). In MDE there are three kinds of models: model, metamodel and metametamodel. "A metametamodel (also called M3) is a model that is its own reference model (i.e. it conforms to itself). A metamodel (M2) is a model such that its reference model is a metametamodel. A terminal model (M1) is a model such that its reference model is a metamodel" [56]. The real-world manifestation of a model is also called M0. Our idea was to relate the two metamodels, XPDL and EXACT, to establish semantic correspondences between respective elements.

XPDL can be considered as our first metamodel defined in XSD, which is its metametamodel (Figure 1). Therefore the XPDL language constructs, including Application and Activity, belong to the M2 level. In M1 we place Application definitions and invocations and Activity instances. An Activity represents an action which will be performed by a combination of resources and/or computer applications. One of the ways to implement an XPDL Activity is by using an XPDL Tool defined as a set of Applications. The latter are the description of programming language interfaces which may be invoked to support the Activity. The definition of Application reflects the interface that should be used to call the specific services that execute the Activity, including any parameters to be passed [57].

Our second metamodel is EXACT that has OWL as its metametamodel (Figure 1). In EXACT, the Action class contains concepts describing what an action can do on the basis of the goal of the actions. These concepts represent the effect of an action but do not give any information about how to obtain this effect. Therefore Action subclasses are abstractions of actions and do not represent the real-world actions.

Following this interpretation, the Action individuals belong to the M1 level. Since EXACT and XPDL are both placed at the M2 level, we applied a model-to-model transformation from the EXACT meta-model to the XPDL meta-model that permits their integration.

The concept of function in programming languages can help to understand the relationship between EXACT and XPDL. The function definition and invocation belong to the M1 level, whereas the grammar rules applied for writing the function are at the M2 level. In our case, instances of the Action class can be thought as functions, and the Action class as meta-function since it describes what a function is and does; for the same reason an Application is a meta-function and its instances are functions. Establishing a relationship between the EXACT Action class and XPDL Application allows the integration of the semantic of the ontology into workflows.

In EXACT each action, included in the Action class, has a list of ad hoc defined properties that specify which (and how) objects are to be manipulated in the action. In this way the formal parameters required for each Action class are specified at the class level, while the actual parameters are passed at the instance level. An example is the Move action, defined as "an experiment action to change a spatial location of an entity from a start location to an end location". For creating a Move instance we need to define the actual parameters: a start location, an end location and an object that is changing location. This formalization has a limitation: for each action reported in a laboratory protocol, we have to create a particular instance of the action specifying the actual parameters to be passed.

XPDL uses a well known standard mechanism for passing parameters based on IN, OUT and INOUT modes. Both formal and actual parameters are respectively specified and passed at the instance level. Starting from the above consideration EXACT can not be directly integrated into XPDL due to the different mode of parameters handling.

In order to permit the integration we have extended EXACT in two ways: adding a new ontology layer named UnGap and enriching the Equipment class with new subclasses. Starting from the Action class, we develop UnGap, an ontology layer that gives a new structure for parameter definition, so that ontology actions can correspond to XPDL Applications. The resulting mapping is represented in Figure 1. As a result each action is characterized by a list of input parameters (ParamIN), a list of output parameters (ParamOUT) and a list of parameters both of input and output (ParamIN_OUT).

In the new layer we also define the new class Datatype specifying the available types of parameters. This class contains the EXACT Equipment class and owl:DatatypeProperty. The former contains objects that can be manipulated by actions; the latter scalar values that can be requested from actions (e.g. μl to be added). The instances of these subclasses can be used as actual parameters of XPDL Applications. The purpose of the UnGap layer is actually that of "closing the gap" between EXACT and XDPL. Thanks to the UnGap definition, EXACT and XPDL elements are now compatible. Therefore, action individuals correspond to XPDL Applications and action datatypes to XPDL datatypes. A relationship can be established between instances of Action and Application. In this way we can transform every instance of Action into the corresponding Application.

This translation mechanism provides a set of XPDL Application constructs that are invokable by workflow block activities. The invoked Application requires the complete specification of its formal parameters. This is obtained filling them with actual parameters defined as variables of subtype of the Datatype class. In this case we follow the same considerations for models and metamodels applied for the EXACT Action-XPDL Application mapping. We obtain a mapping between the UnGap Datatype class and XPDL DataType (Figure 2).

To exploit the advantages of ontologies in describing domain knowledge we decided to maintain Datatype instead of translating it into an XPDL construct. We linked each Datatype subclasses to new custom datatypes. In XPDL this can be conveniently implemented in the DataType using xpdl:ExternalReference construct.

Following this strategy, the UnGap layer permits us to reap the advantages of both ontologies and workflows and makes EXACT semantically and operationally integrable with XPDL. Now in order to execute an activity we can invoke a specific instance of Action (e.g. add_reagent_to_container) through the corresponding XPDL Application that has been translated with COW (Figure 3).

Following the rules defined in UnGap, we can develop domain specific ontology (DSO) defining equipment and actions that are specific to a given laboratory. Figure 4 presents the modified DSO structure and its new included concepts: ActiveEntity, describing the entities able to perform actions and PassiveEntity, corresponding to objects of actions. As a result, we enrich the Equipment class with new concepts common in laboratory protocols like thermoblock and swab.

In this way we defined a mechanism for the automatic transformation between elements of our two base meta-models: EXACT Action corresponds to XPDL Application and individuals of Action correspond to instances of Application.

The protocols formalized with our method will be translated into workflows written in XPDL and their activities will be formalized by EXACT actions and saved in an OWL file.

A COW protocol for paternity test

In order to discuss the novelty and the advantages of our proposal we present how the methodology and the developed tool have been used for formalising a laboratory protocol developed by our group.

In our laboratory we apply a protocol for paternity testing (Figure 5). The objective of the test is to confirm or exclude paternity relationship among the donors of two DNA samples. The protocol was set up and is followed by the wet-lab staff of our laboratory. It is composed of several detailed steps, required to perform a series of operations and involves various instruments to execute these operations. The first three steps of the protocol written in natural language are reported in the first row of Figure 6. These steps describe a series of actions which require specific preconditions and parameters for their execution.

In order to represent the protocol as a workflow, the first operation consists in accurately examining each sentence of the textual protocol which can be divided into numerous independent steps (first row of Figure 6). Reading step by step, we extract ontology concepts for Action and Datatype classes that should be included in our model (second row of Figure 6). In the textual form, the verbs (e.g. Cut, Add, Incubate) describe the nature of the action to be executed, the objects (e.g. Eppendorf, Thermoblock, SwabHead) represent the required equipment, and the parameters of actions (1.5 ml, 30 minutes) become owl:DatatypeProperty.

Each identified verb is a candidate for being included as an ontological action in our DSO. For any action not yet existing in the DSO, a new concept specific for that action is then inserted as an Action subclass. Following the EXACT rules, the newly defined Action subclasses can be classified, according to their nature, among the separation actions, the transformation actions or the combination actions. This solution permits us to define instances of Action subclasses. As defined in the UnGap ontology layer, for each instance of the Action class it is required to specify ad-hoc parameters among the types listed in the Datatype class.

In our ontology all the instances of the Action class share the properties of the class but can be distinguished by the specified parameters, as commonly applied in object-oriented programming (OOP). In Figure 3, the Add class has two instances: add_labware_to_container and add_reagent_to_container. The add_reagent_to_container instance corresponds to step 2 of our protocol and differs from the add_labware_to_container in the paramIN, paramOUT, paramIN_OUT parameters. The paramIN parameters include the Pipette and Reagent as Equipment classes and the volumeQuantity_ul as a owl:DatatypeProperty. It is worth underlining that the add_reagent_to_container is a "template" that is defined just once at the beginning of the formalization process. As a result it can be re-used to model every step in the protocol that requires the addition of a reagent to a container.

Using the COW tool, all the concepts and properties described in the DSO and UnGap layers can be used to design a workflow (third row of Figure 6). The resulting workflow is characterized by a flow of execution where activity blocks refer to the respective action in the corresponding protocol step. To specify a single block, e.g. the Add activity of step 2, we have to define workflow variables (myPipette, myLysisBuffer) that permit us to instantiate the add_reagent_to_container template. Such variables are instances of DSO classes, respectively Pipette and Reagent and they are actual parameters of the XPDL Application corresponding to the template. This method is repeated for each single protocol step obtaining a workflow completely defined by XPDL elements. The execution of the protocol formalized using COW can then be delegated to an independent XPDL-compliant run-time environment. The execution can also be concurrently distributed among several computational units interfaced with robotized stations or laboratory operators.

The COW software

COW comes in the form of a wizard and a plugin and uses ontologies modelled in OWL. Our software has been developed in Java (version 1.5). Protégé (version 3.4) has been used for the modification of EXACT and the creation of UnGap layer and DSO. The COW tool is distributed as an add-on for JPEd with minor changes provided by us (version: 2.0.1-SNAPSHOT). In the wizard, ontology concepts are transformed into XPDL version 1.0 (Figure 7).

The EXACT ontology represents the kernel of laboratory formalized knowledge. On top of this a second ontological layer named UnGap has been added. It extends the concept of Action enriching it with a precise schema for uniformly managing the generic list of parameters for each possible action (i.e. paramOUT, paramIN_OUT, paramIN). A user can develop his own DSO over UnGap. In DSO, in particular, the Action class can be specialized according to the specific nature and needs of the laboratory. The wizard component of the add-on translates each subclass of Datatype into a XPDL DataType.

Furthermore, each individual of the Action ontology class is transformed into XPDL as an Application construct.

Workflows in XPDL can contain variables of the standard types (e.g. integer, strings) but also of any user defined type. Therefore, as the wizard automatically converts a subclass of Datatype into XPDL DataType, the plugin allows the declaration of workflow variables of a type coming from the ontology. Users can create such types of variable also on the fly, thanks to the Protégé API [59]. They enable the use of the Protégé GUI modules for dealing with the OWL model and populating the DSO with individuals, simultaneously with the workflow development.

When beginning a new protocol definition, the user is required to provide the location of the DSO to be used. An ontology Action, mapped into a XPDL Application, can be retrieved in the JPEd Application Panel. Choosing a specific application from the shown list, it is possible to see a general description of the application, including its parameter list with related type. An application can finally be invoked from an Activity block of a workflow process. COW enables us to save the protocols as "ontologized" workflows, creating an OWL file for ontology individuals as well as the usual XPDL file.