May 23, 2004OWL-S straw proposal for SWSL1 OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004 David Martin Mark Burstein Drew McDermott Deb.

May 23, 2004 OWL-S straw proposal for SWSL 1

OWL-S Straw ProposalPresentation to SWSL Committee

May 23, 2004

David MartinMark Burstein

Drew McDermottDeb McGuinnessSheila McIlraith

Massimo PaolucciBijan Parsia


Outline• Overview & Features of OWL-S

– General– Profile– Process Model– Grounding

• Relationships with commercial Web service technologies

• Tools, applications & related work• Case Studies• Bridging to other SWSL proposals• Roadmap for SWSL use of OWL-S


Based on OWL (DL) ontology of services, with selected uses of rules (SWRL+)

• Analysis+ OWL-S services are part of the Semantic Web

+ SWS require the use of domain ontologies; many will be rep'n in OWL; these will be easily exploited and integrated

+ W3C status; potential for wide adoption

+ Can make direct use of OWL and SWRL + Rich data modeling features

+ Convenient and natural for (SW)S

+ OWL and SWRL reasoners / tools can be used

– Restricted expressive power: some aspects of SWS cannot be adequately expressed within the language

General Features of OWL-S


Based on OWL (DL) ontology of services, with selected uses of rules (SWRL+)

• Analysis (cont’d)- Usefulness of DL-based reasoning with process

modeling not established

- Unwieldy syntax (addressable by an OWL-S editor and/or surface language)

+ OWL has well-defined semantics

- OWL semantics do not capture all and only the intended interpretations of our OWL-S ontology (because we can't describe them within the language). Thus, there are unintended models.



Conceptual model

+ Fairly well-developed; represents significant evolution

– Lacks some rigour (could be addressed)



Growing tool base and user community

+ Tools are what brings people

- Many of these tools don't exploit the semantics of the language; they just use OWL-S as a syntax



High-level characterization/summary of a service“What does it do?”

Used for

• Constructing advertisements, requisitions

• Populating service registries• A service can have many profiles

• Automated service discovery

• Service selection (matchmaking)

Service Profile (overview):


Service Profile: Functionality Description

• Functional Specification of what the service does in terms of

– preconditionspreconditions

– inputsinputs

– outputsoutputs

– effectseffects

• Summarizes the top-level Process


Service Profile: NonFunctional Properties

• Provides supporting information about the service.


Supports 2 styles of use

• (A) Class-hierarchical “yellow pages++”• Implicit capability characterization

• Arrangement of attributes on class hierarchy

• Can use multiple inheritance

• Relies primarily on “non-functional” properties

• (B) Process summaries for planning purposes• Inputs, outputs, preconditions, effects

• Less reliance on formal hierarchical organization

• Summarizes process model specs

• Analysis+ (A) leverages work on DL-based matchmaking

+ (B) leverages work on planning

Profile Features (1)


There can be multiple profiles for a service; each loosely related to process model

• Analysis+ Allows for adverts tailored to different contexts

and audiences

+ Allows for advertising at the right level of detail

- Fully automatic generation and consistency checking of profile not possible



Same representation for:

• Service advertisements

• Service requisition

• Analysis+ Helpful in constructing matchmakers, brokers



Service Model“How does it work?”

Process– Interpretable description of service provider’s behavior– Tells service user how and when to interact (read/write

messages)

& Process control– Ontology of process state; supports status queries – (stubbed out at present)

• Used for:– Service invocation, planning/composition, interoperation,

monitoring

• All processes have– Inputs, outputs, preconditions and effects– Function/dataflow metaphor; action/process metaphor

• Composite processes– Control flow– Data flow

Process Model (overview)


Service Model / Process Model (overview)


Service Model“How does it work?”

• Expression language• Relation between outputs and

effects• Dataflow and bindings• Surface syntax

Process Model: Recent Progress


Atomic Process Definitions<process rdf:ID="order_movement"> <hasInput> <Input rdf:ID="dest"> <parameterType rdf:ID="&mil;location"/> </Input> </hasInput> <hasOutput> <Output rdf:ID="ackno"/> </hasOutput> <hasPrecondition>...</hasPrecondition> <hasResult> <Result rdf:resource="#movement_success"/> <Result rdf:resource="#movement_fail"/> </hasResult></process>


Results<Result rdf:ID="movement_success"> <inCondition rdf:datatype="&xsd;#string“ lang=“Kif”> (@mil:motion_possible) </inCondition> <withOutput> <Binding> <theParam rdf:resource="ackno"/>

<valueForm rdf:datatype="&xsd;#boolean"> true </valueForm> </Binding> </withOutput> <hasEffect rdf:datatype="&xsd;#string"> (location ?dest) </hasEffect></Result>


Embedding Expressions

We treat expressions in logical languages as literals, to avoid any danger of “accidental” interpretation

Two broad classes: XML literals and “other.”

The former are for SWRL and DRS expressions, the latter for KiF, PDDL, etc. expressions.


Another Result<Result rdf:ID="movement_failure">

<inCondition rdf:parseType="Literal“ lang=“DRS”>

<drs:Not>

<drs:term_args rdf:parseType="Collection">

<drs:Atomic_formula>

<rdf:predicate rdf:resource="&mil;motion_possible"/>

</drs:Atomic_formula>

</drs:term_args>

</drs:Not>

</inCondition>

<withOutput>

<Binding>

<theParam rdf:resource="ackno"/>

<valueForm rdf:datatype="&xsd;#boolean">false</valueForm>

</Binding>

</withOutput>

</Result>


Dataflow<Sequence rdf:parseType="Collection">

<Perform rdf:ID="step1">

<process rdf:resource="#Generate"/>

</Perform>

<Perform rdf:ID="step2">

<process rdf:resource="#Consumer"/>

<hasBinding>

<InputBinding>

<theParam rdf:resource="#consumee"/>

<valueForm parseType="Literal">

<ValueOf>

<theVar rdf:resource="#producee"/>

<fromProcess rdf:resource="#step1"/>

</ValueOf>

</valueForm>

</InputBinding>

</hasBinding>

</Perform>

</Sequence>

Output producee

From step1

Is input param consumee

To step2

Why is this a Literal?Because any expression can goHere.


Surface Syntax

• Clarity is great, but …RDF is tough to read and write.

do1: Step1; Step2(consumee <= do1.producee)


Process Syntax

• Vanilla conventions; infix notation, more C-like than Lisp-like

• Logical expressions now don’t have to be quoted in a funny way

• Output parameter values written step.param

• Input parameter bindings written

param <= val


Inputs/outputs have OWL types

• Analysis+ OWL-S processes are part of the Semantic Web

+ Rich data modeling features

+ Convenient and natural for (SW)S

+ OWL and SWRL reasoners / tools can be used

– Usefulness of DL-based (subsumption) reasoning with process modeling not established

– Unresolved issues about grounding of OWL types to WSDL message types

Process Model features (1)


Ontology-based process description

• Analysis

+ Allows for inheritance hierarchy of processes (e.g. MIT process handbook)

+ May be useful for tools (search?, internal representations, interchange)

- OWL expressiveness limitations force a cumbersome representation

Process Model features (2)


Service Grounding (overview)

• Implementation-specific

• Message formatting, transport mechanisms, protocols, serializations of types

• Service Model + Grounding give everything needed for using the service

• Builds upon WSDL


OWL-S / WSDL Grounding (overview)


Reliance on WSDL

• Analysis+ Allows for use of SWS with WS

+ Reuse of WSDL work on signatures, bindings, etc.

– Integration details can be somewhat awkward(e.g. use of XSLT scripts often required)

– More work is needed on some aspects of the OWL-S / WSDL mapping (e.g., exceptions, …)

– WSDL 2.0 will allow arbitrary MEPs

– “Service” has different meaning

Grounding Features (1)


Mapping of OWL-S IO to WSDL Message Types

• Analysis+ Reuse of WSDL work on signatures, bindings, etc.

– Unresolved issues about grounding of OWL types to WSDL message types

Grounding Features (2)


Outline• Overview & Features of OWL-S • Relationships with commercial Web service

technologies– Registry-based discovery work (e.g. UDDI) recognizes the need for a

basis for matchmaking• Several matchmaking approaches have been developed using OWL-S and (at

least one) integrated with UDDI• Organizing services in class hierarchies ties in with some industry directions

– Grounded Atomic Processes

• Tools, applications & related work• Case Studies• Bridging to other SWSL proposals• Roadmap for SWSL use of OWL-S


Exploiting Taxonomies of ServicesServiceProfile

ProductProvidingService

Manufacturing

Transportation

ActionService

InfoService

PhysicalProductService Repair

InformationProduct+

physicalProduct+manufacturer+

deliveryRegion*deliveryProvider*

deliveryType

Physical_Product+

transportationMode+geographicRegion+

physicalProduct+

Tie in with UDDI, UNSPSC, …DL Basis for matchmakingMultiple profiles; multiple taxonomies

nameprovider

role+avgResponseTime?

…

FeeBased feeBasis+paymentMethod+


Grounded Atomic Processes

Resources/Concepts

WSDL

OWL-S

Process Model

Atomic Process

Operation Message

Inputs / Outputs

Binding to SOAP, HTTP, etc.


Outline

• Overview & Features of OWL-S


• Tools, applications & related work

• Case Studies

• Bridging to other SWSL proposals

• Roadmap for SWSL use of OWL-S


• OWL-S Authoring ToolsOWL-S Authoring ToolsKSL OWL-S EditorKSL OWL-S EditorCMU WSDL2OWL-SCMU WSDL2OWL-S Mind-Swap OntolinkMind-Swap Ontolink

• Web Service DiscoveryWeb Service DiscoveryCMU OWL-S/UDDI MatchmakerCMU OWL-S/UDDI MatchmakerKSL Semantic Discovery ServiceKSL Semantic Discovery ServiceCMU OWL-S BrokerCMU OWL-S BrokerCMU OWL-S for P2PCMU OWL-S for P2P

• Automatic WS InvocationAutomatic WS InvocationCMU OWL-S Virtual MachineCMU OWL-S Virtual Machine

• Web Service CompositionWeb Service CompositionMind-Swap ComposerMind-Swap ComposerKSL Composition ToolKSL Composition ToolCMU Computer Buyer CMU Computer Buyer LibrariesLibraries

• LibrariesLibraries OWL-S APIOWL-S API

Tools & Components


Tools & Components

• OWL-S is just another OWL ontologyAll the tools & technologies for OWL are

relevant

• See also the accompanying slides: “OWL-S Tools and Applications”“OWL-S Tools and Applications”

• See also: http://www.daml.org/services/– Tools page

http://mygrid.man.ac.uk/


Some Applications Using OWL-S

• CoSAR-TS demo (shown at SWMU)

• CMU demo(s)– Travel planning, Electronic parts buying, DAMLzon, …

• Golog composition demo• MyGrid: (http://mygrid.man.ac.uk)

• AgentCities (www.agentcities.org)

• Task Computing (Fujitsu Labs with MINDSWAP)• Composer demo (http://www.mindswap.org/~evren/composer/)

• MyCampus (http://128.2.199.68/project)

• Secure Mobile Services (UMBC/Finin)

http://www.daml.org/services/



http://mygrid.man.ac.uk/


Other Resources• DAML-S/OWL-S publications

– Many and varied, tying in with several research areas & communities

– See http://www.daml.org/services/owl-s/ for a partial listing

• Formal semantics– McIlraith & Narayanan: “Simulation, Verification and

Automated Composition of Web Services”– Ankolekar, Huch, Sycara: “Concurrent Execution

Semantics for DAML-S with Subtypes”

http://www.daml.org/services/owl-s/


Outline• Overview & Features of OWL-S • Relationships with commercial Web service

technologies• Tools & related work• Case Studies

– Financial transaction example– Amazon example: see OWL-S-Amazon.ppt– Travel service scenario: see OWL-S-Composition.ppt– WS Discovery (proposed)

• Bridging to other SWSL proposals• Roadmap for SWSL use of OWL-S


Outline




• Case Studies




Use of rules has potential to merge with Benjamin’s proposals re: contracting

Define an “API” for composite process modeling (as suggested by Benjamin)

Bridging to other SWSL proposals


Outline




• Case Studies




Roadmap• Keep the OWL-S Profile as the basis of our work on

Advertising and Discovery • See if it can be extended to provide a basis for contracting

/ negotiation

• Keep the grounded atomic processes with IOPEs– Smooth out issues regarding OWL WSDL mapping

• Select a more natural approach for composite process modeling– Evolve it so as to accomodate IOPEs expressed using OWL /

SWRL – Merge with grounded atomic processes

May 23, 2004OWL-S straw proposal for SWSL1 OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004 David Martin Mark Burstein Drew McDermott Deb.

Documents

owls ontology

owls services

swsl use of owl

direct use of owl

syntax general features

service user

level process slide

service registries