Recently there has been an explosion of new data sources about genes, proteins, genetic variations, chemical compounds, diseases and drugs. Integration of these data sources and the identification of patterns that go across them is of critical interest. Initiatives such as Bio2RDF and LODD have tackled the problem of linking biological data and drug data respectively using RDF. Thus far, the inclusion of chemogenomic and systems chemical biology information that crosses the domains of chemistry and biology has been very limitedWe have created a single repository called Chem2Bio2RDF by aggregating data from multiple chemogenomics repositories that is cross-linked into Bio2RDF and LODD. We have also created a linked-path generation tool to facilitate SPARQL query generation, and have created extended SPARQL functions to address specific chemical/biological search needs. We demonstrate the utility of Chem2Bio2RDF in investigating polypharmacology, identification of potential multiple pathway inhibitors, and the association of pathways with adverse drug reactions.We have created a new semantic systems chemical biology resource, and have demonstrated its potential usefulness in specific examples of polypharmacology, multiple pathway inhibition and adverse drug reaction - pathway mapping. We have also demonstrated the usefulness of extending SPARQL with cheminformatics and bioinformatics functionality. Recent advances in chemical & biological sciences have lead to an explosion of new data sources about genes, proteins, genetic variations, chemical compounds, diseases and drugs. Through integrated and intelligent data mining, this information could provide important insights into the complex functions of biological systems and the actions of chemical compounds or drugs on these systems. However, this can only be achieved when data is semantically integrated (i.e. using multiple data sources that are connected in meaningful ways) and in particular when chemical and biological resources are brought together in such a framework ,2.Systems Chemical Biology [chemogenomics .There are critical problems in biology that can only be answered through computational analysis of this kind of integrated chemical and biological information. For example, it is considered increasingly important to profile existing and potential new drugs for their effects across many protein targets, not just a single target of interest . Only Biology , a fieldImplementing such an integrated system involves the creation of large networks of linked compounds, protein targets, genes, pathways, drugs, diseases and side effects from multiple, heterogeneous sources. It must be possible to query these data in ways that go beyond querying of a single source and allow inferences that cross domains: for example a positive experimental test of a chemical compound in a biological enzymatic assay where the enzyme is associated with a particular metabolic pathway constitutes a probable action of that compound on the pathway. Currently, there are significant barriers to carry out this kind of analysis. Many of the needed data sources overlap and cover similar data (we refer to them as homogenous or semi-homogenous data sources) but with slightly different foci. All data sources tend also to be published in very diverse formats  and may be structured or unstructured. The semantic relationship of these datasets to each other is often unclear.Recent Semantic Web technologies provide efficient ways to integrate heterogeneous data. The Semantic Web  initiallBio2RDF [Linking Open Drug Data (LODD) [A variety of RDF-based Semantic Web resources have already been created for biological data and drug data separately. Bio2RDF  providesa (LODD)  led by ta (LODD) , LinkHuba (LODD) , BioDasha (LODD)  and BioGa (LODD) .Chem2Bio2RDF. We present three specific examples of how Chem2Bio2RDF can be used in the previously described important areas of polypharmacology, pathway inhibition and adverse drug reaction analysis.Approaches to querying across heterogeneous data sources in the life sciences have been discussed previously . In the Our datasets are organized into six categories based on the kinds of biological and chemical concepts they contain. These categories are: chemical & drug, protein & gene, chemogenomics, systems , phenotype  and literature. Some data sources are listed in multiple categories. Some of the data used were previously employed in relational database format in our prior work  and in thttp://chem2bio2rdf.org/datasets.html. All the triples are stored together and the whole set is called Chem2Bio2RDF dataset  as the identifier for compounds, and UniProt ID for protein targets. The compounds represented by other data formats  were mapped to CID via InChi keys. A detailed description of each of the datasets can be found at t Figure .http://chem2bio2rdf.org/download.html. The RDF data can be explored and queried in our website http://chem2bio2rdf.org/. Figure We developed a schema to classify the concepts and the RDF resources in Chem2Bio2RDF. The schema file can be downloaded from http://chem2bio2rdf.org/drugbank/resource/drugbank_drug/DB00001 is linked to the following URIs: http://bio2rdf.org/drugbank_drugs:DB00001, http://www.dbpedia.org/resource/Lepirudin, http://www4.wiwiss.fu-berlin.de/dailymed/resource/ingredient/Lepirudin, and http://www4.wiwiss.fu-berlin.de/drugbank/resource/drugs/DB00001We linked our data to LODD and Bio2RDF using the owl:sameAs construct. Since LODD and BioRDF have strict namespace definition and dereferenceable URIs, it is straightforward to link them simply via a D2R mapping file. For example, the drug Lepirudin fingerprint and tanimoto mapping to the CDK functions getFingerprint and Tanimoto.calculate. The fingerprint function generates a string of 166 binary descriptors that represent the presence (denoted as 1) or absence (denoted as 0) of common 2D structural features in a chemical as defined by the popular MACCS structural keys [A and B is defined as:SPARQL is a query language for RDF and provides functions and syntax to satisfy generalized querying needs. However, these basic functions are not able to address specific chemical/biological search needs. We extended SPARQL using the ARQ  in Jena ral keys . The Tanral keys . The TanNC is the number of bits that are set in the fingerprints of both A and B, and NA and NB are the total number of bits set in A and B, respectively.Where We have created a single repository called Chem2Bio2RDF by aggregating data from multiple repositories including PubChem Bioassay , DrugBanpolypharmacology. We recently studied the utility of data in PubChem for identifying cases of polypharmacology [find all the drug-like compounds in PubChem BioAssay that share at least two targets with a drug in DrugBank. We can now translate this into a SPARQL query of Chem2Bio2RDF (in this example using Dexamethasone - an anti-inflammatory 9-fluoro-glucocorticoid which interacts with six proteins - as the drug of interest). The exact SPARQL query used is available on the chem2bio2rdf.org website.Since approximately 35% of known drugs have more than one target, the efficacy of many drugs is increasingly thought to come from their effect on multiple targets. This is known as macology . We can The query starts with retrieving the active compounds, followed by the identification of targets, which are then linked to drugs in DrugBank Figure . In PubCNine of retrieved active compounds are active against at least two of the same protein targets, all of which are drug-like (in terms of Lipinski's Rule of Five). These compounds make sense from a medicinal chemistry perspective. For example, dexamethasone and one result tocris-1126 (CID: 6603742) have similar activities in NFKB1 and NR3C1, because they only have slight difference in stereochemistry. The activity of dexamethasone is also similar to that of another search hit, hydrocortisone (CID: 5754), where the addition of the methyl and fluorine to hydrocortisone has no effect on the activity but improves its drug-likeness as measured by the rule-of-five. In our generalized mapping process, we found 55 significant proteins in DrugBank that are studied in PubChem BioAssay. 27 drugs have corresponding active compounds showing polypharmacology.find all the compounds in PubChem that are active towards at least two targets that are in a given pathway. We can formalize this into a Chem2Bio2RDF query firstly by generating a rule linking compounds with pathways via UniProt. This rule can be illustrated as: compound x is targeting protein y, and protein y belongs to pathway z, thus we reason that compound x is related to pathway z. We can then implement this rule in a SPARQL query (the rule and the query are supplied on the chem2bio2rdf.org website).Traditional drug discovery approaches focus on identifying a potential target in a disease-related biological pathway, and then finding a drug molecule to interact with this target. However, divergent and redundant pathways in humans often enable a system to keep functioning if one pathway is blocked as there is an alternative pathway to compensate . This caThe rule generates triples consisting of compound and pathway, which are further refined by its activity (outcome is 2) and pathway name . Finally, like the linking in case 1, the results are grouped and only compounds that are multiple pathway inhibitors are selected. This is illustrated in Figure The MAPK signalling pathway plays important roles in coordinating cell proliferation, differentiation and death. The inhibitors of proteins involved in the pathway are widely studied, but the robustness of this pathway leads to drug resistance. Cisplatin, for example, is used to treat ovarian cancer but the development of resistant cell population limits its efficiency in long-term trials. It has been suggested that targeting the ERK-MKP-1 system could destroy this pathway and further overcome Cisplatin resistance in human ovarian cancer treatment . One comAdverse drug reactions are of serious consequence and are often the subject of rigorous investigation in pharmaceutical R&D processes. Here, we apply Chem2Bio2RDF to study the most significant pathways that are associated with a given adverse drug reaction. The association between side effect and pathway is made using the pathways' gene components that are targets of drugs with known side effects. More specifically, we consider a gene is related to a certain side effect if and only if at least two drugs targeting this gene have reported the same side effect. Further, if there exists a pathway that contains more than 2 gene targets that are associated with that side effect, an associative relationship between the pathway and side effect can be drawn. Clearly, the more these associative paths can be discovered, the stronger the evidence of such pathway-adverse drug effect association it becomes.necrosis, hepatitis and hepatomegaly.In this study, we examined hepatotoxicity (liver toxicity) as the side effect. Drug induced liver injury is a major cause of safety-related drug withdrawal  both before and after a drug goes to market, and thus identifying pathways in the body that might be associated with liver function and toxicity is important. Here we define drugs associated with hepatotoxicity as those with side effect terms that include find the top 5 pathways in the KEGG pathway dataset that contain at least two efficient targets that have drugs that are associated with hepatotoxicity. A gene target is considered as efficient if the gene is targeted by at least two drugs that cause the given side effect. This question can be formed into a SPARQL query which is available on the chem2bio2rdf.org website.We posed the specific question: The graph linking these terms, pathways, targets and drugs is shown in Figure The difficulties of polypharmacology are to explore the combination of targets and then to identify active compounds against the sets of targets. Linking between chemical, biological, systems, and phenotype data is demonstrated to be a promising way to address the problems. For example, linking between bioassay data and market drug data enables to explore the compounds similar to drugs that already show polypharmacology. Quinacrine, which has been used as an anthelmintic and in the treatment of giardiasis and malignant effusions, shows polypharmacology. One compound Loxapine (CID: 71399) is found to show similar polypharmacology with quinacrine. Loxapine is active in both BioAssay 859 and BioAssay 377, whose targets are CHRM1 and ABCB1 respectively. As Loxapine tends to be hydrophobic, medicinal chemists would not be surprised that it is active in BioAssay 377, which identifies substrates (or inhibitors) for multidrug resistance transporter. It is also reported that Loxapine might get metabolized to Amoxapine that is a considerably weak antagonist in BioAssay 859 . Other tBy linking bioassay data to pathways, we can identify the compounds that inhibit at least two of proteins in a pathway, leading to the pathway dysfunction. For example, compound CID 6419769 could interact with proteins HSD11B1 and AKR1C4, which are in the different branches of C21-Steroid hormone metabolism pathways. The blocking of the pathway might be able to partially explain why CID 6419769 has side effects . In protchemical to pathway via chemogenomics data, chemical has 6 directions (6 chemogenomics datasets) to associate with a gene that is mapped to multiple pathways in either KEGG or Reactome. We randomly picked up 100 drugs from SIDER and linked the drug to pathway through 6 chemogenomics datasets. In another four experiments, we only selected one dataset for one domain instead of using all datasets. If only CTD is selected for chemogenomics data and only KEGG is selected for pathway, the number of paths linking from the 100 drugs to pathways and the number of pathways we found are 6,863 and 178 respectively, compared to 12,240 and 350 when all chemogenomics and pathway data sources were selected . We think that an important part if this work is not just the integration of heterogeneous data, but also the integration of sources covering homogenous kinds of data. Tables We have created a new systems chemical biology resource called Chem2Bio2RDF that integrates small molecule, target, gene, pathway and drug information and permits cross-source linking with LODD and Bio2RDF. We have demonstrated the utility of this approach in specific examples of polypharmacology, multiple pathway inhibition, and adverse drug reaction - pathway mapping. We also demonstrated the usefulness of extending the SPARQL query language with cheminformatics and bioinformatics functionality, and have discussed the importance of integrating not just heterogeneous data but data sources which cover the same kinds of data.We propose three further developments of this work. First, we hope to include more resources and datasets into Chem2Bio2RDF as they become available. Second, we see a variety of applications of using large-scale identification and ranking of paths of interest between data sources, and we are working on developing methods for this. Third, we are linking Chem2Bio2RDF with a variety of network and data visualization tools.BC carried out the majority of the implementation of Chem2Bio2RDF, supervised by YD and DJW. BC, HW and QZ created the data sources. XD worked on the architecture. DJ developed the SPARQL extensions. HW worked on the case 3 study. DJW assembled this paper from a previous white paper written by BC, YD and DJW. All contributed to the intellectual evolution of this project. All authors have read and approved the final manuscript.


Web services have become a key technology for bioinformatics, since life science databases are globally decentralized and the exponential increase in the amount of available data demands for efficient systems without the need to transfer entire databases for every step of an analysis. However, various incompatibilities among database resources and analysis services make it difficult to connect and integrate these into interoperable workflows. To resolve this situation, we invited domain specialists from web service providers, client software developers, Open Bio* projects, the BioMoby project and researchers of emerging areas where a standard exchange data format is not well established, for an intensive collaboration entitled the BioHackathon 2008. The meeting was hosted by the Database Center for Life Science (DBCLS) and Computational Biology Research Center (CBRC) and was held in Tokyo from February 11th to 15th, 2008. In this report we highlight the work accomplished and the common issues arisen from this event, including the standardization of data exchange formats and services in the emerging fields of glycoinformatics, biological interaction networks, text mining, and phyloinformatics. In addition, common shared object development based on BioSQL, as well as technical challenges in large data management, asynchronous services, and security are discussed. Consequently, we improved interoperability of web services in several fields, however, further cooperation among major database centers and continued collaborative efforts between service providers and software developers are still necessary for an effective advance in bioinformatics web service technologies. Web services are software systems designed to be manipulated remotely over a network, often through web-based application programming interfaces (APIs). Through web services, users can take advantage of the latest maintained data and computational resources of remote service providers via a thin client. Web services are increasingly being adopted in the field of bioinformatics as an effective means for data and software access, especially in light of the rapid accumulation of large amounts of information for the life sciences . Most ofTo overcome this situation and to assure interoperability between web services for biology, standardization of exchangeable data types and adoption of compatible interfaces to each service are essential. As a pilot study, the BioMoby project has tried to solve these problems by defining ontologies for data types and methods used in its services, and by providing a centralized repository for service discovery. Additionally, Moby client software exists to allow interconnections of multiple web services ,10. HoweTo address these issues, we organized the BioHackathon 2008 , an inteBioinformatics web services can be categorized into two major functional groups: data access and analysis. Access to public database repositories is obviously fundamental to bioinformatics research, and various systems have been developed for this purpose, such as Entrez at NCBI, Sequence Retrieval System (SRS) and EB-eye at EBI , DistribThe other group of services provides a variety of methods that require a certain amount of computation by implementing various algorithms, and they sometimes have complex input or output data structures. A typical example is a BLAST search, which needs a nucleic or amino acid sequence, as well as numerous optional arguments in order to find homologous sequences from a specified database using a dynamic programming algorithm. Services in this group sometimes require a large amount of computation time, including those providing certain functionalities of the European Molecular Biology Open Software Suite (EMBOSS) , 3 D strHistorically, the term web services was associated with SOAP (Simple Object Access Protocol), a protocol that transfers messages in a SOAP XML envelope between a server and a client, usually over the Hypertext Transfer Protocol, HTTP . SOAP seFor the purpose of service description, SOAP services usually come with a Web Services Description Language (WSDL)  file. A Recently, another kind of web service model named REST  has rapidly gained popularity as an effective alternative approach to SOAP-based web services . REST isper se is not enough for the immediate construction of biological workflows as multiple cascading web services, because of inconsistent data types defined by each service provider, sometimes even for essentially identical objects. Therefore, in most cases output of one service cannot be passed to another service as its input without appropriate conversion of data types or formats. Furthermore, services should also be discoverable by the object models they share so they can be linked in the construction of workflows. To this end, a centralized registry to discover appropriate services according to a given set of data types has become essential for web service interoperability. The BioMoby project has pioneered this task by providing MobyCentral, which serves as a central repository for BioMoby compatible web services [WSDL description services . ServiceTo date, several applications that utilize BioMoby services have been developed, such as Taverna , SeahawkSeahawk is another GUI software tool that invokes BioMoby services in a context-dependent manner, for example, by selecting an amino acid sequence in a website to use as input data, so that users can analyze data as they browse information on web pages.MOWserv  is a webG-language GAE  is a PerFor many tasks custom programming is still needed, for example, to parse the results obtained from web services for further extraction of data, and to integrate with local analysis pipelines. One of these most time-saving ways to accomplish these tasks is by using the Open Bio* libraries, such as BioPerl, BioPython, BioRuby and BioJava. These libraries are being collaboratively developed as open source software by developers distributed all over the world, and they have the capability to manipulate numerous formats used in bioinformatics databases and applications. The Open Bio Foundation  has an iSOAP and REST have improved accessibility of bioinformatics web services, but standardization of metadata is required to increase their interoperability Table . AlthougData types exchanged among bioinformatics web services should ideally follow commonly accepted standards in order to be interoperable without data format conversion. However, in emerging areas of bioinformatics such as protein interaction networks, glycoinformatics, phyloinformatics and text mining, several standard formats have been independently developed, and in many cases data have to be merged and integrated prior to analysis because they need to be collected from multiple repositories. Moreover, identifiers and controlled vocabularies employed in these separate repositories are often different even for identical physical entities. To address these issues, we have gathered a wide range of data providers in their respective areas to discuss obstacles and implement solutions towards interoperable services.In this hackathon representatives from three different service providers, the Database of Interacting Proteins (DIP) , the SeaAs a test client for PSICQUIC the group used the Cytoscape visualization platform. Since version 2.6, Cytoscape supports web services as external data sources. It is relatively easy to implement a client in Cytoscape because the data exchange format is based on PSI-MI . The Cytoscape team is implementing a universal client for PSICQUIC, supporting network data integration and visualization from multiple data sources. The working group and the International Molecular Exchange (IMEx) consortium  members The goal of the glycomics standards and interoperability group was to integrate emerging bioinformatics tools for glycobiology into the larger bioinformatics world, primarily by establishing a foundation for web services for the glycobiology community . BioinfoFurther advancement in this area demands robust protocols for web service discovery and composition of web processes. The BioHackathon was a unique opportunity to get developers of glycoinformatics together to explore possibilities for this purpose. The immediate goal of the group was to develop a prototype workflow that integrates web services provided by the groups of the three represented glycoinformatics groups. This served as a test-bed and model for future integration efforts. There was a debate as to whether glycan structures should be integrated with the existing data types or to be defined separately. There was also a question as to whether the formats for these data types, such as the GLYDE-II XML formats, LINUCS and KCF, should be separate from other biomolecule sequence formats. In the end, it was decided that it would be easier to simply create a single GlycomicsObject data type in the BioMoby ontology from which all other data types would be extended. Using this consensus ontology, the three participants each provided web services that could communicate with one another, resulting in a single workflow. This workflow consisted of an input glycan structure in LINUCS format, and a search for glycans with similar structures in the RINGS (Resource For Informatics Of Glycans) database returning structures as KEGG GLYCAN IDs. The IDs were subsequently transformed to the corresponding GLYDE-II format data, which passed to another web service to output the structure's image in SVG format.In the field of phyloinformatics, existing approaches to integrate data and services into workflows are highly specific to the integration platform  ,54, and As a starting point, the group revisited the representation of phylogenetic trees and annotation (or metadata) often associated with nodes, branches, or the tree as a whole. For example, the branches of a phylogenetic tree can have length values or be associated with metrics indicating support, such as bootstrap value or posterior probability. Tree nodes might be associated with taxonomic information in the case of species trees. Nodes in gene trees may in addition be linked to gene names or identifiers and other gene or genome annotation. Beyond the more standard metadata elements, there is a large and increasing variety of data and annotation that is being associated with phylogenetic tree nodes in research applications, ranging from biogeographical data (latitude/longitude) to host species  to functional gene attributes . Compared with plain text formats, the representation of such metadata according to an XML schema , which may stand for a species as represented by one or more specimens, or for one or more molecular sequences which belong to genes of a specific taxon. Reconciling trees involves matching tips in one tree to those in another where the trees may use different OTUs, or different conventions for labeling OTUs. For example, to infer gene duplication events from reconciling gene trees with species trees, the gene tree OTUs must be matched with the tips in the species tree, which requires identification of the canonical species to be unequivocal for both kinds of trees. A similar problem is encountered for applications that need to find trees in a database of trees, for example trees with nodes matching gene or species names, regardless of which kind of molecular sequence the trees of interest have been built from. A standardized encoding mechanism for OTUs would aid greatly towards exposing and consuming such operations in a consistent and predictable manner as web services.Analysis-based web services for phyloinformatics applications typically require multiple types of data as input, some of which may be large, such as a distance or character matrix and one or many trees in respective order. While there are exchange formats that would allow marshalling of multiple data types in a single attachment or message body  technology has greatly improved in recent years, and enables us to syntactically analyze huge amounts of text data, such as the entire MEDLINE database. While useful biological knowledge can be extracted using this technology, all-in-one software package for easy utilization of state-of-the-art algorithms is still lacking. In addition, the existence of several similar applications with their own specific functions can make it difficult to readily apply NLP in everyday research. Typically, in order to extract biological knowledge from a large amount of text, a series of NLP tools are sequentially applied as follows: 1) a sentence splitter outputs one sentence per line from a given text, 2) a Part-of-Speech (POS) tagger outputs the set of pairs of POS tags and their corresponding word positions in the given sentence, 3) a named entity recognizer (NER) outputs the set of pairs of a domain-specific term such as a gene or protein name and their positions from the given POS-tagged sentence, 4) a deep parser outputs a syntactic tree that describes syntactic dependencies among words of the sentence from the POS with NER-tagged sentence, and finally, 5) an information extraction (IE) tool indicates some biological knowledge such as protein-protein-interactions. At each step, several research groups have developed tools for their own needs, and interoperability has correspondingly suffered.The Unstructured Information Management Architecture (UIMA)  is an opU-Compare  is an inOn the other hand, several components of NLP functions mentioned above are available independently over SOAP, such as NER, domain specific dictionary lookup, or abbreviation searching, as can be seen in services like Whatizit  and TerMThe results obtained from web services will inevitably need to be manipulated locally. Ideally this can happen in a manner that can fully harness and is interoperable between the Bio* libraries, such as BioPerl, BioRuby, BioPython, and BioJava. The Bio* libraries, however, are based on different and independently developed DNA sequence models, and therefore there is no obvious or common way to share object types among these projects. Although the International Nucleotide Sequence Databases (INSD) defined a standard format for DNA sequence and its annotation , the forIn response to these needs, the Bio* projects have started to collaborate to utilize the programming language-independent BioSQL data model  as the bThe opportunities for cross-project collaboration during the BioHackathon allowed the BioSQL group to put the finishing touches on the schema and release the 1.0 version of BioSQL shortly after the event. Previously each of the major Bio* library projects had already developed bindings of their respective object models to the BioSQL relational model. Some of them, in particular the bindings for BioJava and BioRuby, were significantly improved at the event, in particular in regard to the ability to round-trip sequences as truthfully as possible through load and retrieve cycles. Aside from these activities, the group implemented a proof-of-concept BioSQL web service interface powered by Enterprise Java Beans (EJBs). A version ready for use in a production environment will need further optimizations that allow clients to retrieve only those attributes of sequence or annotation objects that they actually need. For example, a client retrieving a whole chromosome sequence entry that has numerous types of annotation attached may only be interested in a small subsequence and correspondingly only the annotation pertaining to that part, and possibly only certain types of annotation. The mechanisms that facilitate this include lazy (on-demand) loading of data, and implementation of call-backs.We discussed data exchange formats in the fields of Interaction Network, Glycoinformatics, and Phyloinformatics, respectively, and have begun to develop web services using them Table . These aIn order for web services to be utilized in high-throughput bioinformatics research, several common technical challenges exist, including management of large data , asynchronous execution, and data security. Below we summarize the discussions regarding these challenges.Transfer of large amounts of data through web services is problematic not only because of performance issues, but also because long transmissions are more likely to be interrupted by sporadic drops in network connectivity and similar transient problems. Aside from the susceptibility to interruption, large data sets sent inside of a SOAP envelope (using Base64 encoding) must always be loaded into memory on both client and server side, and existing web service client stacks often do not handle large documents in a robust manner. One feasible workaround is to send many gigabytes of data as Message Transmission Optimization Mechanism (MTOM) SOAP attachments . MTOM isWe note that creating a service which accepts or creates references is not actually technically difficult; instead, the difficulty is in the advertisement of this capability, specifically with technologies such as WSDL that have no way to identify the actual data types of the de-referenced input values. The challenges that any system must solve to support reference passing are therefore: 1) acceptance of input data passed to the service as a reference type, 2) allowing the client to specify the delivery type for any results, 3) ideally a mechanism where a naive (non-reference aware) client is able to use the service without modification and 4) some level of lifecycle management for results held in a delivery location.Some web service transactions can potentially take a long time to complete, exceeding the timeout threshold of intermediate communication protocols such as HTTP. It is possible to overcome this problem by using an asynchronous invocation model, where a single logical transaction is implemented as multiple, short-lived transport-level transactions. As the web service by itself is stateless, a mechanism needs to be employed to keep state across transactions. For this purpose, BioMoby uses the Web Service Resource Framework (WSRF) , which iThe default solution for asynchronous services in the web service stack is to use callback operations. However, the majority of web services in the bioinformatics domain are unidirectional, and it cannot be generally expected that a client would have the possibility to expose an external service interface and to accept incoming calls from the server. Therefore, a solution based on polling, ideally accompanied by descriptions in WSDL, is more light-weight and suitable since it does not assume that a client also exposes a service interface. One implementation of a polling-based approach is the SoapLab asynchronous interface , which iTo make web services secure, there are two different layers to be considered; one is the transport security level and the other is the protection of shared resources. At the BioHackathon, requirements for the latter case were discussed to define the minimal information that should be provided by the client in order for the service to know who is trying to use it. Using such information, security services may enforce access control policies at all levels to provide secure authentication and communication over an open network, including: 1) resource protection by restricting the availability of software and computational resources, 2) protection of restricted or proprietary data, and 3) scheduling for priority-based systems. An authorization service is desirable for dynamic access control and security management over federated resources. An example implementation of such a management system can be seen in MyProxy , an openTo explore the possibilities and limitations of service integration, we constructed a workflow in Taverna as a case study that pipelines web services from Japan-based providers  to annotate a protein sequence by homology and structure Figure . In thisIn the course of this evaluation, limitations in the current state of interoperability as well as possible challenges became apparent. Firstly, while the SOAP services provided by DDBJ and KEGG were readily usable, the required functionality in this workflow was missing in the SOAP-based API of PDBj, so that the REST interface was alternatively utilized after several necessary modifications. Therefore, although it is difficult to immediately standardize the data types, web services that are available can still be useful for users as long as they only require small modifications on the client side. Secondly, it turned out that Taverna at present does not support conditional branching, so the workflow had to be branched unconditionally. Thirdly, in most cases the output of one service could not be directly passed as the input of another service due to incompatibility of the data types, and small pieces of glue code were necessary for minor adjustments. Nonetheless, BeanShell scripts in Java provided by Taverna proved effective and useful for such formatting. To avoid or minimize glue code programming, it would be convenient if converters of data types were exposed themselves as a web services.After the hackathon, PDBj has begun to provide a required API and the first issue is fixed. The second issue is essentially due to the Taverna software architecture/design, and end-users need to wait for another workflow management environment to be developed or write a code by themselves. To solve the third issue, DBCLS has started to develop a new web service called TogoWS , which eStandardization efforts for exchange formats and service ontologies reached a certain level of agreement in the areas of biological interactions, phyloinformatics, glycoinformatics, and text-mining. However, there still remain several domains in biology where the basic exchange data types are not yet approved and relevant web services are not yet developed. Promoting standardization and interoperability efforts to these emerging areas are essential for integrative analysis, hence appropriate guidelines to develop standard web services are required. It is also very important that major bioinformatics database centers cooperate with each other towards this end. Accordingly, continued collaborative efforts among service providers, Open Bio* library developers, and workflow client developers are necessary for an effective advance in bioinformatics web service technologies.Standardization and integration by their nature require intensive collaboration and coordination between independent projects and work groups. The gaps in the interoperability of web services therefore partly arise from the relative infrequency of opportunities for inter-project face-to-face discussion and collaboration. A highly intensive collaborative meeting with participants who have a wide variety of expertise therefore mitigates this problem, and a "hackathon" provides an effective and unique opportunity to make this happen . FurtherThe authors declare that they have no competing interests.All authors attended the BioHackathon 2008. TK and KAr primarily wrote the manuscript. TK, YY, SK, MN, HC, AY, TNo, KAs and TTak organized the BioHackathon 2008. All authors read and approved the final manuscript.The DBCLS BioHackathon Consortium consists of more than 60 scientists from over 12 nations that attended the workshop that took place in Tokyo, sponsored by DBCLS and CBRC of Japan.


Simple Semantic Web Architecture and Protocol; pronounced "swap") is an architecture, protocol, and platform for using reasoning to semantically integrate heterogeneous disparate data and services on the web. SSWAP was developed as a hybrid semantic web services technology to overcome limitations found in both pure web service technologies and pure semantic web technologies.SSWAP ( (as in to "swap info") uses the description logic reasoner Pellet to integrate semantic resources. The platform hosts an interactive guide to the protocol at , developer tools at , and a portal to third-party ontologies at  (a "swap meet").There are currently over 2400 resources published in SSWAP. Approximately two dozen are custom-written services for QTL (Quantitative Trait Loci) and mapping data for legumes and grasses (grains). The remaining are wrappers to Nucleic Acids Research Database and Web Server entries. As an architecture, SSWAP establishes how clients , providers , and discovery servers (semantic search engines) interact to allow for the description, querying, discovery, invocation, and response of semantic web services. As a protocol, SSWAP provides the vocabulary and semantics to allow clients, providers, and discovery servers to engage in semantic web services. The protocol is based on the W3C-sanctioned first-order description logic language OWL DL. As an open source platform, a discovery server running at i.e., a common syntax, shared semantic, and semantic discovery) while addressing three technology limitations common in distributed service systems: i.e., i) the fatal mutability of traditional interfaces, ii) the rigidity and fragility of static subsumption hierarchies, and iii) the confounding of content, structure, and presentation. SSWAP is novel by establishing the concept of a canonical yet mutable OWL DL graph that allows data and service providers to describe their resources, to allow discovery servers to offer semantically rich search engines, to allow clients to discover and invoke those resources, and to allow providers to respond with semantically tagged data. SSWAP allows for a mix-and-match of terms from both new and legacy third-party ontologies in these graphs.SSWAP addresses the three basic requirements of a semantic web services architecture ( This is driving the need for machines to become increasingly sophisticated in finding, assimilating, and integrating information. Sharing information is at the core of informatics. For bioinformatics, this has been recognized in its various forms since its inception -5. But wThe requirements for (inter)connectivity, interoperability, and integration, form a dependency stack, whereby transitively the former satisfy necessary but not sufficient conditions for the latter. Interconnectivity addresses those technologies necessary for two or more computers to create a network, such that they can be said to be "connected" and able to send and receive bits without loss of information. Interoperability implies a two-way exchange based on common protocols, and uses interconnectivity in an application-specific manner to build productivity. Integration builds upon this with a synthetic attribute, whereby distributed information is aggregated and assimilated either physically or virtually so as to create a whole greater than the sum of the parts.syntax to one of developing and deploying an expressive semantic . Alternatively, we can see this as moving from a framework with an explicit syntax and implicit semantics, to one where both the syntax and semantics are now explicit. The requirement for an explicit semantics is driven as much by the increasing sophistication of science as by the need to address current technology limitations. For example, in the area of bioinformatics, scientists want the synthetic whole generated from an integration of genomic and functional data, but they will generate the underlying data only from within the fractured sociological infrastructure of separate disciplines of scientific thought, research establishments, and funding programs. Because data is generated in different semantic spaces, integrating it requires knowledge of the data's context and suitability-for-purpose. In a low-throughput environment, where we connect resources and integrate data on a case-by-case basis with human intervention, the semantics may be implicit; i.e., evident to humans by reading documentation and applying appropriate judgments on use. But in a high-throughput environment, where we want machines to find distributed information, to assimilate, and integrate it automatically, we are forced to raise semantics to the level of explicit statements available for computation.As we move from interconnectivity to integration, the informatic problem matures from one of predominately specifying a suitable protocol and e.g., [e.g., [There are notable efforts to address these and related issues. EMBL-EBI provides web services for over two dozen operations including sequence similarity, multiple sequence alignment, data retrieval, and others -9. Many e.g., ). To dise.g.,  providese.g.,  providese.g., , thereby, [e.g., ). It has, [e.g., -19).In this paper, we examine high-throughput integration (the "integration equation") by first highlighting three technology limitations that are hindering current solutions; we then describe the SSWAP architecture as an approach to addressing these limitations by delivering on the syntax/semantics/logic stack; lastly we point to its deployment as a platform in the Virtual Plant Information Network (VPIN).We identify three current technology limitations that are hindering solutions to the "integration equation." They are the:fatal mutability of traditional interfaces - the problem where if data and service providers change their interface signatures, client code depending on that signature fails en masse. This has the undesirable property that the more clients engage an interface , the less flexibility providers have in evolving it. For example, consider a provider's interface that is simply a URI (Uniform Resource Identifier) expected to be dereferenced by a HTTP GET: http://www.myProvider.org/myResource?geneName="CDC40". If the provider now changes the query substring to http://www.myProvider.org/myResource?locusName="CDC40", then scripts and programs expecting the former syntax fail. HTTP as a protocol per se and REST as an architectural style offer no protection from this en masse failure; it would be up to the provider to address backwards compatibility by, for example, supporting both URIs concurrently. This fuels rigidity (the inability of software to change to meet new demands) and fragility . The problem occurs because the binding, i.e., the synchronization of client code to the host's signature, is traditionally established both syntactically and semantically when the client code is written, rather than when it is invoked. What we would like is an architecture that supports late binding, whereby signature validation is delayed until transaction time, preferably within a logical framework whereby clients and hosts could negotiate and assess suitability-for-purpose.1. rigidity and fragility of static subsumption hierarchies - the problem where changing the properties of a class near the root of an inheritance hierarchy (an ontology) redefines subsumption criteria for the entire sub-tree. This has the undesirable property that nodes near the root, which were built when the system was least evolved, are the least able to change without generating cascading repercussions. The core issue for semantic web services is that static asserted subsumption hierarchies--in contrast to dynamic subsumption hierarchies calculated closer to transaction time--do not lend themselves well to changes in application, while often leading to a confounding of concepts with their data model: the extreme (yet common) case being when concepts have no explicit properties, meaning that attributes are implied solely from the class' position in the subsumption hierarchy. For example, the statements 'M subClassOf V; V subClassOf E' implies that any individual of type M  has all the necessary and sufficient properties of type V  and may be more; and similarly V to E . Yet without explicitly delineating those properties , machine reasoners are limited in what they can infer from the ontology. This is immediately apparent in many of the Open Biomedical Ontologies, for example, in the 20,000+ node Gene Ontology [e.g., Biological Process--are of little value when organizing knowledge on another topic, e.g., Molecular Function. The Gene Ontology's well-deserved success rests largely on its authoritative subsumption hierarchy and community acceptance of the implied underlying logic [vs. derived subsumption becomes acute when the properties underlying the justification of the subsumption statements are not themselves defined within the ontology (as is often the case). In that situation, the subsumption hierarchy stands as essentially a static statement of axiomatic relationships. One possible solution to this problem is to deploy ontologies with a greater emphasis on properties [2. ng logic . For higoperties -24 and pconfounding content, structure, and presentation - the problem where the information payload--the data itself--is entangled with its data structure and/or the presentation layer and implicit behaviors of the presentation software. HTML and many applications exploiting the hierarchical nature of XML suffer from this type of entanglement. This has the undesirable property that the data of value to the client may be difficult or essentially impossible to generically parse from the data delivered by an arbitrary provider, thereby crippling machine-automated disentanglement. When data is buried deep in XML hierarchical structures, or available only as "hidden" side-effects of semantically opaque SOAP signatures, or encoded as a combination of images and tables in HTML, the client is restricted in the utility it can extract from the data, even if such restrictions are not the intent of the provider. What we would like is an architecture that supports a clean separation of content, structure, and presentation, whereby a provider's dissemination of the data imposes minimal side-effects on the client's suitability-for-purpose.3. No protocol completely address all these limitations in all scenarios. But in the protocol we describe here we make progress on them specifically by grounding a new protocol in a formal logic. Thus the fatal mutability of interfaces is addressed by designing a protocol that allows for cached or transaction time reasoning for assessment of what the service is offering and what it returns. Similarly, by allowing services to describe their offerings using classes and properties, it is backwards-compatible with deep subsumption hierarchies while also enabling just-in-time subsumption determination based on common properties instead of explicit subclass assertions. Lastly, the protocol encapsulates the semantic description of services and data from the presentation layer using non-hierarchical RDF , theAn architecture that addresses the above challenges would go a long way to achieving the robustness, evolvability, and scalability that are required for high-throughput integration -15. In ldescribe their queries and data, find each other on the web, and engage semantic negotiation to determine suitability-for-purpose at transaction time. This requires a solution to satisfy a set of three basal requirements; viz., to:These considerations essentially recast any solution to the "integration equation" from being one of specifying a syntax and messaging layer used to connect clients and providers, to being one of providing clients and providers a way to deploy a common syntax - that is, allow clients and providers to engage each other under shared syntactical rules. Currently, the GET query strings to major web-based biological information resources such as Entrez , Gramene , and LIS  all have differing and idiosyncratic syntaxes, thereby making interoperability consist of one-off scripts that are inherently non-scalable;• develop a shared semantic - that is, allow machine-discernable meaning so clients can request the same conceptual object or service from different providers. For example, many providers offer equivalent DNA sequences or sequence comparison algorithms, yet scripts cannot compare and contrast the offerings without low-throughput, case-by-case customization. An infrastructure for semantic negotiation is needed; especially one that is cognizant of the sociological influences of achieving a shared semantic;• implement a discovery server - that is, allow clients to find providers based on the semantics of their data and services. Specifically we introduce the capability of semantic searching as defined below. As built upon a common syntax and semantic amenable to a formal logic, this is the necessary condition for scalable integration.• Our design goals are to address the three technology limitations listed earlier while satisfying the three requirements listed above. We found both current-day pure-play semantic web and pure-play web service solutions lacking in this regard--the former because of its lack of web service protocols and the latter because of its lack of a formal semantics amenable to reasoning. Cognizant of this, our design approach is to deeply embed the semantic web "philosophy" to the application of web services. We describe here a new protocol to do this. What follows is a document-based design that uses a W3C-compliant middle-layer for a semantically rich encoding of data and service descriptions.i) providers: web sites offering resources--essentially web services for data retrieval or remote algorithm execution; ii) clients: users of web resources. Providers may also be clients, just as traditional web servers may both request and supply web pages; iii) a discovery server: a non-exclusive, web broker that helps clients find providers based on the semantic qualifications of desired data or services (collectively referred to as resources). The architecture does not require that there be any exclusive or specially authorized discovery server; iv) ontologies: terms used by all actors to communicate in a semantically consistent manner. As will become evident, ontological definitions may be hosted term-by-term by anyone on the web, so any web server may act as an ontology server. In many cases providers may act as ontology servers for concepts that are specific to their offerings. This basic model of providers, clients, and discovery servers (search engines) is purposely analogous to our common understanding of the World Wide Web as it operates today.Architecturally, SSWAP posits the existence of four actors on the web: i.e., subclass) relationships can be computed dynamically from examining an aggregation of properties. In practice, just-in-time or even offline reasoning presents computational challenges even for some non-worst case scenarios, though experience shows these challenges are manageable in a wide variety of cases. Indeed, simple subsumption can be determined without DL reasoning, but adding DL support allows restrictions on cardinality and complex classes built upon union and intersection operations that are useful in real-world applications. An important advantage to this approach is that instead of needing to declare all "is a" relationships directly at design time one can state properties about subjects  as the evidence so supports, and thereby allow others to use property aggregation dynamically at transaction time. This has a natural extension to ontology alignment.SSWAP is deeply based on RDF , botsswap:' and available at . In SSWAP, all actors operate on a SSWAP-compliant, OWL DL graph. The graph uses the SSWAP protocol  to express the relationship between a semantic web service and its data. This architecture . The protocol defines a small set of reserved OWL classes and predicates that allow any provider to describe itself  input to some (possibly null) output. The protocol delivers a minimal set of constructs to allow providers to describe their resources, and for resources to assert their data/service transformations. Implementers may use OWL DL to add and extend properties and classes and further idiosyncratically describe their offerings. We are currently examining the feasibility of front-ending RDGs with RDFa [SSWAP deploys semantic web technologies in a more restricted manner than the broad scope of the semantic web proper. By doing so, it is compatible with the web and web server practices, but does not lay claim to the broader visions of the semantic web. Specifically, providers describe their resources to the world by putting an OWL DL RDF/XML document on the web available to anyone via a simple HTTP GET. This means that anyone can read a resource's description by simply dereferencing its URI. The document, called a Resource Description Graph (RDG), makes specific statements about the resource by using a subset of the SSWAP protocol , and out of the universe of relationships it has to things in the world , it has a particular sswap:providesResource relationship to another individual of type sswap:Resource. Here, individuals are web resources. SSWAP guarantees that dereferencing any node with a sswap: prefix via a HTTP GET will return a SSWAP-compliant, OWL DL definition of the node which defines appropriate restrictions, cardinality constraints on properties, and so forth. Indeed, SSWAP best-operating practices state that any URI referencing an ontological term in a SSWAP-compliant graph should always be dereferenceable, returning an OWL DL definition of the resource. If a URI is not dereferenceable, the system does not fail, but actors will simply not be privy to on-demand resolution of a term's definition. This works well with OWL's guarantee of monotonicity. In this manner, the architecture brings the flavor and power of hyperlinks and linked data to web service interface declarations. In Figure :canonicalResource reciprocates the association assertion back to the provider with a sswap:providedBy predicate. This reciprocation, along with a default behavior, is used by the platform to enforce bilateral assertions so that, for example, a resource's claim to be provided by a third-party provider can be verified by querying the provider. The resource also has a sswap:operatesOn relationship to a sswap:Graph. The sswap:Graph class allows one to build data structures so providers and clients can unambiguously distinguish between such structures as a list of pairs and a pair of lists. The blank node (an anonymous resource) that is a sswap:Graph may also have many relationships to other things in the world, but again, we are interested only in its sswap:hasMappping relationship to a sswap:Subject which in turn is related by sswap:mapsTo to a sswap:Object.In Figure sswap:Subject and sswap:Object classes are used to identify input to output mappings, and as such are equivalent to the input parameters and output return values of traditional interface declarations. For example, Soybase, Gramene, and LIS (Legume Information System) SSWAP services all use the value associated with their various sswap:Subjects as lookup keys into databases from which they return a value associated with the sswap:Object. But the semantics of the sswap:mapsTo predicate does not force a delineation of input and output data: RDF's support for multiple relationships means that it offers a natural way for providers to specify one-to-many and inverse mappings . Because SSWAP does not use traditional, ordered input and output parameters, invocation requirements can be changed, deleted, or appended within the constraints of a first-order logic amenable to machine-reasoning, thereby alleviating one of the major disadvantages of traditional, static interfaces. SSWAP builds a semantic web service interface based upon logical assertions, thus delivering an enabling environment whereby machines can better reason at transaction time to assess suitability-for-purpose.The sswap:Resource, sswap:Graph, sswap:Subject, and sswap:Object. In Figure taxonomyLookupService states that it maps the string value of the predicate ncbiTaxa:commonName to an object of type ncbiTaxa:TaxonomyRecord. This service is a working example  addressing a minor but recurring problem in bioinformatics: the problem of unambiguously and universally associating data with the species or taxon from which they were derived. For human readable web pages and idiosyncratic data files, this is traditionally done by inserting ad hoc strings naming the taxon or hyperlinks to database entries. Yet the non-standardized nature of these common sense conventions makes it almost impossible to write broadly re-usable code to reliably extract this metadata across generic web sites. "What data is currently available on legumes?" is a laborious and difficult question to answer. Even seemingly trivial complications such as spellings and alternative names for taxa offer substantial challenges to writing generic, high throughput parsers. These types of tower-of-Babel problems occur regularly in bioinformatics and they conspire to thwart integration. RDF offers a natural mechanism to address a proximal solution: simply reference an unique URI for each taxon and then associate the URI whenever we wish to reference the taxon. For example, the persistent and unique URI for the legume Medicago truncatula at NCBI's Taxonomy database is . When we associate data with this URI under a well defined semantic, we are making a machine-parseable, unambiguous assertion that can be used to universally tag the data with the taxon. The taxonomyLookupService accepts a string of common words as a key  and queries NCBI for the associated taxonomy record (Medicago truncatula). If it finds a record, it returns the taxon's URI as well as supporting properties as defined at ncbiTaxa:TaxonomyRecord.Figure taxonomyLookupService service is using terms from the third-party ontology ncbiTaxa for both the sswap:Subject and sswap:Object. Yet generically SSWAP allows a mix-and-match of terms from across ontologies on the web. This support for mixing independent third-party ontologies while under a formal semantic is central to SSWAP's sociological model of achieving a shared semantic (see ). This offers an important distinction from traditional XML/DTD-based models. In those cases, the lack of a formal semantic and logic underlying the data model and tagging scheme means that extensions tend to break the standard. In SSWAP, OWL's formal first-order description logic (DL) means that extensions are amenable to machine reasoning. In practice, implementations of first-order DL reasoning lags behind our ability to make assertions, so SSWAP relies heavily on basic subsumption and realization (including inferences from rdfs:domain and rdfs:range). Interestingly, it is not necessary that there exist a formal ontological mapping between any two ontological concepts--a problem that in its generic form of ontology alignment is difficult and unsolved. The sole existence of a resource description graph (RDG) is a de facto claim of at least a partial ontology alignment: it is a statement to the world that this resource, offered by this provider, offers a service that maps instances of one ontological concept to another. The appropriateness of the mapping may be further described within OWL DL, or may lie implicit in the resource's implementation.Ontologies are systems of terms and their relationships. In this example the Because all providers and clients have public access via URIs to the same set of ontological terms on the web, the semantics of data and services is open to a shared evolution and marketplace competition. Well-defined, useful terms maintained by trusted public resources encourage re-use. This forms the basis of a shared semantic and consequent integration. Integration is further enhanced by SSWAP's reliance on OWL semantics, so, for example, one may exploit subsumption relations to deduce suitability-for-purpose rather than relying on lexical matching to enforce naïve equivalency via re-use of the same term. The architecture creates what we call a "Web of Ontologies" that is specifically aimed at refocusing the labor of ontology construction from monolithic enterprises to distributed, dynamic "atoms of knowledge."In summary, SSWAP encourages third-parties to build ontologies as they see the world. It then supplies a framework whereby anyone can pick and choose which concepts best fit what they are looking for or what they are offering while allowing providers to associate these concepts with data types. It additionally supplies a mechanism to "learn more"--that is, enable semantic negotiation--about unrecognized terms by performing an HTTP GET on any term to get a graph of OWL DL statements about the term, be the resource either a service or an ontology term.A provider defines its resource by putting the SSWAP-compliant, OWL DL resource description graph (an RDG) on the web, accessible to anybody by a simple HTTP GET. In this manner, providers describe themselves in the web, as part of the web, and use the web not just as a data delivery pipeline, but with all its associated infrastructure. Architecturally, this means their "publishing of service" consists of no more than placing an SSWAP OWL DL RDF/XML document on a web site and supporting a HTTP POST (or HTTP GET w/a query substring) for service invocation. The page can be deployed using their organization's standard web practice work flow; it can be changed without coordination with a central site, and so forth. that hosts a URL http://sswap.info/publish-resource that accepts HTTP POSTs from resources to inform the discovery server of their presence.  Because resource description graphs sit on the web like any other document, there is no active registration process with the discovery server, just like there is no active registration process with Google. This alleviates many of the security issues associated with de-registration or changing service definitions associated with active registration models, though it also means that the discovery server's knowledge of resources may be out of date with what is currently live on the web. When the discovery server is informed of a resource, it will at its discretion perform a HTTP GET on the resource to retrieve its description graph. Upon retrieving the RDG, the discovery server dereferences terms up to three levels of indirection in an attempt to broaden its knowledge of concepts (ontology terms) used by the resource description graph (RDG). We refer to the resulting set of RDF statements as a three degree closure. We then validate the graph for SSWAP consistency using the OWL reasoner Pellet [i) classification: computing all subclass relations between named classes, ii) realization: assigning individuals to their most specific subclass, iii) consistency checking: complete check for logical contradictions, and iv) satisfiability checking: complete check for classes empty by necessity.In practice, we do not run spiders crawling the web to find SSWAP resources, so to garner publishable resources, we run a semantic discovery server at r Pellet . We use taxonomyLookupService accepts as input an object with the predicate ncbiTaxa:commonName (data type xsd:string). This allows one to query the service with a common taxon name as a lookup key to the official NCBI taxon web page and scientific name. When building a knowledge base (KB) of resources, our reasoner executes a HTTP GET on ncbiTaxa:commonName and examines its definition. It discovers that the domain of the predicate ncbiTaxa:commonName is ncbiTaxa:TaxonomyRecord--an ontological class tagging the object. The reasoner then correctly classifies the taxonomyLookupService service as accepting objects of type ncbiTaxa:TaxonomyRecord, even though the service definition never made the statement explicitly. This inference step generates explicit sub-class and sub-property relationships from implicit relations that broaden the KB's statements for later semantic searching. In Kantian terms this is the generation of synthetic a priori judgments and constitutes new knowledge [). This reasoning step greatly enhances capabilities for semantic searching.As an example, the nowledge . In pracIf a resource is already in the KB and the URI dereferences to an invalid description graph, then the resource is flagged for removal from the KB; similarly, if the graph is new or changed, then the discovery server updates its internal model appropriately. Currently this is done by rebuilding the entire KB because algorithms for making incremental changes to first-order description logic knowledge bases are still in their infancy. Once we have built a KB, we use the open source applications of Jena  for RDF  or programmatically engaging the SSWAP query service with a Resource Query Graph (RQG)  that map "anything" (the blank sswap:Subject node) to something of the class taxa:Taxa. A dereference on the taxa:Taxa URL gives necessary and sufficient conditions (properties and classes) of individuals of that class. The use of a query graph that has the same canonical structure as description graphs, invocation graphs, and response graphs is a novel approach to operational integration  Figure . Clientsn Figure . For exaokering" , the undE defined such that all individuals of class E have properties p and q. We now consider class V subClassOf E; necessarily all individuals of class V have properties p and q, and possibly additional properties. This is guaranteed by the formal semantics of rdfs:subClassOf. Thus if we have data belonging to class V and we ask the question: "What services can operate on my data?", we should get all services that accept a sswap:Subject of type V as well as type E. Indeed, a service operating on data of class E will necessarily work on our data, even if it was constructed independently and in ignorance of class V, and even if our data was classified ignorant of class E .For semantic searching, we seek a mechanism to find all resources (services) that are: 1) of a particular (or more specific) type according to some ontology; 2) operate on a particular  type of data; and/or 3) return a particular (or more specific) type of data. For example, we may want to search for all services that perform sequence comparison, or operate on DNA sequences, or return gene annotations. Consider class taxa:Taxa. In Figure :taxonomyLookupService (retrieving its SSWAP RDG with a HTTP GET) shows that the service returns data of type ncbiTaxa:TaxonomyRecord (not shown in figure). Dereferencing that class shows that it is a subclass of taxa:Taxa, thereby satisfying the search request based on the semantic relations of the data, not on any lexical equivalencies.Figures sswap:Resource node of arbitrary named classes R1, ... Rn, with a sswap:Subject node of arbitrary named classes S1, ... Sm and a sswap:Object node of arbitrary named classes O1, ... Oo, the discovery server returns all known resources that satisfy membership in the class{∩: R1, ... Rn} (and by implication any of its subclasses) with subjects that satisfy membership in any superclass of {∩:S1, ... Sm} and objects that satisfy membership in the class {∩:O1, ... Oo} (and by implication any of its subclasses). As is standard, a class is always a trivial subclass of itself. Thus the returned resources would be (possible) specializations of what one requested; that operate on the typed input data , and returned the typed output data . In this manner, semantic searching seeks to reduce false positives in service discovery by returning those, and only those, services that are guaranteed to operate on the requested data and return transformations that are at least as specialized as requested. In Figure taxonomyLookupService as satisfying the request. The service returns data of type ncbiTaxa:TaxonomyRecord  that is used as the "input data", or will fill in predicate value(s) directly in the graph , the client can POST the service's RDG back to the service with input data typed as the t Figure . The clih Figure .. In this case, the URL is itself a reference to lexical (non-semantic) "output data": i.e., a web page. The class ncbiTaxa:TaxonomyRecord is defined via various properties that allow for semantically tagging key data such as the scientific name, taxonomy id, etc The service extracts this unstructured information and places it in a structured, semantic context of OWL predicates .The resource provider receives the graph from the client, parses it according to the canonical structure, and looks for ways to enhance it. In Figure sswap:inputURI and sswap:outputURI) for sswap:Resources which allow resources to identify URIs that should handle the resources' human readable input and output interfaces (see example at ). The combination of RDF order-independence and resource binding to presentation managers, means that SSWAP exists as a true semantic middle layer, appropriate and capable for machine-machine semantic integration.Upon receiving the response graph from the provider, the client can parse the graph according to its unambiguous structure. Because RDF triples can be parsed order-independent, the client is not required to traverse the graph in a particular hierarchical order. Both content and metadata are "first class" elements, which can be sorted or otherwise searched and organized by clients without losing the provider's statements about the data's relational structure. This helps address the limitations of confounding data content with data structure. To disambiguate content and presentation, SSWAP provides two predicates  means that the graph can sit in persistent storage without loss of its description/query/answer information. This preserves the integrity of the "data as a statement" and decouples it from the particulars of the current manipulating technology. If in the future a new serialization or a more powerful logic is implemented, then forward compatibility is achieved by translating the OWL DL serialization into the new representation. A relevant example is the relatively new introduction of OWL 2.0.), RDFS , XML Schema; ) and OWL  over HTTP; it does not use SOAP  and its oft accompanying WSDL  formalism, nor does it use UDDI  for discovery. We rejected SOAP, WSDL, and UDDI because their heavy web service model did not offer strong support for open semantics and description logic reasoning. Adding an explicit and open semantic on top of SOAP, WSDL, and UDDI added a complexity that offered little advantage over using OWL RDF/XML supported by a DL (Description Logic) reasoner over straight HTTP.SSWAP is a semantic web services architecture and protocol. We designed it because SOAP-based web services do not provide a sufficiently rich semantic framework, while the W3C OWL does not provide a sufficiently rich web services framework. SSWAP uses the W3C standard semantic web technologies of RDF . At first it may seem impossible for the provider's resource description to know anything about the client's anticipated query; or the client's discovery request to share anything with the format of the provider's return data. Yet it is in addressing this in a single, mutable graph that allows us to make progress on the problems of the fatal mutability of interfaces, rigidity and fragility of static subsumption hierarchies, and the confounding of content, structure, and presentation. Surprisingly, these graphs are not long lists of idiosyncratic specifications, but are concise representations of the data and its relationships to the resource using publicly available shared ontologies. We conceptually break apart the ontological use of concepts and the data type of objects, and provide an architecture for a dynamic web of ontologies, in a manner strongly analogous to how HTML documents are hyperlinked to each other and one of the major goals of the W3C OWL effort.SSWAP employs a loose-coupling, late-binding model using OWL DL semantics to achieve dynamic semantic negotiation between suppliers and users of data and services. In SSWAP we introduce a design whereby a single, canonical structure (a template OWL DL graph) embeds the information for how a provider's resource is described and published to the world, how a client's request is made to the discovery service to find a resource, how that request is satisfied by the discovery service, how the client's query is made to the resource, how the resource's answer is returned to the client, and how the client parses that response. This canonical structure means that r Figure . This moi) "Do no harm," ii) "Ignore what you don't understand," and iii) preserve the logical integrity of the graph. The first point means that resources should attempt to accept input (sswap:Subject) as broadly as possible , and return output (sswap:Object) as specific as possible . This will give clients the greatest flexibility in constructing pipelines of services. In practice it means that between invocation and response, services should modify a graph in any of three ways: a) adding new information and instances of sswap:Object, thereby fulfilling the mapping, with allowance for inverse mappings; b) adding multiple sswap:operatesOn, sswap:hasMapping and sswap:mapsTo predicates to build 1:many, many:1, and many:many mappings as appropriate; c) adding explicit statements that are logically implied but not explicitly present. A resource should not remove statements, even if they are logically redundant, since other actors' parsers that do not perform reasoning may rely on their explicit existence. The second point, "Ignore what you don't understand," means that parsers should pass through assertions that cannot be semantically resolved, rather than dropping them or generating an error. This assures that SSWAP statements augment, but do not preclude, other RDF statements in the graph. Both points imply that resources should strive to complete the graph passed to them and return an amended graph back to the client, rather than generating de novo "answer graphs" as a response. The third point, to preserve the logical integrity of the graph, means that no resource is required to process, nor should it return, an ill-formed or inconsistent graph. The extent that a partial match is satisfied is up to the provider: open-ended requests leave much discrepancy to providers, while overly-restrictive requests will yield many providers unable to add any information. Either way, both clients and providers treat a graph as a contract, where passage through a provider's service retains the logical consistency and implication of the invoking graph.The nature of the graph model means that providers may optionally only partially satisfy a graph. This is in distinction from more traditional web service models where services tend to either work completely or not at all. In the SSWAP model, a single resource may not be able to fully satisfy a graph, but a series of resources may each be able to read the graph, append data, and contribute to an integrated, synthetic "answer." SSWAP best practices encourage resources to: sswap:Object of one provider's response graph becomes the sswap:Subject of downstream provider's invocation graph. In this manner a query can traverse the web, both in terms of embellishing a single sswap:Subject to sswap:Object mapping among numerous providers implementing different aspects of the same mapping, and also pipelining a sswap:Object to sswap:Subject transitively across providers.Thus SSWAP allows one to combine two powerful features of graph-based semantic web services. The first is partial graph completion, which means that the same graph can be sent to multiple services, and each can annotate or augment it according it own view of the world. This is conceptually distinct from how most traditional web services are implemented, where complete success or complete failure is often a fundamental design feature. The second feature is how SSWAP's persistent canonical graph structure means that pipelining semantic web services is syntactically trivial: the i.e., shallow) hierarchies, since in such systems dynamic subsumption determination is less prone to the rigidity and fragility of deep, static subsumption classifications. Yet SSWAP also addresses this under an embracement of requiring only local consistency. In practice, fragmentary knowledge of ontologies is often sufficient for determining suitability-for-purpose in a transaction between two actors. SSWAP enforces local consistency on resources during their publication to the discovery server, but it does not require global consistency across all uses of a term.  While SSWAP's discovery server does not require global consistency, at regular intervals we do reason over the entire KB to see if global consistency is achievable. To date, we have always achieved this. The ramifications of failing to achieve global consistency mean that some logically equivalent searches could return contradictory responses. From the perspective of expert systems or ontological science this is undesirable, but from the perspective of a world-wide semantic web it is likely that global consistency as a criterion should be abandoned. For example, as users we never know the true false positive or false negative rate of non-semantic search engines such as Google, and we are unsurprised if independent searches on "gene" and "hereditary unit" return non-equivalent search results even if these are considered as equivalent keys under some system of definition. Thus SSWAP aims for a middle ground, whereby it brings a level of formalism and semantics to web resources allowing them to describe their offerings, yet still delivers operational value to users navigating within a world of possible logical inconsistencies. OWL's property of monotonicity and its rejection of the unique name assumption ensures that no mix-and-match strategy breaks the properties of completeness and decidability for consistent models, though computational tractability with finite resources is not guaranteed.SSWAP's enablement of easily mix-and-matching terms across ontologies is closely aligned with the vision of the semantic web and the design of RDF. But from the perspective of well-formed ontological reasoning, one may be hesitant to re-use ontological terms outside of a closed, well-defined ontology. Inevitably, mixing terms from different ontologies can sacrifice desirable global guarantees and can lead to logical inconsistencies if done haphazardly. This is partially addressed by SSWAP's encouragement of using property-rich, subsumption-poor  to build just-in-time ontologies [For use in semantic web services, ideally ontologies would be constructed with an emphasis on properties (predicates) instead of deep subsumption relations (class hierarchies). Thus the emphasis should be on shallow subsumption ontologies rich in properties, versus deep subsumption hierarchies built axiomatically on tologies -24., SoyBase (soybase.org), The Legume Information System , and over 2400 database and web server entry points from Nucleic Acids Research (NAR). Services are discoverable at . The NAR entries wrap web sites under the NAR service ontologies, but do not map the input or output data types to data-specific ontological terms. A description of the VPIN's Gramene, SoyBase, and LIS services will appear elsewhere. Here, we introduce just a brief introduction to these services to substantiate SSWAP's real-world implementation. Discovery and invocation of these services is available at .We are deploying SSWAP as the underlying semantic technology for the Virtual Plant Information Network (VPIN). The VPIN consists of semantic web services offered by Gramene e.g., rice, maize and barley). The emphasis is on presenting QTLs with information on both associated traits and a mapped locus on a genetic map. Gramene acts as a provider within the VPIN semantic web services platform to describe QTL data and services, to enable discovery of those resources, to allow partners to share and integrate data and terms, and to invoke those web processes to operate on those data. By using these semantic technologies we go beyond token matching  and open a combination of lexical and semantic searching instead. In this manner, users may find services that operate on formal QTL objects. Gramene offers distinct SSWAP semantic web services for accessing QTLs by accession ID, phenotypic trait symbol, trait name, trait synonym, trait category, species scientific name, species common name, QTL symbol, linkage group, and Trait Ontology ID. Future plans are to improve the current ontology, integrate resources with other existing ontologies to enable integration with other services and add further capabilities as the QTL database is expanded.Gramene's cereal QTL resources are available to the community as semantic web services using SSWAP. The use of semantic web services allows Gramene QTLs to be integrated with comparative mapping data, genomic data, germplasm data, and other information that has been made available via the VPIN. The Gramene QTL database includes QTLs identified for numerous agronomic traits in the grasses  Merr As part of the comparative genomics activity in the Legume Information System (LIS) we have developed and deployed a number of SSWAP services that provide tools for automatic retrieval of data from SoyBase. Two types of services have currently been designed for SoyBase Locus and QTL classes. The first service type returns a full report of data contained in the Soybean Breeders Toolbox (the current database for SoyBase) for an input soybean genetic map QTL or Locus symbol, SoybaseQtlReportService and SoybaseLocusReportService respectively. The second type of services return a selection of data type properties (database fields) making them more atomic and easily parseable. The services deliver data combinations which would most likely to be needed by other databases or soybean researchers, such as the ability to get a list of all soybean germplasms in which a marker has been analyzed (SoybaseLocusGermplasmService) or the ability to get a list of all soybean genetic maps to which a SoyBase Locus is associated. Other databases can interrogate the Soybean Breeders Toolbox and retrieve a list of the types of soybean loci available (SoybaseLocusTypeService). This list can then be used to systematically retrieve all loci from the database by their "type" using the SoybaseLocusByTypeService and so on. Future improvements to the SoyBase SSWAP services will include the ability to retrieve sequence data associated with soybean loci as well as the expansion of services to include other data types contained in the Soybean Breeders Toolbox. As the soybean genomic sequence data becomes publicly available and incorporated into the Toolbox, information on those data will also be made available through SoyBase SSWAP services.SoyBase getSequenceForIdentifier demonstrates the ease in which RDF allows one to return pointers to data instead of embedding large amounts of data in XML files. The service maps a GenBank accession number, a TIGR transcript assembly number, or a TIGR consensus sequence number to its associated LIS sequence. Because sequence data may be voluminous, instead of embedding the data in the response graph, the service makes the sswap:Object a URL to where the data is located. It annotates the URL with a class  designating it of type FASTA, and appends a property with the FASTA header information. Users of the service simply dereference the URL with an HTTP GET to retrieve the FASTA sequence.The Legume Information System (LIS) has developed SSWAP semantic web services in collaboration with Gramene and SoyBase. First generation services provide an entry point to the Legume Information Network (LIN), while second generation services return LIS genomic and transcriptome sequences given accession ids and marker symbols, as well as a service entry point to BLAST. The LIS service If Gramene, SoyBase, and LIS had used traditional web service technologies, their offerings would have proliferated the current silo effect now seen with hundreds of web services each requiring low-throughput, non-semantic discovery and engagement. Their use of SSWAP mitigated this by establishing an early ground in providing semantically enabled services and data amenable to semantic discovery and invocation.sswap:inputURI and sswap:outputURI provides a natural mechanism to segregate data and content from presentation layers.Implementing SSWAP for the VPIN showed both the strengths and limitations of the semantic web services approach. Re strengths, the ontological flexibility of the model (the "Web of Ontologies") means that new data types and service categories can be introduced in a manner that makes them approachable and available to all actors. In contrast to the flexibility of data and service descriptions, SSWAP protocol standardization means that parsing and low-level code can be easily shared across implementations. Standardization over a formal semantic means that we can apply a reasoner to discover implicit truths, and then build a semantic search capability to use those assertions to return services based on both their service categorization and their data's semantic tagging, as well implied subsumption relations. In future implementations, the deployment of reasoners not only for KB building supporting semantic searching but also at transaction time by individual actors offers a promising approach for addressing the fatal mutability of traditional interfaces. When combined with property-rich classes and shallow subsumption relations, the approach alleviates many of the limitations of static subsumption hierarchies. Finally, OWL's reliance on RDF and our use of SSWAP predicates such as e.g., specifying BLAST parameters). Work-arounds address this with a best practices convention on the use of necessary and sufficient owl:Restrictions  but the fit is not natural from a web services perspective; 2) a service's logical description can be implemented in any number of different syntactical ways. Thus for validation, it is not sufficient to parse graphs solely based on syntactical structure. Yet just-in-time reasoners deployed at transaction time are not well developed, so currently service providers rely heavily on parsing explicit statements which may lead them to incorrectly accept or reject some invocation graphs; 3) OWL DL may be too powerful. Complex restrictions on classes, predicates, and individuals can be verbose and difficult for humans to master when serialized in RDF/XML. The recommended approach is to work at a higher level employing reasoners and parsers to operate on the underlying graphs. But reasoners are still maturing and have some undesirable properties. For example, it is difficult or even impossible to estimate how long a reasoner will take to complete based on a given input graph; 4) knowledge bases--the result of running a reasoner on a set of statements and inferring new truths--are fragile to incremental additions, deletions, and changes in the underlying input statements. In general, once information changes, the reasoner has to be re-run on the entire input corpus, which can take a substantial amount of time. Incremental reasoning is an area of active research; 5) developer tools are still in their infancy. For widespread deployment, bioinformaticians will need helper tools, much in the same way that many web developers use high level languages and integrated development environments to generate HTML and server-side web code.Yet our research also found limitations: 1) OWL DL's property of monotonicity means that some simple properties of web services, such as specifying and enforcing the number and/or codependency of required and optional parameters for a service can be obtuse ; SSWAP: Simple Semantic Web Architecture and Protocol; UDDI: Universal Description Discovery and Integration; VPIN: Virtual Plant Information Network; W3C: World Wide Web Consortium; WSDL: Web Service Definition Language; XML: Extensible Markup Language; XMLS: XML Schema; XSD: XML Schema Document; URI: Uniform Resource Identifier; URL: Uniform Resource Locator.DDGG was the Principal Investigator on the project and wrote the main paper; GSS was the principal software developer; GDM was co-PI for LIS; SA provided software development for Gramene and wrote the section on Gramene services; CDT was co-PI for JCVI; DG was oversight for SoyBase; RTN provided software development for SoyBase and wrote the section on SoyBase services. All authors read and approved the manuscript.