OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004

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

OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004

Documents

Transcript of OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004