This paper argues that several factors conspired to produce a less than optimal OWL version of BioPAX, describes what those factors were, and presents suggestions about a better way to proceed. The BioPAX workgroup agreed to implement BioPAX in OWL-DL and XML-Schema. OWL has a steep learning, and the di culties at the time of its adoption by the BioPAX community were compounded by the lack of tutorials and examples, the lack of tools of any quality, and the general lack of experience. More generally, the BioPAX community found it hard to specify a coherent set of requirements (the fact that there were two camps, one in favor of OWL the other XML Schema, re ected this). The use of OWL was not seen as necessary by all members of the community and it required considerably more work initially than using existing known methods.
? We would like to thank Christopher Brewster for help preparing this paper. our new ndings when we discover a new interaction, as well as the places where we look for answers when we try to nd a new therapeutic drug target. Much basic scienti c research produces pathway data, including environmental research, energy research, genetic and clinical research, and virtually all of life science research today. At some point, in all of these areas, the question is asked, \What pathways are involved?" As this question is fundamental today, it is important to provide a mechanism for access and reuse to these data and thus enable it to have broad impact for science.
he major problem for researchers who use pathway databases has been that the representations of pathway data within these resources are not consistent or interchangeable. This is true both of the conceptual framework and of the details of encoding. For example, interactions in signaling pathways are described in terms of a cascade of interacting molecules (or molecular complexes) resulting in a change in some cellular process in response to some stimuli. Each step in the pathway involves a di erent molecule or molecular complex. Signaling pathways respond to environmental stimuli, either internal or external to the cell, and carry a message that causes (signals) a change in the cell's functioning. Contrast this with a metabolic pathway such as the glycolysis pathway, where one chemical, through a series of precise steps, is transformed into another chemical. In the glycolysis pathway, glucose is transformed into pyruvate. In signaling pathways, it is the activation or inhibition of a process, in metabolic pathways, the end product is a transformed chemical molecule.
At the encoding or syntax level, the representation of a single reaction can be very di erent. In one
database, HumanCyc, the term -D-glucose-6-phosphate is used while in another database, KEGG, the
term -D-Glucose-6P is used. It is clear that we are referring to the same molecule, i.e. the same real world
class of instances, but the vocabulary label used to name these instances di ers and while this di erence is
insigni cant for a human reader, it is signi cant for computational processing. The syntax in KEGG is XML
and a biochemical reaction is de ned as an XML ELEMENT. In KEGG reaction elements have two components,
a substrate and a product. The substrate and product elements each have one required attribute, a name
which is a KEGG identi er. In HumanCyc, a biochemical reaction is represented as an ENZYMATIC-REACTION
in OCELOT [
The consequence of these di erent conceptualizations and encoding standards was that it was impossible to construct federated queries across databases. It meant that either individual queries were needed for each database or individual parsers needed to be written. Researchers embarking on a new wet-lab investigation need to consult a multitude of databases in widely di erent syntaxes. This meant that there was a growing burden to the researcher in making e ective preparation before continuing their investigations. 2
A group of researchers within the molecular biology community recognized the need for these data to be united in a common language and format and set out to create a standard representation for biological pathway data that would enable that goal. The group called themselves and their representation BioPAX. The starting point was to use the existing pathway data that resides in pathway databases. 3 A small team was assembled and an organizational structure was put in place. Biweekly conference calls were held and face-to-face meeting venues rotated amongst the workgroup members to distribute travel inconvenience and costs. 2.1
Biological processes are complex and there was concern about what language would be suitable to represent these complexities. The most prominent exchange format then (and probably still now) were the World 3 When the project began, there were several dozen such databases and this has grown over the years to over 200 now. Wide Web Consortium (W3C) standards, eXtensible Markup Language (XML), and XML Schema. XML is a standardized method for marking up text (or data) in an organized way, allowing that text (or data) to be exchanged between any application that understand the XML standard. XML Schema is a W3C XML language for describing and constraining the content of XML documents. At the same time, another W3C standard, OWL, was emerging as a standard for representation of ontologies. Ontologies are formal ways to describe the relationships among the terms and attributes and can represent knowledge about a domain. In addition to describing and constraining the content, they describe and constrain how the content elements relate to each other. The workgroup decided that a representation using a more semantically rich language was a better and more appropriate choice. In addition to ontologies being machine readable, they enabled a conceptually higher level of data characterization and processing that included detailed expressiveness in the relationships de ned and logical inference across those relationships.
The workgroup discussed their concerns and impact associated with the risks of each decision. OWL was not yet a standard. What if it were not adopted by the W3C? Would the bene t OWL-DL computability outweigh the cost of OWL-Full expressivity? There was a plethora of tools for XML and a paucity of tools for OWL, how much impact would this have on the project? Several within the group knew XML, none knew OWL.
\The next topic we discussed was the choice of a syntax language for BioPAX. We saw four viable options: 1) use OWL to design the ontology, use XML Schema for data instances, distribute software that checks if the XML Schema is valid for a given ontology, 2) use OWL for everything, 3) option 1 with DAML+OIL instead of OWL, 4) use DAML+OIL for everything. Since OWL was deemed superior to DAML+OIL and would likely contain comparable tools in the near future, options 1 and 2 received the most attention. .... After discussing our options, we decided to choose option 2 above (using OWL for everything), but on a three-week trial basis (REF)." By the next meeting, the workgroup agreed to two parallel versions, one in OWL and another in XML Schema. It appears that there was confusion about syntax and semantics and the misapprehension one could translate between OWL and XML Schema in both directions without loss.
The workgroup struggled with these early decisions. Rogers describes the di usion of technological
innovations as involving a number of di erent types of people including early adopters, the late majority and
laggards [
Ultimately, OWL-DL was developed and released, the XML Schema version was not. Or was it the other way around? There were several issues with the OWL-DL in the resultant BioPAX OWL (see [4{6]) and it could be argued that it is really an XML Schema version in OWL's clothing. 2.2
There were a number of further reasons to favor the use of OWL and speci c versions OWL, in this context.
In order to support future uses of pathway data, the BioPAX Workgroup included machine computability
among its design principles[
As OWL was soon to become a W3C recommendation for the standard web ontology language [
Due to the participants relative inexperience with respect to OWL a number of mistakes were made early on. The OWL version of BioPAX exhibited the usual common errors and mistakes due in part to the huge learning curve and in part to the desire for the XML version, which is one of the common formats for OWL ontology exports. These included bad conceptualizations and poor use of of OWL.
{ Bad Conceptualizations: There was confusion about what was being represented, biological processes or database records of biological processes. The Utility class, a concept used in Java, not in biology, was a top level node in the BioPAX ontology. { Poor Understanding of OWL: The rst release did not include disjoint axioms, there was confusion about domain and range, open world assumptions and implications, and much of the semantics were captured in the comments rather than in the ontology. What was said in the ontology, was not what was meant. For further details concerning technical issues and errors in BioPAX, please consult Luciano and Stevens (2007). 3
There were a number of social factors which made it both possible to create BioPAX initially but also hindered its development at various stages.
The goal was to create a public resource for pathway data. People interested in this from the broader scienti c community were invited to participate. A few had already been thinking about such an initiative. The present author was a co-organizer of the BioPathways Consortium, and found herself in a unique position to make a signi cant contribution. She had recently found out from the director of the Department of Energy that the DOE was prepared to support emerging and enabling technology. Thus it was that the DOE, the NSF, Dr. Sander (representing the pathway resource initiative) and a number of other researchers in pathways were brought together. The present author became a paid consultant in the role of community liaison and wrote the initial grant for the initial BioPAX DOE funds. The role was not one of a stakeholder in the traditional sense but rather the role was to make sure the community was involved, that the right people were at the table and their needs met (i.e. their data could be represented, or their tool could be used).
While there was a role as a public face in BioPAX, making presentations to spread the word and get
people involved, most of the work was behind the scenes working individually with research groups around
the world to inform them and invite their participation. At the bi-weekly meetings and face-to-face meetings,
much of the task involved listening and, depending on what said or not said, working to keep things on track.
The author and one other paid consultant met at co ee shops and worked from her home o ce to put in
place the organizational structure and materials that were needed to support, manage, and document the
e ort. The e ort was largely viewed as a success by the global community and many social logistic factors
contributing to that success were presented at Bio-Ontologies in Glasgow [
Once the decision was made, the focus moved back to representational concerns of the pathway concepts. OWL was treated as an output format. There were no tools at the time that wrote OWL. The two ontology tools under consideration were Stanford's Protege Editor and SRI's GKB Editor. We took a vote and the result was split (this time a more evenly). We went with the GKB Editor because SRI had already invested in it, didn't have to retrain and agreed to extend it to export in OWL format. The only serious e ort towards understanding OWL, at the time, was in the Export function. Development was delayed and by the time we were to release, Protege had just come out with it's OWL Alpha version and so we switched to make our release deadline. We switched back shortly thereafter, to GKB editor, had to reenter everything and then had to re-enter everything from the Protege Alpha to the Protege Beta version (these OWL formats were not compatible). The issue resolved itself when both tools supported OWL.
The community saw the value in BioPAX and while initially there were some sense of competition pathway
models, a wider global community had formed and an increasing number agreed to be BioPAX compliant.
The talk at Bio-Ontologies 2004 in Glasgow captured a lot of what went right with BioPAX[
The community outreach was a big part of the adoption of BioPAX and while it got a lot of details incorrect, BioPAX brought the wider community together by creating what e ectively is an upper level ontology for pathways (a level of abstraction that can be used to bring di erent conceptual representation together). Many of the issues that plagued BioPAX are less of an issue now. For example, now there are multiple OWL syntaxes to choose from, a selection of tools, both open source and commercial, better support and methodologies for development and dubbing. However, tools are needed that support ontology developers to analyze the level and type of complexity of use cases and facilitate development in a staged process with increasing complexity at each stage. Tools that would support basic requirements rst, controlled vocabularies, taxonomies, (XML data exchange) then interoperability (SBML/BioPAX) then on to richer semantics enabling integration, inference, and possibly integrated or in-line rules . Support (and perhaps encouragement) for coherent requirements are also important to prevent politics and bullying; two camps equals two solutions, which is not necessary when the only real di erence is in the degree of implementation - that is data exchange at the XML level (often referred to BioPAX-DX, DX for data exchange on the biopax-discuss list) can be viewed as a `di erent use case and therefor argument for a separate community' but it is, at the semantic level, a subset of the full intentions of BioPAX. The BioPAX community was always heterogeneous , stakeholders after all, have di erent interests and di erent goals vary. They come together in a community because each one has something to o er or has something to gain and can contribute a unique perspective. At one point BioPAX had this self image.
It should be remembered that it was a parallel goal to develop the XML Schema version of BioPAX . This fell from the o cial agenda but has not been forgotten. The community had originally agreed to support both formats and it is evident from the user community (as expressed by the mailing list) that there is a considerable user base for the XML schema version. Furthermore there is no indication that this community is diminishing. 6
From this experience and the other lesson's learned, we can see the need to assess the complexity of the use case, the needs of the community and the capability of the language (and its limitations) as well as tools available and proceed in a more constructive manner, one in which subsequent levels of complexity are supported by a sound foundation.
Then we put forth some notions on levels of complexity and making an argument for evaluation at (at least) the levels of correct, complete/comprehensive (needed for the task) and utility/e ectiveness.