[SWSL] requirements and proposed revisions for Semantic Web Servi ces Language

The SWSL committee is developing a statement of requirements for 
Semantic Web Services Language, which is currently in draft condition, 
available here:
     http://www.daml.org/services/swsl/requirements/swsl-requirements.shtml

Here are some proposed revisions.


Section 1 - INTRODUCTION
-RATIONALE

--OLD:
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. 

REPLACE WITH:
Advertising and matchmaking. In order for aN service to be used it needs to be discovered and a SUITABLE correspondence needs to be established between the goal of the client agent with the capabilities of the service. IN GENERAL, GIVEN A CLIENT GOAL, A (POSSIBLY SINGLETON) SET OF SERVICES SHOULD BE IDENTIFIED THAT SUITABLY COMBINED ALLOWS THE CLIENT TO ACHIEVE THE GOAL. INDEED, THE DISCOVERY MAY BE "ONE-TO-ONE", THAT IS, A GOAL SPECIFIED BY THE CLIENT CORRESPONDS TO A SINGLE SERVICE, OR "ONE-TO-MANY", THAT IS, THE GOAL OF THE CLIENT IS SATISFIED BY A NEW SERVICE OBTAINED BY COORDINATING SERVICES FROM THE RETURNED SET. 


--OLD: 
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. 

REPLACE WITH:
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 A (POSSIBLY SINGLETON) SET OF serviceS. 


- Process Modeling.

-- OLD
Composite processes can be created "by hand" by the user, or they can be produced automatically by a planning agent.

ADD:
Composite processes can be created "by hand" by the user or they can be produced automatically by a planning agent. HOWEVER, BETWEEN THESE TWO APPROACHES, SEVERAL INTERMEDIATE ONES CAN BE IDENTIFIED: FOR EXAMPLE, A COMPOSITE SERVICE CAN BE BUILT BY SEMI-AUTOMATED TOOLS, IMPLEMENTING A COMPOSITION ALGORITHM, THAT ACT AS A SUPPORT FOR THE COMPOSITE SERVICE DESIGNER, OR THAT INVOLVE MIXED INTERACTION GUIDED BY THE USER, BETWEEN THE USER HIMSELF AND ITS AGENT.



Section 2: General Requirements:
--OLD:
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? 


--ADD: 


This group [...] services.
Examples of such requirements are the particular aspects of the logic languages that might be required IN ORDER TO GIVE A COMPLETE AND FORMAL CHARACTERIZATION OF SERVICES, e.g.,[...]Logic?

ADDITIONALLY, THE LANGUAGE SHOULD BE EQUIPPED WITH SOUND AND COMPLETE REASONING ALGORITHMS. THEREFORE, IN ORDER TO CHOOSE THE RIGHT FORMALISM, THE TRADE OFF SHOULD BE CONSIDERED BETWEEN THE EXPRESSIVITY OF THE CHOSEN LANGUAGE AND ITS SUPPORT OF AUTOMATED REASONING TECHNIQUES, E.G., WHICH FEATURES SHOULD THIS LANGUAGE HAVE IN ORDER TO PROVIDE AUTOMATED REASONING SUPPORT AND TO CAPTURE AS MUCH OF THE REQUIREMENTS AS POSSIBLE?. WHICH IS THE ACCEPTED COMPUTATIONAL COMPLEXITY CHARACTERIZATION OF THE REASONING ALGORITHMS? IT MAY BE USEFUL TO EXPLORE A FORMALISM IN WHICH DIFFERENT SUBSETS OF IT MAY HAVE DIFFERENT COMPLEXITY CHARACTERIZATIONS. FOR EXAMPLE, EACH SUBSET CAN ADDRESS DIFFERENT ACTIVITIES, E.G., MATCHMAKING, NEGOTIATION, COMPOSITION, OR THEY CAN CORRESPOND TO SEVERAL LEVELS OF ABSTRACTIONS, E.G., THOSE RELATED TO SEQUENCING BEHAVIOR, PARAMETERS AND DATA FLOW, EXCEPTION HANDLING, CONDITIONAL (I.E., RUN-TIME) PLANNING,ETC.

- General Language Property:

--ADD AS 4th bullet: 
the language should be equipped with sound and complete reasoning
algorithms.



Daniela Berardi and Rick Hull

Received on Thursday, 12 February 2004 09:53:15 UTC