Semantics at Different Layers

1. Semantic Web Process Lifecycle:Annotation, Discovery, Publication, and CompositionAmit ShethProfessor, University of GeorgiaDirector, LSDIS LabCTO/co-founder, Semagix

2. Discovery Publication Semantics at Different Layers • Description Layer • Why: • Unambiguously understand the functionality of the services, the semantics of input/output data, andQoSof services • How: • Using Ontologies to semantically annotate WSDL constructs (conforming to extensibility allowed in WSDL specification version 1.2/2.0) • WSDL-S : Incorporates many types of semantics in the service description • Tools for (semi-)automatic semantic annotation of Web Services (e.g., METEOR-S MWSAF) • Present scenario: • WSDL descriptions are mainly syntactic (provides operational information and not functional information) • Semantic matchmaking is not possible Flow Description Messaging Network

3. WSDL-S <?xml version="1.0" encoding="UTF-8"?> <definitions name = "BatterySupplier" targetNamespace = "http://lsdis.cs.uga.edu/meteor/BatterySupplier.wsdl20" xmlns = "http://www.w3.org/2004/03/wsdl" xmlns:tns = "http://lsdis.cs.uga.edu/BatterySupplier.wsdl20" xmlns:rosetta = " http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/pips.owl " xmlns:mep=http://www.w3. rosetta:PurchaseOrderStatusResponse org/TR/wsdl20-patterns> <interface name = "BatterySupplierInterface" description = "Computer PowerSupply Battery Buy Quote Order Status " domain="naics:Computer and Electronic Product Manufacturing" > <operation name = "getQuote" pattern = "mep:in-out" action = "rosetta:#RequestQuote" > <input messageLabel = ”qRequest” element = "rosetta:#QuoteRequest" /> <output messageLabel = ”quote” element = "rosetta:#QuoteConfirmation" /> </operation> <operation name = "placeOrder" pattern = "mep:in-out" action = "rosetta:#RequestPurchaseOrder" > <input messageLabel = ”order” element = "rosetta:#PurchaseOrderRequest" /> <output messageLabel = ”orderConfirmation” element = "rosetta:#PurchaseOrderConfirmation" /> <exception element = "rosetta:#DiscountinuedItemException" /> <pre condition = " order.PurchaseOrder.PurchaseOrderLineItem.RequestedQuantity > 7" /> </operation> <operation name = "checkStatus" pattern="mep:in-out" action = "rosetta:#QueryOrderStatus" > <input messageLabel = ”statusQuery” element = "rosetta:#PurchaseOrderStatusQuery" /> <output messageLabel = ”status” element = "rosetta:#PurchaseOrderStatusResponse" /> <exception element = "rosetta:#OrderNumberInvalidException" /> </operation> </interface> </definitions> Function from Rosetta Net Ontology Data from Rosetta Net Ontology

4. Discovery Publication Semantics at Different Layers(contd..) • Publication and Discovery Layers • Why: • Enable scalable, efficient and dynamic publication and discovery (machine processable / automation) • How: • Use federated registries categorized by domans • Publish services based on domains • Capture the WSDL-S annotations in UDDI • Present scenario: • Suitable for simple searches ( like services offered by a provider, services that implement an interface, services that have a common technical fingerprint, etc.) • Categories are too broad • Automated service discovery (based on functionality) and selecting the best suited service is not possible Flow Description Messaging Network

5. RegistryFederation belongsToFederation belongsTo Registry supports Ontology Domain consistsOf subDomainOf MWSDI

6. Discovery Publication Semantics at Different Layers(contd..) • Flow Layer: • Why: • Design (composition), analysis (verification), validation (simulation) and execution (exception handling) of the process models • To employ mediator architectures for dynamic composition, control flow and data flow based on requirements • How: Using • Templates to capture semantics (functionality/preconditions/effects/QoS) of the participating services and for the process • Knowledge of conversation patterns supported by the service • Formal mathematical models like process algebra, concurrency formalisms like State Machines, Petri nets etc. • Simulation techniques • Present Scenario: • Composition of Web services is static • Dynamic service discovery, run-time binding, analysis and simulation are not directly supported Flow Description Messaging Network

7. Using Colored Petri nets

8. Semantic Web Processes and Services (METEOR-S) • Service Advertisements (WSDL-S) • Functional Aspects (IOPE’s) • Non functional Aspects (QoS ontology) • Interaction Protocol (State Machine / Colored Petri nets) • Semi-automatic annotation of WSDL • Discovery of services (MWSDI) • Subsumption based discovery • Peer to peer network of UDDI Registries • Composition (METEOR-S ) • Design time binding to BPEL along with optimization

9. Discovery Publication Semantics in METEOR-S and WS stack MWSCF: Semantic Web Process Composition Framework Flow MWSDI: Scalable Infrastructure of Registries for Semantic publication and discovery of Web Services Description MWSAF: Semantic Annotation of WSDL (WSDL-S) Messaging Network METEOR-S at the LSDIS Lab exploits Workflow, Semantic Web, Web Services, and Simulation technologies to meet these challenges in a practical and standards based approach http://swp.semanticweb.org, http://lsdis.cs.uga.edu/proj/meteor/swp.htm

10. WSDL-S Based on Joint Technical Note with IBM R. Akkiraju, J. Farrell, J.Miller, M. Nagarajan, M. Schmidt, A. Sheth, K. Verma,"Web Service Semantics -- WSDL-S," A joint UGA-IBM Technical Note, version 1.0,April 18, 2005. http://lsdis.cs.uga.edu/projects/meteor-s/wsdl-s/

11. Adding semantics to WSDL – guiding principles • Build on existing Web Services standards • Mechanism independent of the semantic representation language • Mechanism should allow the association of multiple annotations written in different semantic representation languages

12. Guiding principles... • Support semantic annotation of Web Services whose data types are described in XML schema • Provide support for rich mapping mechanisms between Web Service schema types and ontologies

13. WSDL-S approach • evolutionary and compatible upgrade of existing Web services standards • describe semantics and operation level details in WSDL - upward compatibility. • externalize the semantic domain models - agnostic to ontology representation languages.

14. WSDL-S Extension attributes and elements • Annotating message types (XSD complex types and elements) • extension attribute : modelReference(semantic association) • extension attribute : schemaMapping(schema/data mapping) • Annotating operations • extension elements : precondition and effect(child elements of the operation construct) • extension attribute : category(on the interface construct) • extension element : action (under consideration)(on operation construct)

15. PurchaseOrder.wsdl ………… <xs:element name= "processPurchaseOrderResponse" type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/> </xs:schema> </types> <interface name="PurchaseOrder"> <wssem:categoryname= “Electronics” taxonomyURI=http://www.naics.com/ taxonomyCode=”443112” /> <operation name="processPurchaseOrder” pattern=wsdl:in-out> <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> <!—Precondition and effect are added as extensible elements on an operation> <wssem:preconditionname="ExistingAcctPrecond" wssem:modelReference="POOntology#AccountExists"> <wssem:effectname="ItemReservedEffect" wssem:modelReference="POOntology#ItemReserved"/> </operation> </interface>

16. WSDL-S Annotator – snap shot modelReference

17. Annotating operations • extension element : Precondition • A set of assertions that must be satisfied before a Web service operation can be invoked • “must have an existing account with this company” • “only US customers can be served” • extension element : Effect • Defines the state of the world/information model after invoking an operation. • “item shipped to mailing address” • “the credit card account will be debited” • extension attribute : Category • Models a service category on a WSDL interface element. • category = “Electronics” Code = “naics:443112” • extension element : Action • Annotated with a functional ontology concept. • action = “Rosetta:purchaseOrder”

18. Annotating message types – 1:1 correspondences semantic match 1:1 Correspondences <xs:element name= "processPurchaseOrderResponse" type="xs:string wssem:modelReference="POOntology#OrderConfirmation"/> <wsdl:types> (...) <xs:element name= "processPurchaseOrderResponse" type="xs:string (...) </wsdl:types> Billing has_account results_in OrderConfirmation Account has_accountID xsd:string WSDL message element OWL ontology

19. Annotating input/output elements – complex correspondences semantic match • modelReference to establish a semantic association • schemaMapping to resolve structural heterogeneities beyond a semantic match <wsdl:types> (...) <complexType name=“Address"> <sequence> <element name=“StreetAd1“ type="xsd:string"/> <element name=“StreetAd2" type="xsd:string"/> ........... </sequence> </complexType> (...) </wsdl:types> Address hasStreetAddress StreetAddress hasCity xsd:string hasZip xsd:string WSDL complex type element OWL ontology

20. Using modelReference and schemaMapping • modelReference at the complex type level • Typically used when specifying complex associations at leaf level is not possible • Allows for specification of a mapping function semantic match <complexType name="POAddress“wssem:modelReference="POOntology#Address”wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xq#input-doc=doc(“POAddress.xml”)”> <all><element name="streetAddr1" type="string" /> <element name="streetAdd2" type="string" /> <element name="poBox" type="string" /><element name="city" type="string" /> <element name="zipCode" type="string" /><element name="state" type="string" /><element name="country" type="string" /><element name="recipientInstName" type="string" /> </all></complexType> Address has_StreetAddress xsd:string has_City xsd:string has_Zip xsd:string WSDL complex type element OWL ontology

21. Alternative annotation • modelReference at the leaf levels • assumes a 1:1 correspondence between leaf elements and domain model concepts <complexType name="POItem" > <all> <element name="dueDate" nillable="true" type="dateTime" wssem:modelReference=”POOntology#DueDate”/> <element name="qty" type="float" wssem:modelReference=”#POOntology#Quantity”/> <element name="EANCode" nillable="true" type="string" wssem:modelReference=”POOntology#ItemCode”/> <element name="itemDesc" nillable="true" type="string" wssem:modelReference=”POOntology#ItemDesc” /> </all> </complexType> Item hasDueDate dueDate hasIemDesc ItemDesc hasQuantity Quantity WSDL complex type element OWL ontology

22. Representing mappings <complexType name="POAddress" wssem:schemaMapping=”http://www.ibm.com/schemaMapping/POAddress.xsl#input-doc=doc(“POAddress.xml”)”> <all><element name="streetAddr1" type="string" /> <element name="streetAdd2" type="string" /> <element name="poBox" type="string" /><element name="city" type="string" /> <element name="zipCode" type="string" /><element name="state" type="string" /><element name="country" type="string" /><element name="recipientInstName" type="string" /> </all></complexType> Address has_StreetAddress xsd:string has_City xsd:string has_Zip xsd:string WSDL complex type element OWL ontology Mapping using XSLT .... <xsl:template match="/"> <POOntology:Address rdf:ID="Address1"> <POOntology:has_StreetAddress rdf:datatype="xs:string"> <xsl:value-of select="concat(POAddress/streetAddr1,POAddress/streetAddr2)"/> </POOntology:has_StreetAddress > <POOntology:has_City rdf:datatype="xs:string"> <xsl:value-of select="POAddress/city"/> </POOntology:has_City> <POOntology:has_State rdf:datatype="xs:string"> <xsl:value-of select="POAddress/state"/> </POOntology:has_State>....

23. WSDL-S in perspective

24. Semantic Publishing and Template Based Discovery WSDL-S Operation: buyTicket Input1: <Operation> TravelDetails Output1: <Input1> Confirmation UDDI Operation: Search <Output1> cancel Ticket Input1: Service Template TravelDetails Publish Output1: Confirmation Annotations

25. ... <xs:complexType name="processPurchaseOrderRequest“ wssem:modelReference="POOntology#OrderDetails” > <xs:element name="billingInfo" type="xsd1:POBilling"/> <xs:element name="orderItem" type="xsd1:POItem"/> </xs:complexType> </xs:schema> <operation name="processPurchaseOrder” pattern=wsdl:in-out> <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> ... ... <xs:complexType name="processPurchaseOrderRequest“ wssem:modelReference="POOntology#OrderDetails” > <xs:element name="billingInfo" type="xsd1:POBilling"/> <xs:element name="orderItem" type="xsd1:POItem"/> </xs:complexType> </xs:schema> <operation name="processPurchaseOrder” pattern=wsdl:in-out> <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> ... ... <xs:complexType name="processPurchaseOrderRequest"> <xs:element name="billingInfo" type="xsd1:POBilling"/> <xs:element name="orderItem" type="xsd1:POItem"/> </xs:complexType> </xs:schema> <operation name="processPurchaseOrder” pattern=wsdl:in-out> <input messageLabel = ”processPurchaseOrderRequest" element="tns:processPurchaseOrderRequest"/> <output messageLabel ="processPurchaseOrderResponse" element="processPurchaseOrderResponse"/> ... Semantic Layer WSDL WSDL - S WSDL - S Annotating a service UDDI WSDL-S in the life cycle of a Web services Publishing a service

26. An abstract Web process <Operation> <Operation> WSDL-S WSDL-S <Input2> <Input1> <Output2> <Output1> Web service 2 Service 1 Template <Operation> Web Service Discovery <Input1> <Operation> WSDL-SmodelReferenceschemaMapping WSDL-SmodelReferenceschemaMapping <Output1> <Input2> Web service 1 <Output2> Service 2 Template WSDL-S in the life cycle of a Web process Process execution Transformation

27. WSDL-S in action • ProPreO - Experimental Proteomics Process Ontology (CCRC / LSDIS) <?xml version="1.0" encoding="UTF-8"?> <wsdl:definitions targetNamespace="urn:ngp" …… xmlns:wssem="http://www.ibm.com/xmlns/WebServices/WSSemantics" xmlns:ProPreO="http://lsdis.cs.uga.edu/ontologies/ProPreO.owl" > <wsdl:types> <schema targetNamespace="urn:ngp" xmlns="http://www.w3.org/2001/XMLSchema"> …… </schema> </wsdl:types> <wsdl:message name="replaceCharacterRequest" wssem:modelReference="ProPreO#peptide_sequence"> <wsdl:part name="in0" type="soapenc:string"/> <wsdl:part name="in1" type="soapenc:string"/> <wsdl:part name="in2" type="soapenc:string"/> </wsdl:message> ...... data sequence peptide_sequence Excerpt: Bio-informatics Web service WSDL Excerpt: ProPreO – process ontology

28. WSDL-S collaborations • Collaboration with WSMO • Using WSDL-S for grounding Web services annotated with WSML ontologies

29. WSDL-S summary • WSDL-S : A mechanism to associate semantic annotations with Web services that are described using WSDL • Upward compatible, incremental approach • WS community’s familiarity with WSDL • External semantic models referenced via extensibility elements • agnostic to ontology representation languages • Enables reuse of existing domain models

30. Semi-automatic Annotation (WSDL and Ontologies) Expressiveness • Different reasons behind their development • XML Schema used in WSDL for providing basic structure to data exchanged by Web services • Ontologies are developed to capture real world knowledge and domain theory • Knowledge captured • XML Schema has minimal containment relationship • Language used to describe ontologies model real world entities as classes, their properties and provides named relationships between them Solution • Use heuristics to create normalized representation • We call it SchemaGraph

31. Normalization – SchemaGraph What is SchemaGraph ? • Normalized representation to capture XML Schema and DAML Ontology How to use SchemaGraph • Conversion functions convert both XML Schema and Ontology to SchemaGraph representation • XML schema used by WSDL → W = {wc1, wc2, wc3, …, wcn} where, wci is an element in XML schema and n is the number of elements • Ontology → O = {oc1, oc2, oc3, …, ocm} where, oci is a concept in Ontology and m is the number of concepts • Match function takes both W and O and returns a set of mappings

32. MWSAF – XML Schema to SchemaGraph

33. Rule 6 Rule 1complextype => Node Rule 5 Rule 1simpletype => Node Rule 3 MWSAF – XML Schema to SchemaGraph -<xsd:complexType name="WeatherReport"> -<xsd:sequence> <xsd:elementname="phenomena" type="xsd1:Phenomenon" /> <xsd:elementname="wind" type="xsd1:Wind" /> </xsd:sequence> </xsd:complexType> -<xsd:complexType name="Phenomenon"> -<xsd:sequence> <xsd:elementname="type" type="xsd1:PhenomenonType" /> <xsd:elementname=“intensity" type="xsd1:PhenomenonIntensity" /> </xsd:sequence> </xsd:complexType> -<xsd:complexType name="Wind"> -<xsd:sequence> <xsd:elementname="gust_speed" type="xsd:double" /> <xsd:elementname="prevailing_direction" type="xsd1:Direction" /> </xsd:sequence> </xsd:complexType> -<xsd:simpleType name="PhenomenonType"> -<xsd:restriction base="xsd:string"> <xsd:enumerationvalue="MIST" /> <xsd:enumerationvalue="FOG" /> <xsd:enumerationvalue=“SNOW" /> <xsd:enumerationvalue="DUST" /> </xsd:restriction> </xsd:simpleType> WeatherReport wind phenomena Wind Phenomenon hasElement prevailing_direction type gust_speed Direction intensity PhenomenonType Rule 1 Element => Node PhenomenonIntensity oneOf oneOf oneOf oneOf MIST FOG SNOW DUST

34. MWSAF - Ontology to SchemaGraph

35. MWSAF - Ontology to SchemaGraph -<daml:Class rdf:ID="WeatherPhenomenon"> <rdfs:comment>Superclass for all weather events</rdfs:comment> <rdfs:label>Weather event</rdfs:label> </daml:Class> -<daml:Class rdf:ID="WindEvent"> <rdfs:subClassOfrdf:resource="#WeatherPhenomenon" /> </daml:Class> -<daml:Property rdf:ID="windDirection"> <rdfs:domainrdf:resource="#WindEvent" /> </daml:Property> -<daml:Class rdf:ID="GustingWindEvent"> <rdfs:subClassOfrdf:resource="#WindEvent" /> </daml:Class> -<daml:Class rdf:ID="CurrentWeatherPhenomenon"> <rdfs:subClassOfrdf:resource="#WeatherPhenomenon" /> </daml:Class> -<daml:Class rdf:ID="OtherWeatherPhenomena"> <rdfs:subClassOfrdf:resource="#CurrentWeatherPhenomenon" /> </daml:Class> -<daml:Class rdf:ID="Duststorm"> <rdfs:subClassOfrdf:resource="#OtherWeatherPhenomena" /> </daml:Class> -<daml:Class rdf:ID="PrecipitationEvent"> <rdfs:subClassOfrdf:resource="#CurrentWeatherPhenomenon" /> </daml:Class> -<daml:Class rdf:ID="SolidPrecipitationEvent"> <rdfs:subClassOfrdf:resource="#PrecipitationEvent" /> </daml:Class> -<daml:Class rdf:ID="Snow"> <rdfs:subClassOfrdf:resource="#SolidPrecipitationEvent" /> </daml:Class> -<daml:Class rdf:ID="ObscurationEvent"> <rdfs:subClassOfrdf:resource="#CurrentWeatherPhenomenon" /> </daml:Class> -<daml:Class rdf:ID="Fog"> <rdfs:subClassOfrdf:resource="#ObscurationEvent" /> </daml:Class> -<daml:Class rdf:ID="Mist"> <rdfs:subClassOfrdf:resource="#ObscurationEvent" /> </daml:Class> WeatherPhenomenon WindEvent Rule 1 Rule 5 windDirection GustingWindEvent Rule 2 CurrentWeatherPhenomenon OtherWeatherPhenomenon Duststorm PrecipitationEvent SolidPrecipitationEvent ObsucurationEvent Snow Mist Fog

36. Semantic Web Service Discovery in METEOR-S METEOR-S Web Service Discovery Infrastructure

37. Now QoS B3 A1 B3 B3 A1 A1 B3 A1 A1 A1 A1 A1 A2 A4 A1 A2 A2 A4 A4 A1 A1 A2 A4 A2 A1 B3 A1 B3 A1 B3 A1 B3 A1 A1 A1 A1 A4 A1 A1 A2 A4 B3 A4 A1 A1 A1 A1 A1 A1 A1 A4 B3 A1 A2 A1 A4 A1 A1 A1 A2 A1 A4 A4 B3 A2 A1 A4 B3 A2 A1 A1 A2 A4 A4 A1 A1 A1 A1 A1 A1 A1 A1 A2 A1 A1 A1 B3 A2 A4 A2 A1 A4 A1 A1 A2 A4 A2 A1 A4 A2 A2 A2 A4 A1 B3 A4 A4 A1 A1 A1 A1 A1 A2 A4 A4 A2 A1 A4 A1 A1 A4 A1 A1 B3 A1 A1 A1 B3 A2 B3 A1 A1 A4 A2 B3 A2 A4 A1 A1 A1 A4 B3 A1 A1 A2 A2 A1 A4 A4 A1 A1 A1 B3 A4 B3 A1 A1 A1 A1 B3 A1 A2 A2 A1 A1 A4 A2 A1 A4 A1 A1 A1 A2 A2 A1 A4 A4 A1 A1 A4 A4 A1 A1 A1 B3 A1 A1 B3 B3 A1 A1 B3 A1 QoS E A N1 N2 F E A N1 N2 F C D C D Web Service Discovery Discovery new Requirements Before Tasks B8 A4 Web Services A1 A2 A4 B3 A5 A1 A1 A4 A6 A2 Workflow Web Process

38. State of the art in discovery UDDI Business Registry Results Search Keyword and attribute-based match Provides non-semantic search Search retrieves lot of services (irrelevant results included) Selection Which service to select ? How to select?

39. Semantic Discovery: Overview • Annotation and Publication • WSDL file is annotated using ontologies and the annotations are captured in UDDI • Discovery • Requirements are captured as templates that are constructed using ontologies and semantic matching is done against UDDI entries • Functionality of the template, its inputs, outputs, preconditions and effects are represented using ontologies • Use of ontologies • brings service provider and service requestor to a common conceptual space • helps in semantic matching of requirements and specifications

40. Use of ontologies enables shared understanding between the service provider and service requestor Semantic Publication and Discovery For simplicity of depicting, the ontology is shown with classes for both operation and data Adding Semantics to Web Services Standards

41. Present Discovery MechanismKeyword and attribute-based search Web Service Discovery • UDDI :Keyword and attribute-based search • Example: “Quote” • Microsoft UBR returned 12 services • Human reading of description (Natural Language) help me understand: • 6 Entries are to get Famous Quotes • 1 Entry for personal auto and homeowners quoting • 1 Entry for multiple supplier quotes on all building materials • Categorization suggested for UDDI is useful but inadequate (what does the WS do?) : • 1 Entry for Automobile Manufacturing • 1 Entry for Insurance agents, brokers, & service • Alternatively read and try to understand WSDL • 1 Entry related to security details (Human Understanding) • 1 Test Web service for Quotes (which quote?)

42. Discovery in Semantic Web Using Semantics Web Service Discovery • Functionality: What capabilities the requestor expects from the service (Functional semantics) • Inputs: What the requestor can give to the to the Web service (Data semantics) • Outputs: What the requestor expects as outputs from the service (Data semantics) • QoS: Quality of Service the distributor expects from the service (QoS semantics) (Functional semantics)(Data semantics) (QoS semantics) (Syntactic description) • Description: Natural language description of the service functionality (Syntactic description)

43. DiscoveryThe Match Function • The Web service discovery and integration process is carried out by a key operation: • The match function • The matching step is dedicated to finding correspondences between a service template (ST, i.e., a query) and a service advertisement (SO).

44. The Match FunctionSemantic Similarity • Purely syntactical methods that treat terms in isolation from their contexts. • It is insufficient since they deal with syntactic but not with semantic correspondences • Users may express the same concept in different ways. • Therefore, we rely on semantic information to evaluate the similarity of concepts that define ST and SA interfaces. • This evaluation will be used to calculate their degree of integration.

45. The Match Function SO2 SO3 SO1 0.76 Match Function 0.14 0.31 0.68 0.98 0.43 0.34 0.74 0.99 f(ST, SO1) f(ST, SO2) f(ST, SO3) ST ST Web Process

46. Web Service Discovery Discovery in SWS • Functionality: What capabilities the distributor expects from the service (Functional semantics) • Inputs: What the distributor can give to the to the Manufacturer’s service (Data semantics) • Outputs: What the distributor expects as outputs from the service (Data semantics) • QoS: Quality of Service the distributor expects from the service (QoS semantics) (Functional semantics)(Data semantics) (QoS semantics) (Syntactic description) • Description: Natural language description of the service functionality (Syntactic description)

47. Similarity ? Similarity ? A2 A1 Name, Description, …. Name, Description, … Calendar-Date A Event X … B … Y … C Web Service Web Service Web Service Web Service {x, y} Coordinates Information Function Area {name} Similarity ? QoS QoS Forrest Get Information Get Date Purchase Buy A X B Y C Web Service Web Service Syntactic, QoS, and Semantic (Functional & Data) Similarity Web Service Discovery Syntactic Similarity QoS Similarity Functional &Data Similarity

48. The Match FunctionSemantic Similarity ((O) = (I)) • When comparing concepts defined with the same ontology four distinct scenarios need to be considered: • a) the concepts are the same (O=I) • b) the concept I subsumes concept O (O>I) • c) the concept O subsumes concept I (O<I), or • d) concept O is not directly related to concept I (OI).

49. The Match FunctionSemantic Similarity ((O) =(I)) Similarity ? A2 A1 Calendar-Date Event … … … Web Service Web Service

50. Semantic Process Composition