A Position statement on IRS-III: A Comprehensive Approach to Creating and Using Semantic Web Services
John Domingue, Liliana Cabral, Stefania Galizia, and Enrico Motta
Knowledge Media Institute, The Open University,
Milton Keynes, MK7 6AA, UK
{j.b.domingue, l.s.cabral, s.galizia, e.motta}@open.ac.uk
http://kmi.open.ac.uk/
Creating
software applications requires time and effort from skilled IT
specialists. Even when long standing software engineering practices are
followed more often than not there will exist a gulf of execution
[Norman, 1988] between the intentions and desires of users and the
functionalities afforded by the developed software system. Over the
past eight years we have been investigating how to alleviate the above
problem through the use of intelligent brokers [Benjamins et al.,
1998]. Our overall vision is that through the use of knowledge level
descriptions our brokers will be able to automatically configure
applications on-the-fly from components available over the internet to
support a given user’s task.
Our
early work led to the creation of the UPML framework [Fensel et al.,
1999] which prescribed an epistemology for a library of reusable
knowledge level components founded on tasks, problem solving methods
and domain models. We then created the first version of the IRS
[Crubezy et al., 2002]. The overall design goals for the IRS were two
fold. Firstly, during the development phase the IRS enabled components
to be combined easily through the use of a) a clear process model; b)
semi-automated support for creating bridges between components; and c)
an easy-to-use interface. Secondly, during execution the IRS acts as a
broker between users/clients who have goals that are to be achieved and
executable components available over the internet which provide
functionalities.
The
overall design of the most recent version of the IRS, IRS-III was
driven by the fact that we wished to be compatible with emerging web
service standards. At the ontological level we elected not to try and
adapt the UPML framework but instead adopt and extend WSMO [Roman et
al., 2005]. We had two main reasons for adopting WSMO. Firstly, WSMO is
based on WSMF [Fensel and Bussler, 2002] which is itself partly
descendent from UPML, thus, there was an existing strong relationship
between the two frameworks. Secondly, the underlying epistemology of
WSMO is based on web services, whereas UPML is based on an idealised
conceptualisation of reusable knowledge intensive systems. At the
implementation level IRS-III utilises web service protocols such as
SOAP and is interoperable with standard web service technologies.
In
this paper we focus on the design principles underlying IRS-III,
gleaned from our deployment experiences, the IRS-III ontology and
architecture. More details on IRS-III can be found in [Domingue, et.
al, 2004] and [Galizia and Domingue, 2004].
Since
2002 we have been involved in a process of deploying the system for use
with partners in collaborative projects such as the EU funded DIP
project (see dip.semanticweb.org), the UK funded Advanced Knowledge Technologies (AKT) project (see www.aktors.org) and the MIAKT EScience project (see www.aktors.org/miakt/).
Additionally, since 2003 we have used the IRS within an educational
setting as part of the OntoWeb and KnowledgeWeb summer schools (see babage.dia.fi.upm.es/sssw05/)
and as part of a hands on session within tutorials presented at the
AIMSA and NetObjectDays and ISWC tutorials. In total IRS has been used
to educate 150 students and conference attendees into the area of
semantic web services.
The initial vision of an
intelligent broker and the feedback we have received from our users
have enabled us to generate a generic set of design principles for
systems which aim to support the creation and use of semantic web
services. We outline these below.
The starting point for our design is that web services are invoked by clients.
A client may be a human end user invoking a web service for personal
use, an employee of an organisation or a software program. In each case
the client will exist in its own context which should be modelled
within the semantic descriptions. This context will be quite different
from that of the web service. For example, a personal end user may
request a holiday with a preference for a certain climate, a location
near particular cultural artefacts and amenable to children of a
specific age range. The required flights and hotel booking web services
will be described using concepts such as city and available date. Our
view is that distinct ontological structures are required to describe
potential users and web services. Moreover, within the IRS the
independence between user desires and ontology means that we can
specify user desire which may not in principle be satisfiable, even in
principle, by a web service – for example “I want to be the UK Prime
Minister”. Ontological role separation is also a principle which
underlies WSMO [Feier, 2004].
Building
on the principle above we enable clients (human users or application
programs) to invoke a web service simply by specifying a concrete
desired capability. The IRS acts as a broker finding, composing and
invoking appropriate web services in order to fulfil the request.
Implementing this principle relies on the fact that the semantic
descriptions with the IRS are operational.
We
have designed the IRS interfaces so that much of the complexity
surrounding the creation of SWS based applications is hidden. For
example, the IRS-III browser hides some of the complexity of underling
ontology by bundling up related class definitions into a single tabbed
dialog window.
A
corollary of the above design principle. We have many users who have an
existing system which they would like to be made available but have no
knowledge of the tools and processes involved in turning a stand alone
program into a web service. We therefore created the IRS so that it
supports ‘one click’ publishing of stand alone code written a standard
programming language (currently we support Java and Lisp) and of
applications available through a standard web browser.
This
principle is in part a consequent of the one-click-publishing
principle. Within the design of the IRS we make no strong assumptions
about the underlying service implementation platform. We do however
accept the current dominance of the web services stack of standards and
consequently program components which are published through the IRS
also appear as standard web services with a SOAP based end-point.
When
manipulating web services, whether manually or automatically, one needs
to be able to reason about their status. Often this information needs
to be computed on-the-fly in a fashion which integrates the results
smoothly with the internal reasoning. To support this we allow
functions and relations to be defined which make extra-logical calls to
external systems – for example, invoking a web service. Although, this
design principle has a negative effect on the ability to make
statements about the formal correctness of resulting semantic
descriptions, it is necessary because our domain of discourse includes
the status of web services. For example, a user may request to exchange
currencies using “today’s best rate”. If our representation environment
allows us to encode a current-currency-rate relation which makes an
external call to an appropriate web service then this will not only
make life easier for the SWS developer but the resulting descriptions
will be more readable.
Our
aim is to make IRS-III as open as possible. The IRS-III clients are
based on Java APIs which are publicly accessible. More significantly,
components of the IRS-III server are semantic web services represented
within the IRS-III framework. This feature allows our users to replace
the main parts of the IRS broker with their own web services to suit
their own particular needs.
Our
view is that any data which can be represented is. This principle also
holds for other SWS frameworks. For example, OWL-S [OWL-S, 2002] has a
grounding and non functional properties. Nevertheless, we believe that
this dimension is important enough to stress. It is not possible a
priori to know which specific data will be required for SWS related
reasoning.
In
many parts of the life cycle of any software system it is important
that the developers are able to understand the design and behaviour of
the software being constructed. This is also true for SWS applications.
This principle is concerned with making the semantic descriptions
accessible in a human readable form. The descriptions could be within a
plain text editor or within a purpose built browsing or editing
environment. The key is that the content and form are easily
understandable by SWS application builders.
One
of the main aims for web services is to enable the interoperability of
programs over the internet. A reasonable extension of this is that as
far as possible SWS frameworks and platforms also should be
interoperable. For this reason IRS-III has an OWL-S import mechanism
[Hakimpour et al., 2004] and is interoperable with the WSMO reference
implementation WSMX (see www.wsmx.org).
The
IRS-III ontology is currently based on WSMO standard v 1.0 [Roman et
al., 2004] with a number differences mainly derived from the fact
that in IRS-III we aim to support capability driven web service
invocation. To achieve this we require that goals and web services have
input and output roles. In addition to the semantic type we also store
the soap binding for input and output roles. Consequently a goal in
IRS-III has the following extra slots: has-input-role, has-output-role, has-input-role-soap-binding and has-output-role-soap-binding.
Note that in WSMO v 1.1 goal definitions now refer to a requested
capability (of a potential web service) where the variables used with pre and post conditions, assumptions and affects are explicitly declared.
Goals are linked to web services via mediators. More specifically, the wg-mediators (wg-mediators in WSMO link goals and web services) found in the used-mediator
slot of a web service’s capability. If a mediator associated with a
capability has a goal as a source, then the associated web service is
considered to be linked to the goal.
Web
services which are linked to goals ‘inherit’ the goal’s input and
output roles. This means that input role definitions within a web
service are used to either add extra input roles or to change an input
role type.
When a goal is invoked the IRS broker creates a set of possible contender web services using the wg-mediators.
A specific web service is then selected using an applicability function
within the assumption slot of the web service’s associated capability.
As mentioned earlier the wg-mediators are used to transform between the goal and web service input and output types during invocation.
In
WSMO the mediation service slot of a mediator may point to a goal that
declaratively describes the mapping. Goals in a mediation service
context play a slightly different role in IRS-III. Rather than
describing a mapping goals are considered to have associated web
services and are therefore simply invoked.
The
IRS-III architecture is composed by the main following components: the
IRS-III Server, the IRS-III Publisher, IRS-III Editors and the IRS-III
Client, which communicate through a SOAP-based protocol, as shown in
figure 1.
Fig. 1. The IRS-III Server Architecture
The
IRS-III Server is based on an HTTP server written in lisp [Riva and
Ramoni, 1996] which has been extended with a SOAP [SOAP, 2003] handler.
Separate modules handle soap based requests from the browser, the
publishing platforms and the invocation client. Messages result in a
combination of queries to or changes within the entities stored within
the WSMO library.
The
IRS-III Browser and Editors provide simple interfaces enabling the
creation and editing of WSMO based descriptions. The Browser provides
multiple visualizations of the semantic descriptions which can be
navigated by direct manipulation. The Editor combines related WSMO
components into single multiple tabbed windows. For example, a web
service window will contain the associated interface, capability,
choreography and orchestration definitions.
Publishing
with IRS-III entails associating a deployed web service with a WSMO web
service description. When a web service is published in IRS-III all of
the information necessary to call the service, the host, port and path
are stored within a publisher-information class associated with the web
service’s interface. Additionally, updates are made to the appropriate
publishing platform. IRS-III contains publishing platforms to support
the publishing of standalone Java and Lisp code and of web services.
Web applications (HTTP GET requests) are handled internally by the
IRS-III server.
As mentioned above a key design feature of IRS-III is that web service invocation is capability driven. The IRS-III Client supports this
by providing a goal-centric invocation mechanism. An IRS-III user
simply asks for a goal to be solved and the IRS-III broker locates an
appropriate web service semantic description and then invokes the
underlying deployed web service.
IRS-III is a
framework and implemented infrastructure which allows semantic web
service based applications to be created and used. The main features of
IRS-III are:
As
we mentioned earlier we are deploying IRS-III in a number of projects.
Our current target domains include eGoverment, semantically
enhanced graphical information systems and eLearning. The browser,
publisher and Java API for IRS-III can be downloaded from
http://kmi.open.ac.uk/projects/irs/.
This work is supported by the EU IST project DIP (FP6 - 507483) and the UK EPSRC funded project AKT (GR/N15764/01).
Benjamins,
V. R., Plaza, E., Motta, E., Fensel, D., Studer, R., Wielinga, B.,
Schreiber, G. and Zdrahal, Z. (1998) An Intelligent Brokering Service
for Knowledge-Component Reuse on the World-Wide-Web. In Proceedings of
the 11th Workshop on Knowledge Acquisition, Modeling and Management (KAW 98). Banff, Canada.
Crubezy,
M., Motta, E., Lu, W. and Musen, M. (2002). Configuring Online
Problem-Solving Resources with the Internet Reasoning Service. IEEE
Intelligent Systems 2002.
Domingue,
J., Cabral, L., Hakimpour, H., Sell, D., and Motta, E. (2004). IRS-III:
A Platform and Infrastructure for Creating WSMO-based Semantic Web
Services. Proceedings of the Workshop on WSMO Implementations (WIW
2004) Frankfurt, Germany, September 29-30, 2004, CEUR Workshop
Proceedings, ISSN 1613-0073 (Available at http://CEUR-WS.org/Vol-113/paper3.pdf).
Feier, C (Ed.) (2004) WSMO Primer, WSMO Deliverable D3.1, DERI Working Draft, 2004.
Fensel, D., Benjamins, V. R., Motta, E. and Wielinga,
B (1999) UPML: A Framework for knowledge system reuse. Proceedings of
the International Joint Conference on AI (IJCAI-99), Stockholm, Sweden
Fensel, D. and Bussler, C. (2002) The Web
Service Modeling Framework WSMF. Electronic Commerce Research and
Applications 1(2): 113-137.
Galizia, S. and
Domingue, J. (2004) Towards a Choreography for IRS-III. Proceedings of
the Workshop on WSMO Implementations (WIW 2004) Frankfurt, Germany,
September 29-30, 2004, CEUR Workshop Proceedings, ISSN 1613-0073.
(Available at http://CEUR-WS.org/Vol-113/paper7.pdf).
Hakimpour,
F., Domingue, J., Motta, E., Cabral, L. and Lei, Y. (2004) Integration
of OWL-S into IRS-III, Proceedings of the first AKT Workshop on
Semantic Web Services.
Norman, D A. (1988): The Design of Everyday Things. New York, Doubleday
OWL-S
(2002) Web Service Description for the Semantic Web. In the Proceedings
of The First International Semantic Web Conf. (ISWC), Sardinia (Italy)
2002.
Riva, A. and Ramoni, M. (1996) LispWeb: a
Specialised HTTP Server for Distributed AI Applications. Computer
Networks and ISDN Systems, 28, 7-11, 953-961.
Roman, D.; Lausen, H.; Keller, U. (2004)
The Web Service Modeling Ontology WSMO, Final Version 1.0. WSMO Final
Draft D2, 2004. (Available at http://www.wsmo.org/2004/d2/v1.0/).
Roman, D.; Lausen, H.; Keller, U. (2005)
The Web Service Modeling Ontology WSMO, Final Version 1.1. WSMO Final
Draft D2, 2005. (Available at http://www.wsmo.org/TR/d2/v1.1/).
SOAP (2003) SOAP Version 1.2 Part 0: Primer. (available at http://www.w3.org/TR/soap12-part0/).
