- From: <sam.watkins@bt.com>
- Date: Tue, 14 Sep 2004 11:10:10 +0100
- To: <luke.steller@infotech.monash.edu.au>, <paolucci@cs.cmu.edu>
- Cc: <public-sws-ig@w3.org>
Hi, I think the first case shows why mediation services are of increasing importance. They take the input in the form of one ontology and pass on the output in the form of the second. Obviously, this requires the author of the mediator to be fluent in terms of both ontologies in order to conserve meaning. I think it is interesting to find the means of constructing these mediators without the author having to be fluent in OWL-S (or any other ontology description language) but just in the meaning of the ontologies. While this would allow assisted composition using mediators, rather than fully automated composition, I think this would be a good stepping stone towards automated composition. We could also learn from users alignment of ontologies, forming databases of mediation... What does everyone else think? regards, Sam J Watkins ------------------------------------------------------------------- Next Generation Web Research, BT Tel: +44(0) 1473 60963 -----Original Message----- From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On Behalf Of Luke Steller Sent: 14 September 2004 07:12 To: Massimo Paolucci Cc: public-sws-ig@w3.org Subject: Re: [owl-s] communication between web services Hello, On ontologies, to clarify, if two web services use two different ontologies they cannot understand one another. However if someone defines a 3rd ontology, that maps the parts of the seperate ontologies together, or if these two seperate ontologies reference other ontologies which in turn reference the same ontology, then they can understand one another. On service profiles and service process models. The process model defines composite processes as being made up of many atomic processes. Atomic processes are in turn mapped to WSDL service calls (by the service grounding). However for match making purposes, the process model is too detailed. This is where the service profile comes in. The service profile will reference certain inputs and outputs that describe the service as a whole, in a more abstract context. So in Massimo's book example, like he says: the profile will tell you that the web serivce takes a title and gets you the book, the profile will probably make direct reference to the process model in doing this. That is it may reference the starting inputs of the composite process, and the ending outputs of the composite process. It is a way of abstracting the parts in between, which are not a concern of service requestors. Hope that helps, Luke School of Network Computing Faculty of Information Technology Monash University Australia Massimo Paolucci wrote: > Jean-Michel, > > First, an ontology is like a dictionary: it defines terms in a very > precise and unique way. If two web services use different ontologies > they just do not share a common dictionary, they cannot understand > each other. You can have two great mechanics, one a Inuit the other a > Greek, unless they find a common language their working together will > be very difficult. Web services are not any different, only more messy > since they are automatic. > > Second, the OWL-S Profile gives a glimpse of the Web service as a > monolithic thing, the Process Model allows you to reason about the > different processes. For example, to buy a book you need 1. to give > the book title 2. select the best book among all the books that have > been proposed, 3. pay for what you selected. 4. you get the book. The > Profiles will tell you that the Web service takes a title and gets you > the book (it is a book selling service), the Process Model spells out > the steps 1. to 4, WSDL tells you how to map each step to a message or > a remote procedure call. > > Cheers, > > --- Massimo > > > jean-michel nougayrede wrote: > >> Hi, >> >> Thanks for your answers. But there are some points where I need few >> more explanations please ... >> >> First, >> >> All the inputs and outputs of the functions of a web service must be >> defined in some ontology. >> >> But let's imagine that we have two web services which work on the >> same domain and they want to communicate between each other. But they >> don't have exactly the same ontology (they don't have the same owl >> file). So they can't understand each others and so they never can >> communicate between each other in spite of being in the same domain. >> Is that what it means? >> >> Secondly, >> >> The service profile is used to describe the web service in order to >> be automatically discovered. Service Profile used the inputs and >> outputs of the function in order to describe the web service. So with >> the service profile we can find the web service we want in order to >> execute the function we want. >> >> Then what is exactly the role of the Service Model (or Process >> Model)? Because all the informations needed by the web service are >> describe in the service profile. What I understood is that it is used >> in order to describe what the web service does with the informations >> (if it calls an extern web service ...). But how this can be used by >> the requestor if it is automatic? Does the requestor analyse this >> (during an automatic execution of the web service)? Or does the >> process model not only used for the description of the web service >> processes? >> >> Sorry if my English is not very clear but it is a little difficult to >> explain. Thanks for your attention. >> >> Jean-Michel >> >> --------------------------------------------------------------------- >> --- >> >> *De :* Massimo Paolucci [mailto:paolucci@cs.cmu.edu] >> *Envoyé :* vendredi 10 septembre 2004 20:42 >> *À :* jean-michel nougayrede >> *Objet :* Re: [owl-s] communication between web services >> >> jean-michel, >> >> it all depends on the modeling: you have to be able to encode enough >> information to distinguish the different cases. Specifically, you >> will have to describe the sender, the receiver and the address as >> different concepts then you can say that the function that you want >> to model would be sendpackage(sender,receiver,address) in which case >> things may become more manageable. >> >> The view of OWL-S is that the whole set of concepts is used, strings >> should never be used directly, but buried inside concepts so that the >> semantics of OWL can be exploited. >> >> I hope this is clear, >> >> --- Massimo >> >> >> jean-michel nougayrede wrote: >> >>Hi, thanks for your answer. >> >> >> >>I agree that process model describe what the web service needs to >>execute >> >>correctly. >> >>But in my case, let's imagine that the web service B has the function >> >>sendpackage (name1, name2, address). The process model describes that >>the >> >>function sendpackage need the three arguments name1, name2 and >>address. But >> >>how the web service A could understand that name1 is the name of the >>sender, >> >>name2 is the name of the receiver and address his address? >> >> >> >>What I don't understand is that in the white paper owl-s, it is >>explained >> >>how the web service must be described but not how an extern web >>service can >> >>understand this description and use it. Am I wrong? >> >> >> >>Jean-Michel >> >
Received on Tuesday, 14 September 2004 10:10:53 UTC