Above are links to specific code examples for Synchronous and Asynchronous services, as well as a general discussion of what considerations to have in-mind when designing input and output OWL Classes or SADI. The following is a brief summary of the SADI framework. For complete information, see Mark D Wilkinson, Benjamin Vandervalk, and Luke McCarthy, “SADI Semantic Web Services – ‘cause you can’t always GET what you want!”, presented at Semantic Web Services in Practice, Singapore, 2009. (or watch the presentation on SlideShare.)
Conventions and Best Practices
SADI does not define new standards or technologies, it simply defines a set of standards-compliant best practices that dramatically enhance interoperability between informatics resources and the ability of end-users to discover and access the right resource at the right time. The key conventions proposed by SADI are:
- SADI Services consume and provide data via simple HTTP POST and GET.
- SADI Services consume and produce data in RDF format. This allows SADI Services to exploit existing OWL reasoners and SPARQL query engines to enhance interoperability between Services and the interpretation of the data being passed between them.
- Service interfaces (i.e., Inputs and Outputs) are defined in terms of OWL-DL classes; the property restrictions on these OWL classes define what specific data elements are required by the Service and what data will be provided by the Service, respectively.
- Input RDF data - data that is compliant with the Input OWL Class - is “decorated” or “annotated” by the service provider to include new properties. These properties will (of course) be a function of the lookup/analytical operations performed by the Web Service.
- Importantly, discovery of SADI Services can include searches for the properties the user wants to add to their data. This contrasts with other Semantic Web Service standards which attempt only to define the computational process by which input data is analysed, rather than the properties that process generates between the input and output data. This is KEY to the semantic behaviours of SADI.
- SADI Web Services are stateless and atomic.
Where/When Should SADI be used?
As with any Web Services framework, SADI can expose any source of dynamically-generated information. In most cases this means Web-based analytical algorithms, but any source of data would be applicable - including robots, or even distributed human curators. Because SADI Services are stateless and atomic, Web Services that expose a set of stateful object methods cannot easily be exposed as SADI Services (though in many cases these services could be re-written to follow SADI conventions, and take advantage of the added semantic behaviours). Our observations suggest, however, that almost all services currently available in the bioinformatics space have a SADI-like behaviour that easily maps onto the SADI conventions.
SADI can be used to expose databases (both traditional relational databases as well as the newer triple-stores) as discoverable Semantic Web Services. When viewed this way, SADI is a source of individual “cells” (in a traditional database) or of individual triples (in a triplestore). This may sound odd - why would you want to provide access on a cell-by-cell or triple-by-triple basis when you could more efficiently simply expose the query interface (SQL or SPARQL) on the Web? The short answer is that, historically, few data providers have ever exposed their database for external queries - they almost always utilize some form of limited query interface. The reason for this is obvious - the service provider is protected from potentially crippling erroneous or malicious queries. Though current trends have led to data providers exposing their triple-stores on the Web as SPARQL endpoints, we believe that the same barriers will eventually apply, and that open query interfaces will not be widely available.Using SADI Services, you have the ability to:
- distribute incoming queries over your compute resources (e.g. your farm)
- prevent malicious queries, since queries for individual triples cannot be nonsensical
- implement fine-grained security policies where certain parts of your database (triple/cells) are only available to certain requesters.
We are in the process of creating a simple tool that will instantly transform your existing triple-store as a set of SADI services, and hope to create a similar wrapper for traditional relational databases.
Come to the SADI training course in Fredericton, New Brunswick, on May 19-20th, 2011.