Transcript WSMO WG Presentation

WSDL-S (LSDIS and IBM) & WSMO
http://www.alphaworks.ibm.com/g/g.nsf/img/semanticsdocs/$file/wssemantic_annotation.pdf
http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/
WSMO Working Group Presentation
Matthew Moran, Jacek Kopecky, Adrian Mocan
29 June 2005
 Copyright 2005 Digital Enterprise Research Institute.
All rights reserved.
www.deri.org
Presentation Overview
• WSDL-S overview
• WSDL-S extensions
– Input and output elements
– Preconditions and effects
– Service categorization
• Relationship of WSDL-S to WSMO/L/X
• Is WSDL-S suitable for WSMO Grounding?
• Conclusions
2
WSDL-S Overview
• It is a means to add semantics inline to WSDL for:
– Inputs and outputs
– Operations
– Service categorization
• It is agnostic to ontology representation language used
– OWL used up to now
– No barrier to the use of WSMO
• Targeted at WSDL 2.0 but can be used for WSDL 1.1
• WSDL-S extension is deifined by an XML Schema
3
WSDL-S Overview
•
Adding semantics inline to WSDL abstract definition
– Inputs and output messages
• Annotated with domain concepts
– Operations
• Annotated with preconditions and effects
– Service
• Interface annotated with category information
WSDL Conceptual Model
Semantics
OWL
(From: http://webservices.xml.com/lpt/a/ws/2004/05/19/wsdl2.html)
4
WSDL-S Overview
•
Adding semantics inline to WSDL abstract definition
– Inputs and output messages
• Annotated with domain concepts
– Operations
• Annotated with preconditions and effects
– Service
• Interface annotated with category information
WSDL Conceptual Model
Semantics
WSMO
OWL
RDF
(From: http://webservices.xml.com/lpt/a/ws/2004/05/19/wsdl2.html)
Agnostic to ontology
representation
language
5
WSDL-S XML Schema – WSSemantics.xsd
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
targetNamespace="http://www.ibm.com/xmlns/stdwip/Web-services/WS-Semantics"
xmlns:wssem="http://www.ibm.com/xmlns/stdwip/Web-services/WSSemantics"
xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/">
<attribute name="modelReference" type="anyURI" use="optional"/>
<attribute name=”schemaMapping” type=”anyURI” use=”optional”/>
<element name=”category” maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base=”wsdl:documented”>
<attribute name="categoryname" type="NCName" use="required"”/>
<attribute name="taxonomyURI" type="anyURI" use="required"”/>
<attribute name="taxonomyValue" type="String" use="optional"/>
<attribute name="taxonomyCode" type="integer" use="optional"/>
</extension>
</complexContent>
</complexType>
</element>
<element name = "precondition">
<complexType>
<complexContent
<restriction base="anyType">
<xsd:attribute name=”name” type=”string” />
<attribute name="modelReference" type="anyURI" />
<attribute name="expression" type="string" />
</restriction>
</complexContent>
</complexType>
</element>
<element name="effect">
<complexType>
<complexContent
<restriction base="anyType">
<xsd:attribute name=”name” type=”string” />
<attribute name="modelReference" type="anyURI" />
<attribute name="expression" type="string" />
</restriction>
</complexContent>
</complexType>
</element>
</schema>
6
Input and output elements
Simple type
<xs:element name= "processPurchaseOrderResponse"
type="xs:string
wssem:modelReference="POOntology#OrderConfirmation"/>
• The wssem:modelReference attribute denotes a one-to-one
mapping between schema element and ontology concept
• Uses the extensibility of xsd:element
7
Input and output elements
Complex type
• Annotating complex types
– Bottom Level Annotation:
• At leaf element level
– Top Level Annotation:
• At complex type level
8
Input and output elements
Complex type
• Bottom Level Annotation: using wssem:modelReference
– Bottom Level Annotation: at leaf element level
<complexType name="POItem">
<all>
<element name="dueDate" type="dateTime"
wssem:modelReference=”POOntology#DueDate"/>
<element name="quantity" type="float"
wssem:modelReference ="POOntology#Quantity"/>
<element name="EANCode" type="string"
wssem:modelReference ="POOntology#ItemCode"/>
<element name="itemDesc" type="string"
wssem:modelReference ="POOntology#ItemDesc"/>
</all>
</complexType>
9
Input and output elements
Complex type
• Top Level Annotation
– High level semantic annotation of the complex type
– Either use modelReference attribute or schemaMapping attribute
• Using wssem:modelReference:
<complexType name="POBilling"
wssem:modelReference=”POOntology#Billing”>
<all>
<element name="shipToAddress" type="xsd1:POAddress" />
<element name="billToAddress" type="xsd1:POAddress" />
<element name="accountID" type="xsd1:string />"
</all>
</complexType>
10
Input and output elements
Complex type
• Top Level Annotation
– The XMLSchema type POAddress is mapped using an XSL
Transformation to concepts in an ontology
• Using wssem:schemaMapping:
<complexType name="POAddress"
wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xsl”>
<all>
<element name="recipientInstName" type="string" />
<element name="streetAddr1" type="string" />
…
<element name="zipCode" type="string" />
<element name="country" type="string" />
</all>
</complexType>
11
Preconditions and Effects
• Defined at the level of WSDL operation
• WSMO defines at the level of service
• modelReference has a slightly different semantics here
<interface name="PurchaseOrder">
<operation name="processPurchaseOrder” pattern=wsdl:in-out>
<input messageLabel = ”processPurchaseOrderRequest"
element="tns:processPurchaseOrderRequest"/>
<output messageLabel ="processPurchaseOrderResponse"
element="processPurchaseOrderResponse"/>
<wssem:precondition name="ExistingAcctPrecond"
wssem:modelReference="POOntology#AccountExists">
<wssem:effect name="ItemReservedEffect“
wssem:modelReference="POOntology#ItemReserved"/>
</operation>
</interface>
• (Also possible to define the logical expression inline in WSDL)
12
Preconditions and Effects
• At most one precondition
• Defined at the level of WSDL operation
– To keep the specification simple
– Complex preconditions should
• WSMO defines at the level of service
be specified in the domain
model
• modelReference has a slightly different
semantics here
• As many effects as possible
<interface name="PurchaseOrder">
<operation name="processPurchaseOrder” pattern=wsdl:in-out>
<input messageLabel = ”processPurchaseOrderRequest"
element="tns:processPurchaseOrderRequest"/>
<output messageLabel ="processPurchaseOrderResponse"
element="processPurchaseOrderResponse"/>
<wssem:precondition name="ExistingAcctPrecond"
wssem:modelReference="POOntology#AccountExists">
<wssem:effect name="ItemReservedEffect“
wssem:modelReference="POOntology#ItemReserved"/>
</operation>
</interface>
• Also possible to define the logical expression inline in WSDL
13
Service Categorization
• Category element
– Adopted from OWL-S for use with UDDI
• An extension to the WSDL interface element
<element name=”category” maxOccurs="unbounded">
<complexType>
<complexContent>
<extension base=”wsdl:interface”/>
<attribute name=”categoyname” type=”NCName” use=”required”/>
<attribute name=”taxonomyURI” type=”anyURI” use=”required”/>
<attribute name="taxonomyValue" type="String" use="optional"/>
<attribute name="taxonomyCode" type="integer" use="optional"/>
</complexContent>
</complexType>
</element>
14
Relationship of WSDL-S to WSMO/L/X
• WSMO can be used for semantic annotation of WSDL with WSDL-S
• WSDL-S defines Preconditions and Effects (WSMO postconditions)
– Could be extended to include Effects (WSMO) and Assumptions
• WSMX WG co-operation with the LSDIS lab underway:
– http://www.wsmo.org/TR/d13/d13.8/v0.1/d13.8.pdf
– Linking Semantic Web Services Efforts. (Second International
Workshop on Semantic and Dynamic Web Processes (SDWP), 2005)
• There is no mechanism to describe Choreography or Orchestration
• There is no mechanism to describe Preconditions, Effects etc. for a
Web Service as an entity (they are defined at operation level)
15
Usefulness for WSMO Grounding
• Bottom approach may appeal to those used to WSDL
• The schemaMapping attribute allows for complex
mappings to be identified by a URI
• The modelReference assumes that the XML Schema
and corresponding ontology stay in sync
• Semantics and syntax are tightly coupled
– Different WSDL-S for each ontology language?
– WSDL of existing services would have to be modified
• Seems an incomplete mix of semantics and syntactics
– Choreography and Orchestration etc. missing
 An additional semantic description still required
16
Conclusion
• Bottom-up approach
– Lightweight and WSDL friendly
• WSDL for existing services would have to be rewritten
– In contrast to WSMO grounding
– Semantics and syntax coupled in WSDL-S approach
• Choreography and Orchestration not addressed
– Would still need a second semantic service description
• Is not WSML
– Is not processable by WSMX
• May be a intermediate approach to adding semantics to
Web service descriptions (outside WSMX)
• DERI and LSDIS have started discussing co-operation
17