OWL-S An alternative perspective Terry R Payne Intelligence

OWL-S An alternative perspective Terry R. Payne Intelligence, Agents, Multimedia Group University of Southampton Intelligence Agents Multimedia

Web Services A new paradigm? Or just the new black?

Web Services - A New Paradigm? • Web Services heralded as: § “… self-contained, self-describing, modular applications that can be published, located, and invoked across the Web…” • Which will allow… § …large companies to shrink around their core competencies into small, flexible, and highly profitable units § …on the fly composition of new functionality through the use of loosely coupled reusable software components § …decomposition and distribution of large-scale processing tasks into component tasks executed simultaneously across many devices

Web Services - Liberating the Machine • Web Services traditionally have a human interface § Required information is presented using forms § Humans interpret labels and enter corresponding information § Humans interpret resulting information • Form-based interaction ill-suited for machine comprehension § Prior knowledge can be used to prime parsing of pages - E. g. screen scraping § CGI-based services can ignore presented page and submit a preformed request directly to the server • Web Services make the implicit specifications explicit!

Perspectives on Web Services 1 • Functional (Request-Response) Services § Search Engines or conversion services § May be implemented simply in Java (e. g. unit conversion) or use GET/POST protocol

Perspectives on Web Services 2 • Conversational Services § Online Shopping § Require the user to navigate several stages before transaction is complete

Interaction Mechanisms • Functional – i. e. Request-Response § User visits a page and types in request § Web service returns an answer • Conversational – i. e. Solicit-Response interaction § Analogous to being asked questions to refine the request! § Triggered by the user visiting the page, of course § Whilst attempting to satisfy user’s request, the Web service presents a page containing information and choice § User responds with information § Ultimately, the service returns the desired response to the initial request

Human Oriented Services vs Machine Oriented Services • WWW is organized around URIs, HTML, and HTTP. § URIs provide defined ids to refer to elements on the web - URLs are machine resolvable, but other URIs may resolve to any object… § HTML provides a standardized way to describe document structures - allowing browsers to render information for the human reader § HTTP defines a protocol to retrieve information from the web. - resulting in a near-ubiquitous communication framework • Not surprisingly, web services require a similar infrastructure around UDDI, WSDL, and SOAP. Source: Dieter Fensel & Christoph Bussler

From Human to Machine… UDDI WSDL SOAP URI HTML HTTP Source: Dieter Fensel & Christoph Bussler

XML BPEL 4 WS WS-Security WS-Routing etc… WS-Chor Overview of Web Services Standards • Data and Control Flow descriptions of Web Services; Security and Management UDDI • A mechanism for registering and looking up web services WSDL • Programmatic way of describing the Web Service Interface SOAP • Web Services Communication protocol HTTP

A Case of Too Many Proposals? • Many other Web Services Proposals exist: § Transport - DIME - Direct Internet Message Encapsulation - HTTPR - Reliable HTTP § Packaging & Extensions - SOAP-DSIG - SOAP Security Extensions: Digital Signature SWA - SOAP - Messages with Attachments WS-License - Web Services License Language WS-Referral - Web Services Referral Protocol WS-Routing - Web Services Routing Protocol WS-Security - Web Services Security Language Source: Pavel Kulchenko - http: //www. xml. com/pub/a/2002/01/09/soap. html? page=1

A Case of Too Many Proposals? • Other Web Services Proposals have come (and gone!): § Description - BPEL 4 WS - Business Processing Execution Language for Web WSCM - Web Services Component Model WSMF - Web Services Modeling Framework WSML - Web Services Meta Language WSOL - Web Service Offerings Language WSXL - Web Services Experience Language WSUI - Web Services User Interface XLANG - Web Services for Business Process Design § Discovery - USML - UDDI Search Markup Language - WS-Inspection - Web Services Inspection Language Source: Pavel Kulchenko - http: //www. xml. com/pub/a/2002/01/09/soap. html? page=1

The whole picture, or just a small part? • UDDI, WSDL, and SOAP are important steps into the direction of a web populated by services. § However, they only address part of the overall stack that needs to be available in order to achieve the WS Vision § Are they really addressing the needs of Agents? • Lets recap on what WS and Agents are… Source: Dieter Fensel & Christoph Bussler

Several characteristics of Web Services? • A Web Service is accessible over the Web. • Web Services communicate using platformindependent and language-neutral Web protocols • A Web Service provides a specific functionality that can be used by other programs • Web Services can be located through Web Service Registries Many of these characteristics are shared by Multi Agent Systems… … but is that the whole picture?

Example Agent Architecture - Retsina

Agents vs Web Services • The WS stack provides a representation specification: § SOAP messages can support communication § WSDL - declarative specifications of meaningful messages - Typically thought of as describing service interfaces, but a WSDL operation isn’t necessarily a service! § BEPL 4 WS - describes coordination between operations - Still need to determine if the service (with multiple execution paths) can deliver meaningful results given a set of beliefs § WS-Chor - describes how several services interact to achieve a joint goal - Still need to plan across a dynamic space of services to determine a coalition that will achieve this goal - This may also require supporting services • (e. g. Agent-based commitment, or GRID reservations)

One Advantage of building on Web Services • Web Services have: § provided de facto standard for ubiquitous communication - http !!! § provided a unified base representation language - § provided a universal naming scheme - Universal Resources Identifiers - Name Spaces • All this is syntax, but what does it all mean? § And if it means something to you, does it mean the same to me?

The Need for Semantics for Services • Both Web Services and Multi Agent Systems benefit from inclusion of semantics § For example, DAML - DARPA Agent Markup Language was designed to provide ontologies and description logics for Agent Markup to improve interoperability § Semantic Web provides open, extensible, semantic framework for describing and publishing semantic content • Benefits? § Improved interoperability § Automated service composition, discovery and invocation § Access to knowledge on the internet

Requirements… • Need a framework to provide semantic descriptions of these services to support § Invocation of a previously-unseen service § Composition of several services to achieve a goal § Planning / Model Checking to determine valid execution paths through the composition • For Example § “…generate a workflow to buy all the books within a set, given that only sub-sets of the books are available at any given online book store…” - Jim Hendler

Semantics on the Web • With the Web being such a rich resource, it has been the target of many Semantic efforts § Ontobroker § i. Brow § SHOE • Development of common representation format, shared ontologies, reasoning mechanisms, and query engines to support improved utilisation of Web knowledge Semantic Web has emerged from this to provide description logics and extendable ontologies

The Semantic Web “The Semantic Web is an extension of the current Web in which information is given a well-defined meaning, better enabling computers and people to work in cooperation. It is the idea of having data on the Web defined and linked in a way that it can be used for more effective discovery, automation, integration and reuse across various applications. The Web can reach its full potential if it becomes a place where data can be processed by automated tools as well as people” From the W 3 C Semantic Web Activity statement “computational agents require machine-readable descriptions of the content and capabilities of web accessible resources. These descriptions must be in addition to the human-readable versions of that information. “ From the OWL Guide

Tackling Semantic Interoperability… • Semantic Interoperability is a major hurdle for § Locating Services - Different terms used for advertisements and requests § Negotiating contracts & communications - Different protocols used by different communities when agreeing whether to transact § Invoking - Constructing valid messages based on the published signature/interface of a service § Understanding - Interpreting the results of invoking a service § Composing Services - Constructing plans to achieve meta-goals based on available Services/Agents

Examples of Semantic Mismatch • Semantic Mismatch at the Content Level § Provider returns value Pennsylvania, but requester only understands two letter state codes (i. e. PA) • Semantic Mismatch at the Attribute level § Requester needs rainfall but provider provides precipitation • Semantic Mismatch at the level of Units § Requester has value in inches, but provider requires cm • Semantic Mismatch at the Message level § Requester has length & width, provider requires area

Semantic Web Services • DAML-S (OWL-S) Coalition formed § To explore how Distributed (i. e. Web-Based) semantics could be used to describe agents and facilitate knowledge exchange § Developed a high level architecture and set of ontologies for services § Emphasis moved from Agents to Web Services…

DAML-S & OWL-S • DAML-S: A DARPA Agent Markup Language for Services § An upper ontology for describing properties & capabilities of agents & (Web) services in an unambiguous, computer interpretable markup language. § Originally a DAML+OIL Ontology for (Web) services § Now based on OWL - Web Ontology Language • AI-inspired markup language: § § tailored to the representational needs of Services expressive power well-defined semantics ontologies support reuse, mapping, succinct markup, . . .

OWL-S Objectives • Provide: § An upper ontology for describing properties & capabilities of agents & (Web) services in an unambiguous, computer interpretable markup language. § Supporting ontologies for describing service types, security definitions, execution parameters, access and invocation characteristics. § Guidelines for advertising, modeling and requesting services. § Infrastructure to support the location and invocation of services.

OWL-S Objectives • Model services using DAML syntax and descriptionlogics • Achieve semantic interoperability through tight coupling with Semantic Web standards. • Automate: § § WS Discovery WS Invocation WS Selection, Composition & Interoperation WS Execution Monitoring

Automating WS Discovery & Selection • Support tasks such as - Find me an airline that can fly me to Sardinia • Issues: § How are service capabilities defined in the advertisement/request? - How are constraints specified? § How do mediation/discovery services affect the format of the request specification?

Automating WS Invocation • Support tasks such as - Book flight tickets from Alitalia to arrive on the 9 th June. • Issues: § What is the format of the messages sent between service provider and service requester? § How are values in incoming messages validated to ensure successful invocation?

Automating WS Composition & Interoperation • Support tasks such as: - Arrange travel from Pittsburgh to Civitavecchia via Rome. • Issues: § How are composite tasks defined? § How are multi-party interactions mediated? § How are tasks decomposed - Matching with pre-defined composite models? - Planning based on known or discovered services?

Automating WS Execution Monitoring • Support tasks such as - Have the ferry tickets been reserved yet? ? • Issues: § How does a service monitor and share its current execution status? § How are execution monitoring queries defined? § How are failures and aborts handled?

Standards for Web Services on the Semantic Web • Representation § RDF • Description Logic § DAML+OIL & OWL • Service Ontologies / Methodologies § DAML-S / OWL-S - Service Profiles - Process Models - Service Grounding § Alternate Approaches - IRS & Problem Solving Methods - WSMO

Building on Existing Web Services Standards OWL-S Service Matching XML OWL-S (Grounding) UDDI WSDL SOAP HTTP

Web Services Description Language • Extensible XML based description of web based services and how they are invoked • Allow for several interfaces using different communication languages § E. g. http, SOAP, etc. • Supports simple transactions (operations) § E. g. request-response, solicit-response, etc. • Used within OWL-S to describe interface and simple transaction protocol for atomic services.

UDDI: Universal Discovery, Description and Integration • Provides registries and simple lookup services for: § § § White Pages Yellow Pages Green Pages • UDDI T-models have been defined to support UDDIbased OWL-S Profile descriptions • CMU’s OWL-S Matchmaker extends UDDI server to provide semantic service-capability requests.

OWL-S Upper Ontology . input types. output types. preconditions. postconditions . communication protocol (RPC, HTTP, …). port number. marshalling/serialization • process flow • composition hierarchy • process definitions

Constructing a service 1. Describe the process model § § Atomic (functional) or composite (conversational) Determining what to expose - Just interaction points Additional process information for reasoning • 2. Describe the profile and advertise § § 3. Expose input & outputs, preconditions and effects Determine relevant metadata Bind to a transport mechanism via the grounding § 4. Transporting Wine trans-continental Provide (or augment existing) WSDL document and bind to it Define the Service concept to link the models together § § § presents profile described. By process supports grounding

Presenting Service Profiles • Service Profile § Presented by a service. § Represents “what the service provides” § One can derive: - Service Advertisements - Service Requests

Describing the profile • A profile represents a functional description of the service capabilities § Describe: - Dataflow properties • Inputs required to invoke the service • Outputs that are generated by the service - World State properties • Preconditions that should be satisfied • Effects that will be asserted if the service execution is successful • Service metadata is presented § Determine additional data that should be used when searching for, or selecting services - Quality of Service Parameters - References to supporting services - etc

OWL-S Service Profile Non Functional Properties Functionality Description

OWL-S Service Profile Functionality Description • Functional Specification of what the service provides in terms of parameters, subclassed as: § preconditions § inputs § outputs § effects • Summarizes the abstract capability of a service.

OWL-S Service Profile Functionality Description • Preconditions § Set of conditions that should hold prior to service invocation • Inputs § Set of necessary inputs that the requester should provide to invoke the service • Outputs § Results that the requester should expect after interaction with the service provider is completed • Effects § Set of statements that should hold true if the service is invoked successfully. § Often refer to real-world effects - Package being delivered, or Credit card being debited

OWL-S Service Profile Functionality Description • An Input/Output/Precondition/Effect parameter has three properties: § parameter. Name: the name of the parameter § restricted. To : a resource corresponding to some RDF/DAML property type within some ontology (i. e. the range of a parameter instance) § refers. To : the corresponding parameter defined within the process model

OWL-S Service Profile Functionality Description

OWL-S Service Profile Non Functional Properties • Provides supporting information about the service.

OWL-S Service Profile Non Functional Properties • These include § § § § service. Name text. Description has_process quality. Rating service. Parameter service. Category contact. Information

OWL-S Service Profile Non Functional Properties - Quality. Rating

OWL-S Service Profile Non Functional Properties – Service. Category

OWL-S Service Profile Non Functional Properties – Service. Parameter

Profile Hierarchy • Sub-classing the Profile model facilitates the creation and specialisation of service categories • Each subclass can: § Introduce new properties § Place restrictions on existing properties • Sub-classing can also be used to specialise requests for service • An example Profile Hierarchy is provided, but others could just as easily be defined

Profile Hierarchy – sample ontology

Describing Service Models • Service Process § Describes how a service works. • Facilitates § (automated) Web service invocation § composition § interoperation § monitoring

OWL-S Service Model (Overview)

Processes within the Process Model • Three types of Process § Atomic - invokable, bound to grounding § Simple - Provides abstraction, encapsulation etc. Not invokable unless realized as an atomic process, or expanded into a composite process § Composite process - Models the workflow of several simple or atomic processes • Each process type can express IOPEs § IOPEs bound to atomic processes, or inferred as computed IOPEs

Process Model Control Constructs • Four types of control construct § Sequential, concurrent, conditional, and iteration • Test and conditional constructs used to control workflow

Composite Process Example (Sequence) Composite Process Book. Flight Get Flight Details Get Contact Details Sequence Reserve Flight Sequence Confirm Reservation

Composition of Services • Two definitions commonly used: 1. The workflow or business model of a service. - Describes: • • conversation & interaction between provider and requester abstract description of internal model assumed by provider 2. On the fly construction of plans that achieve meta goals based on available services. • Creating new plans / workflows from existing services…

Composition of Services • Services may themselves be composed by a number of other services. § Can be broken down into a hierarchy of subtasks § Subtasks may be part of a larger service offered by a service provider - e. g. process of logging into an account § May be offered by a different service provider - e. g. booking a hotel as part of a travel plan • Mind Swap’s Web Service Composer § Demonstrates how tasks can be composed from different DAML-S services. § Leads the user (via a web interface) through a top-down view of the composition - http: //www. mindswap. org/~evren/composer/

Mind. Swap’s Web Service Composer

Supporting a Service Grounding • Service Grounding § Provides a specification of service access information. § Service Model + Grounding give everything needed for using the service § Builds upon WSDL to define message structure and physical binding layer • Specifies: § communication protocols, transport mechanisms, agent communication languages, etc.

Service Grounding: “How to access it” • • • How to access the service Implementation-specific Message formatting, transport mechanisms, protocols, serializations of types • Service Model + Grounding give everything needed for using the service

OWL-S / WSDL Binding OWL-S Process Model Atomic Process DL-based Types Inputs / Outputs Message Operation Binding to SOAP, HTTP, etc. WSDL

OWL-S / WSDL Mapping

Mapping Messages and Parts Service Grounding WSDL Definition

Resources Available – Tools & Examples

OWL-S Matchmaker • Filter-Based Semantic Matching Engine for OWL-S profiles based on heuristic filters § Logical inference on the OWL Ontologies guarantee correctness of matching § Information Retrieval techniques that help to speed up the matching • Extends an existing UDDI server § Enable capability descriptions and matching of DAML enabled services registered with UDDI

OWL-S Matchmaker Processing Module Ontology Server Ontology DB Ontology filter Comment filter Words DB Ontology Reasoner Profile DB TF/IDF Calculator Similarity Subsumption Constraint filter OWL-S Matchmaking Engine

WSDL 2 DAML-S Converter • Provides partial conversion from WSDL Web service descriptions to OWL-S descriptions § Generates complete specification of Grounding § Partial Specification of the Process Model - Including Atomic Processes § Partial Model of the Profile • Resulting models require additional annotations to include semantic descriptions • Web Based Interface http: //www. daml. ri. cmu. edu/wsdl 2 damls/

Mind. Swap’s Web Service Composer • Demonstrates how tasks can be composed from different OWL-S services. • Leads the user (via a web interface) through a topdown dynamic view of the composition • Generates a composition that is then directly executable through WSDL groundings. http: //www. mindswap. org/~evren/composer/

KSL DAML-S Editor Define the control structure for composite services

Task Computing • Task Computing Environment § Implemented using RDF, OWL-S and pervasive computing discovery (UPn. P). § Supports composition of services within a pervasive environment § Generates OWL-S process models which are then enacted http: //www. flacp. fujitsulabs. com/~rmasuoka/papers/Task-Computing-ISWC 2003. html

Remaining Issues and Challenges Additional Perspectives

Agents, Services and Processes • Proposed definitions for what constitutes a service / process / agent. . . § Agent: - Intelligent Autonomous Entity capable of offering several services (providing different functionalities) § Service: - Encapsulated functionality (or set of functionalities) that achieve a goal (in a variety of ways). Two types… • Core Service - The main functionality offered • Ancilliary Services - Additional functionalities that support the core service § Process: - Declared sub-components within the service • Composite Process can be hierachically decomposed • Simple Process provides abstraction of a service • Atomic Process has a defined grounding to support invocation/data passing NOTE - Not necessarily the agreed definition across the community!

Current confusion between Services and Processes - service or process composition? • Service composition is currently achieved through process composition • No clear distinction between service-client dialog and coordination of multiple services

Ancillary Services • Provide loosely-bound support for a core service § Additional services, e. g. reservation, commitment - This service should be available at 10 am Thursday, when the prior workflow completes. Can I reserve this service? § Higher order services, based on parametric call - If I invoke this service with these parameters, when will it complete, and what will it cost? • Such ancilliary services necessary for Grid services • Also exist within many agent frameworks § Supporting FIPA behaviors, such as responding to queries § Supporting Commitment or Team-based behaviors

Example - Stock Purchaser • Stock purchasing service can be used to buy stock. It charges a commission wich is a function on the volume of stock bought. Interaction is through a dialog, where the price is provided and creditcard details a requested. § Service provides: - Core Service: Purchase_Stock - Anciliary Service: Execution_Cost (based on calling parameters) Stock_Buying_Service Ticker_symbol Quantity Purchase_Stock-Price Credit. Card# Quantity Stock-Price (atomic service) Sequence (control flow) (composite service) Ticker_symbol Check_Price Execution_Cost (atomic service) Buy_Stock (atomic service) Cost Reciept-Ref

Oblex view of Services • Describing bundles of services § Akkermans et al • Supports relationships between services § § § Core service - main functionality Supporting Service - mandatory additional functionality Extending Service - optional additional functionality • Service bundling common in the business world § E. g. Phone or Electricity operators • Formal concepts applied to agents have received little attention § May facilitate planning or service composition?

Service Dialog • Individual processes indicate dialog points when interacting with the core service Buy_Stock Check_Price (atomic service) Client • Issue: Client is performing some task based on results of Check_Price - this should be defined § Such actions are defined within Agent-based dialog protocols [Mc. Burney & Parsons, 2003] • Need to use the Simple Process

Example - Modified Stock Purchaser • Add behavior expected from the client as a simple process § Should be expanded by the client into an atomic service the client provides, that the client uses to decide whether to buy at the given price. Stock_Buying_Service Ticker_symbol Check_Price Quantity Stock-Price (atomic service) Purchase_Stock Sequence (control flow) (composite service) Stock-Price Commit_to_Buy (simple service) Stock-Price Credit. Card# Sequence (control flow) Stock-Price Credit. Card# Ticker_symbol Quantity Execution_Cost (atomic service) Buy_Stock (atomic service) Cost Reciept-Ref

Planning for dialogs • Planning is necessary to determine execution paths through service dialogue § i. e. Model Checking § Given a set of beliefs, can the agent: - 1) Understand the different stages of the dialog 2) Provide necessary resources to satisfy the dialog 3) Trust the service given the resource requirements and client expectations • Also necessary to: § Determine if client can perform the dialog task (based on its own capabilities) § Determine if the task should be delegated to a third party

Planning also used for Service composition • Several services can be combined to achieve higher level goals § e. g. many book stores offer book-buying services. Another may provide a currency conversion service. § To achieve Jim’s goal, many book-buying services may need to be combined, including those out of the country - which need the prices converting to ? ? ? into dollars • This is the commonly used definition of “Service Composition” § May result in several services being choreographed according to the composed model / workflow § Different compositions require different control structures…

Service and Process Interaction • Conversational Service involves interaction with client throughout the process model (Hub-n-Spoke model) P 1 P 2 P 3 Client § This is the approach currently assumed by OWL-S • Pipelining service composed of several other services § Client provides data at start, and retrieves result at end P 1 P 2 P 3 Client § This is the approach often required by GRID Services

Partially Instantiated Services • Workflows may be generated by hand, as well as through automated composition § Some service instances may be mandatory, and shouldn’t be replaced through discovery. - E. g. P 2 below § Other services can be selected for the plan at plan/execution time - E. g. P 1 and P 3 below Any P 1 P 2 at http: //… Client Any P 3

Wrap up… Agents, Web Services and OWL-S • There exists a considerable body of work on Agents § encompasses notions of - communication negotiation / argumentation / auctions commitment, coalitions, communities evolving behaviour and adaptation autonomous behaviour § Different MAS have different ways of defining these - both in terms of syntax, and their semantics • Web Services provide § a declarative specification of - messages workflows, orchestrations, and choreographies resources, security requirements, contracts § Standardized syntax (XML) but lacking: - higher level autonomous reasoning, adaptation and coordination - formal semantics to support interoperation between services

Wrap up… Agents, Web Services and OWL-S • OWL-S provides § Set of ontologies for defining services, that support: - Discovery - Workflow analysis, composition - Service invocation / interaction § Initial design grounded in AI techniques - but focus shifted towards augmenting Web Services • Question: Are requirements of Agents the same as WS? § From a simple, functional perspective… perhaps… § but complex multi-agent behaviors requires a richer, dynamic representation - Many Agent theories have no analogies within the WS community… yet!

Questions? Intelligence Agents Multimedia