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

1
OWL-S Straw ProposalPresentation to SWSL
CommitteeMay 23, 2004

• David Martin
• Mark Burstein
• Drew McDermott
• Deb McGuinness
• Sheila McIlraith
• Massimo Paolucci
• Bijan Parsia

2
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

3
General Features 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

4
General Features of OWL-S

• ? Based on OWL (DL) ontology of services, with
  selected uses of rules (SWRL)
• Analysis (contd)
• 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.

5
General Features of OWL-S

• ? Conceptual model
• Fairly well-developed represents significant
  evolution
• Lacks some rigour (could be addressed)

6
General Features of OWL-S

• ? 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

7
Service Profile (overview)

• 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)

8
Service Profile Functionality Description

• Functional Specification of what the service does
  in terms of
• preconditions
• inputs
• outputs
• effects
• Summarizes the top-level Process

9
Service Profile NonFunctional Properties

• Provides supporting information about the service.

10
Profile Features (1)

• ? 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

11
Profile Features (2)

• ? 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

12
Profile Features (3)

• ? Same representation for
• Service advertisements
• Service requisition
• Analysis
• Helpful in constructing matchmakers, brokers

13
Service ModelHow does it work?
Process Model (overview)

• Process
• Interpretable description of service providers
  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

14
Service Model / Process Model (overview)
15
Service ModelHow does it work?
Process Model Recent Progress

• Expression language
• Relation between outputs and effects
• Dataflow and bindings
• Surface syntax

16
Atomic Process Definitions

• ltprocess rdfID"order_movement"gt
• lthasInputgt
• ltInput rdfID"dest"gt
• ltparameterType rdfID"millocation"/gt
• lt/Inputgt
• lt/hasInputgt
• lthasOutputgt
• ltOutput rdfID"ackno"/gt
• lt/hasOutputgt
• lthasPreconditiongt...lt/hasPreconditiongt
• lthasResultgt
• ltResult rdfresource"movement_success"/gt
• ltResult rdfresource"movement_fail"/gt
• lt/hasResultgt
• lt/processgt

17
Results

• ltResult rdfID"movement_success"gt
• ltinCondition rdfdatatype"xsdstring
  langKifgt
• (_at_milmotion_possible)
• lt/inConditiongt
• ltwithOutputgt
• ltBindinggt
• lttheParam rdfresource"ackno"/gt
• ltvalueForm rdfdatatype"xsdboolean"gt
• true
• lt/valueFormgt
• lt/Bindinggt
• lt/withOutputgt
• lthasEffect rdfdatatype"xsdstring"gt
• (location ?dest)
• lt/hasEffectgt
• lt/Resultgt

18
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.

19
Another Result

• ltResult rdfID"movement_failure"gt
• ltinCondition rdfparseType"Literal
  langDRSgt
• ltdrsNotgt
• ltdrsterm_args rdfparseType"Collection
  "gt
• ltdrsAtomic_formulagt
• ltrdfpredicate rdfresource"mil
  motion_possible"/gt
• lt/drsAtomic_formulagt
• lt/drsterm_argsgt
• lt/drsNotgt
• lt/inConditiongt
• ltwithOutputgt
• ltBindinggt
• lttheParam rdfresource"ackno"/gt
• ltvalueForm rdfdatatype"xsdboolean"gt
  falselt/valueFormgt
• lt/Bindinggt
• lt/withOutputgt
• lt/Resultgt

20
Dataflow
Output producee

• ltSequence rdfparseType"Collection"gt
• ltPerform rdfID"step1"gt
• ltprocess rdfresource"Generate"/gt
• lt/Performgt
• ltPerform rdfID"step2"gt
• ltprocess rdfresource"Consumer"/gt
• lthasBindinggt
• ltInputBindinggt
• lttheParam rdfresource"consumee"/gt
• ltvalueForm parseType"Literal"gt
• ltValueOfgt
• lttheVar rdfresource"producee"
  /gt
• ltfromProcess rdfresource"step
  1"/gt
• lt/ValueOfgt
• lt/valueFormgt
• lt/InputBindinggt
• lt/hasBindinggt
• lt/Performgt
• lt/Sequencegt

From step1
Is input param consumee
To step2
Why is this a Literal? Because any expression can
go Here.
21
Surface Syntax

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

do1 Step1 Step2(consumee lt do1.producee)
22
Process Syntax

• Vanilla conventions infix notation, more C-like
  than Lisp-like
• Logical expressions now dont have to be quoted
  in a funny way
• Output parameter values written step.param
• Input parameter bindings written
• param lt val

23
Process Model features (1)

• 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

24
Process Model features (2)

• 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

25
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

26
OWL-S / WSDL Grounding (overview)
27
Grounding Features (1)

• 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

28
Grounding Features (2)

• 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

29
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

30
Exploiting Taxonomies of Services
nameproviderroleavgResponseTime?
ServiceProfile
FeeBased
feeBasispaymentMethod
ProductProvidingService
ActionService
Physical_Product
Manufacturing
InfoService
InformationProduct
physicalProductmanufacturerdeliveryRegiondel
iveryProviderdeliveryType
PhysicalProductService
Repair
physicalProduct
Tie in with UDDI, UNSPSC, DL Basis for
matchmakingMultiple profiles multiple taxonomies
transportationModegeographicRegion
Transportation
31
Grounded Atomic Processes
OWL-S
Resources/Concepts
Process Model
Inputs / Outputs
Atomic Process
Message
Operation
Binding to SOAP, HTTP, etc.
WSDL
32
Outline

• Overview Features of OWL-S
• Relationships with commercial Web service
  technologies
• Tools, applications related work
• Case Studies
• Bridging to other SWSL proposals
• Roadmap for SWSL use of OWL-S

33
Tools Components

• OWL-S Authoring Tools
• KSL OWL-S Editor
• CMU WSDL2OWL-S
• Mind-Swap Ontolink
• Web Service Discovery
• CMU OWL-S/UDDI Matchmaker
• KSL Semantic Discovery Service
• CMU OWL-S Broker
• CMU OWL-S for P2P
• Automatic WS Invocation
• CMU OWL-S Virtual Machine
• Web Service Composition
• Mind-Swap Composer
• KSL Composition Tool
• CMU Computer Buyer
• Libraries
• Libraries
• OWL-S API

34
Tools Components

• OWL-S is just another OWL ontology
• All the tools technologies for OWL are relevant
• See also the accompanying slides OWL-S Tools
  and Applications
• See also http//www.daml.org/services/
• Tools page

35
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/comp
  oser/)
• MyCampus (http//128.2.199.68/project)
• Secure Mobile Services (UMBC/Finin)

36
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

37
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

38
Outline

• Overview Features of OWL-S
• Relationships with commercial Web service
  technologies
• Tools, applications related work
• Case Studies
• Bridging to other SWSL proposals
• Roadmap for SWSL use of OWL-S

39
Bridging to other SWSL proposals

• Use of rules has potential to merge with
  Benjamins proposals re contracting
• Define an API for composite process modeling
  (as suggested by Benjamin)

40
Outline

• Overview Features of OWL-S
• Relationships with commercial Web service
  technologies
• Tools, applications related work
• Case Studies
• Bridging to other SWSL proposals
• Roadmap for SWSL use of OWL-S

41
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