Two main challenges in service description:
Web service tunnel vision and
Semantic myopia

Justin O'Sullivan, David Edmond, and Arthur H.M. ter Hofstede

Business Process Management Group
Centre for Information Technology Innovation
Queensland University of Technology
GPO Box 2434
Brisbane QLD 4001 (Australia)
justin@service-description.com

Overview

Through media such as newspapers, letterbox flyers, corporate brochures and television we are regularly confronted with descriptions for conventional (bricks 'n' mortar style) services. These representations vary in the terminology utilised, the depth of the description, the aspects of the service that are characterised and their applicability to candidate service requestors. Existing service catalogues (such as the Yellow Pages) provide little relief for service requestors from the burdensome task of discovering, comparing and substituting services. Add to this environment the rapidly evolving area of web services with its associated surfeit of standards, and the result is a considerably fragmented approach to the description of services. It leaves the reality of the Semantic Web somewhat clouded.

Let's consider service description briefly, before discussing our concerns with existing approaches to description. The act of describing is performed prior to advertising. This simple fact provides an interesting paradox as services cannot be described exactly before advertisement. This doesn't mean they can't be described comprehensively. By "exactly", we are referring to the fact that context provided by a service requestor (and their service needs) will alter the description of the service that is presented to the discoverer. For example, a service provider who operates a cinema wants to describe the price of their service. Let's say the advertised price is $15. They also want to state that a pensioner discount and a student discount is available which provides a 50% discount. A customer (i.e. service requestor) uses the cinema web site to purchase tickets online. They find the movie of their choice at a time that suits. However, its not until some context is provided by the requestor that the exact price is determined. The requestor might state that they are a pensioner. The same is applicable for a service requestor who purchases multiple tickets perhaps on behalf of other people. The disconnect between when the service is described and when a requestor provides context introduces challenges to the description process. A service provider would be ill-advised to offer independent descriptions that represent all the permutations possible for a single service. The descriptive effort would be prohibitive.

We propose some sample questions that we put to existing web service description standards as a means of highlighting our concerns:
  1. What is the length of period allowed for deferred payment, and what is the minimum payment required to use a deferred payment option?
  2. What percentage deduction does the service provider offer when price matching?
  3. What trademark or patent intellectual property rights exist with respect to a service?
  4. How many reward scheme points are required for redemption with a particular service?
  5. What rights with respect to suspension/resumption, warranty, extension or privacy does a service offer for its requestors?

Our position

Our concerns with the existing approaches to web services, and in particular, service description are two-fold.

Concern #1: Conventional services are being ignored for a purely web services view of service description [Web service tunnel vision].

Are web services so different from conventional services? Amongst other usages, its our belief that web services will act as the electronic request mechanism for conventional services. For example, a web service that allows flight/travel bookings. Under this scenario, the exposed web service becomes an enabler of automation. We believe that there are numerous benefits for removing the "tunnel vision" of service descriptions to include both web and conventional services. These benefits include:
  1. The ability to compare both types of services - Queries over service catalogues could return responses from both service types. Catalogues would be capable of storing both types of service descriptions.
  2. It would provide familiarity for service requestors to the discovery process.
  3. It offers protection to service requestors through the knowledge that what they are requesting of web services may be similar to conventional services.
To achieve these benefits, a single service description technique is required. That technique must be capable of expressing the functional and non-functional aspects of services. We subscribe to the notion that non-functional properties are constraints over the functionality [1]. This type of technique brings with it a certain series of challenges. Foremost is the need to support service providers in the description of their services in ways similar to their current approach. For example, a service provider can describe the temporal availability of their service using a recurring time interval (e.g. Every Monday to Friday from 9am - 5:30pm). We consider such a technique to enable "rich" descriptions. Some implications are:
  1. Richly described services increase the complexity of user interfaces for discovering services.
  2. Richly described services require more effort on behalf of the service provider to describe its service (although varying depths of description would be available). There would be a need to entice service providers to describe their services as richly as possible.
  3. A language that is flexible may make the discovery process more difficult. For example, a temporal interval may be expressed as specific set of dates/times, or it could be expressed as an overall interval with restrictions to sub-intervals.
Concern #2: The semantic richness of the non-functional properties of services is not being exploited.[Semantic myopia].

Our previous work has highlighted the need to describe the non-functional properties of services, as well as the types of properties that should be described [2]. The OWL web service ontology [3] offers "placeholders" for the description of non-functional service properties, along with a minimal number of specific non-functional properties. In the context of the OWL-S profile, the non-functional properties of services are considered to be almost entirely domain specific. The Web Services Modelling Ontology (WSMO) [4] uses Dublin Core metadata as the core properties, then extends these to include some web service properties. The non-functional properties thus far outlined are more indicative of the categories of non-functional properties than a specific non-functional property set. The model is extensible and caters for domain-specific inclusions. The Web Services Description Language [5] presents an entirely functional view of services and was not intended to attempt the description of the non-functional properties of services.

Our recent work is an attempt to narrow the void between the functionally focused web service description standards and the non-functional description of services [6]. There we present a discussion of many non-functional properties (mentioned in section 3). The intent is to outline a basic set of domain independent non-functional properties that can be used to improve discovery, comparison and service substitution. The approach we've used provides opportunity to augment our work with an existing description technique such as WSMO, or to develop a separate concrete language. Our preference is for the former. Without rich service descriptions we are incapable of achieving automated service discovery, comparison, negotiation and substitution.

Our work

We have previously claimed that non-functional properties were an essential component of the characterisation of any service [7, 2]. Our motivation is to provide a theoretical basis for automated service discovery, selection, and substitution. We have recently completed a large technical report that contains 79 models that describe non-functional properties such as availability (both temporal and locative), payment, price, discounts, obligations, rights, penalties, trust, security, and quality [6]. This content has been published on the Web as a set of navigable models [8]. To develop these models we undertook a significant analysis of services from numerous domains. We have extracted hundreds of non-functional properties that have been subjected to criteria before inclusion in our models. These criteria included: whether the non-functional property presented itself in numerous services across multiple domains, whether the property represented a domain specific non-functional property (in which case it was excluded), and whether the non-functional property required knowledge of the service requestor that is not available at the time that description is performed.

We prefer not to distinguish between conventional services and web services. Historically, services have always been distinguished according to some criteria of a service requestor (such as price, payment alternatives, availability, security etc). We are motivated to ensure that the criteria used to evaluate conventional services are also available for web services. We are motivated to ensure that service providers can publish descriptions in a manner suitable to their needs. For example, where a service provider wants to outline when a service is available, rather than specifying exact dates they may prefer to outline recurring temporal intervals. We envisage that service catalogues will evolve to a point where localisation of information is primarily for service requestors, and where the context of the service requestor is used to facilitate this localisation. Our approach seeks to offer a domain-independent method for describing the non-functional properties of both conventional and web services.

Our models offer the interesting capability of recursion. In describing the non-functional properties of services there are numerous instances where references to other services or providers are used. For example, a service provider can outline the warranty offered for their service but state that the warranty is fulfilled by a separate provider. Queries over our models then allow us to not only filter based on the criteria of the service of interest, but also over the non-functional properties of the associated services/providers.

Challenges

The non-functional properties of services introduce complexity to the description of services but their inclusion is crucial to the automation of service discovery, comparison and substitution. We have stated in this paper our belief that two main challenges confront the future of service description - overcoming web service tunnel vision and overcoming semantic myopia. That is, choosing to ignore both the rich history of conventional services, and the non-functional properties of services (perhaps through deferring to domain specific ontologies, or by a continued functional focus). It is our opinion that our work has managed to utilise conventional services as the basis for describing a range of domain independent non-functional properties. This provides an opportunity for expressing the non-functional properties of services using a single technique for both conventional and web services.

References

  1. Chung, L.: Non-Functional Requirements for Information System Design. In Andersen, R., Bubenko, J.A., Sølvberg, A., eds.: Proceedings of the 3rd International Conference on Advanced Information Systems Engineering - CAiSE'91. Lecture Notes in Computer Science, Trodheim, Norway, Springer-Verlag (1991) 5-­30.
  2. O'Sullivan, J., Edmond, D., Hofstede, A.t.: What's in a service?: Towards accurate description of non-functional service properties. Distributed and Parallel Databases Journal - Special Issue on E-Services 12 (2002) 117­-133.
  3. OWL-S Coalition: OWL-S Web Service Ontology (2004) Available from http://www.daml.org/services/owl-s/1.1/, accessed on 21-Nov-2004.
  4. Bruijn, J.d., Bussler, C., Fensel, D., Kifer, M., Kopecky, J., Lara, R., Oren, E., Polleres, A., Stollberg, M.: Web Services Modeling Ontology (WSMO) - Working Draft 21st November 2004 (2004) Available from http://www.wsmo.org/2004/d2/v1.1/20041121/, accessed on 22-Nov-2004.
  5. Christensen, E., Meredith, G., Curbera, F., Weerawarana, S.: Web Services Description Language (WSDL) 1.1. W3C Note, Ariba, Microsoft and IBM Corporation (2001) Available from http://www.w3.org/TR/2001/NOTE-wsdl-20010315, accessed on 26-Jun-2001.
  6. O'Sullivan, J., Edmond, D., Hofstede, A.H.t.: Formal description of non-functional service properties. Technical FIT-TR-2005-01, Queensland University of Technology, Brisbane (2005) Available from http://www.citi.qut.edu.au/about/research_pubs/technical/non-functional.jsp, accessed on 15-Feb-2005.
  7. Dumas, M., O'Sullivan, J., Heravizadeh, M., Edmond, D., Hofstede, A.t.: Towards a Semantic Framework for Service Description. In Meersman, R., Aberer, K., Dillon, T., eds.: Proceedings of the 9th International Federation for Information Processing (IFIP) Conference on Database Semantics - Semantic Issues in e-Commerce Systems. Volume 239 of IFIP International Federation for Information Processing, Hong Kong, China, Kluwer Academic Publishers (2001) 277­-291.
  8. O'Sullivan, J., Edmond, D., Hofstede, A.H.t.: service-description.com (2005) Available from http://www.service-description.com/, accessed on 15-Feb-2005.