BACKGROUND
biology is rapidly becoming an information science.
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  <cit> .
but what was initially seen as an issue of the setting of standards for sharing data, has grown into a mature assessment that distributed, decentralized, possibly ephemeral, resources are now the fabric of the informatic landscape.
navigating this landscape requires technologies that far exceed simply establishing connectivity and sharing data via a common format.
the fact that interconnectivity and interoperability protocols and middleware such as ftp , telnet , ethernet , tcp/ip , smtp , gopher , http , and corba , have been with us for nearly  <dig> years, yet the level of integration we want in informatics remains elusive, shows that broad, interoperability standards per se may be necessary but are not sufficient for integration.
the requirements for 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.
as we move from interconnectivity to integration, the informatic problem matures from one of predominately specifying a suitable protocol and 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.
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  <cit> .
many embl-ebi web services use the industry-standard technologies of wsdl  documents to describe services and soap  as the protocol for interoperability.
embl-ebi also support rest  interfaces for some services.
in a similar manner, ncbi offers web services using standard wsdl and soap descriptions and protocols.
these web services can be engaged via the rest-like, url-based eutils services that are essentially http wrappers to the entrez query system  <cit> .
indeed, embl ebi and ncbi are just two of many bioinformatic web services available .
to discover and engage such services, one needs to either peruse the unstructured information on web pages and within the published literature, or use a discovery service specific for web services.
for example, biocatalogue  <cit>  provides a google-like search service for web services, while biomoby  <cit>  provides an xml-based namespace and object ontology that both enables discovery and invocation for biomoby-compliant services.
a limitation of wsdl and soap is that their syntactical rules of engagement do not allow for machines to readily determine the semantics of the underlying data and services.
efforts have been made to address this.
one approach, as taken by the myexperiment project is to encapsulate the underlying service details in a higher-order integrative layer.
myexperiment combines social networking with scientific workflows  <cit> , thereby emphasizing not the web services per se, but the end product of their thoughtful integration.
moving to a state where machines can better contribute to higher level integration has been slow coming, in part because steady progress in implementing an infrastructure that allows machines to discover services and assess their suitability-for-purpose in a fully automated manner presupposes a formal logic over web resources .
it has only been relatively recently that the tripartite of syntax, semantics, and logic is available in a web standard, such as the w3c standard of owl .
in this paper, we examine high-throughput integration  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 .
three current technology constraints limiting integration over the web
we identify three current technology limitations that are hindering solutions to the "integration equation."
they are the:
<dig>  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  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  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.
<dig>  rigidity and fragility of static subsumption hierarchies - the problem where changing the properties of a class near the root of an inheritance hierarchy  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  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  <dig> + node gene ontology  <cit> .
the gene ontology has separate ontologies for biological process, molecular function, and cellular component exactly because subsumption claims on one topic--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  <cit> .
for high-throughput integration--particularly cross-ontology integration--the problem of asserted vs. derived subsumption becomes acute when the properties underlying the justification of the subsumption statements are not themselves defined within the ontology .
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  <cit>  and push subsumption determination closer to transaction time.
<dig>  confounding 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.
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 , thereby helping to separate content, structure, and presentation.
syntactical, semantic, and discovery requirements
an 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  <cit> .
in light of these challenges, we were impressed with the overwhelming success of the web; its stateless, method-sparse, document-based architecture demonstrating many desirable properties of robustness, evolvability, and scalability.
our solution was to design an architecture that mimicked much of what worked for the web; in particular, a document-based architecture with explicit delineations of data and its contextual relationships.
this leaves the manipulation of the data's "raw value" to any particular technology of the day, allowing the system to evolve as new technologies are developed.
a technology assessment phase in an earlier related project called semantic moby  led to the choice of rdf and owl dl as the underlying enabling technologies.
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 describe 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:
• 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.
implementation
sswap: a simple semantic web architecture and protocol
architecturally, sswap posits the existence of four actors on the web: 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 .
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  is purposely analogous to our common understanding of the world wide web as it operates today.
sswap is deeply based on rdf , both in its use of rdf as a technology and also in rdf's conceptual model of presenting information in the form of entities and relationships.
rdf allows semantics to be expressed via a series of subject-predicate-object assertions .
assertions simply state that some "thing"  has some relationship  to something else .
a series of subject-predicate-object triples creates a network of assertions that can be represented as a graph.
rdf may be serialized in a number of different formats; the w3c specifies rdf/xml as the recommended messaging layer.
in this manner rdf and rdf/xml set the basic underlying syntax for anyone to say anything about anything  <cit> .
owl , and specifically owl dl and the newer owl  <dig>  variants, is the w3c recommendation of how to express a first-order description logic for the web.
owl is based on rdf.
owl introduces reserved classes and predicates with a formal semantic so that machines can reason over statements and come to conclusions.
owl dl is mappable to an underlying first-order description logic  with guarantees of completeness and decidability.
this provides a precise and explicit semantics which enables dl reasoning.
theoretically, the ability to reason should alleviate the need for static "is a" relationships, because subsumption  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 establishes a small set of reserved classes and predicates to allow owl to be used for semantic web services.
this is the protocol itself; essentially a light-weight sswap ontology designated in this paper with the prefix 'sswap:' 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  is different from traditional provider/client/search-engine models.
in traditional systems, different technologies are used to describe services, to discover services, to engage them, and to handle the result.
in sswap, all actors work from the same, mutable graph; a graph that always adheres to the same canonical structure.
this establishes both a common syntax and skeleton structure across all actors and activities and yields benefits in terms of shared parsing constructs and re-usable code.
this is worth emphasizing: the same canonical structure that allows providers to describe their offerings, is the same canonical structure for expressing queries on those offerings, which is in turn the same canonical structure for phrasing service invocation, which is the same canonical structure for representing results.
exposition on this point follows.
the sswap protocol
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 , makes specific statements about the resource by using a subset of the sswap protocol .
the protocol defines a small set of reserved owl classes and predicates that allow any provider to describe itself  and its resources  within a canonical, recognizable structure.
in practice, service providers host one rdf/xml file defining themselves as a sswap:provider, and any number of other rdf/xml files, each with its own sswap:resource.
of course there is no implementation requirement that these be physical files: e.g., web masters may deploy servlets to parse uris.
the explicit use of reserved classes and properties allows us to establish an explicit semantics under the larger umbrella of owl dl.
this means machines have clear, unambiguous rules within which to parse any sswap graph, and can ignore assertions that are not relevant to sswap.
out of a universe of ways one could use owl dl to describe a resource, the canonical graph structures all resource definitions in terms of a transformation of some  input to some  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  <cit> , such that providers could simply host marked-up web pages that could be transformed into rdgs upon the action of an agent.
this would tighten sswap's position with linked data  <cit> .
in figure 2a, the canonical graph states that there is some provider , 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 2b, the uri :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  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.
the 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  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 web of ontologies
ontologies are systems of terms and their relationships.
in this example the 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 .
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  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 .
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  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.
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.
resource publication with a discovery server
a provider defines its resource by putting the sswap-compliant, owl dl resource description graph  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  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.
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  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  used by the resource description graph .
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  <cit> .
we use pellet to make explicit any and all implicit statements.
the reasoner performs the following four operations: 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.
as an example, the taxonomylookupservice accepts as input an object with the predicate ncbitaxa:commonname .
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  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  <cit> .
in practice, a rdg of a dozen or so statements is often rendered into thousands of statements after execution of the third degree closure and reasoning .
this reasoning step greatly enhances capabilities for semantic searching.
if 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  <cit>  for rdf manipulation via sparql on top of a postgresql rdbms  <cit>  as a triple-store.
resource discovery and semantic searching
clients engage the discovery service by using either the web front-end at  or programmatically engaging the sswap query service with a resource query graph  .
clients construct their query graphs using the same publicly available ontological concepts as used by providers to describe their resource.
just as search engines on the web provide non-exclusive points of entry for web surfing, the discovery server provides a non-exclusive point of entry for resource discovery.
architecturally, clients are not required to use the discovery server; indeed, if they know of a resource's uri then they may engage it directly .
in figure  <dig>  the client is asking the discovery server to return all resources  that map "anything"  to something of the class taxa:taxa.
a dereference on the taxa:taxa url gives necessary and sufficient conditions  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 .
for example, the client could send a graph without the taxa:taxa qualifier, thereby asking "get me anyone who can map anything to anything."
clearly, numerous combinations are possible.
while the discovery server fulfills the role described variously as "matchmaking" or "brokering"  <cit> , the underlying owl ontology extends the usual lexical basis for such matches by allowing for semantic searching based on subsumption relations.
for semantic searching, we seek a mechanism to find all resources  that are: 1) of a particular  type according to some ontology; 2) operate on a particular  type of data; and/or 3) return a particular  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 e 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 .
figures  <dig> and  <dig> give a demonstrative example of how these operational guarantees deliver semantic search results in a decentralized model.
in figure  <dig> , the client asks for all resources that return data of type taxa:taxa.
in figure  <dig>  the discovery server returns a graph with the resource http://...taxonomylookupservice.
dereferencing :taxonomylookupservice  shows that the service returns data of type ncbitaxa:taxonomyrecord .
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.
the model of semantic searching with query graphs is to return all resources that are a "sub-concept" of the query graph.
given a query graph with a sswap:resource node of arbitrary named classes r <dig>  ... rn, with a sswap:subject node of arbitrary named classes s <dig>  ... sm and a sswap:object node of arbitrary named classes o <dig>  ... oo, the discovery server returns all known resources that satisfy membership in the class{∩: r <dig>  ... rn}  with subjects that satisfy membership in any superclass of {∩:s <dig>  ... sm} and objects that satisfy membership in the class {∩:o <dig>  ... oo} .
as is standard, a class is always a trivial subclass of itself.
thus the returned resources would be  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  <dig>  the discovery server response graph sent back to the querying client returns the taxonomylookupservice as satisfying the request.
the service returns data of type ncbitaxa:taxonomyrecord  which is a subclass  of the requested taxa:taxa in figure  <dig>  in practice, transaction-time reasoning on graphs to compute subconcepts is expensive and algorithms are still in their infancy.
thus sswap satisfies mostly subsumption support on named, explicit classes already established in the kb.
service invocation
by sswap convention, posting a graph to a resource is interpreted as a request to invoke the service.
once a client has a service's uri , the client can post the service's rdg back to the service with input data typed as the sswap:subject .
the client always knows the service's interface because the rdg is a logical description of the service's transformation available to anyone with a simple http get on the same uri used for invocation.
in figure  <dig>  the client replaces the null string value of the predicate taxa:commonname with the look up key "barrel medic" and posts the graph to the taxonomylookupservice.
in all cases, the client will either instantiate the sswap:subject with a resource  that is used as the "input data", or will fill in predicate value directly in the graph .
service completion
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  <dig> the service completes the mapping of the string "barrel medic" to the resource .
in this case, the url is itself a reference to lexical  "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 .
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  for sswap:resources which allow resources to identify uris that should handle the resources' human readable input and output interfaces .
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.
the canonical graph structures a process for semantic negotiation between client and provider, which is essentially brokered by using shared, third-party ontological terms, the meaning of which are available at transaction time.
the document-centric, serialization of a logic  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  <dig> .
RESULTS
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 , 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  reasoner over straight http.
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  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 the description frames the query frames the answer .
this model is in stark contrast to most existing models where technologies used for resource description, discovery, querying, invocation, and response may share little in common .
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.
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: i) "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  as broadly as possible , and return output  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: <dig>  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.
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 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.
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  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.
for use in semantic web services, ideally ontologies would be constructed with an emphasis on properties  instead of deep subsumption relations .
thus the emphasis should be on shallow subsumption ontologies rich in properties, versus deep subsumption hierarchies built axiomatically on rdfs:subclassof assertions.
this approach provides an opportunity to shift subsumption determination from creation time to closer to transaction time, and thereby enhances ontologies' flexibility for addressing suitability-for-purpose.
this is expected to increase the likelihood of term reuse by third-parties outside of the original context, and makes it more likely that independently produced ontologies will retain global consistency after aggregation.
we have investigated the use formal concept analysis  to build just-in-time ontologies  <cit> .
virtual plant information network
we are deploying sswap as the underlying semantic technology for the virtual plant information network .
the vpin consists of semantic web services offered by gramene , soybase , the legume information system , and over  <dig> database and web server entry points from nucleic acids research .
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 .
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 .
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.
soybase , is the usda-ars public repository for community contributed and professionally curated genetic and genomic data for the soybean glycine max  merr as part of the comparative genomics activity in the legume information system  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  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  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  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 .
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.
the legume information system  has developed sswap semantic web services in collaboration with gramene and soybase.
first generation services provide an entry point to the legume information network , 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 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.
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.
CONCLUSIONS
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  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 sswap:inputuri and sswap:outputuri provides a natural mechanism to segregate data and content from presentation layers.
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 .
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.
we view these limitations as "growing pains" on a path towards web integration that offers to transcend many of the limitations that currently limit integration.
some limitations, such as a relative unfamiliarity with owl in the bioinformatic community or the lack of suitable developer tools are addressable.
other limitations, such as advances in just-in-time or incremental reasoning will require new advances in computer science.
availability and requirements
project name: sswap
project home page: ; source code deposited at
operating system: platform independent; implemented on unix
programming languages: java, owl, html, jsp
requirements for provider development kit: java  <dig>  or higher, ant  <dig>  or higher, tomcat  <dig>  or higher, jena  <dig>  or higher.
hosting an independent discovery server also requires pellet  <dig>  or higher and a database backend such as postgresql  <dig> .
protégé  <dig>  or higher is useful for developing ontologies.
license: minor variant on mit license; see lib/license.txt on main svn trunk at .
any restrictions to use by non-academics: none beyond general licensing terms; see license for details.
list of abbreviations
dl: description logic; kb: knowledge base; lis: legume information system; owl: web ontology language; qtl: quantitative trait locus; rdf: resource description framework; rdfs: rdf schema; rdg: resource description graph; rig: resource invocation graph; rqg: resource query graph; rrg: resource response graph; soap: simple object access protocol ; 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.
authors' contributions
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.

 biology is rapidly becoming an information science. 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. but what was initially seen as an issue of the setting of standards for sharing data, has grown into a mature assessment that distributed, decentralized, possibly ephemeral, resources are now the fabric of the informatic landscape. navigating this landscape requires technologies that far exceed simply establishing connectivity and sharing data via a common format. the fact that interconnectivity and interoperability protocols and middleware such as ftp, telnet, ethernet, tcp/ip, smtp, gopher, http, and corba, have been with us for nearly years, yet the level of integration we want in informatics remains elusive, shows that broad, interoperability standards per se may be necessary but are not sufficient for integration. the requirements for 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. as we move from interconnectivity to integration, the informatic problem matures from one of predominately specifying a suitable protocol and 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. 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. many embl-ebi web services use the industry-standard technologies of wsdl documents to describe services and soap as the protocol for interoperability. embl-ebi also support rest interfaces for some services. in a similar manner, ncbi offers web services using standard wsdl and soap descriptions and protocols. these web services can be engaged via the rest-like, url-based eutils services that are essentially http wrappers to the entrez query system. indeed, embl ebi and ncbi are just two of many bioinformatic web services available. to discover and engage such services, one needs to either peruse the unstructured information on web pages and within the published literature, or use a discovery service specific for web services. for example, biocatalogue provides a google-like search service for web services, while biomoby provides an xml-based namespace and object ontology that both enables discovery and invocation for biomoby-compliant services. a limitation of wsdl and soap is that their syntactical rules of engagement do not allow for machines to readily determine the semantics of the underlying data and services. efforts have been made to address this. one approach, as taken by the myexperiment project is to encapsulate the underlying service details in a higher-order integrative layer. myexperiment combines social networking with scientific workflows, thereby emphasizing not the web services per se, but the end product of their thoughtful integration. moving to a state where machines can better contribute to higher level integration has been slow coming, in part because steady progress in implementing an infrastructure that allows machines to discover services and assess their suitability-for-purpose in a fully automated manner presupposes a formal logic over web resources. it has only been relatively recently that the tripartite of syntax, semantics, and logic is available in a web standard, such as the w3c standard of owl. in this paper, we examine high-throughput integration 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. three current technology constraints limiting integration over the web 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 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 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. rigidity and fragility of static subsumption hierarchies - the problem where changing the properties of a class near the root of an inheritance hierarchy 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 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 + node gene ontology. the gene ontology has separate ontologies for biological process, molecular function, and cellular component exactly because subsumption claims on one topic--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. for high-throughput integration--particularly cross-ontology integration--the problem of asserted vs. derived subsumption becomes acute when the properties underlying the justification of the subsumption statements are not themselves defined within the ontology. 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 and push subsumption determination closer to transaction time. confounding 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. 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, thereby helping to separate content, structure, and presentation. syntactical, semantic, and discovery requirements an 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. in light of these challenges, we were impressed with the overwhelming success of the web; its stateless, method-sparse, document-based architecture demonstrating many desirable properties of robustness, evolvability, and scalability. our solution was to design an architecture that mimicked much of what worked for the web; in particular, a document-based architecture with explicit delineations of data and its contextual relationships. this leaves the manipulation of the data's "raw value" to any particular technology of the day, allowing the system to evolve as new technologies are developed. a technology assessment phase in an earlier related project called semantic moby led to the choice of rdf and owl dl as the underlying enabling technologies. 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 describe 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: • 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. implementation sswap: a simple semantic web architecture and protocol architecturally, sswap posits the existence of four actors on the web: 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. 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 is purposely analogous to our common understanding of the world wide web as it operates today. sswap is deeply based on rdf, both in its use of rdf as a technology and also in rdf's conceptual model of presenting information in the form of entities and relationships. rdf allows semantics to be expressed via a series of subject-predicate-object assertions. assertions simply state that some "thing" has some relationship to something else. a series of subject-predicate-object triples creates a network of assertions that can be represented as a graph. rdf may be serialized in a number of different formats; the w3c specifies rdf/xml as the recommended messaging layer. in this manner rdf and rdf/xml set the basic underlying syntax for anyone to say anything about anything. owl, and specifically owl dl and the newer owl variants, is the w3c recommendation of how to express a first-order description logic for the web. owl is based on rdf. owl introduces reserved classes and predicates with a formal semantic so that machines can reason over statements and come to conclusions. owl dl is mappable to an underlying first-order description logic with guarantees of completeness and decidability. this provides a precise and explicit semantics which enables dl reasoning. theoretically, the ability to reason should alleviate the need for static "is a" relationships, because subsumption 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 establishes a small set of reserved classes and predicates to allow owl to be used for semantic web services. this is the protocol itself; essentially a light-weight sswap ontology designated in this paper with the prefix'sswap:' 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 is different from traditional provider/client/search-engine models. in traditional systems, different technologies are used to describe services, to discover services, to engage them, and to handle the result. in sswap, all actors work from the same, mutable graph; a graph that always adheres to the same canonical structure. this establishes both a common syntax and skeleton structure across all actors and activities and yields benefits in terms of shared parsing constructs and re-usable code. this is worth emphasizing: the same canonical structure that allows providers to describe their offerings, is the same canonical structure for expressing queries on those offerings, which is in turn the same canonical structure for phrasing service invocation, which is the same canonical structure for representing results. exposition on this point follows. the sswap protocol 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, makes specific statements about the resource by using a subset of the sswap protocol. the protocol defines a small set of reserved owl classes and predicates that allow any provider to describe itself and its resources within a canonical, recognizable structure. in practice, service providers host one rdf/xml file defining themselves as a sswap:provider, and any number of other rdf/xml files, each with its own sswap:resource. of course there is no implementation requirement that these be physical files: e.g., web masters may deploy servlets to parse uris. the explicit use of reserved classes and properties allows us to establish an explicit semantics under the larger umbrella of owl dl. this means machines have clear, unambiguous rules within which to parse any sswap graph, and can ignore assertions that are not relevant to sswap. out of a universe of ways one could use owl dl to describe a resource, the canonical graph structures all resource definitions in terms of a transformation of some input to some 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, such that providers could simply host marked-up web pages that could be transformed into rdgs upon the action of an agent. this would tighten sswap's position with linked data. in figure 2a, the canonical graph states that there is some provider, 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 2b, the uri: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 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. the 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 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 web of ontologies ontologies are systems of terms and their relationships. in this example the 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. 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 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. 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 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. 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. resource publication with a discovery server a provider defines its resource by putting the sswap-compliant, owl dl resource description graph 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 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. 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 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 used by the resource description graph. 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. we use pellet to make explicit any and all implicit statements. the reasoner performs the following four operations: 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. as an example, the taxonomylookupservice accepts as input an object with the predicate ncbitaxa:commonname. 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 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. in practice, a rdg of a dozen or so statements is often rendered into thousands of statements after execution of the third degree closure and reasoning. this reasoning step greatly enhances capabilities for semantic searching. if 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 manipulation via sparql on top of a postgresql rdbms as a triple-store. resource discovery and semantic searching clients engage the discovery service by using either the web front-end at or programmatically engaging the sswap query service with a resource query graph. clients construct their query graphs using the same publicly available ontological concepts as used by providers to describe their resource. just as search engines on the web provide non-exclusive points of entry for web surfing, the discovery server provides a non-exclusive point of entry for resource discovery. architecturally, clients are not required to use the discovery server; indeed, if they know of a resource's uri then they may engage it directly. in figure the client is asking the discovery server to return all resources that map "anything" to something of the class taxa:taxa. a dereference on the taxa:taxa url gives necessary and sufficient conditions 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. for example, the client could send a graph without the taxa:taxa qualifier, thereby asking "get me anyone who can map anything to anything." clearly, numerous combinations are possible. while the discovery server fulfills the role described variously as "matchmaking" or "brokering", the underlying owl ontology extends the usual lexical basis for such matches by allowing for semantic searching based on subsumption relations. for semantic searching, we seek a mechanism to find all resources that are: 1) of a particular type according to some ontology; 2) operate on a particular type of data; and/or 3) return a particular 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 e 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. figures and give a demonstrative example of how these operational guarantees deliver semantic search results in a decentralized model. in figure, the client asks for all resources that return data of type taxa:taxa. in figure the discovery server returns a graph with the resource http://...taxonomylookupservice. dereferencing:taxonomylookupservice shows that the service returns data of type ncbitaxa:taxonomyrecord. 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. the model of semantic searching with query graphs is to return all resources that are a "sub-concept" of the query graph. given a query graph with a sswap:resource node of arbitrary named classes r... rn, with a sswap:subject node of arbitrary named classes s... sm and a sswap:object node of arbitrary named classes o... oo, the discovery server returns all known resources that satisfy membership in the class{∩: r... rn} with subjects that satisfy membership in any superclass of {∩:s... sm} and objects that satisfy membership in the class {∩:o... oo}. as is standard, a class is always a trivial subclass of itself. thus the returned resources would be 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 the discovery server response graph sent back to the querying client returns the taxonomylookupservice as satisfying the request. the service returns data of type ncbitaxa:taxonomyrecord which is a subclass of the requested taxa:taxa in figure in practice, transaction-time reasoning on graphs to compute subconcepts is expensive and algorithms are still in their infancy. thus sswap satisfies mostly subsumption support on named, explicit classes already established in the kb. service invocation by sswap convention, posting a graph to a resource is interpreted as a request to invoke the service. once a client has a service's uri, the client can post the service's rdg back to the service with input data typed as the sswap:subject. the client always knows the service's interface because the rdg is a logical description of the service's transformation available to anyone with a simple http get on the same uri used for invocation. in figure the client replaces the null string value of the predicate taxa:commonname with the look up key "barrel medic" and posts the graph to the taxonomylookupservice. in all cases, the client will either instantiate the sswap:subject with a resource that is used as the "input data", or will fill in predicate value directly in the graph. service completion 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 the service completes the mapping of the string "barrel medic" to the resource. in this case, the url is itself a reference to lexical "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. 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 for sswap:resources which allow resources to identify uris that should handle the resources' human readable input and output interfaces. 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. the canonical graph structures a process for semantic negotiation between client and provider, which is essentially brokered by using shared, third-party ontological terms, the meaning of which are available at transaction time. the document-centric, serialization of a logic 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.  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, 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 reasoner over straight http. 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 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 the description frames the query frames the answer. this model is in stark contrast to most existing models where technologies used for resource description, discovery, querying, invocation, and response may share little in common. 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. 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: i) "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 as broadly as possible, and return output 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: 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. 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 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. 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 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. for use in semantic web services, ideally ontologies would be constructed with an emphasis on properties instead of deep subsumption relations. thus the emphasis should be on shallow subsumption ontologies rich in properties, versus deep subsumption hierarchies built axiomatically on rdfs:subclassof assertions. this approach provides an opportunity to shift subsumption determination from creation time to closer to transaction time, and thereby enhances ontologies' flexibility for addressing suitability-for-purpose. this is expected to increase the likelihood of term reuse by third-parties outside of the original context, and makes it more likely that independently produced ontologies will retain global consistency after aggregation. we have investigated the use formal concept analysis to build just-in-time ontologies. virtual plant information network we are deploying sswap as the underlying semantic technology for the virtual plant information network. the vpin consists of semantic web services offered by gramene, soybase, the legume information system, and over database and web server entry points from nucleic acids research. 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. 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. 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. soybase, is the usda-ars public repository for community contributed and professionally curated genetic and genomic data for the soybean glycine max merr as part of the comparative genomics activity in the legume information system 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 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 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 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. 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. the legume information system has developed sswap semantic web services in collaboration with gramene and soybase. first generation services provide an entry point to the legume information network, 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 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. 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.  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 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 sswap:inputuri and sswap:outputuri provides a natural mechanism to segregate data and content from presentation layers. 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. 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. we view these limitations as "growing pains" on a path towards web integration that offers to transcend many of the limitations that currently limit integration. some limitations, such as a relative unfamiliarity with owl in the bioinformatic community or the lack of suitable developer tools are addressable. other limitations, such as advances in just-in-time or incremental reasoning will require new advances in computer science. availability and requirements project name: sswap project home page:; source code deposited at operating system: platform independent; implemented on unix programming languages: java, owl, html, jsp requirements for provider development kit: java or higher, ant or higher, tomcat or higher, jena or higher. hosting an independent discovery server also requires pellet or higher and a database backend such as postgresql. protégé or higher is useful for developing ontologies. license: minor variant on mit license; see lib/license.txt on main svn trunk at. any restrictions to use by non-academics: none beyond general licensing terms; see license for details. list of abbreviations dl: description logic; kb: knowledge base; lis: legume information system; owl: web ontology language; qtl: quantitative trait locus; rdf: resource description framework; rdfs: rdf schema; rdg: resource description graph; rig: resource invocation graph; rqg: resource query graph; rrg: resource response graph; soap: simple object access protocol; 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. authors' contributions 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. 
sswap addresses the three basic requirements of a semantic web services architecture 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. as an architecture, sswap establishes how clients, providers, and discovery servers 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. as an open source platform, a discovery server running at uses the description logic reasoner pellet to integrate semantic resources. 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 was developed as a hybrid semantic web services technology to overcome limitations found in both pure web service technologies and pure semantic web technologies. the platform hosts an interactive guide to the protocol at, developer tools at, and a portal to third-party ontologies at.
 sswap 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.  there are currently over resources published in sswap. approximately two dozen are custom-written services for qtl and mapping data for legumes and grasses. the remaining are wrappers to nucleic acids research database and web server entries. as an architecture, sswap establishes how clients, providers, and discovery servers 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 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.  sswap addresses the three basic requirements of a semantic web services architecture 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. 