Integration of metabolic pathways resources and regulatory metabolic network models, and deploying new tools on the integrated platform can help perform more effective and more efficient systems biology research on understanding the regulation in metabolic networks. Therefore, the tasks of (a) integrating under a single database environment regulatory metabolic networks and existing models, and (b) building tools to help with modeling and analysis are desirable and intellectually challenging computational tasks.PathCase Systems Biology (PathCase-SB) is built and released. The PathCase-SB database provides data and API for multiple user interfaces and software tools. The current PathCase-SB system provides a database-enabled framework and web-based computational tools towards facilitating the development of kinetic models for biological systems. PathCase-SB aims to integrate data of selected biological data sources on the web , and to provide more powerful and/or new capabilities via the new web-based integrative framework. This paper describes architecture and database design issues encountered in PathCase-SB's design and implementation, and presents the current design of PathCase-SB's architecture and database.PathCase-SB architecture and database provide a highly extensible and scalable environment with easy and fast  access to the data in the database. PathCase-SB itself is already being used by researchers across the world. There are many computer science applications that integrate the data of different data sources, and build new tools that are otherwise difficult or impossible to build. PathCase Systems Biology (PathCase-SB)  brings tPathCase-SB has two goals:and biochemical network data sources, and1. Integrate into a single database selected data of systems biology data sources providing added-value as compared to the original data sources.2. Build a database-enabled and SBML-  or CellMThe current version of PathCase-SB, released on August 2010, integrates models from BioModels Database -8 and KEThis paper is about the architecture and database design of PathCase-SB. More specifically, we describe• Data source integration issues encountered during PathCase-SB design, and the approach taken to resolve them,• BioModels Database SBML parser and KEGG parser developed for the original data sources, and problems encountered,• Current PathCase-SB architecture and database design, and the resulting database schema, and• Current database content.BioModels Database and CellML repositories are two leading open-access primary data sources that biologists and modelers use to store, search, exchange, and retrieve published quantitative systems biology models. Models from BioModels Database are available as SBML documents which are enriched with additional annotations in RDF (Resource Description Framework ) format.performance goals in mind.PathCase-SB architecture and database are designed with four Extensibility. The database is currently populated with three parsers, namely, BioModels Database SBML parser, CellML parser, and KEGG FTP data parser. Since biological data sources continually extend or change  their data formats, these three PathCase-SB parsers also continually go through major or minor revisions. Accordingly, (a) the corresponding PathCase database data model is designed to accommodate such  changes with relative ease, and (b) all visualization and graph manipulations are encapsulated within a client-side applet, and delegated to client-side-only computation. In summary, the PathCase-SB architecture and database are designed with extensibility in mind, i.e., the design takes into consideration possible future growth and changes.• Easy data access. User interfaces of computational applications for life sciences are usually very rich and detailed with many types of data. In order to allow such interfaces provide fast and easy data access for many different user interface functionalities, the database designs of applications should be in synch with their user interface designs, which, we hope, is the case for PathCase-SB. And, in addition, PathCase-SB interfaces are multi-faceted, involving sophisticated browsing, querying, visualization, and simulation components. PathCase-SB database is designed with easy access in mind for all the functionalities of PathCase-SB user interfaces.• Fast  response time for all interface functionalities. PathCase-SB tools are available online to users on the web. Consequently, the architecture and database is designed for providing real-time response capabilities for each functionality in PathCase-SB user interfaces. Visualization interface is designed to minimize client-server trips by shipping the original visualization specifications from the server to the client  only once, and then performing all visualization commands only at the client side, with no communications with the server. The design takes into account the requirement that all PathCase-SB queries must be processable in real-time, i.e., in a matter of seconds. That said, in some cases, this requirement also necessitates main-memory-based maintenance and manipulation of subsets of PathCase-SB database tables. We are currently looking into rewriting some of the user interface code  which cashes parts of database tables and retains them in main memory, in order to speed up observed response-time delays of some interface functions.• Scalability. PathCase-SB can be accessed by a large number of users at the same time, and the PathCase architecture and database must scale effortlessly to concurrent accesses by hundreds of users. Fully completed stress tests on PathCase-SB will be reported elsewhere; however, by load balancing on two fast servers and by offloading visualization to the client side, PathCase-SB scales to concurrent access of many (low hundreds) users.• In this section, we briefly summarize the PathCase-SB system architecture and database content.PathCase is a series of applications developed in Microsoft.NET that serve a wide variety of purposes. This paper discusses the database of one of the applications, namely, PathCase-SB. Current PathCase-SB architecture is shown in Figure At the server-side, PathCase-SB data is managed by a relational database management system, namely, Microsoft SQL Server 2008. In addition, an object-oriented data-access interface between the relational database and the application layer is provided in the form of a large set of wrapper class functions, in order to provide easy, extensible, and fast data access as well as to prevent major changes in the application when a schema change occurs during the evolution of PathCase-SB. When designing the object model behind the system, a persistent object model is used which hides the details of the actual database implementation and database access. As an example, users can easily create an object that can be stored into the database or search for a specific object by using the PathCase-SB API (application programmer's interface) without writing any SQL queries.For any browser functionality that requests a new visualization, the server first prepares an XML document providing all visualization details, and sends it to the Graph Viewer (applet) at the client-side. The Graph Viewer visualizes the data, and, handles all subsequent interactive visualization-related user commands of the current visualization directly and without any client-server communication. This speeds up the command execution, and scales the visualization. On the flip-side, if the client machine is old and slow, or is short in main memory, PathCase-SB visualizations also slow down, but, from our own testing, a typical average office PC/laptop can easily run PathCase-SB visualization tools with no noticeable performance problems.Client-side PathCase-SB functionality includes basic HTML that renders the main site interface to the user, and JavaScript with AJAX that makes the site highly responsive to the user.The amount of core data in PathCase-SB database, which is parsed from BioModels Database and KEGG, has been updated periodically since its initial version 1 (2008) to the current release . From Version 1 to Version 2, PathCase-SB database has grown 200 MB in size, and nine new tables are added to the database schema. As a result, Version 2 of the PathCase-SB database contains 20% more models, 37% more reactions, 10% more processes, 4% more basic molecules, and ~4% more proteins when compared to PathCase-SB database in 2008. The detailed statistics are shown in Table Please note that the user interfaces of PathCase-SB system are extensive, covered in a separate paper , and will not be discussed here. Next, in the section on "data model design", we discuss data model design issues. The section on "scalability and efficiency" discusses two optimization schemes for browsing and built-in query processing, namely, the use of labeling schemes and caching small dimension tables for main-memory joins. The section on "BioModels Database SBML parser" presents the details of parsing SBML documents from the BioModels Database site. In the section on "capturing BioModels information in PathCase-SB database", we discuss how BioModels Database data is converted into PathCase-SB database schema . The section on "mappings" presents how BioModels SBML documents "link" models to external data sources; and, based on this knowledge, in the section on "PathCase-SB Database Schema", we discuss the actual mapping- and annotation-related tables of PathCase-SB.Appendix 1, Figure One design criterion used is for PathCase-SB never to involve any data curation. With this in mind, PathCase-SB database design has encountered two data integration choices, discussed next.separate tables for common entities of different systems biology and/or biochemical network data sources, e.g., BioModels Database and KEGG data sources. As an example, PathCase-SB database maintains a species table occurring in BioModels Database models and molecular_entities table for KEGG molecular entities. Such an approach allows the system to cleanly separate data from different data sources, and, to add new data sources seamlessly, without any future data cleansing and data integration problems. The current approach however requires an additional "mapping" effort: PathCase-SB maintains mappings between all pairs of data sources on their corresponding entities. For BioModels and KEGG, there are three major mappings: <species, molecular entities>, <reactions, process-entities>, <models, pathways>.One design choice is whether or not to integrate common information between systems biology  data sources and biochemical reaction network data sources . In an earlier database design, such information was fully integrated, and soon many data integration, data repopulation, and curation problems surfaced. The current approach for capturing data that originate from different systems biology and biochemical network databases is to have different systems biology (or metabolic network) data sources into a single set of tables. As it turns out, the data models of SBML-oriented data sources (such as BioModels) and CellML data source are significantly different, turning any tightly-coupled data integration into a significant data curation issue. Thus, at this point in time, PathCase-SB keeps separate tables for different systems biology data sources as well. As an example, currently, PathCase-SB generates and maintains distinct sets of tables for BioModels Database and CellML data sources.A second design choice is whether or not to integrate data in Briefly, the advantages of keeping separate tables for different systems biology data sources and pathways data sources are as follows.No data curation. Integrating data from different systems biology data sources almost always translates into further data curation, which may be prone to errors, and needs extensive domain expertise. The current PathCase-SB database design approach avoids data curation as a design principle.• Simple and easy to maintain application. The clean separation of data originating from different data sources, and creating selective "mappings" is a simpler and easier-to-maintain approach, and is used by PathCase-SB. The interfaces of PathCase-SB are designed in such a way that data in different data sources are naturally presented separately, while model data is linked to biochemical network data  and relevant annotations  at the presentation level on an as-needed basis.• Easy data replenishment. With a data separation-and-mapping approach, replenishing data from a data source becomes a relatively straightforward work, in comparison to the task of curating and integrating data of different data sources with each data reload.• Easier adaptation to data source format/version changes. The exception to "easy data replenishment" occurs when, for various reasons, the data source itself makes significant format/version changes that translate into significant data source parser changes on the PathCase-SB side, which unfortunately occurs sometimes. We have already encountered such data source format/version changes when both BioModels Database and KEGG data formats have changed recently--BioModels Database changes involving relatively easy-to-handle SBML version improvements, and KEGG changes involving significant format changes, with an overall effect of significant changes in our parser applications. Nevertheless, if the data of PathCase-SB were to be tightly coupled, we believe that PathCase-SB database repopulation would have been even more difficult.• At the present time, PathCase-SB database has data from the BioModels Database (as the systems biology data source), and from the KEGG data source (as a metabolic pathways data source).Currently, the PathCase-SB database contains four classes of tables capturing the following information:a. Biochemical reaction network-related tables: These tables capture information in a biochemical reaction network as defined by a well-defined web-based data source on biochemical networks. As the biochemical network and its database, we use the KEGG metabolic pathways and the PathCase database (see [ase (see ). The Paase  to the systems biology models , andd. Tables annotating systems biology data with other ontologies or taxonomies: These tables capture annotations of systems biology models .Towards the goals of improving time efficiency and scalability, the PathCase-SB system has utilized two optimization schemes for browsing and built-in query processing, namely, the use of labeling schemes for efficiently evaluating descendant/ancestor queries within hierarchical structures such as Gene Ontology (GO) , and thebiological process, cellular component, and molecular function, are defined in GO. They are represented as directed acyclic graphs (DAGs) in which the terms form nodes and the relations between terms form edges.The Gene Ontology is the result of an effort aimed at providing a controlled vocabulary for describing roles of genes and gene products in any organism. Three ontologies, t, obtains all descendant terms of the term t within the GO, and lists all models that refer to terms in all descendants of t as well as the term t. This functionality can be implemented in an iterative manner, which becomes time-inefficient .The use of labeling schemes when traversing the Gene Ontology helps improve the performance of the PathCase-SB browser when browsing for "BioModels Database models by GO terms". More specifically, the PathCase-SB browser functionality "Browse BioModels Database models by GO terms" takes a GO term s and making all roots the children of s). For each node u in the graph, the set of NodeCodes of u, denoted NC(u), are assigned using a breadth-first-search traversal starting from the source node as follows: If u is the virtual source node, then NC(u) contains only one element, the empty string. Let u be a node with a set of NodeCodes, NC(u), and 0v, 1v,...k vbe u's children in sibling order, then for each x in NC(u), a code xi is added to NC(iv), where 0 ≤ I ≤ k. While we have chosen to use the NodeCodes labeling in PathCase-SB, there are also interval-based labeling and prefix-based labeling schemes, which are efficient for evaluating descendant/ancestor queries in GO as well. Next we briefly evaluate the time efficiency of using the NodeCodes labeling approach in PathCase-SB.To overcome the limitations of traditional iterative methods for descendant/ancestor query evaluation, we have chosen to use a labeling scheme for modeling DAG-shaped hierarchies (such as GO) in order to efficiently process descendant/ancestor queries. In PathCase-SB, we use NodeCodes labeling ,16 for qIterative and NodeCodes. The Iterative method refers to the method where the descendants of a given term are retrieved by iteratively traversing the GO graph. The Iterative method is our baseline approach which is commonly utilized by existing tools [NodeCodes labeling method performs 2.50 times faster than the Iterative method.As of Aug. 2010, Gene Ontology has 10,268 terms having one or more descendants. In our first experiment on time efficiency, we have run descendant queries for these 10,268 terms, and compared two methods: ng tools ,18. The selectivity is defined as the proportion of terms that it returns. In Gene Ontology, the term (GO: 0008150) biological_process has the maximum number of descendants. This term has 14,889 descendants, which leads to the maximum selectivity (58.7%) for the descendant query. In this experiment, we have chosen to use selectivity values ranging from 58.7% to 0.01%. We have run these five query types 50 times each, and the average query processing time is shown in Table In our next experiment, we have run descendant queries on five different classes: each class corresponds to a different choice of input node type, and, therefore, of different query selectivity. Here, query NodeCodes requires close to constant time for processing each class. For Class 1 and Class 2, NodeCodes Labeling performs 190.52 times and 90.45 times faster than the Iterative method, respectively. Figure From Table Attribute, EntityName, GraphNode, MolecularEntityType, NameId, NameType, PathwaysType, ProcessEntityRole, ReactionSpeciesRole, RnaType, RuleType, and UnitDefinitonTables. As an example, consider the ReactionSpeciesRole table. The cached table is utilized by four built-in queries:PathCase-SB utilizes a caching scheme for optimizing browsing and built-in query processing. More specifically, for fact-dimension tables, PathCase-SB caches all small dimension tables  in the database subschemas to avoid multiple disk-based joins with the fact table  in that subschema. In total, there are twelve such cached tables, which include Find models containing different expressions of metabolic flux associated to the same reaction;1) Find models that contain metabolites of a given pathway;2) Find models that contain reactions of a given pathway; and3) Find kinetic models corresponding to a given reaction in a given pathway.4) Species Name (Reaction Role) column which is obtained from a join between ReactionSpecies and ReactionSpeciesRole tables on the column roleId from ReactionSpecies table. Since joins are expensive, and such a caching approach improves the efficiency of query processing, our caching approach helps with PathCase-SB real-time query processing and scalability requirements.In the third query "Find models that contain reactions of a given pathway", the tabular results include The chart in Figure After parsing the relevant SBML elements or annotation, the parser populates the database not by direct inline SQL calls, but by employing a large number (about 200) of database wrapper class functions. One problem with having inline SQL code is that, since there is no abstraction from the data source, one is bound to a particular schema because table and column names are specified directly in the code, and, this may have negative implications: (i) when the data source is changed, the whole parser application code needs to be scanned, and the corresponding inline SQL calls need to be changed one by one, instead of revising just the wrapper class library; and (ii) error handling becomes difficult and decentralized.PathwaysSBLib. There are two classes that all database access classes use, DBWrapper and DBRow. DBWrapper implements a singleton pattern via the use of an instance, and creates one single database connection at a time, which is shared by multiple database calls. DBRow is used to abstract the idea of a database tuple  into a class in an object-oriented manner. These two classes centralize all database access through a series of public functions. All pertinent information such as connection string (which is stored in configuration files) and exception handling are processed inside these classes. This approach of "single point of database contact" allows us to centralize all data access information and customization, making future updates much easier.PathCase-SB system uses object-oriented wrapper classes to access the data. Wrapper classes share common interface and data access code, as well as common utilities such as logging  and error handling. The new class library is called Server" wrapper class associated with it. Each one of these classes exposes public properties that correspond to columns in that table. This approach allows us to change the database schema without breaking an existing class that might reference the class at hand. It also allows for type-safe access to data without any knowledge of column names or database schema. Type-safe access means, for example, that the code specifies in property declaration that ID is an integer), compared to inline SQL usage where one would cast a column to a data type without any guarantees that it will work.Each table in the PathCase-SB schema has a "In Section "BioModels Database Entities and Relationships", we present entities and relationships of data in the BioModels Database data source. Section "PathCase-SB Schema: BioModels Database-Related Information" lists database table schemata, and presents additional details for each table. Since BioModels Database uses SBML documents to capture its data, we view a model from a BioModels Database as an SBML document. A BioModel Database model also captures additional information, mostly in the form of annotations.Model, Species, SpeciesType, Reaction, Compartment, CompartmentType, Event, Rule, RuleType, Constraint, FunctionDefinition, UnitDefinition, Parameter, InitialAssignment; for more details on these entities, please see the SBML Level 2, Version 3 specification [BioModel Database SBML documents capture all entities as defined by the Systems Biology Markup Language (SBML) Level 2, Version 3 specification. SBML is a model representation format for systems biology, and allows models of arbitrary complexity to be represented. More specifically, SBML allows the specification of the following entities: DataSource, Sbase, ModelLayout , KineticLaw, ReactionSpeciesRole, ReactionSpecies, StoichiometryMath, EventTrigger, EventDelay, EventAssignment, EventAssignmentArgument, and KineticLawParameter. To save space, below, we describe only a few of these PathCase-SB-specific entities and relationships. Please see Appendix 1, Figure In addition to SBML-based entities, PathCase-SB has other entities and relationships, namely, DataSource entity retains all information specific to a systems biology data source.Sbase entity serves as a base object for the actual entities. Each entity (except DataSource) in the database extends Sbase entity. Sbase contains a sboTerm attribute for SBO (Systems Biology Ontology) annotations. Most SBML elements have SBO annotations which define the semantics of the corresponding term. For instance, for a modifier in a reaction, its SBO term (if available) may specify its specific modifier role  in that reaction. Storing SBO annotations helps in terms of establishing connections both between different models and between metabolic pathways and models.Model entity contains basic information for each systems biology model.StoichiometryMath entity specifies the full stoichiometry of a given reaction. SBML specification allows the definition of stoichiometry through either double values, or MathML expressions (for more complicated stoichiometry representation). This entity includes two stoichiometry-related fields: (i) stoichiometry (float), and (ii) stoichiometryMath (mathml) where the expression in parentheses shows the type of the stored information.DataSource, Sbase, Model, ModelLayout, FunctionDefinition, UnitDefinition, Unit, UnitComposition, CompartmentType, SpeciesType, Compartment, CompartmentClass, CompartmentClassDictionary, Species, Common_Species, Parameter, InitialAssignment, RuleType, Rule, Constraint, Reaction, KineticLaw, ReactionSpeciesRole, ReactionSpecies, StoichiometryMath, Event, EventTrigger, EventDelay, EventAssignment, Author, ModelMetadata, DesignedBy. Please see Appendix 2, Figure In this section, we specify the database tables of the BioModels-related part of PathCase-SB database, omitting the CellML- and KEGG-related tables in PathCase-SB. The complete list of BioModels-related tables in the database include For ease of understanding, in naming tables, we use the same naming conventions as defined by the SBML Level 2, Version 3, Release 2 specification ). UnderlDataSource  table captures data source information. name is a key  in this table.Sbase . Unless noted otherwise, each entity (except DataSource) in this schema extends Sbase entity. Therefore, in each table (including Model table), id field is a foreign key referring to the id field in Sbase table. Whenever a table contains a field with name "id", it is a primary key in that table. Unless noted otherwise, all foreign keys adopt "ON DELETE CASCADE" property.Model  table captures basic information for each systems biology model. dataSourceId is a foreign key referring to the id field in DataSourcetable.ModelLayout  table. One lesson we learned in PathCase [id, where id is a foreign key referring to the id field in Model table.PathCase  is that Compartment .CompartmentClass  table contains a biologically well-defined compartment classification class hierarchy. parentId is a foreign key referring to the id field in CompartmentClass table. Parent of root compartments is null.CompartmentClassDictionary  table holds information needed to match the correct compartment class with a compartment. This table is mainly used by SBML parser during the creation of each compartment. Compartment names in this table are unique.Species  table captures species information and the relationships it is involved in. Attribute speciesTypeId is a foreign key referring to the id field in SpeciesType table; substanceUnitsId is a foreign key referring to the id field in UnitDefinition table; and compartmentId is a foreign key referring to the id field in Compartment table.Reaction  table captures reaction information in models.ReactionSpecies  table captures species information in reactions.Author table contains general information about authors.DesignedBy table captures information about the creator(s) of each model. It represents many-to-many relationship between Model and Author tables which are linked through modelKey and authorKey foreign keys, respectively.ModelMetadata  table contains version (date) information about the model. publicationId is a foreign key which is used to link the Model to BioModels[BioModels originalBelow we briefly discuss a number of additional issues that have arisen when pushing data in SBML documents into database tables.uniqueidentifier. On the other hand, each SBML model specification contains an id field of type alphanumeric string for the corresponding entities. Ids in an SBML model are used for cross-referencing among different entity definitions, and, most of the time, id is the only meaningful name  for the corresponding entity. Although each database table has an id field, such fields store an arbitrarily generated unique identifier which is independent of the corresponding model. This information is usually crucial, especially when models omit the optional name field, and use id for that purpose. Thus, we have added the sbmlId field into the corresponding relations, for which SBML specification defines an id field.Each table in a PathCase-SB database needs to have an id field of type Most of the mathematical expressions (represented in MathML) such as kinetic laws, rules, etc., in a model are allowed to contain references to pre-defined mathematical functions in the model. To accommodate such a relationship in the database model, one alternative is to consider it as an argument like species, parameter, and compartment names in math expressions. And, adding an attribute function_id into the argument entity accommodates references to function names in different MathML expressions throughout the model.units and models, model ids can be included as a field in units table. For built-in base units, the model id is set as null. And, base units are pre-specified before any database population.In SBML, there are built-in "base" units, and user-specified units that are defined based on built-in units. User-specified units cannot be built upon other user-specified units. Furthermore, since user-specified units are defined in the context of a specific model to provide connection between Pathcase_SB_UserUploads in order to temporarily save user-uploaded data. This database has a schema similar to the Pathcase-SB schema. The user-uploaded data is presently kept in a separate database than the PathCase-SB database due to (i) privacy and intellectual property rights concerns, and (ii) possible manageability issues to maintain, purge, and integrate the uploaded data into the existing permanent data.To implement the functionality of users uploading their own models for visualization and simulation, PathCase-SB maintains a separate database, namely, Part of the BioModels' curation effort involves linking components of a systems biology model to other external and related databases. Such external links are located in the annotation field of each major entity in an SBML model. Annotation fields in SBML are formatted in RDF . Note that some models may have only a subset of the five external links.• Linking Reactions. The annotation field of each reaction element contains links to four external related databases, namely, KEGG, Reactome, EC number, and Gene Ontology. Note that some reactions may have only a subset of the four external links.• Linking Species to Metabolites/Compounds. The annotation field of each species element contains links to two external related databases, namely, KEGG and CHEBI [• nd CHEBI ,22,23 whLinking Compartments to GO. The annotation field of each compartment element contains link to GO Cellular Component Subontology, which may be used to reconcile compartments from different models.• We have designed and populated three tables that map BioModels Database entities and KEGG entities:Species of systems biology models and Molecular Entities of KEGG,(a) Reactions of systems biology models and Process Entities of KEGG, and(b) Models of systems biology models and Pathways of KEGG.(c) Below we briefly specify the schema of the three relations.MapSpeciesMolecularEntities . In this table, molecularEntityId is a foreign key referring to the id field in molecular_entities table; speciesId is a foreign key referring to the id field in species table, and qualifierId is a foreign key referring to the id field in AnnotationQualifier table.MapReactionsProcessEntities . In this table, processId is a foreign key referring to the id field in processes table; reactionId is a foreign key referring to the id field in reaction table; and qualifierId is a foreign key referring to the id field in AnnotationQualifier table.MapModelsPathways . modelId is a foreign key referring to the id field in models table; pathwayId is a foreign key referring to the id field in pathways table; qualifierId is a foreign key referring to the id field in AnnotationQualifier table; and organismGroupId is a foreign key referring to the id field in organismGroup table.We maintain three annotation tables for BioModels Database models:models with organisms from the NCBI organism taxonomy,(a) Annotating models with Gene Ontology (GO) terms,(b) Annotating reactions in models with EC (Enzyme Commission) numbers.(c) Annotating Below we briefly specify the schemata involving the above-listed three mappings.ModelOrganism  table annotates BioModels Database systems biology models with organisms/organism groups (as specified in the NCBI organism taxonomy). This information is not part of SBML document; however, BioModels Database curators have captured it as metadata (annotation). modelId is a foreign key referring to the id field in model table; organismGroupId is a foreign key referring to the id field in organism_groups table; qualifierId is a foreign key referring to the id field in AnnotationQualifier table.MapSbaseGO  table annotates systems biology models with GO terms.sbaseId is a foreign key referring to the id field in sbase table. goId is a foreign key referring to the id field in go_terms table ; and quMapReactionECNumber . reactionId is a foreign key referring to the id field in reaction table; ecNumber is a foreign key referring to the ec_number field in ec_numbers table ; and qualifierId is a foreign key referring to the id field in AnnotationQualifier table.For efficiency purposes involving browser interface functionalities of PathCase-SB, we also maintain three distinct tables, as listed below.AnnotationQualifier. BioModels' MIRIAM specification [AnnotationQualifier table. id is an auto-increment field. This table is pre-filled with the following name attribute values: is, isDescribedBy, encodes, hasPart, hasVersion, isEncodedBy, isHomologTo, isPartOf, isVersionOf, occursIn, unknown.fication  defines GONodeCodes  is a secondary table which is added to make "Browse Models by GO terms" functionality of the PathCase-SB web interface more efficient. The table stores precomputed NodeCodes (See section on "Labeling Schemes") for GO terms. goId is a foreign key referring to the id field in go_terms table .ec_numbers  table is designed to make "Browse Reactions by EC Numbers" functionality of the web interface more efficient through the use of NodeCodes [nodeCode attribute.odeCodes . The tabodeCodes , and modBelow, we summarize the current results from mapping KEGG pathways to Biomodels Database models based on the annotation information provided in each model. The extracted annotations are stored in the PathCase-SB database. Currently, the PathCase-SB main browsing interface now has four browsing functions: "Models by Name", "Models by KEGG Pathways", "Models by Organisms" and "Models by GO Terms" in order to aid users with faster and intuitive way to browse models.http://www.genome.jp/kegg/pathway.html for the complete list of pathway categories in KEGG).Out of 252 models in the database, (a) 30 models have a reference to a KEGG pathway, and (b) 229 models have a reference to a GO term. Due to the fact that multiple models are mapped to the same pathway (possibly in different organisms), the number of distinct KEGG pathways referred in 30 models is 30. Among 30 referenced KEGG pathways, only 14 of them are metabolic pathways, and the remaining 16 pathways belong to other categories listed in KEGG, such as signaling pathways, gene-regulation pathways, and so on . There is no model that refers to a metabolic pathway which is not included in the PathCase KEGG database.The PathCase KEGG database contains 8,182 processes among which 173 processes have at least one mapped reaction in a BioModels Database model. In the database, there are 6,957 reactions stored (extracted from 252 models), and 421 reactions have a mapping to one or more of the above 173 processes.The PathCase KEGG database contains 27,220 molecular entities among which 223 molecular entities have at least one mapped species in a BioModels Database model. In the database, there are 4,963 species stored, and 1110 species have a mapping to one or more of the above 223 molecular entities.In this paper, we have described the architecture and database design and modeling issues of PathCase-SB, which integrates data from different systems biology data sources (BioModels Database and CellML) and a metabolic network data source (KEGG).We believe that integrating data from multiple biology data sources and then providing additional computational tools is a commonly occurring theme in life sciences, and Pathcase-SB is one such example. And, in designing an application architecture and database for such an integrated environment, there are many lessons to be learned, some easily generalizable to different environments , and some data source instance-specific . There are also tradeoffs involving extensibility, data access, realtime response time, and scalability. This paper, in the context of PathCase-SB, has highlighted a number of lessons and tradeoffs.http://nashua.case.edu/PathwaysSB/Web.PathCase-SB is freely available for use at Operating Systems: PathCase-SB is accessed from a browser; therefore, it is platform-independent.Browsers: PathCase-SB is extensively tested with browsers Internet Explorer and Mozilla Firefox. It is also tested to a lesser degree with Google Chrome and with Safari browsers.Other Requirements: (a) Ajax and JavaScript. PathCase-SB makes use of Ajax, which is a way of sending data between a web server and client asynchronously with normal page requests. This helps PathCase-SB remain quick and responsive even if there are a substantial amount of data to display at once. For this and other features of the site to work (such as collapsing windows), JavaScript must be enabled in the browser. All modern web browsers such as those mentioned above support JavaScript, but it is possible to have personal security settings in place that prevent JavaScript from running. If certain portions of the site do not appear to be working properly, the user must ensure that JavaScript is enabled and that the browser security settings allow scripting elements to run. (b) Cookies. In order to view certain portions of the site correctly PathCase-SB occasionally uses, which are small bits of text stored on a local system's hard drive. Users must ensure that cookies are enabled in the browser in order to get the most out of PathCase-SB. (c) Java Runtime Environment. The PathCase-SB Graph Viewer uses the Java software platform. In order to view the applet, version 1.6 or later of the Java Runtime Environment must be installed on the system from which the viewer is accessed. Users should download and install the latest version of the free plug-in, JRE 1.6 . Some browsers may not allow Java applets to run because of security concerns; if the JRE is installed properly and the Graph Viewer still does not appear, the user should make sure that the browser's security settings allow Java applets . (d) Monitor Resolution. While PathCase-SB has been designed to gracefully fit into just about any monitor resolution, it is best viewed at resolutions of 1024 × 768 pixels and up. 800 × 600 and 640 × 480 resolutions will work, too, but the results may not be quite as pleasing to the eye. (e) Server-side implementation. Server-side implementation of PathCase-SB is done with ASP.NET Framework using the C#.NET language.Database access support and extensibility. For safety, integrity, and other reasons, the Pathcase-SB application's database is accessed only through its API (Application Programmers Interface), which has about 50 API functions. Third-party application developers can use the existing API functions currently available in the PathCase-SB API to develop new applications. New API functionalities can also be developed if they are needed for third-party developers.Any restrictions to use: PathCase-SB is free to use by academics and non-academics; there are no restrictions.PathCase-SB architecture and databases design was a collaborative task, led by AC, ZMO, GO, NL, and (late) MC. PathCase-SB implementation was done by AC (both server-side and client-side components), XQ , SAC , MD (CellML parser), EC (KEGG data parser), and AEC (software testing). Manuscript has been read and approved by all authors and that all authors agree to the submission of the manuscript to BMC Systems Biology journal.In Figure In Figure In Figure Appendix 4 is a summary from the following web page (retrieved on September 2011)http://www.ebi.ac.uk/compneur-srv/miriam-main/mdb?section=qualifiersThe qualification of an annotation specifies the relation between a model component and its annotation.is: The specified modeling object is the subject of the referenced resource.isDescribedBy: The specified modeling object is described by the referenced resource.isDerivedFrom: The specified modeling object is described by the modeling object in the referenced resource.encodes: The specified biological entity encodes, directly or transitively, the subject of the referenced resource.hasPart: The specified biological entity includes the subject of the referenced resource, either physically or logically.hasProperty: The subject of the referenced resource is a property of the biological entity represented by the model component.hasTaxon: The biological entity represented by the model element is taxonomically restricted, where the restriction is the subject of the referenced resource.hasVersion: The subject of the referenced resource is a version or an instance of the specified biological entity.is: The biological entity represented by the model component is the subject of the referenced resource. This relation might be used to link a reaction to its exact counterpart in KEGG or Reactome for instance.isPropertyOf: The biological entity represented by the model component is a property of the referenced resource.isDescribedBy: The specified biological entity is described by the referenced resource.isEncodedBy: The specified biological entity is encoded, directly or transitively, by the subject of the referenced resource.isHomologTo: The biological entity represented by the model component is homolog, to the subject of the referenced resource, i.e. they share a common ancestor.isPartOf: The specified biological entity is a physical or logical part of the subject of the referenced resource.isVersionOf: The specified biological entity is a version or an instance of the subject of the referenced resource.occursIn: The specified biological entity represented by the model component takes place in the subject of the reference resource.model element contains links to external pathway-related databases which are listed below with example entries. Note that some models may have only a subset of the external links listed below.The annotation field of each a. KEGG<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:kegg.pathway:tbr00010"/></rdf:Bag></bqbiol:is>b. Reactome<bqbiol:isHomologTo><rdf:Bag><rdf:li rdf:resource="urn:miriam:reactome:REACT_1383"/></rdf:Bag></bqbiol:isHomologTo>c. NCBI's Organism Taxonomy<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:taxonomy:5691"/></rdf:Bag></bqbiol:is>d. PubMed<bqmodel:isDescribedBy><rdf:Bag><rdf:li rdf:resource="urn:miriam:pubmed:11415442"/></rdf:Bag></bqmodel:isDescribedBy>e. GO<bqbiol:isVersionOf><rdf:Bag><rdf:li rdf:resource="urn:miriam:obo.go:GO%3A0006096"/></rdf:Bag></bqbiol:isVersionOf>a. KEGG<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:kegg.reaction:R00771"/></rdf:Bag></bqbiol:is>b. Reactome<bqbiol:isHomologTo><rdf:Bag><rdf:li rdf:resource="urn:miriam:reactome:REACT_1164"/></rdf:Bag></bqbiol:isHomologTo>c. EC#<bqbiol:isVersionOf><rdf:Bag><rdf:li rdf:resource="urn:miriam:ec-code:5.3.1.9"/></rdf:Bag></bqbiol:isVersionOf>d. GO<bqbiol:isVersionOf><rdf:Bag><rdf:li rdf:resource="urn:miriam:obo.go:GO%3A0046323"/></rdf:Bag></bqbiol:isVersionOf>a. KEGG<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:kegg.compound:C00074"/></rdf:Bag></bqbiol:is>b. CHEBI<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:obo.chebi:CHEBI%3A18021"/></rdf:Bag></bqbiol:is>a. GO<bqbiol:is><rdf:Bag><rdf:li rdf:resource="urn:miriam:obo.go:GO%3A0005829"/></rdf:Bag></bqbiol:is>


Signaling networks in eukaryotes are made up of upstream and downstream subnetworks. The upstream subnetwork contains the intertwined network of signaling pathways, while the downstream regulatory part contains transcription factors and their binding sites on the DNA as well as microRNAs and their mRNA targets. Currently, most signaling and regulatory databases contain only a subsection of this network, making comprehensive analyses highly time-consuming and dependent on specific data handling expertise. The need for detailed mapping of signaling systems is also supported by the fact that several drug development failures were caused by undiscovered cross-talk or regulatory effects of drug targets. We previously created a uniformly curated signaling pathway resource, SignaLink, to facilitate the analysis of pathway cross-talks. Here, we present SignaLink 2, which significantly extends the coverage and applications of its predecessor.C. elegans and D. melanogaster; 2) combines manual curation with large-scale datasets; 3) provides confidence scores for each interaction; 4) operates a customizable download page with multiple file formats . Non-profit users can access SignaLink 2 free of charge at http://SignaLink.org.We developed a novel concept to integrate and utilize different subsections  of the signaling network. The multi-layered (onion-like) database structure is made up of signaling pathways, their pathway regulators  and modifier enzymes , as well as transcriptional and post-transcriptional regulators of all of these components. The user-friendly website allows the interactive exploration of how each signaling protein is regulated. The customizable download page enables the analysis of any user-specified part of the signaling network. Compared to other signaling resources, distinctive features of SignaLink 2 are the following: 1) it involves experimental data not only from humans but from two invertebrate model organisms, With SignaLink 2 as a single resource, users can effectively analyze signaling pathways, scaffold proteins, modifier enzymes, transcription factors and miRNAs that are important in the regulation of signaling processes. This integrated resource allows the systems-level examination of how cross-talks and signaling flow are regulated, as well as provide data for cross-species comparisons and drug discovery analyses. Caenorhabditis elegans, the fruit fly Drosophila melanogaster and humans [Reliable analyses of signaling pathways need uniform pathway definitions and curation rules applied to all pathways. Accordingly, we previously created SignaLink, a resource containing major signaling pathways of the nematode d humans . Specifid humans . Signalid humans . In addid humans ,5.in silico prediction and existing dataset imports [Despite the complexity of eukaryotic signaling networks, current signaling or regulation-related resources contain only specific parts of such a global signaling network. As a consequence, computational background and expertise in different bioinformatics resources are needed to answer questions about how a signaling pathway is regulated, or how the pathways influence each other through transcription and miRNA-mediated gene silencing. A few studies already combined regulatory and protein-protein interaction networks -9, while imports .Taking into consideration the need for a novel arrangement of signaling and regulatory data to examine signaling processes on a systems-level, we present SignaLink 2, a database with multi-layered (onion-like) structure. Our basic aim was to develop an integrated database that helps anyone to understand how cellular signaling pathways and their cross-talks are regulated. To accomplish this goal, SignaLink 2 contains for worms, flies and humans 1) pathway components and cross-talks; 2) interacting proteins that modify or facilitate signaling reactions; and 3) regulatory components (transcription factors and miRNAs) that affect the expression of pathway proteins and their interactors.We developed an onion-like, multi-layered database structure to integrate and utilize the different subsections  of the signaling network. The multi-layered structure and content of each layer is illustrated and listed in Figure The core of SignaLink 2 contains seven major pathways, which are biochemically and evolutionary defined, and encompass all major developmental signaling mechanisms : RTK  With manual curation, we collected scaffold proteins and endocytosis-related proteins and linked them to signaling pathway proteins, based on the scaffold protein list of the Ref.  and signNext, using the ELM server , we searFinally, we identified underlying transcriptional and post-transcriptional regulatory networks that control the expression of signaling components and their interactors. TF–TF binding site interactions were used to list transcriptional connections between TFs and genes encoding signaling components or pathway interactors. We downloaded experimental and predicted data from the EdgeDB, REDFly, DroID, ABS, JASPAR, HTRIdb, OregAnno, ENCODE and PAZAR databases ,20-27. WThe core of SignaLink 2 contains the interactions of pathway member proteins and their regulators (endocytotic and scaffold proteins). This data is derived from manual curation of the literature, and has been entered into the database directly. All the other layers of the database were acquired from external resources. To integrate these resources with the core of SignaLink 2 and with each other, we used the original accession numbers of the imported databases  and mapped them to UniProt Primary IDs using the UniProt Mapping Service . The intUtility section), allowing a personalized level of quality and confidence to be set.For every data source containing integrated data sets that is interactions collected with different methods, quality control is highly important. For each PPI, we calculated a confidence score based on a GO semantic similarity score  Figure . By perfWe also note that all experimental interactions in SignaLink either collected by manual curation or integration of other sources were coming from various cell types and experimental conditions. Therefore, interactions in SignaLink 2 are the sum of many possible interactions but not all of these interactions can happen at the same time or same place. Users can integrate cell localization and tissue expression data to the networks of SignaLink 2 to filter compartment- or tissue-specific interactions, respectively. We plan to include such data types in the next version of SignaLink., where each source has an attribute whether the source contains experimentally verified or predicted interactions. In addition, each interaction has one or more literature references  about the interaction, retrieved from the integrated databases). References are listed in the reference table. In the interaction table, each interaction also has attributes whether it is direct or indirect, directed or undirected, stimulatory or inhibitory. For example, direct interaction occurs between a kinase and its phosphorylation target; and we mean indirect interaction between a transcription factor and its target gene, or between two proteins that are members of a complex but no evidence is known that they directly bind to each other. All literature-curated interactions in SignaLink 2 are directed. For the protein-protein interactions retrieved from external resources, we predicted a single direction. Thus, these interactions are also listed as directed, while the remaining PPIs for which we could not determine the direction are listed as undirected. Interactions may have stimulatory or inhibitory effect. Where we could not determine the effect from the original publication or sources, we mention "stimulatory or inhibitory interaction". An interaction may have multiple scores, which are stored at the interaction_score table. This table contains the original scores from ELM Structure Filter, TarBase, miRecords, miRanda, PicTar, TargetScan, PutMir and JASPAR as well as the confidence scores we generated with a GO Semantic Similarity-based method and with the PRINCESS protein interaction evaluation tool [SignaLink 2 stores data in a MySQL database  On the top of a protein datasheet basic information is shown: name, species-specific database  IDs and UniProt accessions. All of these IDs are hyperlinked to the corresponding website to help discovering further details. In the case of pathway member proteins, basic information also includes pathway memberships and topological properties. On the protein datasheet, users can interactively explore the interactions of the queried protein both with a list, where interactions are grouped by layers, and with an interactive network visualization of these interactions. In both cases, the user can easily obtain information on each interaction, including the type of the interaction , interaction scores from the original source (if applicable) and confidence scores generated by SigaLink 2. The evidence for the interaction is shown with PubMed links to the external source from where we integrated the given interaction, and PubMed links to the original paper used as a reference. The information originated from different integrated resources is easily comparable, and bi-directional relations also have good visibility. The URLs of the protein datasheets are constructed simply from the proteins’ UniProt IDs, with a scheme similar to that of UniProt, e.g., http://signalink.org/protein/P00533. In addition, all protein datasheets can be accessed with gene names or species-specific database IDs allowing the easy linking of these datasheets from other webpages or resources . We have included a comprehensive FAQ site and inserted short popup help-boxes in most of the web pages to support the users.The protein datasheets of the website display all information stored in SignaLink 2 about the queried protein. In Figure The entire database is available as a MySQL dump file. Alternatively, we developed a BioMART-like customizable download page, where users can easily select and combine the species, pathways, layers and the file format of download. The customized subnetworks can be downloaded in various formats: CSV, BioPAX, SBML, PSI-MI tab or PSI-MI XML and in a Cytoscape CYS file. Data can be compressed by GNU zip or zip. After selecting the details of the download, for advanced users, we offer additional customization where within each layer the different source databases can be filtered by score values, or even excluded. A general switch is also available to exclude all predicted interactions.All user-specified download options are automatically transformed to MySQL queries. For each download, we generate a URL, where users can access the data for 14 days. Optionally, users can provide their e-mail addresses to which files smaller than 10 MB will be e-mailed. We have developed a download module (written in Python), to manage the queries and to convert the result of the queries to user-specified file formats. In conclusion, SignaLink 2 serves as an integrated signaling resource where the origin, type and confidence level of each interaction are clearly listed, allowing the user to easily access and filter data.Signaling cross-talks are important connections between different pathways and can generate novel input–output combinations as well as maintain the dynamic adaptation of the signaling system ,40. We hThough cross-talk is generally defined as a physical interaction between pathway proteins, genetic studies often point out the importance of pathway cross-talks through transcription. In this case, cross-talk is mediated by a terminal transcription factor (TF) of a given pathway that regulates the expression of a component of another pathway ,42. Withi.e., signaling pathways and regulatory components) with network data of other cellular processes, such as autophagy or apoptosis, would allow Bayesian modeling on the regulation of these processes.Modeling signaling networks is a key approach to understand their dynamic properties in adaptation and diseases ,46. HoweC. elegans, D. melanogaster and H. sapiens, we have predicted 271 novel signaling components  based on ortholog information of the previous version of SignaLink [Genome programs and high-throughput screenings have greatly contributed to the construction of signaling networks in various model organisms, ranging from invertebrates to mammals. Reliable network resources enable the prediction of novel components and functions by analyzing cross-species data with the toolbox of functional genomics ,49. AccoignaLink . SignaLiignaLink .Studying cross-talks, pathway regulator TFs and miRNAs have high pathological relevance as their malfunction often lead to diseases such as cancer . Earlierin silico perturbation analysis on the multi-layered signaling network of SignaLink 2 may facilitate the development of pharmacological interventions [Pharmacological targeting of key signaling components, including multi-pathway proteins and miRNAs is a promising strategy -55. But ventions ,58,59. Aventions . SignaLiventions : selectiventions . The stihttp://SignaLink.org website with a protein, AXIN1. Next, the advantages of the download options of SignaLink 2 are illustrated with an integrated map of Notch and TGF-β pathways.First, we illustrate the usage of the We selected AXIN1 to demonstrate how regulatory interactions can be examined for a given protein with the protein datasheet of the SignaLink 2 website. With the previous version of SignaLink, we found that AXIN1 is a multi-pathway protein having connection to more than one pathway . BesidesTo illustrate the usage of SignaLink 2 download options, we selected two pathways, Notch and TGF-β. These two pathways have mostly different biochemical reactions and their members have distant evolutionary relations. Both pathways have been extensively studied as cross-talking pathways, having connections with other pathways ,66. InteSeveral excellent resources already exist that contain similar information as SignaLink 2. In Table e.g., proteolysis) as a possible explanation of the high number resource-specific proteins and interactions [We previously compared the number of proteins and interactions between SignaLink 1, KEGG, Reactome and NetPath [Knowing that the list of components and interactions in each layer is not complete, we will include further experimentally validated datasets yearly, which will complement the manual curation update we perform every two years. We also intend to include cellular compartment and tissue-specific localization information to future versions of SignaLink. In addition, we will increase the number of integrated hyperlinks in the protein datasheet page and develop connections to medical and drug-related resources.We presented the upgraded and extended version of the SignaLink resource that allows users to explore signaling pathway interactions and to identify pathway regulators, as well as transcriptional and post-transcriptional regulatory components. With SignaLink 2 users can examine in a single resource how scaffolds, enzymes, TFs or miRNAs regulate cross-talks and signaling flow. We hope that SignaLink 2 will be an efficient resource for modeling signaling systems as well as for signaling-related network medicine and pharmacology.http://SignaLink.org.Non-profit users can access SignaLink 2 free of charge at The authors declare no competing interests.MK, ZD and MP performed the manual curation. DF, DT, DM and MSB integrated the external resources and constructed the SignaLink 2 database. DT developed the website, DF wrote the download module. LZ, KL, FIJ and TK participated in the design of the database and website. TK coordinated the work. FIJ, TV, PC and TK wrote the manuscript. All authors read and approved the final manuscript.


Summary: Pathview is a novel tool set for pathway-based data integration and visualization. It maps and renders user data on relevant pathway graphs. Users only need to supply their data and specify the target pathway. Pathview automatically downloads the pathway graph data, parses the data file, maps and integrates user data onto the pathway and renders pathway graphs with the mapped data. Although built as a stand-alone program, Pathview may seamlessly integrate with pathway and functional analysis tools for large-scale and fully automated analysis pipelines.Availability: The package is freely available under the GPLv3 license through Bioconductor and R-Forge. It is available at http://bioconductor.org/packages/release/bioc/html/pathview.html and at http://Pathview.r-forge.r-project.org/.Contact:luo_weijun@yahoo.comSupplementary information:Supplementary data are available at Bioinformatics online. The pathway-based approach has been widely used in high-throughput data analysis . CompareR/Bioconductor has become a primary software environment for high-throughput data analysis and visualization (Supplementary Table S2. Pathview provides three features that are rarely implemented well in other tools: (i) fully accessible and functional pathway visualization. It adheres to human readable pathway definitions and layouts like KEGG . None of these features are brand new, but surprisingly, few of the existing tools provide satisfactory functionality in these aspects.In this article, we introduce a novel package called Pathview. We did a detailed comparison between Pathview and existing pathway tools in R/Bioconductor and other languages in Supplementary Figure S1. Most importantly, Pathview maps and renders user data on relevant pathway graphs.The Pathview package can be divided into four functional modules: Downloader, Parser, Mapper and Viewer, as depicted in Supplementary Fig. S1). This keeps the user interface simple and consistent.Pathview generates both native KEGG view b and GraSupplementary Table S1). It can be used to integrate, analyze and visualize a wide variety of biological data: gene expression, protein expression, metabolite level, genetic association, genomic variation, literature record and other data types mappable to pathways. Notably, it can be directly used for metagenomic data when the data are mapped to KEGG ortholog pathways. The integrated Mapper module maps 12 types of gene or protein IDs, and 21 types of compound or metabolite related IDs to standard KEGG gene or compound IDs, and also maps between these external IDs. For other types of IDs  not included in the common ID lists, Pathview’s auxiliary functions will map user data to pathways when users provide the ID mapping data manually. Pathview applies to pathways for over 2000 species, and species can be specified in multiple formats: KEGG code, scientific name or common name. In addition, Pathview works with different data attributes and formats, both continuous and discrete data (Supplementary Table S1), either in matrix or vector format, with single or multiple samples/experiments and so forth.Pathview provides strong support for data integration . In normal cases, Pathview uses KEGGgraph package .Conflict of Interest: none declared.


Although many biological databases are applying semantic web technologies, meaningful biological hypothesis testing cannot be easily achieved. Database-driven high throughput genomic hypothesis testing requires both of the capabilities of obtaining semantically relevant experimental data and of performing relevant statistical testing for the retrieved data. Tissue Microarray (TMA) data are semantically rich and contains many biologically important hypotheses waiting for high throughput conclusions.An application-specific ontology was developed for managing TMA and DNA microarray databases by semantic web technologies. Data were represented as Resource Description Framework (RDF) according to the framework of the ontology. Applications for hypothesis testing (Xperanto-RDF) for TMA data were designed and implemented by (1) formulating the syntactic and semantic structures of the hypotheses derived from TMA experiments, (2) formulating SPARQLs to reflect the semantic structures of the hypotheses, and (3) performing statistical test with the result sets returned by the SPARQLs.When a user designs a hypothesis in Xperanto-RDF and submits it, the hypothesis can be tested against TMA experimental data stored in Xperanto-RDF. When we evaluated four previously validated hypotheses as an illustration, all the hypotheses were supported by Xperanto-RDF.We demonstrated the utility of high throughput biological hypothesis testing. We believe that preliminary investigation before performing highly controlled experiment can be benefited. Biological databases are collections of scientific experiments, published literatures, and computational analyses organized under a specialized scheme. Biological databases became essential resources to biologists in their daily researches by providing information about biological facts and experimental results and procedures and also by providing management tools for the obtained data. Because these biological databases are designed for specific purposes, and independently managed, and metadata are not provided in many cases, they are neither semantically explicit nor interoperable. To overcome these problems, semantic web technologies such as Resource Description Framework (RDF), Web Ontology Language (OWL) and SPARQL (SPARQL Protocol and RDF Query Language) have been actively accepted in the field of life science for new database design -6. SemanIn spite of the benefits of semantic web technologies, these databases cannot directly answer to biologists for biologically meaningful questions or hypotheses. For machines to answer these questions, the process of inference based on either logical or statistical relationships of stored data is required. The inference by description logic is a part of semantic web technologies, but statistical inference was not implemented in the current semantic web technologies. These problems, therefore, cannot be solved within the framework of semantic web technologies alone and are rather dependent on the design of an application. However semantic web technologies are still beneficial in those applications.To prove a biological hypothesis, 1) an experiment is designed to test the hypothesis, 2) the experimental data is gathered, and 3) the data is tested by statistical test(s). Because of the increasing amount of high throughput experimental data in biological databases, there is an increasing need of high throughput validation of biological hypotheses. To implement such an application, 1) a hypothesis given by a user should be semantically interpreted, 2) the relevant experimental data should be retrieved from the database, and then 3) the hypothesis should be statistically tested against the retrieved data.Besides the fact that tissue microarray (TMA) is being widely used as a high throughput validation tool for the large number of data-driven hypotheses from other genomic technologies, TMA databases is a good candidate for the proof of concept of above mentioned applications. First, most biological hypotheses that can be derived from only TMA experiment are syntactically simple. The hypothesis derived from TMA experiments can be stated as, “In a biological condition A, an entity B is either positively or negatively correlated with an entity C.” Basically a TMA experiment is designed to test dependency between two entities and a hypothesis about the mechanisms of the interactions between two entities cannot be tested unless relevant additional information is provided. There are two important biological entities in TMA, biological samples and markers. In the TMA-validated hypothesis, “Reduced expression of Apaf-1 in colorectal cancer correlates with high-grade phenotype” , for exa2 test are the most frequently used statistical tests in TMA experiments to test dependency. They are frequently used because most of clinical or histological parameters  and the extent or the intensity of the marker expression in a tissue  have discrete or categorical values and the dependencies between these values are tested by them. For example, if we want to test the above mentioned hypothesis, “Reduced expression of Apaf-1 in colorectal cancer correlates with high-grade phenotype.” by Fisher’s exact test, we have to investigate each number of cores in slides for four exclusive conditions : a) negative Apaf-1 expression and high-grade phenotype, b) negative Apaf-1 expression and low-grade phenotype, c) weak to strong Apaf-1 expression and high-grade phenotype, and d) weak to strong Apaf-1 expression and low-grade phenotype. Then these four parameters are used for Fisher’s exact or χ2 test to test negative association between Apaf-1 expression and histological grade.Fisher’s exact and χIn spite of these benefits of TMA database, if it were not semantically explicit, applications for hypothesis testing could not be implemented. TMA data have complex and wide range of semantics, including information for clinical and histopathological features and large amount of metadata should be provided. Semantic web technologies support richer semantics than traditional RDB-based models. It, therefore, is more desirable that the databases for applications for hypothesis testing should be represented as RDF. In addition, SPARQL as a query language is more intuitively understandable to biologists . Lastly,We have created and managed Xperanto-TMA, a web-based TMA database supporting TMA-OM (Tissue Microarray Object Model)  and TMA-When implementing Xperanto-TMA and Xperanto, we extensively investigated semantics of experimental data of TMA and DNA microarray. This experience gave us good resources in constructing semantically rich and explicit TMA and DNA microarray database represented as RDF. Because Xperanto-TMA and Xperanto were independently developed, it was difficult to integrate these two databases. The integration of gene expression microarray and TMA data is a powerful approach to molecular profiling of human cancer . SemantiIn this study, we present how we designed semantic TMA database from the existing relational one and then how applications let researchers test hypotheses using semantic web infrastructures. Marker-level integration of TMA and DNA microarray databases will be also described.We represented Xperanto and Xperanto-TMA data as RDF triples. The relational schema were derived from TMA-OM by object-relational mapping . The priXperanto, which supports Microarray Gene Expression-Object Model (MAGE) , was devhttp://grip.snubi.org) to integrate these two databases.In addition to these data, data about the mapping of DNA microarray probes to antibodies used in TMA experiment was provided using Genome Research Informatics Pipeline  was not considered in this research because our main goal was to prove a hypothesis-testing system could be implemented with existing semantic web technologies and the goal could be achieved with our application-specific ontology.According to the scheme of the ontology, we made a mapping rule for every data element (not shown) and data in Xperanto-TMA and Xperanto was represented as RDF. As in Fig. In the actual implementation of RDF representation, we used a mediator system, D2RQ, instead of triple store for transformed RDF triples. When a mediator system is implemented, queries are directed against the mediator and then the mediator translates the queries into multiple SQLs for source RDBs. The use of mediator system have been shown to scale better and be easier to maintain . D2RQ isWe investigated the syntactic and semantic structures of four scientific hypotheses, which were validated by TMA experiments, from biomedical articles and pathologists. The hypotheses could be considered as triadic predicates with three parameters, “In a biological condition A, an entity B is either positively or negatively correlated with an entity C.” Factor A was defined as shared properties among the samples, factor B as an attribute and value set pair for distinct properties of the samples classifying the samples into two groups (the classifier), and factor C as an attribute and value set pair for dependent properties of the samples on the classifier.In a hypothesis, “Reduced expression of Apaf-1 in colon cancer correlates with high-grade phenotype,” a shared property corresponded to colon cancer, a classifier to the reduced expression of Apaf-1 and dependent property to high histological grade. In this hypothesis, ‘reduced expression of Apaf-1’ needed to be explicitly stated through the process of the interpretation by pathologists and it was interpreted as the value of staining intensity of Apaf-1 in tumor cells having “0”. On the contrary, if “increased expression” had been used in the hypothesis, it could have been interpreted as the value having “1”, “2” or “3”, implying the complementary value set against “0”.Based on these findings, we made a model for the hypothesis to investigate how a given hypothesis can be analyzed with regards to TMA experimental data and statistical test Fig. . To get The complementary value sets to the value sets of the classifier and the dependent property were parts of the hypothesis model, but they were not described in the hypothesis and should be reasoned. If a value set of either the classifier or the dependent property is provided, the complementary value set is generated as the complementary set to the value set of it among the set consisting of permissible value of the attribute of it. Taking an example from the above mentioned hypothesis, each of  and  was a complementary value set for the classifier and the dependent property, respectively because the permissible value lists for each factor were  and , and “High-grade” and “0” was described in the hypothesis. This process was implementable because we had already defined permissible value sets for every data element depending on the context when implementing Xperanto-TMA ,13.With the help of these analyses, we could implement the applications for hypothesis testing, which were operated in three steps. First the applications received inputs for the model construction. Second SPARQLs were generated according to the hypothesis model by a SPARQL generator. Third the applications called a statistical module and performed Fisher’s exact test using the result set of SPARQLs.Four SPARQLs were generated from each hypothesis model by a SPARQL generator in the applications to obtain four elements for Fisher’s exact test. For example, the following is a SPARQL from the hypothesis model in Fig. Generally, SPARQLs are generated as in the following.,iSPARQL := “SELECT count(distinct ?cr) WHERE {” + Σijphrase + “?sl xpe:Slide Block ?b. ?sl xpe:Slide_Reporter ?r.}”ijPhrase := jFactor2SPARQLijValueset : if j = 1, the shared properties among the samples if  and j = 2) or  and j = 3), hypothesis-describing value set for jFactor, otherwise its complementary value seti = 1, 2, 3,4, j = 1, 2, 3).. After processing, the statistical module shows the p-value of the Fisher’s exact test to the user. Based on this p-value, the user can decide whether the database supports or rejects the given hypothesis.We designed a use case using integrated DNA and TMA database, which was to find the distributions of the histologies among the cores of TMA where the intensities of the antibodies corresponding to the markers of interest in DNA microarray were high or lowhttp://clara.snubi.org/Xperanto-RDF). Data from these two databases were represented as RDF triples by a mediator system such that users could have the benefits of semantic web technologies as well as those of RDB.As described above, Xperanto-RDF was implemented based on existing TMA and DNA microarray databases (http://clara.snubi.org/Xperanto-RDF). In the context field, a user can choose the shared property among the samples. The attribute of the classifier and the dependent property can be selected by tracking along the tree structure of the entity. Once the classifier or the dependent property is selected, the permissible value set of the attribute is delivered to the select box to the right side of the tree frame. Using the buttons beside, the user can select hypothesis-describing and complementary value sets. Then the relevant SPARQL is generated by the SPARQL generator. On submitting the SPARQLs, the applications perform the query against the stored TMA data, the result sets are delivered to the statistical module, and finally the result of the statistical test including p-value is displayed.A hypothesis model testing dependency can be constructed in the index page of Xperanto-RDF as shown in Fig. As a result of hypothesis testing for the hypothesis in Fig. Table Xperanto-RDF achieved marker-mediated integration of TMA and DNA microarray data by mapping of DNA probes into antibodies in TMA experiment. By the use of mapping data, we could execute some of semantically integrated queries against data from TMA and DNA microarray experiments. A use case for this system was presented here.Query: In an experiment for glioblastoma using Affymetrix HT Human Genome U133A array, the signal from the probe, “201983_s_at” were interesting to a researcher [searcher . He wantIf TMA and DNA microarray database management systems had not been semantically integrated, it would have taken many steps to execute the queries and furthermore we needed external data source that showed what the corresponding antibody to the “201983_s_at” probe is. In Xperanto-RDF, the queries can be formulated as in Fig. We presented how a semantic database for TMA and DNA microarray experiment can be developed from the existing RDB implementations using currently available semantic web technologies, how the application for hypothesis testing using TMA experimental data was designed and used, and how TMA database can be integrated with DNA microarray database using semantic web technologies.We successfully implemented applications for hypothesis testing and their usefulness was validated by testing several experimentally validated biological hypotheses by TMA experiments. Although the applications seems useful to biologists, it is still challenging to spread the idea of the hypothesis testing in the biological database using experimental data to the whole community of the biologists. In traditional biomedical research, an experiment is designed to test a hypothesis  and it hThe applications for hypothesis testing can be regarded as a semantically-enhanced meta-analysis tool for TMA experiments in one aspect. One of requirements to perform meta-analysis is the process of data normalization. Our applications do not have the process of data normalization yet because there are no known methods of normalization in TMA experiments. The absence of normalization process do not appear to be greatly influential on the experimental results at present because TMA experiments are usually interpreted by human eyes, crude categorical values are used in the interpretation, and experimental procedures and interpretations are rather standardized.We separated the process of hypothesis model construction, SPARQL execution, and statistical test when implementing the applications for hypothesis testing. This allows us more flexibility to easily manage and develop the whole systems. More statistical modules will be easily implemented to our applications if a hypothesis cannot be tested with current statistical modules. We will implement a statistical module for survival analysis soon.Post et al. suggested integrative bioinformatics experimentation, defined as in silico data integration experiment using semantic web technologies, and made a use case to prove a hypothesis . They teFrom the beginning our TMA database was developed with consideration on the integration with the other TMA or omics databases. Any TMA database based on TMA-OM can easily exchange the experimental data and the direct implementation of our application for hypothesis test is possible.We also achieved marker-mediated integration of TMA and DNA microarray database. The integration enabled marker-mediated bidirectional data flow between TMA and DNA microarray experimental data. With these integrated databases, the results of DNA microarray experiments can be validated in TMA experiments.Our future works are targeted in three directions. First, we are developing hypothesis miner extracting biological hypotheses directly from biomedical literature databases. The miner will feed hypotheses to TMA databases without the insertion procedures by the user. When realized, the integration of literature and experimental databases mediated by the hypotheses can be accomplished. Second, we will test if the same applications can be applied to DNA microarray databases using the same semantic web technologies. Although data-driven approach is predominant in interpreting the DNA microarray experiment results, we believe that traditional hypothesis-driven approach will continue to give us new insights to perceive the biological meaning of the DNA microarray experiment data. Third, we will improve descriptive power of our application-specific ontology and align it with existing ontologies. Our application specific ontology describes two array-based technologies (DNA and tissue microarray). Because DNA microarray is usually describable by MGED ontology, our ontology will become semantically more powerful by relating it with MGED ontology. Meanwhile, a part of our application-specific ontology was made based on TMA-OM and there is no other standard on ontology for TMA to the best of our knowledge. We, therefore, will expand our application-specific ontology so as to fully describe TMA experiment and align it with other neighbourhood ontologies.We proved semantic web technologies are beneficial in statistical inference as well as in logical inference based on description logic by implementing an application for hypothesis testing without disrupting previously implemented RDF-based applications. We proposed an application in which biologist’s real interests are reflected. The same scheme we used in developing Xperanto-RDF could be applied to the other omics technologies. However extensive study on the semantic and syntactic structure of the biologic hypothesis will more facilitate the development of applications for hypothesis testing in biological databases.All authors declared that there is no conflict of interest in this research.YSS and JHK designed and developed the study and wrote the manuscript. CHP and HJC implemented the system and wrote the manuscript. HJS and JK tested and coordinated the system and wrote the manuscript. All authors read and approved the final manuscript.


Protein kinases are a large and diverse family of enzymes that are genomically altered in many human cancers. Targeted cancer genome sequencing efforts have unveiled the mutational profiles of protein kinase genes from many different cancer types. While mutational data on protein kinases is currently catalogued in various databases, integration of mutation data with other forms of data on protein kinases such as sequence, structure, function and pathway is necessary to identify and characterize key cancer causing mutations. Integrative analysis of protein kinase data, however, is a challenge because of the disparate nature of protein kinase data sources and data formats.haematopoietic neoplasm cancer type map to only 8 kinases in the human kinome. This is in contrast to glioma, where the mutations are spread over 82 distinct kinases. We also provide examples of how ontology-based data analysis can be used to generate testable hypotheses regarding cancer mutations.Here, we describe ProKinO, a protein kinase-specific ontology, which provides a controlled vocabulary of terms, their hierarchy, and relationships unifying sequence, structure, function, mutation and pathway information on protein kinases. The conceptual representation of such diverse forms of information in one place not only allows rapid discovery of significant information related to a specific protein kinase, but also enables large-scale integrative analysis of protein kinase data in ways not possible through other kinase-specific resources. We have performed several integrative analyses of ProKinO data and, as an example, found that a large number of somatic mutations (∼288 distinct mutations) associated with the http://vulcan.cs.uga.edu/prokino.We present an integrated framework for large-scale integrative analysis of protein kinase data. Navigation and analysis of ontology data can be performed using the ontology browser available at:  Cancer is caused by an accumulation of mutations, often in a subset of genes that confer survival and growth advantage. The protein kinase gene family, which controls key signaling pathways associated with cell growth and survival, is one of the most over-represented families of oncogenes Experimental characterization of cancer mutations, however, requires that one first formulate the right hypotheses based on analysis of existing data. In particular, analysis of mutation data in light of other forms of data available on protein kinases such as sequence, structure, function and pathway is necessary to develop and test new hypotheses regarding the functional impact of cancer mutations associated with”. It is this conceptual representation of knowledge that distinguishes ontologies from relational databases, and enables efficient integration and mining of diverse data sets http://rgd.mcw.edu/tools/ontology/ont_search.cgi), protein modification Ontologies Protein Kinase Ontology (ProKinO). ProKinO provides a controlled vocabulary of terms and relationships connecting sequence, structure, function, pathway, and mutation data on protein kinases. ProKinO is encoded using the Web Ontology Language (OWL) (http://www.w3.org/TR/owl-ref/), an ontology authoring language recommended by the World Wide Web Consortium (http://www.w3.org/). The integration of diverse data sets in a machine-readable format not only allows navigation of diverse forms of protein kinase data in one place, but also enables aggregate queries on existing data in ways not possible through existing kinase-specific resources. For example, aggregate queries such as “counts of kinases associated with cancer type” or “counts of cancer mutations located in various kinase sub-domains” can be readily performed using ProKinO and the ontology query language SPARQL (http://www.w3.org/TR/rdf-sparql-query/). We describe the significance of such queries in knowledge discovery and hypothesis generation. An aggregate query “counts of kinase mutations in various cancer types”, for example, revealed that the mutations associated with haematopoietic neoplasm (288 distinct mutations) primarily target only 8 kinases in the human kinome, compared to glioma, where the mutations are spread over 82 distinct kinases. Likewise, queries such as “mutations targeting kinase functional features” can be used to generate new hypotheses regarding the structural and functional impact of cancer mutations. We also describe a browser that enables rapid navigation and examination of ProKinO data, accessible at: http://vulcan.cs.uga.edu/prokino.Here, we report the To conceptualize the wealth of knowledge regarding protein kinase sequence, structure, function, pathways and diseases, we have introduced several key concepts (classes) and relationships (object properties) in ProKinO. These classes, organized in a hierarchical manner, and the relationships amongst these classes, represent and describe protein kinase knowledge in a manner analogous to a domain expert.hasMutation” property . For instance, EGFR is also referred as EGFRvIII, ERBB1, ERBB, or mENA in the literature. By including the “hasOtherName” data property, all information pertinent to EGFR can be obtained irrespective of which gene name is used as a query.In addition to the object properties, key data properties have been introduced to describe the internal organization of the concepts and to facilitate data mining and extraction. For example, the data property, “With a large set of classes and properties related to kinases in the designed schema  for parsing, creating and querying Resource Description Framework (RDF) (http://www.w3.org/RDF/) and OWL ontologies.We have created a specialized software system to automatically populate ProKinO from the above described sources. The software is written using the Java programming language. The software performs all of the required functions for ontology creation and automatic population, including data acquisition, parsing and processing, as well as the creation of instances and connections among them using the relationships defined in the ProKinO schema. The populated ontology is encoded and output in OWL, an ontology authoring and sharing language recommended by the World Wide Web Consortium. Our software also uses Jena, a widely used Java-based Application Programming Interface (API)  a manual approach in which a set of instances and relationships among them are randomly selected and cross-checked with content from original sources, and (ii) a query-based approach in which ontology data is queried for information that can easily be cross validated with data from original sources.EGFR kinase's relationship with pathways represented as a property “partcipatesIn” was verified for accuracy by cross validating the content in ProKinO with the original data available in Reactome. Our verification has not detected any errors in ProKinO. The details of the evaluation are shown in In the manual approach, the test sets were chosen to evaluate a broad coverage of the ontology content. The accuracy of the data was checked by cross validating with the original data sources. The integration of the data in ProKinO was also verified by evaluating the introduced object and data properties for accuracy. For example, Cdk2 . This result was also cross-validated with the original source, i.e. Reactome (BRAF (30 cancer types)  , which wThe compendium of knowledge represented in ProKinO can be used for a variety of applications such as data mining, text mining and genome annotation. In particular, the representation of diverse protein kinase data in machine-readable form enables complex aggregate queries on ontology data, in ways not possible through existing kinase-specific resources. Below, we describe some of these queries to illustrate how ProKinO data can be used for knowledge discovery and hypothesis generation. The queries, which have been formulated in SPARQL, also provide an initial evaluation of ProKinO's usefulness.carcinoma (1168 mutations), glioma (180), malignant melanoma (201), haematopoietic neoplasm (288), and lymphoid neoplasm (164) are highly over-represented in kinase mutations compared to other cancer types  are altered in haematopoietic neoplasm, compared to glioma. Such observations have implications in targeting the mutated kinome for therapies, and in generating new hypotheses for experimental studies.The SPARQL queries “counts of substitution missense mutations in cancer types”, and “counts of protein kinases having missense mutations” was performed on ProKinO to analyze the distribution of kinase mutations in various cancer types. Analysis of the results generated by this query revealed that the distribution of kinase mutations is strikingly different for different cancer types . In parter types . Furtherhaematopoietic neoplasm. For example, the query requesting for the “counts of protein kinases having missense mutations in haematopoietic neoplasm” indicates that ABL1, KIT, FLT3 and JAK2 are more frequently mutated compared to other kinases  can be further refined to obtain testable hypotheses regarding cancer mutations. For example, queries requesting functional features and sub-domain location for In addition to the queries described above, we have formulated several additional queries on ProKinO. The results obtained from these queries are provided as supplementary figures see , S8, S9.http://vulcan.cs.uga.edu/prokino.ProKinO is an ontology of terms and relationships capturing the state of knowledge on the protein kinase family. Representation of protein kinase knowledge in the form of ontology allows effective mining and systems-level analysis of protein kinase data, as demonstrated through several SPARQL queries. To enable navigation and integrative analysis of ontology data, an ontology browser has been developed. The browser can be accessed from While the current version of ProKinO largely focuses on human protein kinase genes, information on other model organisms can be incorporated in ProKinO through the addition of new classes and data properties in the ontology schema. Likewise, the wealth of information generated on protein kinase substrates through high-throughput phospho-proteomic data can be incorporated to integrate cancer data with proteomics data. Furthermore, we anticipate ProKinO to be useful in providing consistent annotation of mutations identified in cancer genome sequencing studies.haematopoietic neoplasm is novel and provides new hypotheses for follow-up studies. Likewise, the prediction that Y253F mutation alters the phosphorylation status of the glycine rich loop in ABL tyrosine kinase can be tested experimentally. The SPARQL queries described in this study can be executed from the browser by selecting the “Example queries” tab in the main page.Using specific queries we have demonstrated how data in the ontology can be used to generate new hypotheses regarding the structural and functional impact of mutations. In particular, the observation that nearly 288 mutations map to only eight kinases in http://www.obofoundry.org/), after introducing necessary changes to make ProKinO conformant to OBO guidelines. Similarly, we plan to make it available through NCBO BioPortal . We also intend to continue the study of the applicability of ProKinO to other bioinformatics tasks, including text mining of bio-medical scientific literature, genome annotation, and others.In the near future, we are planning to submit ProKinO to be included in The Open Biological and Biomedical Ontologies (OBO) foundry  showing concepts and relationships representing protein kinase knowledge. The high resoulution image of the schema is also available from the main page of ProKinO browser.(PDF)Click here for additional data file.Figure S2Plot showing counts of different mutations  for all kinase genes.Top 10 hits are displayed in the descending order of their values. Notably, KIT and EGFR are the two of the most frequently mutated kinases in human cancers. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 7” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S3Plot showing counts of substitution missense mutations for all genes. Top 10 hits are displayed in descending order of their values. It should be noted that while the total number of mutations is higher for KIT Click here for additional data file.Figure S4Plot showing counts of protein kinases (at least 2) having mutations (of any type) implicated in different types of cancer. Kinases are displayed in descending order of the counts. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 9” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S5Plot showing counts of protein kinases (at least 4) participating in pathways. Hits are display in descending order of their values; include only pathways with 4 or more participating kinases. Notably, most of the mutated kinases appear to target pathways associated with the immune system, as indicated by high counts for “signaling in immune system” pathway. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 10” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S6Plot showing counts of pathways in which mutated protein kinases participate. Hits are displayed in descending order of their values. Kinases that participate in 4 or more pathways are included. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 11” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S7Plot showing counts of protein kinases having mutations (of any type) in various primary sites. Hits are displayed in descending order of their values. Notably, most number of mutated kinases are implicated in the cancers of lung and the central nervous system. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 12” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S8Plot showing counts of different mutations  for all sub-domains. Notably, the flanking N and C-terminal tail segment harbor significant number of mutations, followed by the regulatory activation segment and C-helix in the kinase domain. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 13” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S9Plot showing counts of substitution missense mutations of the protein kinase FLT3 all having the primary site of Haematopoietic and Lymphoid tissue, and located in various sub-domains. Notably, the activation segment has the most number of mutations. The SPARQL query to generate this figure can be directly viewed and excuted from the ProKinO browser by selecting “Query 14” under the “Example query” tab in the main page.(PDF)Click here for additional data file.Figure S10SPARQL queries for the main  and supplementary , S8, S9 (PDF)Click here for additional data file.Table S1Classes (concepts) in ProKinO.(DOC)Click here for additional data file.Table S2Object properties used in ProKinO.(DOC)Click here for additional data file.Table S3Data properties used in ProKinO.(DOC)Click here for additional data file.Table S4ProKinO evaluation statistics.(DOC)Click here for additional data file.Table S5Protein kinases implicated in Haematopoietic and lymphoid_tissue and having modified residue type property.(DOC)Click here for additional data file.