Semantic Web JAVA API

The Java API (Application Programming Interface) is a full-featured API that allows data and service providers to host iPlant Semantic Web Services; it allows them to invoke services and be invoked, and respond to invocations.

Who uses the Java API? Data and service providers who want to offer semantic web services. The API also includes preliminary client support (users of semantic web services).Full-featured client support will arrive in 2011.

Why Java?  W3C semantic web standards are RDF, RDFS, XSD, and OWL serialized as RDF/XML, with SPARQL for transaction querying. While theoretically any computer language could be used to manipulate these languages within the process space, legacy work is heavily coded in Java. We use the Open Source Hewlett-Packard Semantic Web Framework Jena for low level RDF data modeling and the Open Source Clark and Parsia Empire for Java Persistence. In all, the API is over 20,000 lines of source code (whitespace and comments included) and 80 various libraries. But for the developer-user of this API, the vast majority of this is hidden with a high-level API of less than 50 classes.

Let me see it quickly, so I can judge  Here it is. The Javadocs are separated into three components:

• Java API developer docs: for reference, you only need these.
  Usage is almost entirely through interfaces, complemented with a convenient centralized factory to create top level objects. Easy. To get the Java byte-code to link in, see the download notice below.
• How it is implemented. This is the back-end support; you do not ever need to reference or learn this, but for the curious here it is:
  • Java API Implementation
  • HTTP API Implementation

You can download everything as a SDK (Software Developement Kit), which includes the ability to host your own HTTP API. To download, please visit the Sourceforge distribution directory for the latest release.

How do I get started?  iPlant Semantic Web Services are built upon the technology of SSWAP: Simple Semantic Web Architecture and Protocol. It is useful to read the Overview and the Architecture pages (1 and 2) to get a high level of how semantic web services are done. If you want to see how this works in peer-review, you can ref the paper. The model is that you will be writing a servlet to handle requests for your semantic web service. To do this, run a servlet container such as Apache Tomcat. Then it is a three step process: 

1. extend the class AbstractSSWAPServlet and override the method handleRequest() to do steps 2 and 3
2. use the API to extract the data being sent to you and process it according to your service
3. use the API to bundle your response data and return it

The method handleRequest() automatically translates for you incoming terms from one (or more) ontologies into the terms you understand as
published by your own RDG (Resource Description Graph). For example, consider that you publish a service saying it accepts a property called accessionID with a default value of 3.  Then, somewhere on the web, someone -- unknown to you -- introduces a new myAccessionID as a subPropertyOf accessionID.  Your service can, and should, work with this property; but how could it know? When your service is invoked with myAccessionID = 5, the API's semantic machinery will reason the subPropertyOf relation and present you with the input that accessionID
= 5. This is done transparent to you, and done by dereferencing terms on the web and reasoning at transaction time. This is a key to distributed data and service integration, because it means that services can operate on data based on the data's semantics, and are not constrained to token matching (i.e., "I cannot operate on myAccessionID = 5 because I do not recognize it"). While the accessionID/myAccessionID example is simple, the machinery is set up to do the same semantic matching and translation even for complex types (classes) and properties -- such as taxonomic names, biological data types, etc.. The full value of this will be realized over the coming year as we use this to enable pipelining from one service to another based on the semantic relations
of the data, not on what they are named. For that capability, semantics becomes a requisite for large-scale distributed integration.

The API has a single SSWAP factory class to create high level objects. The flow of control mimics the workflow of semantic web services: the API "knows" about the various graphs (PDGs, RDGs, RQGs, RIGs, and RRGs) and offers methods to allow one to mutate from one graph to another as evident in the architectural model.

How can I learn more? We will be developing specific iPlant Semantic Web Services using the API and releasing that code open source. We will also be hosting a developer conference in June 2011. Contact Dr. Damian Gessler at dgessler at iplantcollaborative dot org
for details.

Can you make this easier?Yes. We are always working to make it easier. Below is the current technology stack: we hit every level. We are working tirelessly to make semantic web services a reality and as easy as drag-n-drop.  Drag-n-drop is still some time away, but we're working ....

Technology Stack