Introduction

Semantic web services are implemented on top of conventional, syntactic web services. The connection between the two-the grounding-must enable an actual web service to be invoked based on the content of a semantic description of a service invocation. The conventional approach taken by all the major semantic services frameworks [1][2][3] is to use an XML mapping language to translate between the two. This naturally doesn't work for non-XML services, such as many of the growing number of RESTful services [4] (section 2). Moreover, XML mapping requires the service engineer to use an use another language in addition to the knowledge representation language used for describing the ontologies, and to consider the XML serialisation of their ontology: three languages instead of one.

We present an alternative which models the target service's input and output (HTTP messages) as ontological objects, and uses backward chaining rules to direct the translations between the semantic service invocation and the low-level data formats required by the service (section 3). As a case study, we take the RESTful version of Amazon's commercial web-storage service, where Amazon's authentication process precludes its description by WSDL or WADL (section 4). We develop the ontologies for describing the HTTP protocol itself, cryptography, and the broker's ontological hooks for the grounding procedure, and put them together in a description of Amazon's service (section 5). The ontologies and grounding have been implmented in the Internet Reasoning Service broker [5]. We compare our scheme to current XML-centric approaches to groundings (section 6).

Semantic web services rely on normal web services to source and manipulate information and to effect change in the world. This requires that semantic service brokers translate between the world of domain theories, represented in some ontology language, and the on-the-wire data formats and protocols that are the language of the target web services. For semantic web services to be taken seriously by practitioners, groundings must be able to organise communication with a comprehensive subset of real, deployed web services.

The triumvirate of XML, SOAP, and WSDL [6][7][8] is the basis for the W3C's web services stack, colloquially known as 'WS-*'. As the complexity of the WS-* stack has increased, SOAP's hegemony has ebbed, with many services being offered using lighter weight alternatives. The genuinely simple protocol which inspired SOAP has re-emerged in its own right as XML-RPC [9]. Simultaneously, REST [4] has gained considerable mind-share: according to Amazon's web services evangelist Jeff Barr, around 80% of invocations of Amazon's services are done through the REST interface1 . Yahoo! does not provide a SOAP interface at all, and has no intention of adding one2 . Flickr, a popular photo-sharing website, provides its API in all three web service flavours: SOAP, XML-RPC, and RESTful. The SOAP interface does not have a WSDL description, and none of the the third-party bindings The XML-RPC equivalent is very similar, albeit with no SOAPAction header, nor the large number of XML namespace declarations. Unlike SOAP, XML-RPC relies on HTTP as more than a transport protocol. For example, authentication is handled at the HTTP level, so the Authorization header must be accessible to the grounding.

Representational State Transfer, better known as REST [4], emphasises resources over operations. It is most often implemented on top of HTTP, where it aligns web service operations with the 'methods' of the HTTP protocol. This means that information requests are performed using GET, changes of state are made with POST, while PUT and DELETE are used to manage the data stored at the specified URI. In practise, this means that many operations are performed simply by encoding an operation in a URI and having the client request it:

GET http :// world -weather . org / forecast / italy / rome /20081216 HTTP /1.1

Note that the URL can be an arbitrarily complex amalgam of service's 'name', and some of the service parameters-country and city names, and forecast date. The returned content need not be XML: in this case, it might be plain text description of the weather, or a graphic illustration of the weather over Rome. The correct use of HTTP headers such as Content-Type and Date become essential. With RESTful and XML-RPC services, WSDL and XML schema descriptions are rarely, if ever, furnished by the service provider.

Approach

Given that SOAP is no longer the sole deployment route for web services, we need to reconsider the desiderata for a grounding scheme. For us, we needed a grounding which could address REST services, but which would also support SOAP and XML-RPC in the same framework. This led to the following aims:

1. Target HTTP, not SOAP. 2. Be agnostic about content type: HTTP carries XML, but also images, sound, and other data formats. 3. Do not require third-party cooperation.

Stay within the ontology language.

Principle 1 enables us to support the three web services approaches today, and gives us some degree of future-proofing. Principle 2 allows us to describe, for example, services that return images. Principle 3 frees the semantic web services description from the service provider. If a service's WSDL description is not available, or incorrect, we should not be prevented from creating a grounding if we can otherwise discover the interface, through reverse engineering or reading documentation. Nor should we expect the provider to link to our semantic description of their service: it is our description, and they have no obligation to trust or advertise it. Principle 4 is just the application of Ockham's razor: the fewer languages the engineer must deal with, the better. But it also retains the possibility of reasoning over the grounding, for instance in data mediation. More philosophically, if we are truly convinced of the power of ontologies to model such things, it seems odd to avoid their use at this point.

This thought leads to our approach: we model, in a series of ontologies, the various protocols and encodings needed to invoke web services. Each facet of the process is represented by its own ontology: a pure HTTP ontology; a cryptography ontology; and the IRS specific ontology which allows us to map from service invocations to data on the wire. While our ontologies were developed for the purpose of supporting groundings, they could in principle be general purpose ontologies developed for other uses in the respective domains. To invoke a web service, a WSMO broker follows this procedure:

1. A user invokes a semantic services goal by calling the broker with a goal name and the parameters. 2. After some processing by mediators, a web service invocation instance is created. The invocation object holds the service name, input parameters, and slots to hold the return values from the web service. 3. A rule from the service's ontology is called to create an HTTP message object based on the service invocation object, with its various slots' values set to reflect the parameters from the the service invocation object. 4. The HTTP message is passed to the broker, which then turns the HTTP object directly into a request on the network.

The process happens in reverse when the service replies. The stage addressed in this paper is step 3. The two rules we call lower and lift, which respectively 'lower' and 'lift' the service request object to an implementation level and back. Concretely, the two rule heads are:

( lower ? service-type ? service-instance ? http-request ) ( lift ? service-type ? http-response ? service-instance )

The first argument, ?service-type, allows each service to have its own implementation, dispatched on the value of the ?service-type argument. The lower rule is a series of subgoals whose successful fulfilment leads to the instantiation of ?http-request, which can then be interpreted by the broker to call the web service. When a response is received from the server, the lift rule runs on the same ?service-instance, and the newly returned ?http-response, modifying the original ?service-instance frame to record the return value.

We implemented this approach in the Internet Reasoning Service (IRS) [5]. The IRS is based on the Web Service Modelling Ontology (WSMO) [11], and uses OCML [12] for knowledge representation and reasoning. OCML is a frame language with procedural attachment, and is comparable in expressiveness to the Ontolingua and Loom languages. In our implementation, we use OCML's ability to define the operational semantics of ontological components directly in Lisp.

Amazon's Simple Storage Service

Before looking at the ontologies in detail, we examine our motivating task: the targeting of a real-world web service in the context of our work in the Living Human Digital Library project (LHDL) [13]. LHDL is building a library of data about the human musculoskeletal system, along with web services to visualise and manipulate it. The medical imaging and motion data, from MRI scans, dissection and gait analysis, is stored in repositories accessed and managed by XML-RPC web services, and computational services accessed through SOAP. We use semantics to manage and integrate them with external services.

A key aim of LHDL is to enable the storing and sharing of the research data, but the data files commonly range in size from hundreds of megabytes to several gigabytes. It would be beneficial if we could outsource the storage and transfer of this data, and several major web services providers have recently begun offering such facilities. We decided to use Amazon's 'simple storage service' (S3) as our test-bed. Amazon's S3 is a commercial service, with charging being a function of storage and data transfer (in Gigabytes per month), and number of HTTP operations.

Storage at S3 is organised by 'buckets' and 'keys', which are analogous to directories and files in file systems. Buckets live in a global namespace, and users can create new ones provided the name is currently unused. Within a bucket, the owner has control over the keys and the objects they name, as well as access control for other users. A user is identified by an 'access key', and authorised by means of a 'secret key'. Buckets are created by executing a PUT to the bucket's corresponding URL. The following HTTP request instructs S3 to store the string 'Hello, world!' in the object with key hello in the bucket lhdl: Note the Authorization header. The content of this field is specified by Amazon to be the pair of the user's access key, and a digital signature (using the HMAC-SHA1 hash) of the HTTP request itself, created with the user's secret key. Figure 1 shows the grammar provided by Amazon specifying the signature's content. Since a request's Date header must agree with that on the Amazon servers (within a narrow margin of error), the above request would not work now. Note that, because the signed string includes the date, the authorisation value cannot be generated before the date is decided. Since the date is only decided at the HTTP layer, they must both be done as part of the same process in the broker, and with one control procedure being responsible. These features make S3's interface impossible to capture in WSDL [8] or WADL [14], but straightforward to ontologise using rules. REST service (From Amazon web services documentation.)

Ontologies

Having seen our overall approach, and our target web service, we are now in a position to present the ontologies: one each for the IRS broker, HTTP protocol, cryptographic operations, and the Amazon service description itself. In OCML, namespaced symbols are written #_namespace:localName. A symbol #_localName without a namespace refers to the current namespace. In this paper, the namespace prefixes map to ontologies as follows:

irs → irs The broker's grounding interface rfc2616 → rfc2616 HTTP protocol crypt → cryptography Cryptography store → storage Amazon S3 services

The IRS ontology contains the lift and lower rules. Our HTTP ontology is named rfc2616, for the IETF standard for HTTP/1.1 [7]. We modelled only a subset of HTTP, but it is sufficient to perform invocations described here. A message is represented by the class #_rfc2616:http-message. A message has a method, URL, and set of headers. To provide security, the S3 services require the cryptographic signing of the HTTP requests using the HMAC-SHA1 hash. Figure 2 shows the cryptography ontology developed to handle this. The SHA1 hash function is represented by the hmac1-sha1 function.

( def-function # _hmac-sha1 ( data key ) " Return the SHA-1 digest of DATA , using KEY . " : lisp-fun # '% hmac-sha1 )

( defun % hmac-sha1 ( data key ) " Compute an RFC 2104 HMAC-SHA1 digest on DATA using KEY . " ( let (( hmac ( ironclad : make-hmac ( ironclad : a s c i i -s t r i n g -t o -b y t e -a r r a y key ) : sha1 ))) ( ironclad : update-hmac hmac ( ironclad : a s c i i -s t r i n g -t o -b y t e -a r r a y data )) ( ironclad : hmac-digest hmac ))) ( def-function # _encode -base64 ( octets )

" Encode OCTETS into base 64 ASCII . " : lisp-fun # ' base64 : u s b 8 -a r r a y -t o -b a s e 6 4 -s t r i n g ) Fig. 2. Cryptography ontology fragment. Here we use OCML's ability to define, within the ontology itself, entry points to functionality implemented in the host language, Lisp. This is only only a convenience: our approach requires only that the broker can somehow operationalise the low-level elements of the ontology. The encode-base64 function actually lives in the MIME ontology.

Figure 3 shows the key parts of the storage ontology which holds the description of the S3 service for getting objects from the server. The class amazon-get-object-service models the web service, where it is characterised by input and output roles. Those are typed by the five domain classes which relate to the S3 concepts of buckets, object keys, access keys, and secret keys, with the latter two being tied together in an account structure. The description shown omits several WSMO elements related to choreographies, capabilities and so on which are not relevant here. Figure 3 contains the lifting and lowering rules. Note that the lift-for-get-object recovers not just the content of the HTTP message, but the Content-Type header, too. For S3, this is important because arbitrary data types can be stored, and S3 records the type specified at upload time and returns when the object is downloaded.

The lowering rule itself is natural and straightforward. It begins with the creation of a new frame instance, the ?http-request, and the date and host fields being set up. The target bucket and key objects are recovered from the service invocation with the slot-value relation, and are used to create the URL. The HTTP object's URL and method slots are set appropriately. Finally, the keys are recovered from the account, and used to sign the request. The signature itself is controlled by the rule sign-amazon, whose structure parallels that of the grammar provided in Amazon's documentation as shown in figure 1.

WSDL [8] has been the de facto specification means for web services since the birth of web services. Both OWL-S [1] and WSMO [11] define their groundings by pointing at the WSDL of their targets, but the mapping to the syntactic content of the messages is something of a grey area. The OWL-S WSDL document [15] suggests that OWL-S services should require web services to use an OWL specific encoding in their implementation. The semantic annotation extensions for WSDL-WSDL-S and then SA-WSDL (Semantic Annotations for Web Service Description Language) [3]-make it possible to have WSDL descriptions link to semantic descriptions in various frameworks. SA-WSDL uses mapping schemas to handle the lifting and lowering, but again it is XML specific. The IRS [5] used XPath expressions to generate OCML relations which performed the lifting and lowering. Another WSMO based broker, the Web Services Execution Environment (WSMX) uses service-specific 'adaptors', written in Java, to connect to services.

Although the principle of 'lifting and lowering' the XML serialisation is well established, it does not address aspects of the HTTP protocol like the Authorization header. Naturally, XML translation precludes the use of many services that do not use XML. Although WSDL and SOAP are products of the W3C standards, there is significant disquiet amongst developers about their complexity, interoperability, and their lack of Web nature. Personal experience has made us skeptical of the quality of WSDL and XSD descriptions, even, or perhaps especially, machine generated ones. Finally, using an XML mapping scheme like XSLT forces the ontology engineer to leave the semantic realm to work on the groundings, and to consider the domain objects in terms of their XML serialisation.

In contrast, our groundings unify the lifting and lowering with the management of the HTTP protocol, and are declarative and wholly within the ontology language, modulo the small number of operational primitives such as the cryptography functions. Since there are relatively few data encoding and cryptography schemesmany orders of magnitude fewer than there will be web services-it makes sense to embed them in semantic brokers, and make them available to ontology rules. With these hooks in place, we can encode groundings to a large number of important, real-world web services in a unified, ontology-based manner.

Conclusion

Semantic web services are about web services as well as semantics. In this paper, we introduced an approach to groundings rooted in ontologies and rules. A set of ontologies for modelling aspects of web service implementation was introduced, allowing us to use the ontological language itself to express the grounding, including the 'lifting and lowering' to string serialisations of data structures. We used these to describe a popular commercial REST web service, Amazon's S3. We have implemented the ontologies discussed, and used them in the IRS. They currently support the automated transfer of file resources in the LHDL project (http://lhdl.open.ac.uk:8080/irs).

We see this approach as a useful low-level implementation platform: it is sufficiently powerful to connect to any kind of HTTP service, and yet is fully accessible from the ontological level. It is general enough, for instance, that it could support multi-part MIME messages. We intend to add ontologies for reasoning directly with XML, XML-RPC, and SOAP messages, which currently must be accessed by direct manipulation of the XML string representation. On top of this, we expect to layer generic rules which will handle any services which have WSDL or WADL definitions, as well as semantic approaches like SA-WSDL.