1 / 41

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

OWL-S Straw Proposal Presentation to SWSL Committee May 23, 2004. David Martin Mark Burstein Drew McDermott Deb McGuinness Sheila McIlraith Massimo Paolucci Bijan Parsia. Outline. Overview & Features of OWL-S General Profile Process Model Grounding

charla
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OWL-S Straw ProposalPresentation to SWSL CommitteeMay 23, 2004 David Martin Mark Burstein Drew McDermott Deb McGuinness Sheila McIlraith Massimo Paolucci Bijan Parsia OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  4. 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. OWL-S straw proposal for SWSL

  5. General Features of OWL-S  Conceptual model • Fairly well-developed; represents significant evolution • Lacks some rigour (could be addressed) OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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) OWL-S straw proposal for SWSL

  8. Functional Specification of what the service does in terms of preconditions inputs outputs effects Summarizes the top-level Process Service Profile: Functionality Description OWL-S straw proposal for SWSL

  9. Provides supporting information about the service. Service Profile: NonFunctional Properties OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  12. Profile Features (3)  Same representation for: • Service advertisements • Service requisition • Analysis • Helpful in constructing matchmakers, brokers OWL-S straw proposal for SWSL

  13. Process Model (overview) 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 OWL-S straw proposal for SWSL

  14. Service Model / Process Model (overview) OWL-S straw proposal for SWSL

  15. Process Model: Recent Progress Service Model“How does it work?” • Expression language • Relation between outputs and effects • Dataflow and bindings • Surface syntax OWL-S straw proposal for SWSL

  16. 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> OWL-S straw proposal for SWSL

  17. 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> OWL-S straw proposal for SWSL

  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. OWL-S straw proposal for SWSL

  19. 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> OWL-S straw proposal for SWSL

  20. Dataflow Output producee <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> Fromstep1 Is input param consumee To step2 Why is this a Literal? Because any expression can go Here. OWL-S straw proposal for SWSL

  21. Surface Syntax • Clarity is great, but …RDF is tough to read and write. do1: Step1; Step2(consumee <= do1.producee) OWL-S straw proposal for SWSL

  22. 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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  26. OWL-S / WSDL Grounding (overview) OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  30. Exploiting Taxonomies of Services nameproviderrole+avgResponseTime?… ServiceProfile feeBasis+paymentMethod+ FeeBased ProductProvidingService ActionService Physical_Product+ Manufacturing InfoService InformationProduct+ physicalProduct+manufacturer+deliveryRegion*deliveryProvider*deliveryType PhysicalProductService Repair physicalProduct+ Tie in with UDDI, UNSPSC, …DL Basis for matchmakingMultiple profiles; multiple taxonomies transportationMode+geographicRegion+ Transportation OWL-S straw proposal for SWSL

  31. Grounded Atomic Processes OWL-S Resources/Concepts Process Model Inputs / Outputs Atomic Process Message Operation Binding to SOAP, HTTP, etc. WSDL OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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/composer/) • MyCampus (http://128.2.199.68/project) • Secure Mobile Services (UMBC/Finin) OWL-S straw proposal for SWSL

  36. Other Resources • DAML-S/OWL-S publications • Many and varied, tying in with several research areas & communities • Seehttp://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” OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  39. Bridgingto other SWSL proposals • Use of rules has potential to merge with Benjamin’s proposals re: contracting • Define an “API” for composite process modeling (as suggested by Benjamin) OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

  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 OWL-S straw proposal for SWSL

More Related