Semantic Web Services Language Requirements

Version 1

This version:

http://www.daml.org/services/swsl/requirements/swsl-requirements.shtml

Latest version:

http://www.daml.org/services/swsl/requirements/swsl-requirements.shtml

Editors:

Benjamin Grosof (Massachusetts Institute of Technology)
Michael Gruninger (University of Maryland, College Park)
Michael Kifer (State University of New York, Stony Brook)
David Martin (SRI International)
Deborah McGuinness (KSL, Stanford University)
Bijan Parsia (University of Maryland, College Park)
Terry Payne (University of Southampton)
Austin Tate (AIAI, University of Edinburgh)

Abstract

This document specifies requirements and objectives for a language to support the most salient aspects of Semantic Web Serives.

Status of this document

Table of contents

• 1. Introduction
• 2. General Requirements
• 3. Process Modeling
  
• 4. Advertising and Matchmaking
  
• 5. Negotiation and Contracting
  
• 6. Process Enactment
  
• 7 Glossary
• References
• Acknowledgments

1 Introduction

The Committee seeks to develop a formal language that allows for rich declarative specification of a wide variety of information about Web services, which will support automation of a broad spectrum of activities related to Web services, such as discovery, selection, composition, negotiation and contracting, invocation, monitoring of progress, and recovery from failure.

The committee aims to build on the success of OWL-S, taking the existing language as a starting point, while allowing scope for the revisions and additions necessary to address these new requirements.

This document discusses the requirements for such a language.

Rationale

SWSL has divided the requirements for Semantic Web services languages into two categories -- functional requirements and formalization.

• Functional requirements: These are the requirements to support the various aspects around operation of and interaction with one or more Semantic Web services. These requirements are subdivided into four broad categories. While there is overlap between the categories, they highlight four fundamentally different perspectives on services and their composition, and suggest the different kinds of modeling and reasoning that must to be addressed.


• Advertising and matchmaking. In order for a new service to be used it needs to be discovered and a correspondence needs to be established between the goals of the client agent with the capabilities of the service.

  Discovery is made possible primarily by a set of semantic descriptions, which are analogous to advertising in the material world. To illustrate the focus here, it is useful to thing in terms of the kinds of descriptions of service capabilities found in real life advertisements (such as offers of a cheap long-distance phone service), although this information needs to be expressed in a formal logical language.

  On the client side, the goals of the agent must also be described in a formal language. The primary purpose of matchmaking is to find a "sufficiently good" similarity between the goals of the client agent and the advertised capabilities of the service. Generally, the match is determined by heuristic algorithms, which are aided by domain-specific ontologies that define the terms used in the advertisements as well as descriptions of the agent's goals.

  WSDL and analogous signature-like descriptions based on parameter types or sequential behaviors can also be used in support of matchmaking. Once a first phase of matchmaking is accomplished based on semantic descriptions, a second and more detailed determination of the "fit" between discovered services can be performed using signature-like descriptions.

• Negotiation and contracting. A semantic correspondence produced by the process of matchmaking is no guarantee that the client can actually use the service. For instance, the service might not accepts the type of credit card that the client plans to use. Making sure that the client can, indeed, use the service (i.e., the service satisfies the functional goals of the agent) and that the terms of the use are acceptable to both sides (e.g., qualitative goals, behavioral properties) is the purpose of negotiation and contracting.

  Negotiation and contracting is enabled by a formal description of the capabilities of a service. (Note that WSDL is not enough for this purpose, since it is not capable of stating what a service does -- only how to invoke it.) Note that description of service capabilities is related to advertisements and a subset of such descriptions can be expressed using the same formalism. However, advertisements will probably require different types of ontologies (for instance, the concept of "cheapness" is less likely to be useful in contracting, while it is obviously useful in advertising). In addition, contracts may have behavioral, process-like aspects, which would describe what the service will do in response to certain client actions. For instance, a contract might say that the service will collect escrow if the client cancels the contract after certain date.

• Process modeling. Process modeling is relevant to several aspects of Semantic Web services. We already mentioned the possible role in describing the behavioral aspects of contracting. Service composition is another application domain, since a composite service is, obviously, a process with a possibly nontrivial internal structure. Composite processes can be created "by hand" by the user or they can be produced automatically by a planning agent. In addition, the service might provide an abstract model of its underlying process to either assure its customers or, possibly, to enable simulation of the service's operations. Formalisms that describe data types (such as WSDL), sequential patterns of operation, and related properties can be useful in reasoning about service compositions and their process models.

• Process enactment. The client must be able to monitor the execution of a composite service -- a concept well-familiar in workflow management. For instance, the client might decide to cancel, if the service invocation is far from being finished or to wait otherwise. To enable monitoring, some structure of the process underlying the service might need to be exposed to the client. Thus, process modeling and monitoring are closely related. Process enactment also involves other aspects, such as "wrapping" of components (e.g., to re-format parameters passed between services), constraint checking during execution, authorization, exception handling, etc.


• Formalization: These requirements are intended to help identify the formalisms that can adequately support the functional requirements. They are also intended to enable such activities as formal translations between SWSL and other formalisms and languages, and analysis and verification of properties of SWSL artifacts.

2 General Requirements

This group of requirements is intended to help choose the formalisms necessary to support the functional requirements of Semantic Web services. Examples of such requirements are the particular aspects of the logic languages that might be required, e.g., will first-order logic suffice? will the language include non-monotonic defaults? meta-reasoning? What style of process modeling will be required: Ontological in the style of PSL or in the logic-programming style, as in Concurrent Transaction Logic?

Most of the requirements in this category come from our analysis of the functional requirements mentioned above. Others are motivated by the work on defining the upper ontology of semantic services.

General Language Properties

• declarative semantics, in the typical sense used in knowledge representation where the meaning may be expressed in a logical framework that establishes overall principles of what conclusions are sancitoned from a set of premises
• compositional in that language constructs may be put together in an order-independent manner
• extensible in that the language can grow for example in ways described in W3C's Extensible Languages Note.
  

Expressive Power

• interface descriptions
• functional and behavioural specifications of component software
• simple workflow descriptions
• incomplete service specifications (that may evolve incrementally)
• constraints
• temporal constraint satisfaction
• exceptions
• plans and planning domains
• scheduling
• security issues (ownership, permissions, trusted boundaries, ...)
• policies
• hypothetical scenarios (what-if reasoning)
• compositions of sub-activities (where the sub-activities may have various constraints)
  

Meta properties

• understandable by a broad range of practitioners
  
• usable tools should be able to be written by a broad range of practitioners (thus enabling the quick assembly of critical mass and a user community)
• integrated with existing semantic web and industry standards, e.g.,  OWL-S, OWL, RDF, XML, SOAP, WSDL, BPEL, PSL
• able to address the knowledge representation and programming language aspects of web services
• interoperable with automated reasoning techniques
• capable of linking to remote service specifications
• capable of supporting analysis
• capable of interoperating with programs that can execute a (partial or complete) process model
• capable of supporting multi-party activities across organizational boundaries
• capable of supporting lifecycle management and process control
• capable of supporting the specification of taxonomies of services and service descriptions including the notions of cost, owners, resource requirements, payment mechanisms, etc.
• capable of importing external ontologies (e.g., time, cost, e-commerce, geospatial, etc.)
• a general extendible annotation mechanism

3 Process Modeling

Requirements

A semantic web service description is a representation of a web service which describes the activity it performs. It may be composed of any number of subactivities where the description is useful. An activity occurs over a time interval delineated by its begin and end time points. A set of constraints of various types may be expressed between domain objects and the activity, its subactivities and their associated timepoints. These may include the following:

• Ordering and temporal constraints
  • Simple workflows
  • Iterated processes
  • Duration constraints
  • Concurrency
  • Conversations
• State constraints
  • World state conditions, inputs, and outputs, epistemic states of actors
  • Preconditions and effects
  • Conditional processes
• Resource constraints
• Composition
  • Process decomposition (e.g., subactivities)
  • Nondeterminism (e.g. alternative processes)
  • Incomplete process specifications.
  • Composition that incorporates interactions among process models of multiple (possibly non-cooperative) actors
  • Support for automatic composition of processes by planning algorithms

Objectives

1. Compatibility with existing process modelling standards, such as UML and the Process Specification Language.
2. Support mappings from existing process modelling software tools.

4 Advertising and Matchmaking

Requirements

1. The language must support a description of the functionality of the core component service (i.e. a functional description), This should be provided in terms of:
   • knowledge states - i.e. a set (or subset) of states that must be externally asserted in order that the service may be invoked successfully, and also a set of states that will be asserted by the service during, or after successful invocation.
   • data interfaces - i.e. a set (or subset) of datum that is provided to the service (inputs) and a set (or subset) of data that is generated by the successful invocation of the service.
   In addition, auxiliary services (i.e. those that support or augment the management or invocation of the core component service) much be described and associated with the service description.
   Note: a successful invocation is one where the service is invoked and executes without raising any errors or exceptions.
2. The language must support, in an extensible manner, the description of a wide range of (non-functional) characteristics, that may:
   • characterise or differentiate the class or type of service;
   • support scoping or contextual relevance constraints to a service (e.g. ???);
   • define the operational characteristics of the service (e.g. temporal or geographic availability, encryption/decryption capabilities, etc);
   • define parametric characteristics that may be varied to modify the behavior of the service. Such characteristics may be used during negotiation and contracting (e.g. negotiating quality of service, etc);
   • provide additional or higher-order statements about the functionality of the service (e.g. cost of execution, typical response times etc).
3. The language must support the relaxation (or tightening) of certain properties, by service providers, service consumers, or intermediaries. That is, both service descriptions and service requests must permit variations in their exact interpretation, thus facilitating (for example) varying degrees of matching. This is sometimes known as the "misleading (or lying) advertisement" requirement.
4. The language must support the definition of a service request; i.e. a description of the desired service, such that it may be used by a discovery service to facilitate the location of a service (e.g. in the case of a registry based discovery service) or to achieve a goal (e.g. in the case of mediated discovery services).
5. The definition of service descriptions must consider issues such as scale and distributed discovery (thus supporting service discovery at the "global" Web Scale).
6. No assumptions should be made on the architecture of discovery services that utilise or mediate service descriptions and service requests. For example, one should not assume that matchmaking requires a centralised broker, etc.
7. The language must support ordering, ranking, and filtering of matches. (This is related to points 2 and 3).
8. One must be able to determine how a service request relates to matching service descriptions, in order that the matching service descriptions can be utilised by the requester. If additional facts are required to infer matches between the request and matching service descriptions (i.e. such inferences cannot be made directly from these descriptions), then they must be provided by the discovery service responsible for identifying the match. This is the "tell that they're consistent" requirement).
9. It must be possible to specify a request and matching process that is precise enough that the resulting matches can be used directly by a fully automated composition or invocation software process. (The "No Eyeballs Always Required" requirement).
10. Advertised service descriptions must be consistent (in some sense) with their (correct) process descriptions, such that they provide a valid representation of the service they are advertising.

Objectives

1. It should be possible to identify cases where service descriptions deviate from providing a valid representation of the service (defined by some model of the associated processes - see Process Modeling, below).
2. If human intervention is required in a matchmaking process, there should be sufficient accessible information to the intervener to make the intervention (proportionally) easy.
3. Service descriptions and service requests should be easy for people to read, write, understand, and predict matches, or should facilitate the creation of human-oriented descriptions that support these requirements.

5 Contracting and Negotiation

Requirements

1. representation of a wide variety of attributes/aspects of a deal (i.e., contract), particularly pricing and contingent provisions;
   • Frequently-needed contract characteristics besides pricing include, for example: quantity, form and timing of payment, delivery and shipping details including timing, refunds, cancellation, deposits, methods of recourse, performance penalties/bonuses, quality of service, business partner qualifications, reputation/rating info, notifications, roles of different parties to the contract (e.g., buyer, seller, broker, banker, auditor, notary, escrow), contract phases and renegotiation timepoints, choice of security protocols, currency units, etc.
2. representation of committed or proposed contractual agreements -- i.e., of contracts or contract proposals;
3. representation of partial or complete contracts or contract proposals;
4. representation of business partner qualification;
5. communication between contracting parties (or relevant other third parties) of proposed or committed deals (with deep shared semantics), including of bids and offers, requests for proposals/quotes;
6. modification of (proposed or committed) deals, especially during negotiation;
7. execution of contract provisions, including to draw inferences or to perform procedural business actions, e.g., to make authorizations;
8. monitoring of execution of committed deals, including to apply/execute contingent provisions, e.g., for exception handling, or for notifications during long-running services; and
9. hypothetical reasoning about the contract/proposal by contracting parties/agents (or by third parties, e.g., adjudicators of disputes), including to test or evaluate a deal during selection, matchmaking, or negotiation. Such hypothetical reasoning should support simulation and verification.

A service contract (committed or proposed, partial or complete) is an artifact that may be the final or intermediate result of a process of negotiation. Different modes of such negotiation include, for example: simple "take it or leave it"; bilateral bargaining; auction; and other kinds of conversation. A negotiation process may itself be another service (possibly a semantic web service).

Objectives

1. The language should complement development of standard/common ontologies for frequently-needed contract characteristics (e.g., the ones listed earlier).
2. The language should complement well other emerging standards efforts relevant to e-contracting beyond SWS. Candidate examples of such other emerging standards efforts include: ebXML/UBL; UNCEFACT and ANSI EDI; Oasis Legal XML; and American Bar Association (and EU etc. counterparts') proposals on e-contracts law.
3. The language should seek to represent commitments in such a way as to mesh well to methods of dispute resolution and recourse, both legal and reputational.
4. The language should seek to be compatible with, and ideally extend, the contract aspects of in existing industry standards for web services, e.g., their concepts/approaches of roles and commitments.

Relationships to Other Areas of SWSL Requirements

1. Advertising, Discovery, and Matchmaking (ADM):
   • In requests for proposals/quotes, or in auctions, the info used/usable for ADM may be largely or totally a partial subset of the info used to describe a contract.
2. Process Modeling and composition, execution and monitoring:
   • The contract may have contingent provisions which should be activated upon recognition of a condition being monitored, or the contract may include portions which invoke or specify (fairly directly) executable process specifications.
   • The language overall should support expressing, and reasoning about, service/action pre-conditions, post-conditions, and various kinds of constraints including about resources or costs.
3. Services that perform "solo" decision making within an individual contracting party during negotiation will need to input and/or output contract proposals that are communicated/shared with other contracting parties.
4. A contract may specify part of the service process model and/or part of the service profile.

6 Enactment

Requirements

The language must support, in an extensible manner, the description of a service so as to support tasks related to enactment or execution, monitoring, recovery and compliance/verification of results. These include many complex aspects, for many of which no consensus can be expected to be reached in the near future. So the approach must encompass ways in which separate emerging standards in these areas can be utilized.

Process enactment is closely related to aspects of process modelling. There are features which can be modeled, analyzed, simulated and checked at the time a process is defined, others than can be elaborated upon when a compound process is composed or synthesized, and some that can only be verified at the time of enactment. It can be expected that process modeling features will allow for effective or reliable enactment (e.g. being able to specify contingencies, exception handling and run-time policies which must be adhered to).

Some aspects that may indicate requirements for SWSL include:

1. Ability to describe and allow for the invocation of services via service endpoints
2. Ability to recognise and handle exceptions
3. Constraint checking - e.g., choreography, synchronization, parameter checks
4. Security aspects - digital rights management
5. Policy aspects - authorization, obligations, etc.
6. "Make it so" elements to link to the environment - sensing, effectors - e.g.,
• Data base query and update is one example of above
• Dealing with world state sensing, run-time modelling of state and querying this model
7. Dealing with the status of services, resource levels, epistemic states of actors (e.g. presence, availability, loading)
8. Logging, metering, billing, auditing, notification
9. Services metrics, Quality of Service guarantees
10. Dispute Resolution and Compliance
11. Explanation
12. Health checks and debugging aids
13. Redundancy and Robustness
14. Resource allocation and load balancing
15. Allowance for dynamic runtime aspects of discovery, composition and negotiation of services on-the-fly
16. Version update while services are live

Objectives

1. The language should complement well other emerging standards efforts relevant to enactment and execution. Candidate examples of such other emerging standards efforts include: WSDL, Workflow, BPEL
2. The language should be seen as an significant enhancement to existing or emerging web service enactment protocols - such as WSDL.

Relationships to Other Areas of SWSA and SWSL Requirements

Enactment may require modelling the current state in such a way that state information can be used to make progress in the processes being enacted. A key issue is where and in what way such a state model is built and kept. Can it be entirely distributed to remain within the individual services being used, or are there cases where some separately maintained state model must be kept. Is this an SWSA architecture issue?

There are several points of overlap/contact with the other aspects of SWSL requirements. Execution often involves repairing or recovering from partial or total failures, dealing with exceptions, violation of policy, etc. This can involve "going round the loop" with refining and replanning for new composite services that can meet original requirements, etc.

7 Glossary

• Advertisement:
A service description or capability request that is submitted to some individual or intermediary (e.g. a discovery service), with the intention of being "discovered" in response to (or matched with) a request.
• Capability Request:
A description of a desired service. This may be in terms of functional and/or non-functional properties, that define the salient properties of a required service, and desired characteristis that assist in the filtering and ranking of matching service descriptions.
• Contract:
Result of a negotiation process (if successful?)
• Dynamic state constraint:
Condition involving predicates on any combination of these states: initial, final, intermediate.
• Dynamic action constraint:
Condition on the order and/or occurrences of actions (e.g., action A before action B, if A and B execute then C executes, if A executes then B before C)
• Functional description:
A description of a service in terms of (a) what is required by the service in order that it can execute successfully, and (b) what is generated by the successful execution of the service. This includes data elements (i.e. data that is consumed by the service, or produced by it) and knowledge states (i.e. states that should be asserted prior to invocation, or that are generated by the service during execution).
• General constraint:
A formula involving any of the above types of predicates.
• Effect of an action:
The actual change to the initial state that the action does. Note that the effect can be specified as a formula that involves the final state, but, unlike the postcondition, such a formula is always true in any final state of the action.
• Negotiation process:
Execution of a negotiation protocol
• Non-functional Description:
A description of a service in terms of its descriptive metadata, such as a reference to a classification type, or characteristics that are not directly related to the functional description of the service.
• Postcondition of action:
A constraint that expresses a condition on the final state of action execution (what must be true in the state immediately after the action is over). Note that a postcondition is a constraint. The action definition might not imply that the postcondition is true in every possible final state of the action.
• Precondition of action:
A constraint that expresses a condition on the initial state of action execution.
• Query:
A description of the desired products of a service. This may require the synthesis of a capability request that is then matched to an advertised service description, and subsequently invoked, possibly by an intermediary.
• Request:
A service description or capability request that is submitted to some individual or intermediary (e.g. a discovery service), with the intention of finding or locating a matcing capability request or A service description already advertised.
• Service description:
A high-level description of a service, in terms of functional and non-functional properties. In the context of adverising and service discovery, service descriptions may not necessarily include process or workflow descriptions.
• Service request:
A description of a desired service. This may be in terms of functional and/or non-functional properties, that define the salient properties of a required service, and desired characteristics that assist in the filtering and ranking of matching service descriptions.

Acknowledgments

This document is a result of the work by the members of the Semantic Web Services Language committee and includes contributions from Karl Aberer, Steve Battle, Stefan Decker, Ian Horrocks, Richard Hull, Drew McDermott, and Sheila McIlraith.