BioPAX is a data exchange format intended to facilitate sharing of pathway data between databases and tools. It aims to provide a consistent format so pathway data is easier to integrate from multiple sources. BioPAX represents pathways, interactions between entities such as proteins and small molecules, and the entities themselves using an ontology defined in OWL and XML Schema. It is being developed by an international working group to support major pathway types and be extensible to new data types.
1. BioPAX A Data Exchange Format for Biological Pathways BioPAX Workgroup www.biopax.org
2.
3. Exchange Formats in the Pathway Data Space BioPAX Molecular Interactions Pro:Pro All:All PSI Biochemical Reactions SBML, CellML Regulatory Pathways Low Detail High Detail Genetic Interactions Interaction Networks Molecular Non-molecular Pro:Pro TF:Gene Genetic Metabolic Pathways Low Detail High Detail Database Exchange Formats Simulation Model Exchange Formats Small Molecules (CML) Rate Formulas
4. High Throughput Experimental Methods Expression, Interaction Data, Function, Protein modifications PubMed Existing Literature Multiple Pathway Databases Integration Nightmare! Microarray Two-Hybrid Mass Spectrometry Genetics
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16. Representing Metabolic Data in BioPAX EcoCyc: Reaction BioPAX Class: Reaction Glucose-6-p to fructose-6-p Name 5.3.1.9 EC 0.4 kcal/mole Delta G <cml>fructose-6-phosphate</cml> Product <cml>glucose-6-phosphate</cml> Substrate 1 ID Reaction
17. Representing Metabolic Data in BioPAX (cont 1) EcoCyc: Enzyme Catalysis BioPAX Class: Catalysis 2 ID Low pH Inhibitors BioPAX ID=1 Reaction glucose-6-phosphate isomerase Enzyme Catalysis of glucose-6-p to fructose-6-p Name Catalysis
18. Representing Metabolic Data in BioPAX (cont 2) EcoCyc: Pathway BioPAX Class: Pathway 10 ID 1. BioPAX ID=2 2. BioPAX ID=4 3. BioPAX ID=6 etc. Interactions Glycolysis Name Pathway
19. Converting PSI Data into BioPAX PSI XML BioPAX Class: Molecular Association PDB:3HHR DB Source PMID = 1549776 Reference X-ray Crystallography Experiment Description hGHR binds to hGH Name hGRH; hGH Participants 1 ID Molecular Association
20.
21.
22.
23.
24.
25.
26.
27.
28.
Hinweis der Redaktion
This slide shows the difference between exchange formats in the pathway data space. Pathway databases and tools are not considered here, although each one is important and addresses specific use cases. BioPAX level 1 is broad and shallow allowing us to quickly build a format that can represent most the existing data types in databases today. Details will be added in subsequent levels. This is a practical approach.
Why create a pathway exchange standard? There is a dire need in the community for the existing pathway databases to standardize on a common exchange format!!! Existing formats for pathways, such as SBML, CellML do not cater to databases needs. E.g. databases need to store extensive information is a structured way about database accession numbers, experimental description, copyright statements, etc. No current format provides this. Also, lots of data is being produced, as shown here that needs to be integrated. Power of analysis software increases with the size, quality of the data set it is run on
Also many other databases and tools have been published e.g. Patika We would like to learn from these as well. Importantly: An exchange format needs to be a compatible superset of the databases, thus BioPAX will be copying certain structures from the databases in order to support them. A good reaction to BioPAX from a group that has developed their own ontology is that BioPAX looks like their specification. Designed by the databases for themselves (DB-DB exchange) and for users.
Encapsulation: All proteins, small molecules, etc. should be able to be stored in a BioPAX record so that people don’t have to fish around for a Swiss-Prot entry when they want information about a protein. This is not space efficient, so is optional – you can choose at download time whether you want the explicit form or not. Compatible: We specifically want to be file format compatible with PSI. We want to use the same constructs as SBML where possible to maintain compatibility there. CellML can be converted to SBML, so there is already some aspect of compatibility there, Flexible: this is extremely important for community acceptance because people will not change their representation methods to enable data exchange. Thus, BioPAX will not solve the problem of semantic matching between ontologies, but it is a very good first step towards that goal, towards the goal of having everyone speak the same language (this may not be possible, though, to encompass all cases because one language may not be able to solve everyone’s problems).
One way to translate between XML based languages is to use XSLT, which is a standard method of transforming one XML document into another. (XSLT = XML Stylesheet Language Transformation) XML Schema is much more widely used. OWL will likely become the standard method for ontology development used in the knowledge representation community and the basis for the proposed semantic web. Some members of BioPAX require the types of ontology features only present in OWL. Problems we have with OWL: current lack of support, not being able to constrain slots so that they have more specific names or aliases going down the class hierarchy
Like the PSI format, BioPAX will likely have a choice of representation to cater to different needs. For instance, the user can choose a compact representation or a full representation at download time. BioPAX will be able to support both representations.
We may end up calling parts ‘Interactor’ instead of ‘Part’ to be compatible with the PSI format Pathway is a name for a set of interactions. The cell is really a large network, but we tend to organize the network into pathways for our own understanding of the very complex network. For this reason, it is important to be able to have a set of interactions and give it a name (and other description)
This list is extensible, so we can add more later. We have defined our scope to be molecular and cellular biology. For instance, you could add ‘organism’ to allow encoding of food webs or host-pathogen interaction networks on a high level of spatial scale or you could add atoms and subatomic particles to describe chemical bonds at a low level of spatial scale, but these are currently out of our scope.
This list is extensible if we choose to add other classes of interactions. This list was the most difficult to develop. We initially broke all interactions down to ‘directed’ and ‘undirected’, which is a classification by direction and is nice and simple. This did not capture enough biology for our liking so we moved to this list, which captures good parts of BIND, BioCyc, WIT, aMAZE and Patika ontologies, thus we should be able to encode and exchange data between these and other resources. Genetic interactions are in a separate branch of interactions because they are fundamentally different than physical interactions. They have no direct basis in the physical world, only in relation to the genetic concepts of genotype and phenotype. Combinations of genetic interactions can be used to infer physical pathways and interactions.
This slide puts it all together. Also shows how we will implement. XML Schema is also simpler to understand. Good editors and tools available. OWL provides a more in-depth class structure, constraints, etc. – allows you to develop a real ontology in the AI/knowledge representation field of computer science sense. DBs that support OWL have powerful data query ability that makes use of the ontology to make logical inferences to improve query results. Problems with OWL: not yet standardized, not many tools available, not many people using it or related languages.
A scientist studies particular Pathway. She is interested if newly discovered compound or its analogs can be connected to the Pathway. This requires identification of possible structural or functional analogs and cross-database search for potential connection to the Pathway. This is one of the goals of ChemBank --- siRNA, knock-outs A scientist is interested in knocking out a particular physiological function. He knows several genes reported to be involved. He constructs a total metabolic/signal transduction/gene activation network of an organism. His task is to identify if these genes 1. Can be isolated as functional blocks, modules or cluster in the network topology; 2. What is the minimum number of compounds, which need to be removed to isolate this block of genes; 3. If function is still undisrupted – go back to experiment and try to identify compensatory pathways.
Most of the data present in the BioCyc and WIT databases is metabolic pathway information. This and the following examples show that there are multiple ways to represent this data and BioPAX must be flexible to allow each representation. Remember, this is an exchange format, so we want to optimize data exchange. It seems that mandating that everyone agree to change their representations to a single model can not work. The reason for this is that each model is optimized to its specific task and people will not want to use an inefficient data model for their day to day work. This example is the second step in glycolysis and can be represented as a BioPAX reaction. Metabolic pathway data is important because it is well known for a variety of species and is present in the best developed pathway resources. Note that the enzyme is not represented here. Since multiple enzymes can catalyze the same reaction in different or even the same contexts, enzyme catalysis must be decoupled from biochemical reaction.
This example shows the enzyme catalysis step. The catalysis and the reaction classes shown here together represent this glycolysis step. This is very similar to how this data is represented in BioCyc, aMAZE and other databases.
The entire glycolysis pathway can be represented as a set of catalysis and reaction interactions. The pathway can then be given the name ‘Glycolysis’
This example shows how protein-protein interactions are represented in BioPAX. This data is important because it is being generated at a very large rate in the Proteomics field and is providing much insight into how signal transduction is organized in the cell – the basis of diseases such as cancer, diabetes and Alzheimer's. The PSI format already exists to exchange protein interaction information. It has been ratified and will be supported by the major protein interaction databases. It makes a lot of sense for BioPAX to be compatible with this existing format, so our representation of protein interactions is identical to PSI.
This example shows one way how signal transduction pathways can be represented. It is similar to how metabolic pathways are represented, although signal transduction can be represented in other ways, such as just a list of protein interactions, without any reference to the underlying biochemical mechanisms. This is an accepted high level representation because it is efficient and people in the signal transduction field can easily understand this representation because they share a significant amount of common knowledge about these patwhays.
Having subgroups allows us to have a good balance between representation and size in BioPAX. Large size slows discussion progress, but can be very representative, so subgroups involve many, but groups are small.
No comprehensive small molecule database exists, but ChemBank looks like it will become the de facto standard if it continues its current rate of development. The small molecule subgroup is also in contact with ChemBank to raise issues related to BioPAX, such as having unique and stable accession numbers for small molecules in ChemBank.
The states subgroup currently has reached a recommendation stage for BioPAX, which now needs to be turned into a document and a part of the ontology.
Examples are important to make sure we are not missing being able to represent valuable data. We are currently optimizing our development time to represent abundant data first. Although we must think about all types of data so that we can remain extensible.
This is mostly a volunteer effort, so no one is working on this full-time. We are satisfied with progress so far, although it could be faster.
Implementing the ontology in OWL will be easy when OWL support is available in GKB. Otherwise it will be very difficult because there is currently no OWL editor available. XML Schema implementation involves augmenting the PSI format. This has been done once, but needs to be updated.
Since BioPAX will be compatible with PSI, if you have only protein-protein interactions to make available, you should use that format: more details at http://psidev.sf.net
Many other people have contributed in discussions in person and on the mailing list and we would like to thank them as well.