| Challenge | Discover | Learn | Connect |
Semantic Web Architecture 2
iPlant's Semantic Web Architecture is based on the concept of single, mutable document that traverses the web.
The document has a universal syntax (RDF/XML, as recommended by the W3C), a formal semantic (OWL, as recommended by the W3C), and a canonical, immutable protocol (SSWAP, our contribution bringing OWL to semantic web services).
iPlant Semantic Web Services Architecture 2
This single, mutable document is called a Resource Graph. It's a graph, because it is RDF (Resource Description Framework) (constrained by the semantics of OWL), and thus adheres to the basic RDF structure of a Subject -> Predicate -> Object (for an introduction, see the W3C's RDF Primer). Data and service Providers map their idiosyncratic data schemas and offerings into publicly accessible ontologies in the graph. This mapping is presented on the web as a Resource Graph called a Resource Description Graph, or RDG. You can see anyone's RDG by simply visiting it with your browser (an action called a HTTP GET). There's nothing hidden, nothing under the covers (this is technically called a RESTful interface). RDG's present an offering to the world in the formal semantic and computable logic of OWL DL. These RDG's tend to be surprisingly short. You can see many by visiting http://sswap.info, typing in a search word, and then clicking on the RDF icon 
next to any discovered service. (One may note, that even though RDG's are short and tight, they are rich with information. As part of a service's publishing process, RDGs are sent through a reasoner. The process dereferences cascading layers of hyperlinks and terms and reasons over them. It is not uncommon for a 10 line RDG to be expounded into a 1000 line graph of "necessarily implied truths"--all done automatically and without user intervention. It is by this "publishing" process that our Discovery Server knows about semantic web resources so as to be able to answer search queries). Resources--services--claim ownership by a Provider (an institution, or web host) by pointing to a Provider Description Graph, or PDG. PDGs are very simple and allow a single provider to offer a unlimited number of discrete semantic web services (RDGs).
All Resource Graphs follow the Protocol. How can an arbitrary client read an RDG and "know" what's being expressed? They can do this, because all Resource Graphs follow the Protocol. The Protocol establishes a basic, universal and agnostic framework upon which description, querying (discovery), invocation, and response all rest. The Protocol follows the SSWAP Protocol as:
iPlant Semantic Web Services Protocol
Web resources used RDGs to describe themselves to the world, and to describe their mapping of input data (Subject) to output data (Object). The data can be embedded in the graph or be located at a URL (a hyperlink). Graph nodes can have properties so that resources can express input parameters and output values; indeed the data nodes can be arbitrary OWL subgraphs describing simple--or complex--relations. We provide two APIs (Application Programming Interfaces) to aid developers in this process (HTTP API and Java API).
Get the Quick on SSWAP on Wikipedia
RDGs are the basis of an entire work flow of interactions. Clients (consumers of data and services) construct Resource Invocation Graphs, or RIGs, based almost entirely on RDGs; it's easy: simply take the RDG and add the data that you are using to invoke the service. You know exactly where to add it (to the Resource or the Subject), and the service knows exactly how to read it, because everyone is following the same protocol, using the same syntax, under the same formal semantics. The real power of semantics comes in enabling actors to interpret the domain-specific parts of the data description (those parts that are not part of the protocol, but reflect the actual data at hand, such as a gene or a ID number. More on this below). Don't know where on the web to get the RDG that you want (who is offering service X, or accepts data Y, or returns data Z?): clients can create a Resource Query Graph, or RQG, and send it to our semantic Discovery Server. RQGs are also virtually identical to RDGs, but with a different interpretation: they do not describe a resource, they describe a desired match or set, of resources. The Discovery Server returns all resources that match the query.Two points of note: 1) traditionally, it is uncommon that the same protocol is used to both describe a resource and query for any resource, but this is exactly how RDGs and RQGs interact. This adds a "universality" to description and discovery: the way you describe yourself is they way you will be discovered; 2) because RQGs resemble RDGs so closely, they enable semantic searching, described in the next paragraph. Once you have queried and chosen your service to invoke, clients send the service their RIG. The response? It comes back in the same syntax, following the same formal semantics and logic, following the same protocol in a Resource Response Graph, or RRG. For further details, please see Gessler et. al 2009.
Semantic Searching "guarantees" suitability-for-purpose and enables web-based pipelining. How does an RQG enable semantic searching? It enables it by allowing the Discovery Server to return to the user only those services that match the semantics of the query graph with the semantics of resource offerings. Matching means all RDGs in our Knowledge Base that satisfy all three of the following conditions:
- have a Resource that is a subClass of the query's Resource, and
- have a Subject that is a superClass of the query's Subject, and
- and have an Object that is a subClass of the query's Object.
Examples help.If you are searching for a Pizza restaurant, you want your search engine to return for you the subClasses, or specializations, of Italian Pizza and New York Pizza, but not the more general Restaurant class; i.e., you want what you are searching for, or something subsumed, and conceptually contained within. What is true for Pizza restaurants is also true for biological services, such as the Nucleic Acids Research Database and Webserver category trees. For the input data (the Subject), the opposite is true. Here, we have some type of data, so services that can operate on it necessarily are those that also operate on its superclasses (more general). Services that require something more specific require a data that perhaps we do not have, so we do not want these returned. For output data (the Object), we are back to subClasses again: find me services that return the type of data I want, or data that may be even more annotated or have more properties. More information is at our research Graph Search page and on Wikipedia.
Public, shared, ontologies becomes a lingua franca, but only under a formal, computable semantic. The iPlant Semantic Web Protocol does not describe your data, but it does enable you to do so. The architecture, protocol, and technology allows you to use and reuse biological ontologies or your own ontologies. On the web, large, monolithic ontologies are conceptually OK, but practically the web demands that we be able to access terms and concepts separately (just as you want to be able to access a web page, and not have to download an entire web site in order to see a page). We have developed helper tools to help developers convert large, monolithic ontologies into formats suitable for semantic web services (see the research Developers' Page). This opens a wide and important new "marketplace" for legacy ontologies: to be used as the semantic glue and currency-of-trade in web services. But just terms are not enough. Arbitrary extension leads to confusion and silo-ing, not integration. One wants a manner that one can extend and reuse the work of others without breaking the original author's intent. Combining separately dereferencable terms and the formal semantics of OWL allows us to do just that. Thus anyone can put an ontology on the web--an ontology of one term or a million terms; and anyone can extend it in a manner computable by others, because all extensions follow a formal, shared semantic. We have refactored a number of important biological ontologies, as well as "filled-in-the-gaps" by creating a few of our own, available at the research "swap meet": http://sswapmeet.sswap.info.