Details of a semantic annotation are outlined, both for the semantic model consisting of concepts to model the area of discourse as well as the individual model for a single service. The annotation is used to build a concrete implementation of a generic processing framework translating the annotation of a service into rules to be integrated into an OWL knowledge base rule engine.
The realization is done for the Jena Semantic Web Framework, an open source library for Semantic Web application for the Java language. The realization is designed as an add-on to Jena which integrates service calls in such a way that service invocation is transparent to applications building on Jena.
A discussion on optimizations, both implemented ones and realizable but not implemented ones is included. They can serve as starting points for moving the implementation from a proof of concept status to real world usability. The section finishes with some considerations on general run-time behavior.
Finally the presented framework is evaluated in more detail: Firstly, a sophisticated scenario for the running example is described and shown, how automated service selection, composition and invocation is actually realized during run-time. Then the approach is evaluated with regard to services with more complex parameterizations with particular focus on the data supplied to the services and the rules generated from such complex parameterized services and whether such rules are still usable.
The prime design rationale of the presented framework implementation is as a proof of concept for the approach of generically integrating Web Services as rules with Semantic knowledge bases. Therefore there is still a long way to go for a real world application to be build on the framework. At several points notes are added hinting on potential challenges, particularly with regard to specific techniques for optimizing reasoning on knowledge bases. Neither are these remarks to be seen as exhaustive nor are they to be understood as short treatments. Rather they are intended as selected starting points for further research.
Contents
1. Introduction
1.1 The Task
1.2 Case Studies
1.3 Overview
1.4 Notation
2. Current approaches
2.1 OWL-S
2.2 WSDL-S
2.3 WSDF
2.4. Remarks
2.5 Open questions
3. Semantic model
3.1 General modelling decisions
3.2 The base ontologies
3.3 The instance model
3.4 The example: Service annotations
3.5 The example: Process model document
4. Processing framework
4.1 Implementation rationale
4.2 The Jena framework
4.3 Implementation overview
4.4 Implementation details
4.5 Optimizations
4.6 Runtime behavior
5. Evaluation
5.1 Commerce use case
5.2 T-Info use case
6. Conclusion
6.1 Outlook
Acknowledgment
Appendix A: InformationProcess.owl
Appendix B: StockQuote WSDL and OWL-S documents
Appendix C: T-Info service parameters
Appendix D: RouteService WSDL and OWL-S documents
Appendix E: EmergencyPharmacyService WSDL and Process document
Bibliography
1. Introduction
Every software project includes three main tasks:
1. Definition of the information needs
2. Selection and composition of resources satisfying these needs
3. Implementation of the technical details for accessing the resources
Thorough software engineering generally leads to a modular architecture in step one, allowing for decomposition of the overall problem with clear cut components to be specified in step two and a reduction in work package sizes in step three. This approach allows in particular considerable reuse of components in different applications, thus, reducing overall implementation effort to the definition of interfaces between already existing resources i.e. components.
Traditionally, individual modules are worked upon step by step, hard coding connections between the application and used resources individually.
Recently however, Service Oriented Architecture (SOA) has become widely accepted as the prevailing programming paradigm in the near future, with all of the major software vendors backing it, see Ort, [Ort], and Sprott and Wilkes, [SpWi].
With the emergence of the SOA paradigm, external resources like Web Services are seen as commodities to be accessed and used in a standardized way. Thus, it should be the goal of a web application to integrate Web Service access without any hand crafted code for individual services. Moreover, Service Oriented Architecture not only means integration of some isolated services: SOA aims at separating functionality (e.g., some data transformation) and data flow, the latter being the modelling of some real world process by the application. That is, in a similar fashion as the emergence of data bases separated data storage and processing, SOA separates data manipulation and data flow. Thus, by this paradigm, a dedicated application primarily consists of intelligent compositions of services, reducing application specific coding to a minimum.
Therefore, task two not only requires selection of individual services, rather the central task is composition of services to represent the business logic, or more generally the process flow, the application is designed to model, while task three consists of accessing individual services.
With the advent of the internet, the need for accessing resources not only within some internal computer network, but also across company and institution borders, became urgent. The solution was the introduction of standardized Web Service technologies like data formats and protocols.
The current standards defined by the World Wide Web Consortium W3C represent a hierarchy, based on XML formatted data, [XML], with data types defined in XML schemas, [XSD], and the Simple Object Access Protocol SOAP, [SOAP].
For Web Services, (see e.g. Alonso et al, [ACKM]), the Web Service Definition Language standard WSDL became widely adopted as a means to describe the technical details for accessing a service, from URL to protocol to data structures of the service parameters. In particular, the task of connecting to a service which publishes a WSDL document, can be automated, i.e., an application can connect to the service without the need of hard coding the connection details by hand: Corresponding technologies are widely implemented in commercial and open source software packages like Apache. E.g., for a Java class with some method to be offered as a Web Service, the WSDL document can be generated automatically on the server side, the document can be read by a potential consumer, and a proxy can be generated on the client side, again automatically without any service specific coding by hand.
In combination, task three is completely automated in such systems, removing a substantial amount of work from the application programmer's task list. An example for the Java language is the Apache Axis package, [Axis], which provides a complete framework for creating and invoking automatically Web Services.
With the internet gaining momentum within broad classes of the population, there is now arising the need for accessing web resources without human guidance. While one always has to tell some system, e.g., an electronic assistant, what one wants it to do, one generally does not want to tell it how it should do that – with more and more publicly accessible Web Services at hand, it is a serious bottle neck for applications to access only those services, which have been integrated into the system by hand. It would therefore be desirable to let a system integrate new Web Services automatically, e.g., Web Services newly found in some public repository like the Universal Description, Discover and Integration repository UDDI, [UDDI]. To achieve that goal means to go the next step and automate task two.
1.1 The Task
Solutions for task two, that is to automate selection and composition of services, is the vision of Semantic Web Services: Not only should some given service be accessed in a standardized way. But it should be possible for a system, given some specific task, to automatically select an appropriate service. Moreover, if necessary, a system should be able to combine services to fulfill some task which can not be achieved by a single service.
Clearly, for automatic service selection and composition, purely technical descriptions of services as contained in WSDL documents do not suffice: E.g., knowing from a service that it requires two strings and one integer parameter as input and returns an integer as output is not of much help if the system needs to find some person's telephone number – the system should not have to parse free text or names for assigning correctly the first string parameter to the given name, the second to the family name and the integer to the postal code of the person's home town, while the return parameter corresponds to the person's telephone number: although such parsing could be done by current natural language processing systems, this would be a very error prone process depending heavily on the service provider to use unambiguous names – often an impossible task due to ambiguousness of natural language. In general, the system can neither find out that this service is the one it needs to invoke, nor can it associate the right data from its data base with the service parameters.
Thus, to allow automation of Web Service selection and composition, an additional layer of semantic information has to be added on top of the technical information provided by the WSDL document: The WSDL document adds meta-data to the service on the types of connection and operations, of which messages an operation consists, of which parameters a message is build up and the data types of these parameters. This information describes the syntax for communicating with a service. On top of this information we now need meta-data describing the meaning of the messages' contents, both how the service interprets the data to be send and how to interpret the service's answer. Once a framework for processing this semantic information is available, it can use the existing technology for the technical details of service invocation described above.
The W3C committee already works on some standards for annotating web resources with semantic meta-data: Resource description is based on RDF-triples, that is triples defined in the language of the Resource Description Framework, [RDF].
Using RDF as syntax, the Resource Description Framework Schema language RDFS allows the definition of types, hierarchies of types and relations and associated simple inference. On top of RDFS, a full fledged description logics based language, the Ontology Web Language OWL, is defined, [SW], [BHS], [BCM+]. More precisely, three dialects – OWL lite, OWL DL and OWL full - of increasing expressivity but also increasing computational complexity are defined. In this thesis complexity issues are only considered when inevitable, so in the following we are talking only of OWL.
These standards are designed to define a computer readable description of the meaning of web resources. E.g., search engines can query the web with such an annotation much more focused and thus return more precise lists than by pure text searches. Semantic Web Services now use Semantic Web technologies to allow Semantic Web applications to seamlessly integrate the services. That is, an ontology describing the input and output parameters of the service interface is added, for a system to 'understand' the semantics of parameters. Moreover the semantic dependence of these parameters must be described, how the service transforms data, what actions the service performs, like charging a credit card, and how different service components must be called for communicating successfully with a service (e.g., you might first have to identify yourself before you can proceed).
There exists a range of approaches and projects for automatic Web Service selection, composition and invocation, [IRS], [MET] , [NM], [PBCMT], [WSMO] (building on [WSMF]) and several others. They mainly focus on complex service interaction as defined, e.g., in work flow tools, thus, there are two main sources of research on which they draw: logic based planning and service / process models. Consequently, proposed standards for service annotations focus on business process description, [ACD+]. An already widely used proposal for service annotation for such scenarios is OWL for Services, OWL-S, [OWL-S], which explicitly focuses on complex services as they are called by the authors of version 1.0 in [OWL-S1]. A similar scope has the alternative proposal [WSDL-S]. We will have a detailed look at these proposals in section two.
However, while work flow plays a central role in industrial software like Enterprise Resource Planning, Supply Chain Management and others, current publicly available Web Services are still far from such complex scenarios. Therefore, such systems, as discussed in the above mentioned projects, will definitely be valuable, e.g., for (semi) automated assistance in process flow design tools but there is still quite some way to go for real world applications in publicly accessible web based systems, not only due to lack of existing Web Services supporting such a scenario but also due to serious open questions concerning security, support of transactions etc.
As noted above, the current standards already in use are description logic based OWL and the data representation framework RDF it builds upon. OWL is strongly routed in logic programming traditions and consequently one of the most intensively discussed extension of OWL is by horn rules as suggested in the [SWRL] proposal. Thus, Semantic Web applications currently focus on information description and will be extended to classical logic data bases in the future.
There already exists a range of publicly accessible Web Services which simply provide information and have a simple request / response behavior, [WebX]. Also many packages provided by internet service providers focus on information, like real time stock quotes, tourist information and the like. Clearly, such services do not need the complex description as defined in OWL-S and obviously a user of some information system does not really want to distinguish between information the system can retrieve from its OWL knowledge base and information it retrieves by some service invocation.
It therefore makes sense to narrow the scope to what we will call in the following Information Providing Services, in short IPS, and try to integrate such simple services with an OWL knowledge base, thus avoiding some of the current problems the full blown approaches are struggling with.
The goal is to integrate them in such a way that not only for some end user, but also for applications building on Semantic Web data bases, Web Service selection, composition and invocation is completely transparent. In particular, the integration process itself should be completely automatic, that is once a URL pointing to some service is known, the integration does not need any further human intervention, thus, once some service registry, e.g., a semantically enhanced UDDI, is available, service interaction can be fully automated.
In order to exemplify the problem we now present two case studies, one of them also serving as running example in the subsequent sections for illustration purposes.
1.2 Case Studies
We consider two use cases:
- one consisting of two services with very simple interfaces from the commercial area,
- one consisting of two services with rather complex structured parameterization concerning traveling needs.
The first set of services will be our running example during the following sections as the referring illustrations can be kept small and easy to follow – nevertheless it will turn out that they already exemplify the problems and needs of annotation we encounter, thus also demonstrating that the problems discussed are not aberrations but occur already in rather simply structured services.
The traveling services will be used as a more sophisticated test for evaluating our approach to see how it copes with complexity in service parameterization.
Commercial services: These services are publicly available for free from the WebserviceX web site, [WebX], at http://www.webservicex.net/. They both have very simple interfaces:
illustration not visible in this excerpt
- The StockQuote service at http://www.webservicex.net/stockquote.asmx expects as input a string containing a stock ticker symbol and returns the current trading price of the corresponding stock at the New York Stock exchange.
- The CurrencyConvertor service at http://www.webservicex.net/CurrencyConvertor.asmx expects two strings with abbreviated currency names and returns their current exchange rate.
As they are both publicly available, one can easily check them out and duplicate our running examples. As all aspects of annotations are described in detail in the following, we don't want to discuss them here. The WSDL file for the StockQuote service can be found in Appendix B. Due to its simplicity there is no need for explications.
One remark on WSDL: In this section, no standardized vocabulary is used, except for concepts related to WSDL. In particular the reader is assumed to be accustomed with WSDL and the corresponding vocabulary, as described in [WSDL] and [CCMW]. Other notions are used informally, only in later sections, when we adopt standards from the Semantic Web, some will be defined more precisely.
In sections two and three, which concern annotation of services, we only need a single service for illustration purposes. We will use the StockQuote service, as it contains only a single input and a single output parameter. For the further discussion we give an informal overview on how we think about the service in terms of semantic description, in contrast to the purely syntactic description given in its WSDL file: The input is some string which can be modelled, e.g., by some instance of a class StockTickerSymbol, while the output is the current stock price of type xsd:double. It could be related to the input parameter via some relation hasPrice. However, it is clear that this relation can not simply be a data type relation with range of type xsd:double: every price consists of the currency it is related to and its numeric value. Therefore, as a semantic service it should return an instance of some class, say MonetaryValue, with some object property hasCurrency which has as range instances of some class Currency and some data type property numericalValue of type xsd:double.
In particular, now the service annotation can describe that the return value is meant in US Dollar, a fact which is not even mentioned in the WSDL file and thus can be derived only by a human programmer from the fact that the stock quotes are from the New York Stock exchange, again not mentioned in the WSDL file. Even if these facts would be mentioned in some documentation part of the WSDL file, it clearly could not be processed perfectly. Thus, we see that the semantic description generally contains elements not contained in the syntactic description of the service.
We now also see how the two services can interact: The CurrencyConvertor service gets two instances c1 and c2 of class Currency and returns a double value which can be used to convert the numericalValue of a MonetaryValue which hasCurrency c1 into the numericalValue of another MonetaryValue which hasCurrency c2 and which is related to the first one via some relation sameMonetaryValue. In section three on semantic modelling, this description will be formalized in standard notation.
T-Info services: Recent projects such as the SmartWeb project, [SmartW], included a set of services provided by Deutsche Telekom, [DTWS]. They provide a range of services centering on travel assistance as route planning, weather forecast, address finder for places like cinemas, pharmacies and the like.
As these services will constitute our evaluation test-bed, we want to have a detailed look on how the services might be used in a real world scenario.
To limit the size of the thesis, we focus on two particular services. However the reader can easily check that the other services are of the same nature and can be treated in the same way. Thus, for the following, attention is restricted to the following two services:
illustration not visible in this excerpt
- Route service at http://route.services.tinfo.com/soap/services/RouteService
- Pharmacy service at
- http://emergencypharmacy.services.tinfo.com/soap/services/EmergencyPharmacyService
The route service has a single wsdl:portType with one wsdl:operation, thus there is a single functionality provided by a single request / response round trip. It receives a list of addresses consisting of at least two elements - start and end point and possibly a list of stations in between – and a set of properties for the result:
- Whether to generate a map and if so what details should be included.
- What time reference should be used (start or end point).
- Details of the route calculation, like measure of unit, speed profile of the traveler, level of detail.
The service then returns the corresponding information, in particular a list of maneuvers describing for example where and how to change streets.
The pharmacy service has a single wsdl:portType with one operation for searching pharmacies which provides its functionality by a single request / response round trip.
It receives an address from where to start, parameters on how far to search and the date when the pharmacy is needed and returns an array of pharmacies available.
Both services can throw a ServiceException or an InvalidParameterException in case the service invocation failed due to technical reasons or to invalid parameters, respectively.
For the convenience of the reader, the service WSDL files are listed in Appendices D and E. Moreover, in Appendix C one can find a list of the complex types of the two operations including some information on how they are used by the service as published by the service provider.
Now a tourist (in the following named 'the user') with an electronic personal assistant (in the following named 'the system') might need to visit a pharmacy. To do so she needs a travel route from her current location to the pharmacy. Obviously, the travel information can be provided by the route service.
The user does not want to know the services and the likes available to her electronic assistant, therefore it is desirable to let the system invoke the service autonomously whenever the data provided by the service is needed. For this, the data has to be semantically enriched such that the system, whenever corresponding data is needed, autonomously selects the service for invocation, in our case, whenever the user requests a travel route from one point to the next.
A travel route generally consists of a travel date, a list of points which should be crossed in a certain sequence and a list of maneuvers which have to be performed to travel the route. Considering the output of our route service, this information is indeed provided.
However, there are no semantic relations between the list of maneuvers, the list of points and the date – indeed, there is no single data structure which can be assigned the label ' travel route '. Thus, we see that a semantic annotation of the service needs to model such relations between the parameters involved and the whole service output itself..
Now to invoke the service, the input parameters have to be set. Of course, they also have to be set autonomously by the system. To do so, the system has to be able to associate the corresponding data from its local sources with the required data from the service. For this, both the system's own knowledge base and the service's input parameters have to be semantically annotated for the system to match semantically fitting data.
Clearly, some information has to be given explicitly by the user, e.g., when to travel, where to travel. Such information constitutes the situational context, the user is embedded in, and generally is stored in some separate knowledge base, called pragmatic knowledge by Loos and Porzel, [LoPo].
However, which data precisely have to be set depends on the circumstances: If the user is plagued by some chronic disease, she may want to know in advance where to find a pharmacy at some specific travel date. On the other hand, during some emergency she needs to find a pharmacy right now, and the system can deduce the current date from the built in calendar and clock functionality.
From the point of view of the service, these two kinds of data (user set versus internally calculated) do not really differ: although the first kind of data has to be put into the system somehow (with a speech processing module, a text based natural language processing module or even some form based input), it must be processed by the system to be transformed into RDF-triples, as the user does not know of the service, respectively does not want to communicate directly with the service. Thus, in any case the service's parameters have to be assigned by the system on its own.
One question that arises is, what to do if the data available in the system's local database is not sufficient to assign all (necessary) parameters of the service. Of course for a dialog system there is always as a last resort to directly ask the user to fill them in.
However one of the goals of personal electronic assistant design is to reduce such requests from the system to the user to a minimum. Thus, the system might also try to fill in missing data by calling other Web Services: e.g., the user queries the system for “please give me a route to the next pharmacy”. Then the most important input parameters of the RouteInputProperties, see Appendix C, are the start and end point of the route. There may be a default rule, to use as start point the current location, which in turn can be supplied by some cell based positioning system. For the end point, the system needs to find the address of a pharmacy, which in turn is returned by the pharmacy service.
Therefore the system should be able to compose the service calls and transform their data such that the route service input parameters are completely satisfied.
To the pharmacy service the same considerations apply, e.g., for the search center again we can use the current location. Thus, we can get complete chains of data interdependence. A further example would be the invocation of the traffic service which would first require the invocation of the route service to find out which streets should be checked.
The main point to note is that the services considered are pure information sources, that is they are examples of the above mentioned IPS. In particular, no further actions are performed in the real world during invocation of these services. Thus, interdependence of services is restricted to information needs required to invoke some service.
Moreover, because the service simply provides some information, there is no ongoing communication between the service and the requester, that is there is no need for a description on how to communicate with the service beyond the need for providing the required input parameters and receiving the service response. We shall see in section two that these observations reduce the annotation needs considerably.
In particular, the description of the services only requires semantic description of information sources. Considering the idea of the Semantic Web, semantic description of these services should fit nicely to the scope of Semantic Web languages like RDFS and OWL. Moreover, seamless integration of the services with some local Semantic Web database should be possible as well as integration of information retrieval from the database and invocation of the services.
Another point is about quality of service: apart of the functional description of the service, for usage it is also important for a system to know that the service meets certain – task dependent – reliability criteria. For information providing services, two dimensions are important:
- Execution failure: this is not really critical, as a service failure during runtime can simply be modelled as absence of data, something a querying system should be able to cope with*.
- Information trust: this is of course very critical for information providing services. Depending on what the information is used for, the service must satisfy a certain degree of trust regarding the information it provides. However, in this study we will not go into details information trust, leaving it to the system which services to accept for inclusion into the framework.
1.3 Overview
This work is structured as follows: at first, in section two, three existing approaches to Semantic Web Service annotation and realization shall be considered with regard to the type of services we are considering, that is with regard to Information Providing Services.
The approaches – OWL for Services, Version 1.0, [OWL-S], WSDL for services, [WSDL-S] and the Web Service Description Framework, [WSDF] – are considered and how their design fit the task at hand:
- What is their design rationale and how can an IPS be aligned to it?
- What are their limitations and what are the consequences for an IPS?
- Which problems do these specifications have and how may they be solved for an IPS (or possibly in general)?
At the end of that section we summarize what we learned and describe the framework we use – it will be OWL-S – and how it should be modified to suit our needs.
In section three the details of semantic annotation are outlined, both for the semantic model consisting of concepts to model the area of discourse as well as the individual model for a single service. For modelling the universe of discourse we are using the WonderWeb library of foundational ontologies, [MBG+] and the Suggested Upper Merged Ontology, [SUMO]. In addition we are using concepts modelled in the SMARTSUMO ontology on top of these ontologies created within the SmartWeb project, [SmartW].
In section four, the annotation is used to build a concrete implementation of a generic processing framework translating the annotation of a service into rules to be integrated into an OWL knowledge base rule engine. The implementation is mainly intended as a proof of concept for both the annotation presented in the prior section and the overall approach of integrating Web Services as rules with some knowledge base, thus, it is not designed to be directly used in a performance sensitive real world application.
The realization is done for the Jena Semantic Web Framework, [Jena], an open source library for Semantic Web application for the Java language. The realization is designed as an add-on to Jena which integrates service calls in such a way that service invocation is transparent to applications building on Jena.
The section also includes a discussion on optimizations, both implemented ones and realizable but not implemented ones. They can serve as starting points for moving the implementation from a proof of concept status to real world usability. The section finishes with some considerations on general run-time behavior.
Section five evaluates the presented framework in more detail: First we describe a sophisticated scenario for the running example and show, how automated service selection, composition and invocation is actually realized during run-time.
We then evaluate our approach with regard to services with more complex parameterizations as it is the case with the T-Info services. We particularly have a close look at the data supplied to the services and the rules generated from such complex parameterized services and whether such rules are still usable.
We finish the study with an outlook on how the presented approach may be extended to be applicable to a wider range of services.
In appendix A, a new OWL-S model tailored for the types of services we are considering is listed. For the readers convenience, XML documents for the use cases and their parameterization are added in the other appendices. They are referred to from the following sections and mainly serve for illustration purposes.
Note that the prime design rationale of the presented framework implementation is as a proof of concept for the approach of generically integrating Web Services as rules with Semantic knowledge bases. Therefore there is still a long way to go for a real world application to be build on the framework. At several points notes are added hinting on potential challenges, particularly with regard to specific techniques for optimizing reasoning on knowledge bases. Neither are these remarks to be seen as exhaustive nor are they to be understood as short treatments. Rather they are intended as selected starting points for further research which is beyond the scope of the current work.
1.4 Notation
In the following, besides of the standard font for ordinary text, we will use Courier New font for coding snippets and Arial for XML documents, e.g., XML serializations of RDF documents. The Courier New font will also be used within ordinary text for referring to coding elements like schema types and OWL classes as done in section 1.2. The same applies to the Arial font – note that one has to distinguish between a class and a corresponding element in an XML document representing it. While most often this distinctions is not so important and will be not be made explicit in the following, sometimes both aspects are used at the same time and then the same String will be used with different fonts.
As usual in XML notation, we will use speaking names for XML elements as OWL classes and attributes, e.g., StockTickerSymbol as done in section 1.2. To avoid lengthy formulations, the class names will be also be understood in their literal meaning when being used within ordinary text, the same applies to notation taken from standards as WSDL: e.g., in section 1.2 in the sentence 'The route service has a single wsdl:portType with one wsdl:operation' the two WSDL attributes are also used in their literal meaning.
Under the database of a system, we understand the set of RDF-triples which can be queried by the system, regardless of the underlying storage system, e.g., a relational database system, in memory or the likes, and regardless of the actual representation of the triples, e.g., as objects in some object oriented programming language, as entries of some relational database etc.
If a specific type of database is referred to, it will be named explicitly. As we are working with systems capable of inferencing, the set of RDF-triples which can constitute the result of some query can include triples which are not physically present in the database. For an application building on the system, there is no difference between physically present triples and inferred ones. Therefore, in general, when we will talk in the following of the database, all triples are referred to, including those which can be inferred. Only if a distinction between the two types is important, it will be made explicit which triples we are talking about.
2. Current approaches
Following the case study in the previous chapter, three existing frameworks for Semantic Web Service description are described in this section. We start with OWL-S (formerly DAML-S), a collaborative effort of academic and industrial partners within the DARPA Agent Markup Language program. For a comprehensive overview including examples, [OWL-S].
As all three frameworks have many similarities, OWL-S shall be investigated thoroughly, while the following two, WSDL-S and WSDF, shall only be described in so far they differ significantly from OWL-S.
Particularly OWL-S and WSDL-S are closely interconnected with the syntactic description of a service, that is with its WSDL file. We assume the reader to be familiar with the W3C specification for WSDL, [WSDL], [CCMW].
2.1 OWL-S
In the following we use [OWL-S1] as reference on OWL-S 1.0. However, on principal all of [OWL-S] is used as reference. There also exists version 1.1, [OWL-S1.1]. However, their major difference is in definition of semantic parameters of services. The latter defines them as SWRL variables. Unfortunately, there does not exist an accepted Semantic Web standard for rules and variables as of yet, and I hold the position that, if possible, one should avoid non-standardized constructs in the definition of a standardization proposal. We will see in section 2.5 how problems, arising from the definition of parameters by OWL classes as done in OWL-S 1.0, can be solved by means of OWL without using rules. Thus, in the following we always refer to version 1.0 when talking of OWL-S.
The scope of OWL-S is explicitly set to include IPS. However, complex services are the primary motivation and guiding use case for OWL-S. Therefore OWL-S draws heavily on work done in the area of planning and work flow processes.
Under a complex service it is understood a service with several operations, like a book buying service, which require several operationally interdependent calls: To buy a book, first a search has to be done to check if the book asked for is in store, then one has to submit address information where to send the book to and finally payment informations have to be provided, dependent on the payment options available (which again first have to be asked for). In particular, these calls have to be made is a specifically ordered sequence and failure in of the individual calls breaks the chain of calls and even may require to undo some effects of prior calls.
In short, a complex service consists of one or even more complex processes, which in turn are composed of simple processes, the latter being an abstract face of an atomic process or a complex process. A process itself is hereby seen in general as some data transformation with well defined input and output parameters, for a more detailed definition [OWL-S1], section 5.
This behavior is in sharp contrast to the simple call in our examples above: services as the currency exchange service are completely self sufficient and their outcome (either the information provided or failure of the call) does not have any consequences on other services or other calls to the same service.
According to its scope, OWL-S is designed to enable four tasks:
- Automatic Web Service discovery: this also should be enabled for IPS.
- Automatic Web Service invocation: this task was already identified in the case study.
- Automatic Web Service composition and interoperation: this task was also identified in the case study in section two, limited to the scope of IPS, while the OWL-S scope is defined also for operationally interdependent services, in contrast to information needs only.
- Automatic Web Service execution monitoring: this task is important mainly for operationally interdependent services, as from the failure of one service might arise the need to reset some result of another service, e.g., the unavailability of a hotel reservation service of some hotel might force the cancellation of some transport reservation done by some other service. Of course the failure of some service B, requiring information by some service A also might render the call to A irrelevant, however there exists no action, caused by A, which might have to be undone because of the failure of B. Thus, such a capability is not important for our use cases.
Neverless, although deemed important, the last task in fact is not supported yet by current OWL-S versions, thus three tasks, which correspond – partly with limited scope – to the tasks required by our use case are enabled by OWL-S.
The three tasks correlate roughly with three classes which describe corresponding aspects of the service:
illustration not visible in this excerpt
- ServiceProfile describes what the service does and what it requires to be invoked – this information is needed for selecting the service by some matchmaker with respect to some agent's needs.
- ServiceModel describes how the service works as a process which is needed to find out how a service has to be called within a whole set of interdependent services.
- ServiceGrounding describes how the service is actually called, that is how to invoke the service.
Based on an instance of the class Service which is the domain of three properties ranging over the corresponding classes, an individual service shall be described to enable the above mentioned three tasks. In particular there is a central starting point for the description of every service, which is technically important as some system thus can collect all services available to it in a single list of instances of class Service. This class is serialized in some XML document, see for example in Appendix B the document StockquoteService.owl for the StockQuote service.
ServiceProfile: The service profile serves for matching the offer by the service provider with the needs of a service requester. Thus, a requester may send a service profile describing her needs to some service registry where it is matched with the profiles of the registered services. This match my not completely satisfy the requesters needs. For an IPS this means that not the exact information needed is provided by the service.
In this thesis no algorithm for determining similarity is discussed, nor the question how the requester may cope with non-sufficient information. In our use case, information is requested via some query, thus only cases where the information returned contains a complete answer to the query is accepted: for services involved this means that their information combined with the database must answer the query call. On the other hand it is clear that only if the information available can fill in all required parameters, a service can actually be called. Thus, the decision whether or not a service is called is already implicitly decided by the information available and the information requested by the query.
So in short, if the system shall be able to cope with incomplete information, this capability has to be implemented at some level above the actual query generation and is not considered at the level of service invocation, thus we do not include it in the list of tasks our system shall support.
The profile includes contact information about the provider. Clearly such information is needed for every service and is independent of the type of service. On the other hand this information is not critical as it is completely separated from the functional description of the service and can be dealt with by the system before actually including the service in its library of services used.
The same holds for information on service quality: before the system includes a service into its library of used services it decides, based on the task at hand, which level of reliability of service it requires. In the case study this has been considered and the necessary information obviously can be provided by an OWL-S profile.
The most important information regarding semantic modelling is the functional description of the service. This is done by describing:
- Data transformation, that is the input and output parameters of the service and their relationship. This is basically all that we have to know from an IPS.
- The effects and conditions caused by and required for the service invocation, respectively. These are irrelevant for an IPS. Such a description may require a quite extensive ontology about the real world objects affected by the service. Its absence in our use case reduces considerably the effort of semantic service modelling and processing during run time.
From point two it follows that there are only two kinds of conditions in which an IPS does not return the expected parameters:
- The occurrence of exceptions, which can be divided into invalid parameter exceptions and service failures. This situation should not be modelled in the same way as conditional outputs depending on the actual data flow and which may represent fully valid service executions.
- There are parameters which can have different semantical meanings which in turn lead to semantically different responses. Such a scenario raises the question if the service should rather be separated into different (semantic) services with different descriptions, all of them calling the same service implementation. This fits nicely with the intention of OWL-S to allow multiple profiles for a single service. It also includes optional parameters, where the empty value might be seen as semantically different to non-empty ones, depending on the handling of such a value. One must note that such handling must also be included in the semantic description for a consuming agent to work with the service properly.
Thus, for an IPS the distinction between conditional and unconditional output parameters is of little value.
The inclusion of a service type in the profile allows the definition of an IPS type with the above described limitations, thus enabling a system which can cope only with this kind of services to include only these in its service library.
For our example, the profile basically includes the semantic models of the input and output parameters, that is a StockTickerSymbol and a MonetaryValue. One problem, which we will consider later, is the fact, that the output parameter has to be related to the input parameter by a functional property describing that the output is the monetary value of a stock corresponding to the ticker symbol (the simplest possible way to model this would be to identify the symbol with the stock and thus assign the monetary value directly with the symbol, although this would be a rather crude modelling).
ServiceModel: Currently the only model provided by OWL-S is the ProcessModel therefore this model is considered here. The service model is intended primarily to describe data flow in complex services: it allows the description of service dependence, particularly of how composite processes are composed of simple processes and these in turn are realized by atomic processes. As already noted, this does not make much sense for an IPS. In fact, the model derives from work in planning, process modelling and work flow technology. As complex services are the guiding use case for OWL-S, such a model is of course needed.
However, for our use case it is clearly not appropriate. Obviously some parts of the model could be realized also for an IPS, e.g., a simple process could be defined from an atomic process. But such a modelling would not bring any additional value for the consumer of the service and thus would only be an unnecessary complication in the service description. Thus, the whole model consists of a set of atomic processes. In section six we will consider extensions of the presented framework to (slightly) more complex services. When doing so, the distinction between simple and complex processes becomes important again.
The second function is the (semantic) definition of data types, that is the assignation of data types to some ontology, which of course is needed for an IPS as well.
Finally, some remarks on the relation between profile and model. The relation between profile and model is not specified, although implicitly the profile is intended to represent a part of the model relevant for choosing a service. While in general a distinction between profile and model regarding parameters, conditions, effects and even processes, included in the description, might be useful, for an IPS it is not of much use:
- As already noted when discussing the elements of the service described be the profile, there are no preconditions and effects of a service of the type we consider, so there is no selection which of them might be important for the selection process and which are not.
- Interdependence of services is purely data driven, so there are no operations of the service which might be used but not advertised – basically every IPS should be advertised. Again, this does not hold anymore when extending the framework to more complex services.
- As there are no side effects, the output parameters will all be relevant to the user, otherwise it does not make sense to return them at all. For the input parameters there might be the consideration that optional parameters might not be advertised. However, as the return parameters will depend on them, their semantic modelling necessarily includes also the optional input parameters as well, otherwise the requester would not be able to discern their meaning.
In short, the functional description in the profile completely reflects the model. Any difference is an inconsistency which renders the description worthless. Thus we have completely redundant information in these two parts of the service description.
It follows that the model extends the description already given in the profile only in so far as we might collect the description of several atomic processes in one profile, in which case the model would describe how the service parameters correspond to the atomic processes. Thus, its main function is to hold data type descriptions which are referred to from the profile. So one property of the above mentioned type of IPS would be the restriction of the model to some type consisting basically of data type definitions. However, in proceeding with our considerations we will find new, additional information, not yet covered by OWL-S, to be included in the model
So at the moment, in OWL-S semantics, an IPS can be viewed as consisting of a set of atomic processes, each consisting of a single request / response cycle which can be invoked individually and is described by the profile and a model consisting of data type definitions only. That is, there should be defined a new model class with corresponding restrictions, i.e. which contains no process except of atomic processes. However, the ProcessModel was designed to cope with the complexity arising from the interdependence of complex processes, simple processes and atomic processes as described in [OWL-S1]. To define a restriction of this class containing only atomic processes would render the design rationale of ProcessModel obsolete, thus it would be better the new class inherits directly from ServiceModel instead of ProcessModel. Moreover such a new model would also allow to define the above mentioned new properties, a possibility we want to make use of in the following.
For our example, the atomic process would thus have an input parameter s1 of type StockTickerSymbol and an output parameter m1, of type MonetaryValue. Moreover there needs to be some relation hasPrice between the two classes.
ServiceGrounding: For the concrete messages to be send and received between the service and its consumer, the grounding describes how the parameters of atomic processes are mapped to these messages. The grounding builds on the service's WSDL document ([OWL-S] refers to WSDL 1.1):
- A grounding corresponds to a binding in the WSDL document. There is no difference between a complex service and an IPS in that respect.
- An atomic process corresponds to an operation. Operations can differ syntactically because of different protocols supported but may be semantically identical. In this case one atomic process may correspond to several operations as they clearly can have identical semantic descriptions. Thus, if we follow the philosophy of assigning a profile to every atomic process, one set of semantically equivalent operations correspond to one profile.
- The input and output parameters of an atomic process correspond to the associated operation's message parts. This correspondence does not need to be one to one but can be by means of an XSLT transformation. This is the central modelling aspect when annotating an ordinary Web Service semantically.
- The class-types of the parameters correspond to XSD abstract data types. The corresponding types may be mapped via two XSLT transformations (from OWL-S to WSDL and the other way round). This allows for semantic modelling of already existing Web Services (which might have non-OWL class data types), as in our use case. As there already exist many Web Services without a semantic description, this possibility is crucial for the success of Semantic Web Services.
While it is possible to use OWL classes directly as abstract data types in a WSDL document, that is the corresponding service has been designed as a Semantic Web Service from the start, at the moment this is really the exception while generally an already existing service will be semantically annotated.
A crucial point is how to associate a WSDL document with an OWL-S description of a service. The grounding contains in particular the URI of the WSDL document thus giving access to it. A separate repository for WSDL documents which would have to be kept in sync with the OWL-S service repository is therefore obsolete. However this is true only if all services are indeed semantically annotated.
The grounding contains a WsdlAtomicProcessGrounding instance for every single atomic process and in turn for every operation a WsdlOperationRef instance.
The actual connection between elements of the WSDL document and OWL-S elements is described as follows:
- Every operation in the WSDL message has an attribute owl-s-process pointing to the associated OWL-S atomic process. The grounding of the atomic process contains a wsdlOperation pointing to the operation grounding which in turn points to the WSDL operation. Thus, the association between atomic processes and operations is expressed explicitly in both directions.
- Every message part of the WSDL document has an attribute owl-s-parameter pointing to the associated OWL-S parameter type definition (in the model). The grounding of the atomic process points to the messages and contains:
- a mapping of each part of the input message consisting of a pointer to the atomic process's parameter associated with the part. Or some XSLT transformation transforming the atomic process's parameters into the message part.
- a mapping of each output parameter consisting of a pointer to the operation's part associated with the parameter. Or some XSLT transformation transforming the message parts into the output parameter.
One should note that while the first point (new attribute in a message part) is already allowed in WSDL 1.1, point two requires extension of the WSDL 1.1 standard.
Considering our example, we get the problem that any XSLT transformation of the output message part only can produce the value of property numericalValue for m1. Adding information about the currency, producing an instance m2 of MonetaryValue, there still is nothing said about the relation between s1 and m1.
Resources: In section seven of [OWL-S1] resource consumption associated with a service are considered. Fortunately, an IPS does not affect real world entities, thus there is no need for a consideration of resources and no need for a description of required resources, constraints on resources and the effect of service execution on resources.
One might object that some services require information from other services, but this resource (that is the required information) is already dealt with during collection of values for the service input parameters, thus there is no need for an additional layer of service description.
This fits nicely in the fact that the problem of describing resource constraints is not solved in OWL-S yet, due to limitations of the OWL language.
illustration not visible in this excerpt
Summary: Following the design rationale for a specification capturing in particular complex services, for the task of modelling IPS only a portion of the service description options offered by OWL-S are needed. Moreover, this portion is distributed across several documents. Particularly the model only serves for parameter and data type definitions. However, these definitions are accessed during all stages of service interaction.
On one hand, for some simple, isolated IPS this can be seen as design overload. On the other hand, defining a separate document for parameter and data type definition might be useful for organizational reasons and encourages reuse: several profiles might use the same model, particularly if they present different aspects of the same or related services, e.g., if several profiles are used for modelling method overloading.
In short, by restricting OWL-S to IPS, it is well suited to describe such services for automated processing except for the following problem of semantic relations between input and output parameters:
Problem: We already noted one problem with the service description in OWL-S when discussing our example: The output parameters of an atomic process are acquired by some transformation of the associated output message parts, but semantics may require that the output parameter also contain elements from the input parameters. In [OWL-S1] this is described at the end of section five by the problem of equality of parameters. It is solved by introduction of elements in the description of processes. Unfortunately, this problem is a consequence of OWL language expressivity limitations and thus can not be solved adequately with OWL language constructs but requires a specialized OWL-S process reasoner.
In version 1.1, parameters are defined as SWRL variables. Thus one could use rules to describe relations between them, although there is no specific construct defined for expressing general relations: currently they are restricted to identity of parameter instances by referring to the same variable.
Aside of the requirement of a specialized process reasoner, the OWL-S solution has another drawback: relations between input and output parameters can vary, that is they are not limited to equality of instances. Moreover, as for an IPS, such information is needed in almost all services, not only in those implementing processes. Thus, one should think about a more general solution.
2.2 WSDL-S
WSDL-S is a specification by IBM and the METEOR-S group at the University of Georgia, [WSDL-S]. It has been developed after OWL-S and is explicitly intended to resolve some shortcoming of the latter (shortcomings in the view of the WSDL-S authors). Its design rationale is to extend WSDL with semantic annotations to enable the four tasks already defined by OWL-S.
A major difference to OWL-S is that WSDL-S is agnostic to the modelling language used in the referred semantic model of the service. While this enables reuse of existing models in languages different to OWL like UML, on one hand this will limit a semantic model's use to those consumers able to process a description in the corresponding language which is particularly for automated processing a serious obstacle to the emergence of widely used standards, a prerequisite to the success of the Semantic Web. On the other hand it allows for seamless upgrade of annotated documents in case new languages are to become standards.
WSDL-S is designed to be an upward compatible extension to WSDL 2.0: the WSDL-S description of a service is added to some existing WSDL document, a sensible approach considering the widespread use of automatic WSDL document generators as in the Apache Axis package, [Axis]. Moreover, WSDL based repositories are already widely integrated in software components. In OWL-S, the reference point is the Service document from which the grounding is reached which in turns points to the WSDL document. That means existing repositories either have to be switched or be synchronized with some semantic repository, an obstacle to quick adoption of semantic descriptions.
While the semantic annotations are directly added to WSDL documents, they refer to some external semantic model, e.g., some OWL ontology. This reduces the overhead of pointing between documents as in OWL-S while keeping the possibility of reuse of the semantic model.
The design of WSDL-S allows the same annotations as OWL-S such as input and output parameters and conditions and effects, however they are not defined separately but directly in the WSDL document by additional markup of the type definitions, the operations and the interface (in WSDL 1.1, the portType is used instead of the interface element). E.g., by the correspondence of atomic processes and operations, effects and conditions are directly added to operations. Similar remarks apply to other information as service categorization.
This design removes the redundancies inherent in OWL-S, e.g., between profile and model or grounding and WSDL document. As redundancies always contain the potential of inconsistencies, particularly for documents maintained in different repositories like the WSDL description and the OWL-S description of a service, this is an advantage of WSDL-S.
As in OWL-S, a central point of the design is the type mapping from WSDL parameters to the semantic model. This is done directly in the type definition, allowing the same variant of mapping, that is, usage of OWL native types as well as XSLT transformations. In addition, any schema mapping language can be used and aside of complete XSLT transformations of complex types also simple mappings of the leaf elements in complex type definitions can be employed.
It is important to note once more that OWL-S is based on WSDL 1.1 while WSDL-S is based on WSDL 2.0, and this is one of the reasons why WSDL-S can cope without any additional documents (aside of the semantic model): WSDL 2.0 allows definition of interfaces including data exchange patterns. Thus, key functions of OWL-S profiles (to allow multiple views on a service) and models (to describe the interaction pattern of processes) are already part of the WSDL document.
Moreover, the import property allows the definition of services being a composite view of several services which might be operational interdependent and which should be presented together.
Returning to our example, the mapping between service parts and semantic model is now added directly to the interface in the WSDL document, without the need of defining an atomic process and corresponding associations between message parts and process parameters.
All other informations are very similar to corresponding elements of an OWL-S description, although it is completely integrated into the WSDL document.
illustration not visible in this excerpt
Summary: the WSDL-S approach of collecting annotations in the WSDL file reduces complexity of the semantic description while facilitating reuse of semantic models. Note that the semantic model is also in OWL-S located outside the service description, so different atomic processes might refer to the same ontology. Thus, the reuse is really in the actual process description. However, if there are several profiles for describing different parameterizations of the same service, one nevertheless has to consider the profiles for service selection as the system needs to find out which parameter combinations are indeed required for calling the service. In particular for an IPS the reuse thus is fully maintained in the semantic model. For an IPS the WSDL-S approach also removes the problem of description overload.
The restriction of WSDL-S in the part of a service description corresponding to the profile is mainly due to its design rationale not being on complex services and their operational interdependence. One reason why this can still be seen as a fully valid approach applicable to the whole range of Web Services is that the issues of service interaction are already considered in the WSDL 2.0 specification. Only at this point the OWL-S model allows some reuse not offered by WSDL-S, as the service interaction is described in WSDL 2.0 in the interface, thus, for interfaces presenting different aspects of the same service, the same interaction patterns are repeated. As for IPS this is of no concern, that is fine with us.
Unfortunately, WSDL-S also does not give any means to solve the problem of input / output parameter relations. This is left completely to the semantic model used. However, as WSDL-S is agnostic to the semantic modelling language used, it opens the possibility to use some more expressive extension of OWL, e.g., some rule language like RuleML or SWRL, which are currently under investigation, [Rule], [SWRL].
2.3 WSDF
The Web Service Description Framework, [WSDF], is an older approach (old in this case means three years) by the AIFB at Karlsruhe and DFKI. The main reference for the following is [WSDF1].
WSDF is limited to services without side effects. This is roughly the same limitation we use for IPS.
In sharp contrast to OWL-S and WSDL-S, WSDF not only provides a semantic markup of Web Services, but also a complete framework to process the markup for automatic invocation of the services. This is also the main reason for the limitation on services, as it reduces complexity of processing of the semantic markup.
[...]
* This is in sharp contrast to services with operational dependency, in particular if some irreversible real world effects are involved
-
-
-
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen. -
-
Laden Sie Ihre eigenen Arbeiten hoch! Geld verdienen und iPhone X gewinnen.