Semantic Web Services Language Requirements

1. Semantic Web Services Language Requirements Presenter: Emilia Cimpian http://www.daml.org/services/swsl/requirements/

2. Overview of Topics • Introduction • Formalization (General Requirements) • Functional Requirements

3. Introduction • SWSI Language Committee • to develop computer language technology that will provide a firm, long-term foundation for the future of Web services on the Internet • formal language that allows for rich declarative specification of a wide variety of information about Web services • starting point – OWL-S

4. Introduction • Requirements (SWSL): • Formalization • Functional

5. General Requirements • General Language Properties • Expressive Power • Meta Properties

6. General Requirements- General Language Properties - • Declarative semantics • Compositional • Extensible

7. General Requirements- Expressive Power - • Interface description • Functional & behavioral specification on component software • Simple workflow description • Incomplete service specification • Constraints & temporal constraints satisfaction • Exceptions • Plans and planning domains • Scheduling • Policies • Hypothetical scenarios • Composition of sub-activities

8. General Requirements- Meta Properties - • Understandable • Easy to be written by a broad range of practitioners • Possibility of integration • Address aspects of the web services • Interoperable with automated reasoning techniques • Extendable annotation mechanism

9. General Requirements- Meta Properties - • Capable of: • Linking the remote service specifications • Supporting analyses • Interoperating with programs that can execute a process model • Multi-party activities across organizational boundaries • Lifecycle management and process control • Specification of taxonomies of services and service descriptions • Importing external ontologies

10. Functional Requirements • Advertising and Matching • Negotiation and Contracting • Process Modeling • Process Enactment

11. Functional Requirements- Advertising and Matching - • The language must support: • Description of the functionality of the core component service • Knowledge state • Data interfaces • Description of a wide range of characteristics • Relaxation of certain properties • Definition of service request • Ordering, ranking and filtering of matches

12. Functional Requirements- Advertising and Matching - • The definition of service description must consider issues like scale and distributed discovery • No assumption should be made on the architecture of discovery services that utilize or mediate service descriptions and service requests • One must be able to determine how a service request relates to matching service descriptions • “No Eyeballs Always Required” • Consistency between advertise service descriptions and their process descriptions

13. Functional Requirements- Advertising and Matching - • Objectives: • Possibility to identify cases where service descriptions deviate a valid representation of the service • Sufficient accessible information for a human intervention • Easy for people to read, write and understand service descriptions

14. Functional Requirements- Contracting and Negotiation - • The language must support • Wide variety of attributes/aspects of a deal • Committed/proposed contractual agreements • Partial/complete contracts or contract proposals • Representation of business partner qualification • Communication between contracting parties • Modification of proposed/committed deals • Execution of contract provisions • Monitoring of execution of committed deals • Hypothetical reasoning about the contract/proposal

15. Functional Requirements- Contracting and Negotiation - • Objectives • Complement development of standard/common ontologies for frequently needed contract characteristics • Complement other emerging standard efforts • Should seek to represent commitments in such a way as to mesh well all methods of dispute resolution and recourse • Should seek to be compatible with the contract aspects of the existing industry standards for web services

16. Functional Requirements- Process Modeling - • Ordering and temporal constraints • State constraints • Resource constraints • Composition

17. Functional Requirements- Process Modeling - • Objectives • Compatibility with existing process modeling standards • Support mappings from existing process modeling software tools.

18. Functional Requirements- Enactment - • Describe and allow for the invocation of services via service endpoints • Recognize and handle exceptions • Constraint checking • Security aspects • Policy aspects • "Make it so" elements to link to the environment • Dealing with the status of services, resource levels, epistemic states of actors • Logging, metering, billing, auditing, notification

19. Functional Requirements- Enactment - • Services metrics, Quality of Service guarantees • Dispute Resolution and Compliance • Explanation • Health checks and debugging aids • Redundancy and Robustness • Resource allocation and load balancing • Allowance for dynamic runtime aspects of discovery, composition and negotiation of services on-the-fly • Version update while services are live

20. Functional Requirements- Enactment - • Objectives • complement well other emerging standards efforts relevant to enactment and execution • significant enhancement to existing or emerging web service enactment protocols