A Semantic Web Services challenge

Steve Battle, Stuart Williams, Chris Preist
Hewlett Packard

Abstract

In this paper we make a plea for practical demonstrations of the utility of web-service semantics. There is no shortage of ontologies, logics and architectures, but a real need for real downloadable tools that ordinary web developers can use and play with. We present this criticism constructively, in the form of a concrete challenge - to find and buy a book. This should demonstrate simple discovery, service composition, negotiation, process enactment, mediation, and grounding. Aside from demonstration, the advantage of such a challenge is that it showcases the relative strengths of the different proposals for capturing web-service semantics. However, the investigation should primarily be requirements-led, rather than feature driven.

Introduction

We come from the perspective that the aim is to capture the semantics of existing web-services, that is, services using technologies from the current web-service stack: WSDL, SOAP (and their extensions). At the heart of the Service Oriented Architecture is the service contract. It answers the question, "what service is delivered to the customer?" In the current web-services stack, WSDL is used to define this contract. However, WSDL defines only the operational signature of the service interface and is too brittle to support discovery in a scalable way. The semantics of a Web service is a model of the behaviour of the service, representing a contract governing the meaning and purpose of the interaction. Our aim is to support the development of next-generation standards that extend the existing web-service architecture by embracing the tools and technologies of the semantic web. The terminology of this paper is drawn from the Web Services Architecture document.

A challenge

So what can we build with the web-services at our disposal? Two exemplars of the web-service paradigm are Google's Web APIs and Amazon's E-Commerce Service. For both services, freely downloadable development kits are available for developers to create value-added web-sites and services. The challenge is to discover a retailer of a particular book (discovery), to communicate with the vendor to obtain a price (negotiation), and to take the user to the check-out with the chosen book ready in the shopping cart (enactment). Our challenge is to create a purely description-driven agent (using your favourite web-service ontology) based on these widely accessible services (somewhat in the spirit of the DAML-S virtual machine), rather than in some fictional or private domain that limits the testability by our peers in the semantic web services community. Google can be used to search for online resources, Amazon provide the facility to search their online catalogue and make an offer, as well as a remote shopping cart that can be submitted for check-out processing when the user comes to make their purchase.

The challenge is not to create a completely autonomous agent. Such things surely take away all the fun of using the web. The job of an agent is to make life easier for the user, supporting them in the tricky task of juggling the information they have and giving it to the appropriate service when required. An autonomous agent may not know exactly which book to add to the cart if several hits are discovered, and they may not be authorised to actually go ahead and actually make the purchase (and besides, this function is not currently available as part of the Amazon web-service). These important decision points, especially those that commit the user to a contract, remain in the hands of the user.

Discovery and advertising

We will use the Google Web API to perform the discovery stage of the process. The aim is not to demonstrate complex semantic match-making but description driven usage of a web-service. Google is able to identify a resource by matching key-words. We want to find a book we know is called 'Weaving the Web', by Tim Berners-Lee; the search string to Google might be 'Weaving Web Berners-Lee'. Google identifies a collection of matching resources, one of which we hope represents a book offer from an online store. Note that at this stage, our agent doesn't know which bookseller it must work with, so cannot be pre-programmed to work with any single one of them. Our agent must work with an abstract, perhaps goal-oriented, plan which allows us to add detail dynamically as we find out more about the services we are interacting with. The way our agent combines one service description with another is service composition.

The next step is to identify which of the returned hits represents a discovered offer. This is essentially a semantic-web function: to associate the different sites Google has identified with their capabilities. We don't assume from the outset that the customer will buy the book from Amazon. They may in fact consult many different book vendors. For our challenge there need only be one vendor present, though other online bookstores can be added as they become available. We will assume that the agent has access to an RDF knowledge source that associates the Amazon site http://www.amazon.com with their E-Commerce service and associated service description.

The kind of thing we want to know about Amazon is that they are a book vendor - one of their (many) value propositions. Despite the fact that Google discovered a page about a particular book, that doesn't imply Amazon themselves would advertise their service in terms of each and every product available; they may instead publish a generalized service offer. Amazon, for example, divide their product range into a number of offerings including Books, Music, DVDs, etc. The service offer may simply describe Amazon as a book vendor, assuming we have a readily available domain ontology that declares the concept of 'Books' together with a suitable 'offering' relationship. Another resource we have available to describe the type of service offered by Amazon is the MIT Process handbook that classifies the customer interaction with Amazon.com as an example of the 'Sell via electronic store with posted prices' business model.

The Amazon site may be associated with more than one service offer. For example, an alternative offer may describe Amazon as a Music vendor. Which advertisement should be used by the agent? On the face of it, it seems obvious that an agent searching for books should only consider book ads. However, if Music is not explicitly disjoint from Books then there are also interpretations where Music is deemed synonymous with Books. What is the logical justification for choosing the Books offer over the Music offer? This is one of the main foci of the SWSL rules language that is designed to capture the non-monotonic reasoning that would select this latter offer only in the absence of the first; selecting Amazon Books over Amazon Music.

We can define the Google search as an OWL-S atomic process defined below using the proposed OWL-S surface syntax. The terminology is explained later. The 'key' is a license key provided by Google on request, and the query string is much like the string that can be entered on the Google web-page. The output includes possibly many result elements, each of which represents a single matching resource.

define atomic process search (
	inputs: (key, query - string),
	outputs: (item - ResultElement)
)

Negotiation and contracts

The Amazon e-commerce service (ECS) exposes a range of capabilities including access to the full Amazon product catalogue. This allows our agent to see confirm that the required book is actually for sale and at what price (the information on the discovered page may be out of date). The requester agent must enter into direct negotiation with the service provider agent to fill in the gaps - to come up with the service contract. The contract represents an agreement between the customer and the service provider, defining exactly the service (instance) to be provided. The contract must be specific about the required product, for the title may not be sufficient by itself:

The service contract defines the content of a negotiation process. With Amazon, negotiation involves a catalogue search that returns product info including price and availability. Only once we have that do we have the raw material for a service contract - a tangible offer. To flesh-out and shake-hands on the contract, the agent adds the book to the cart and proceeds to the checkout. We assume the final go-ahead to make the purchase is referred back to the customer. This style of negotiation follows a very simple take-it-or-leave-it pattern, but requires a technically non-trivial choreography that likely differs between services. For this reason, we require a method of process modelling so that our agent can negotiate on the customer's behalf.

One of the operations provided at the Amazon interface allows the requester agent to perform an ItemLookup, searching the product catalogue for the desired item.

define atomic process ItemLookup (
	inputs: (SubscriptionId, Operation, ItemId - string),
	outputs: (Item)
)

Process composition and enactment

A key feature of the Service Oriented Architecture is its characterization of the tasks and actions concomitant with the negotiation and delivery of a service. The value of OWL-S is its focus on the vocabulary of service description, especially with its process model. An OWL-S process model essentially describes a single task which breaks down by way of composite processes into more primitive atomic processes that represent basic actions. A process model expresses declarative process constraints rather than directly executable programs. This provides additional flexibility to agents that may use them to govern, rather than determine, their behaviour. Each process is modelled in terms of its inputs and outputs which provide an epistemic account of the impact of these actions on the knowledge-base of the agent. Additionally, OWL-S provides a place-holder for the preconditions and effects of a process that describes their semantics; their meani= ng and purpose, over and above the mechanics, of the interaction. Through process modelling we are able to capture the overall service interaction which involves actions that relate to catalogue search; remote cart management; and checkout processing (there are also tasks that pertain to service delivery, such as order tracking, that are not covered in the immediate challenge).

The 'SubscriptionId' is provided by Amazon to uniquely identify each registered user. The 'Operation' is set to 'ItemLookup' and the 'ItemId' is the ASIN derived from the Google search. The 'Item' output represents one or more matching offer including pricing and availability details. The example would also be supported by the creation of a domain ontology that defines structured objects that appear, such as 'Items'. The advantage of using a domain ontology is that we can work with the data independently of any particular message syntax. For example, it may allow us to compare the catalogue content with that of other online stores. We also have a level of abstraction that is resilient to syntactic evolution of the interface (semantic differences require deeper changes).

In the example above, nothing really changes other than the agent's knowledge of the product catalogue. Contrast this with the effect of adding the book to the cart. Amazon provides a 'remote shopping cart' resource that is managed by the Amazon server. Operations on the cart allow an agent to add items to a new or existing cart; to clear and modify a cart; and to view the current contents of a cart. The real-world effect is the state-change of a remote shopping cart (a new cart resource is created). Following PSL, the process model of SWSL talks about fluents which model the way things (resources) change. This goes beyond the simple OWL-S ontology by adding a theory that enables us to make useful inferences about a process. Any stateful resource is described by a fluent that reflects the way it changes in response to events. Effects (or Results) encode the changes that can be directly attributed to an action. Preconditions describe the state of the world (i.e. not just the knowledge of our agent) that must pertain prior to performing an action.

We look at adding an item to a new shopping cart with a CartCreate operation. We can add more than one item at a time so the input is again a collection of items. The response includes a URL from which the contents of the cart may be purchased. The existence of this new shopping cart is a statement of fact about the world so this is expressed as an effect (or a result set); an assertion of the existence of the new cart with a specific cart identifier.

define atomic process CartCreate (
	inputs: (SubscriptionId, Operation - string, Item),
	outputs: (CartId - string, PurchaseURL - anyURI),
	result: cart(CartId)
)

Any 'item' that is an output of item lookup may be an input to any cart operation. We can describe this linkage of inputs to outputs as a constraint on the relative ordering of an occurrence of a search and cart operation. In this case we wish to describe a sequential process composition where we put the search before the cart. We describe this process as a shopping activity, and just like window shopping there is no implication that anything is actually purchased.

define composite process shop (
	inputs: (ItemId - string)
	outputs: (PurchaseURL - anyURI))
{
	lookup :: perform ItemLookup(<myAmazonId>,'ItemLookup',ItemId);
	perform CartCreate(<myAmazonId>,'CartCreate',lookup.Item)
}

Currently, the Amazon API does not allow an agent to complete a purchase automatically, but each shopping cart has a purchase URL that the customer can visit to finalize the purchase. This creates an interesting challenge for process modelling. How do we represent these out-of-band actions that are not directly performed by the agent and are not grounded in web-services? The effect of order submission is also significantly different from the simple state-changes we see in shopping carts. Adding items to a cart does not actually commit the buyer to anything. However, when the buyer places a confirmed order, the seller is then under an obligation to deliver the product (and the customer is under obligation to pay). This is understood to be central to the buyer/seller contract and may be described as an obligation between the requester and provider. It represents a commitment to honour an agreement at all future times (until it is discharged). In reality, these obligations are conditional. The buyer has the right to cancel the order at any time up until the order is actually dispatched. Conversely, a permission proffers the right at some future time to perform an action (until it is withdrawn). Both obligations and permissions are described in the web-service policy model.

Grounding and Mediation

Grounding represents the low-hanging fruit of semantic web-services and is exploited in proposals such as METEOR-S. The service grounding should identify the appropriate domain ontology and provide enough information for a client to lift message content into this abstract ontology. Amazon web-services are interesting in this respect because they provide two alternative modes of service invocation with equivalent semantics. A Service Oriented Model utilizing SOAP over HTTP is supported, together with a REST-compliant Resource Oriented Model.

Because we're using one service in conjunction with another, this means that we may have to convey information from one context to another. Mediation is arguably one of the main driving forces behind the WSMO project (Web Service Modelling Ontology). Because there are many possible service compositions we can't rely on specific point to point mappings. From our experiences in the SWWS project (Semantic Web enabled Web Services), we recommend an ontological approach where data from any source can be mapped onto whatever common class definitions are available. Mediation (of data) is possible where we can find an intermediate class common to both services. The URL returned from the Google search includes the Amazon Standard Item Number (ASIN) that provides a unique product code, which for books, at least, is equivalent to their ISBN. From the output of Google (though an Amazon URL, it is from a different context) we can derive the ISBN which can then be used to find the same book in a search of the Amazon catalogue. The ISBN is the common abstract concept.

Conclusion

It is our position that both the community of web-service developers and potential customers of semantic web-service technology need convincing demonstrations in the form of downloadable tools that showcase description-driven discovery, negotiation, enactment, grounding and mediation using real and openly available web-services. We believe that such demonstrations are entirely feasible drawing on ideas from one or more of the SWS proposals available to us.

Valid XHTML 1.0!