Functional Units: Abstractions for Web Service
Annotations
Paolo Missier1, Katy Wolstencroft2, Franck Tanoh3, Peter Li4, Sean Bechhofer5, Khalid Belhajjame6, Carole Goble7
School of Computer Science, University of Manchester
Oxford rd, Manchester, UK
1pmissier@cs.man.ac.uk 2kwolstencroft@cs.man.ac.uk 3ytanoh@cs.man.ac.uk 4peter.li@manchester.ac.uk
5sean.bechhofer@manchester.ac.uk 6khalidb@cs.man.ac.uk 7carole.goble@manchester.ac.uk
Abstract—Computational and data-intensive science increas-
ingly depends on a large Web Service infrastructure, as services
that provide a broad array of functionality can be composed
into workflows to address complex research questions. In this
context, the goal of service registries is to offer accurate search
and discovery functions to scientists. Their effectiveness, however,
depends not only on the model chosen to annotate the services,
but also on the level of abstraction chosen for the annotations.
The work presented in this paper stems from the observation
that current annotation models force users to think in terms
of service interfaces, rather than of high-level functionality,
thus reducing their effectiveness. To alleviate this problem,we
introduce Functional Units (FU) as the elementary units of
information used to describe a service. Using popular examples
of services for the Life Sciences, we define FUs as configurations
and compositions of underlying service operations, and show how
functional-style service annotations can be easily realised using
the OWL semantic Web language. Finally, we suggest techniques
for automating the service annotations process, by analysing
collections of workflows that use those services.
I. INTRODUCTION
The popularity of Web Services for e-science applications is
not without its problems, as scientists find themselves explor-
ing a large space of available and potentially useful services,
with only a limited understanding of the functions they offer.
Part of the problem is that, despite a wealth of research over
the past few years, service annotations still reflect a interface-
oriented view, rather than a functional view of the service.
This is a central problem for large registries of services, and for
Biocatalogue in particular. Launched in 2009, the Biocatalogue
registry1 caters primarily to the bioinformatics and biomedical
community. Building upon previous work on service registries
and semantic annotation from the myGrid project2 and the
Embrace registry3, Biocatalogue positions itself as a high-
quality, annotation-rich clearinghouse for domain-specific ser-
vice descriptions on a large scale (hundreds or thousands of
services). Its primary goal is to provide descriptions of services
that can be used both for accurate search and discovery, and
to support the process of composing service invocations as
part of larger workflows. The project is now at a critical
1http://www.biocatalogue.org
2http://www.mygrid.org.uk/
3http://www.embraceregistry.net/
juncture, where the choice of annotation model may determine
its adoption by the Life Sciences community.
A variety of conceptual models have been proposed over
the years for service annotation. These include SAWSDL4,
a W3C recommendation containing syntactic conventions for
augmenting a WSDL interface specification with semantic
annotations; OWL-S [8]5, and WSMO6, amongst others. While
these are potentially viable annotation models, they are all
based on the common implicit assumption that the two core
tasks mentioned earlier are best served by annotating services
at the level of their individual operations, and of the data types
of the operations’ messages.
The OWL-S model, for example, includes three perspectives
on a service, namely its profile (what the service does), its
model (how it works), and its grounding (how to access the
service). Focusing on the profile, consider for example the
DDBJ database7. Its Blast service can be annotated to spec-
ify that the operation searchSimple accepts a biological
sequence as input, as follows:
<profile:serviceOperation>
<operation:name> searchSimple</operation:name>
<process:input id resource=”#biological sequence” />
</profile:serviceOperation>
In this example, the annotation makes a reference to the
biological sequence concepts in the myGrid ontol-
ogy [15] (with namespace omitted).
The WSMO annotation model [10], [3], along with its
WSMO-Lite counterpart [14], adds expressivity to annotations
by accounting for functional descriptions. These are repre-
sented as capabilities, which define pre- and post-conditions
that must hold before and after the invocation of a service’s
operation, or as functionality classications that define the
service functionality using some classication ontology.
While these models abound in expressivity, their main
shortcoming is that they apply rigidly either to the entire
service, or to its individual operations, following the under-
lying WSDL-based structure of service description (a second
shortcoming is that they do not apply at all to REST-style
4http://www.w3.org/2002/ws/sawsdl/
5http://www.w3.org/Submission/OWL-S/
6http://www.w3.org/Submission/WSMO/
7http://www.ddbj.nig.ac.jp/