Your SlideShare is downloading. ×
Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration
Upcoming SlideShare
Loading in...5

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration


Published on

“Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration,” Keynote/Invited Talk, WWW 2003 Workshop on E-Services and the Semantic Web, Budapest, …

“Semantic Web Process Lifecycle: Role of Semantics in Annotation, Discovery, Composition and Orchestration,” Keynote/Invited Talk, WWW 2003 Workshop on E-Services and the Semantic Web, Budapest, Hungary, May 20, 2003.

Here is the paper based on this talk:
Kaarthik Sivashanmugam, Kunal Verma,Amit Sheth, and John Miller, 'Adding Semantics to Web Services Standards,'International Conference on Web Services 2003 (ICWS'03), Las Vegas, NV, June 23-26, 2003.

Published in: Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

No notes for slide
  • Telecommunications industry: service provider needs to support different classes of customers (e.g., individual residences, small businesses, and large businesses) and require flexibility to deal with a limited set of partners. For example, a CLEC may need flexibility in leasing network capacities for long distance services from QWEST communications or Level 3 communications.
  • Telecommunications industry: one of the visions of the future networks includes the facility to allow consumer devices to interact with other devices and humans on the network in an integrated fashion. The device may be able to specify a need for a specific type and quality of network services required and the network dynamically composes a customized process to allow processing of the request.
  • TPA = Trading Partner Agreement Some URLs: 1. 2. "A Trading Partner Agreement is a legal document which gives the guidelines of business between you and your Trading Partner. You may need a Trading Partner Agreement for each new Trading Partner. By signing the Agreement, you agree that any transactions done via EDI are as legal and binding as a transaction done through the mail or over the phone. " from
  • Intalio n3 : Completor, deploy, execute, analyze and optimize processes…brochure says it supports BPML specification WSEL: Web Service End Point Language-- Non-operational specification of Web service WSIL: The WS-Inspection specification provides an XML format for assisting in the inspection of a site for available services and a set of rules for how inspection related information should be made available for consumption. A WS-Inspection document provides a means for aggregating references to pre-existing service description documents which have been authored in any number of formats. These inspection documents are then made available at the point-of-offering for the service as well as through references which may be placed within a content medium such as HTML.
  • UDDI supports only text based keyword search and taxonomy based search. But they are not sufficient. For example: if you search for services using the keyword "Quote" in Microsoft UBR (Universal Business Registry), it results in 12 services. The services range from "famous quotations" to "automobile quote" Of these 12 services, 8 services are understood using their descriptions Out of this 8, 6 services are described as services that give out famous quotations, 1 service description says it is related to "personal auto and home owners quoting", 1 service describes itself as "multiple supplier quotes on all building materials" Though these descriptions are helpful to understand the purpose/capability of the services, they are in Natural Language and hence it is not feasible to understand all kind of descriptions. Out of the 12 service returned from UDDI, 2 services are categorized under "Automobile Manufacturing" and "Insurance agents, borkers and service". But these categorizations are too broad and do not characterise the capabilities of the services Of the 12 services, 2 services were neither described well, nor categorized, so to understand the capabilities of the service one needs to use the data types and comments in WSDL file. So simply speaking the discovery mechanism supported by UDDI is inadequate.
  • This slide tells the problems in understanding/using/invoking even a simplest service. From the list of services shown previous slide we have taken a service that returns "world famous quotes". It is available in the URL given in the slide. To use this service we need to understand the different kind of operations available in its WSDL file. Looking at this WSDL file, shows that it has different operations called "GetQuote", "GetQuoteById", "GetQuoteForPerson" etc. So we need to select the one that is suitable for our purpose. Selecting a particular operation may involve understanding the signature of the the operations. for example "GetQuote" service has the signature as shown in the slide. But it does not describe what a quote type is, apart from saying it is of type integer. This Web service also supports different kind of interactions. New users have to register, confirm before invoking the GetQuote() method. Existing users can directly invoke the method. How do we understand these different kind of interaction patterns. The description of the "confirm" operation says it "This method is used to confirm your email address". From the signature of the method we can see that it takes a string "UserGUID" as input. How are we going to interpret the signature and decide if it is suitable. The WSDL description of "Register" operation says that "registeruser method is used to register to use.....". To use the service properly we need to understand this description". Preconditions and effects are helpful to specify these conditions which can be made easy to understand using the ontologies. Preconditions and effects along with a "Conversation specification" like WSCI or WSCL could be of use.
  • Out of these results, some do not have formal WSDLimplementation, some links are not working and it does not return all the results. As it is a Business registry. SOme are just names of the businesses and I did not find WSDL descriptions for them. Some of the links they have given for the implementation are not working. So i couldn't find if they are really working or not. And there are some more services which are named not as weather service but do provide same functionality. But due to keyword based search we cant find them in UDDI by searching for Weather Services. We need to have some idea about the name of the service or provider in order to get really good results from UDDI which is in most of the cases may not be possible.
  • The solution to this problem are Formally describing Inputs and outputs of the services [DAML-S] approach Our way : Annotating WSDL constructs
  • This slide shows URL to another WSDL file. It has a method called GetRandomQuote. The description says "Returns a random quote, as GetRandomQuote, but this time just German ones". How do we understand this kind of descriptions. Also the interface (signature) supported by the operations in this service are different from the operations in WSDL given in previous slide. Inspite of the fact that both the services are used to get world famous quotes", they differ in the terminologies (data and message names) used in their WSDL file and in their signatures. So the discovery system should also support analysing these different operations in WSDL to find a relevant and suitable service to invoke. Just to reiterate the point that WSDL descriptions are inadequte to represent a service, here is an example. There is another service with an operation called getJoke which has similar signature as that of getQuote. But the purpose is entirely different. WSDL descriptions do not capture this kind of differences.
  • The description of the Concept in WSDL file can be there as a comment or we can get it from Wordnet. In DAML-s ontologies we do have the description of the concept. Now regarding Name matches, we can apply stemming algorithms and stop word processing which removes unnecessary words, like "Event in case of windEvent“ or "_ in case of gust_speed to give gustSpeed" and then do the name matching. Then synonyms, meronyms etc could be obtained from Word net or similar dictionary. Abbreviations and acronyms would be provided by the user. It could be a file or some customized class for the same.
  • Both ontology and WSDL are from real world Red Arrow : Acronym Green Arrow : Structural Match Light green arrow : Description Match Blue Arrow : Hypernym relation Violet Arrow : Name Matching with stemming
  • Registry Types * [JP2P Unleashed]: Corporate Registries (Public/Non-public) CRM/ERP vendor Registries (Package of services) E-market places (Private/Open) Consortia Registries (Industry specific/Standards specific) etc..
  • From Cardoso’s PhD dissertation
  • From Cardoso’s dissertation
  • Three value propositions for using templates: (a) allows you to focus on semantics of the process rather than WSDL of constituent Web services, (b) better structure to help optimize Service selection, and © help in validation
  • Semantics (of information, communication) is a very old area, and extensive work on Semantic Technology has been going on for well over a decade (many projects on semantic interoperability, semantic information brokering) Semantic Web and related visions are being achieved in various depth and scope – mostly starting with targeted applications where requirements are much better understood and scope is manageable
  • ×