- From: Katia Sycara <katia+@cs.cmu.edu>
- Date: Mon, 31 Jan 2005 14:17:38 -0500
- To: 'Charlie Abela' <charles.abela@gmail.com>, jpathak@cs.iastate.edu, 'Jyotishman Pathak' <jyotishman@gmail.com>
- Cc: public-sws-ig@w3.org, katia@cs.cmu.edu
Charlie, Jyoti and all, There were a number of issues raised in this discussion: 1. Does OWL-S discovery assumes that requesters and provides use a unique ontology? The answer is NO. OWL-S does not assume the use of a single onrology. It is difficult, however, to see what you mean by "one single ontology". If you mean "one single OWL file", then of course trivially OWL-S does not assume a single ontology since you can import as many OWL files as you desire in an OWL-S description, and use any of the concepts defined in those files to describe the OWL-S profile or any other OWL-S component. During the discovery process the Profile of the requested service may refer to a concept, say a:A (the concept A defined in "file" a), and an advertisement may refer to concept b:B that belong to a different ontology (different owl files), and yet b:B may be defined as a subclass of a:A. In this case, matching engines would still be able to match exploiting the logical relation between A and B. At CMU, we have shown different kinds of matches (e.g. exact, plug-in etc) in our matching algorithm (see e.g. [3]). Another way in which the use of different ontologies can be handled in OWL-S is through mapping rules that could be expressed in SWRL. In this way, to the extent that the similarity between A and B can be made explicit, then the mapping can be exploited. Of course there are issues of where these mappings live, how it is discovered where they live, since of course in the process of service discovery one does not know a priori what the ontological needs of one request would be vis a vis the current advertisement knowledge base. Even if one assumes a unique knowledge base containing such mappings, another set of issues is of course, how this knowledge base gets searched efficiently. The issue of ontological mapping is an old and well known one that has predated Semantic Web Services. Work on how to express mappings to achieve semantic interoperability efficiently (even assuming the mapping rules are known) has been going on since the late 80's (perhaps even earlier). The general problem of arbitrary ontology mapping is an open research problem. The real scientific work is in trying to attack the technical issues that I outlined (and others that are there but I did not refer to). After we solve these scientific problems (ie. How to derive the mappings, and how to use them), we can worry about what to call the algorithms. Since ontology mediation is an open research issue, OWL-S is agnostic about the actual ontology mediation process used. To the extent that the mediation process is a service, rather than a set of rules, it can be represented in OWL-S and discovered. 2. Should OWL-S do something about ontological mediation like WSMO is doing with the OO mediators? Up to now, there is no clear operational definition of what a WSMO mediator is, neither is there a clear specification of an ontology or language for describing mediators, or an algorithm for ontological mediation. To the extent that WSMO mediators are services, rather than sets of rules, they can be represented in OWL-S by specifying what is their profile, process model and grounding (for a detailed discussion on this point see [2]). Furthermore, the discovery mechanism may then become similar to a composition procedure where you combine discovery of the appropriate mediator with the discovery of the appropriate service. Note that if you take this viewpoint, the sentence "OWL-S has no mediators" is non-sensical: it is analogous to sentences like "Java has no Operating System" or other such sentences. OWL-S is a language (it uses OWL semantics) that allows you to describe Web services, it does not tell you what infrastructure Web services need, nor does it stipulate the existence of mediators or of a discovery registry or any other component. If you think you need a mediator, the role of OWL-S is to provide you the tools to describe a mediator if you decide to implement it as a Web service. If you look at [2] there is a discussion on how to do that. 3 The question was: Does the OWL-S profile consists only of inputs and outputs? The answer is again NO. The OWL-S profile (that is used to express service advertisements and requests) includes service description, product description, inputs, outputs, preconditions, effects, access conditions, quality of service, security parameters etc . All these can be expressed in OWL ontologies and matched. As a matter of fact the next version of the CMU matchmaking algorithm is going to include matching on those (rather than just matching on inputs and outputs). In prior work, [1] we have also developed an algorithm to match security parameters. [1] Kagal, L., Paolucci, M., Srinivasan, N. Denker, G., Finin, T and Sycara, K., "Authorizationa and Privacy for Semantic Web Services", IEEE Intelligent Systems, V. 19, No. 4, July/August 2004. [2] www.ai.sri.com/SWS2004/final-versions/ SWS2004-Paolucci-Final.pdf - [3] Sycara, K., Paolucci, M. Ankolekar, A., Srinivasan, N. "Automated Discovery, interaction and composition of Semantic Web Services", Journal of Web Semantics, Vol 1. no. 1, December 2003, pp. 27-46. I hope this helps to clarify the situation, --Katia Sycara and Massimo Paolucci Carnegie Mellon University Members of the OWL-S coalition ------------------------------------------------------------------- -----Original Message----- From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org] On Behalf Of Charlie Abela Sent: Friday, January 28, 2005 4:34 PM To: jpathak@cs.iastate.edu Cc: public-sws-ig@w3.org Subject: RE: Service Discovery >From what I understood about querying services defined in OWL-S is basically that a query should be similar to a profile. I feel that this is not that realistic, as I've pointed out in earlier mails to this list. I've also asked whether its possible to change the profile to reflect differences between service capabilities and goals, similar to what other initiatives are doing, for eg. WSMO. Such seperation together with existing constructs such as service category, taxonomy etc can help in creating more realistic queries. As u pointed out, in real situations, client requesters and matchmakers will not necessarily use the same ontologies, and as Adrian pointed out this is quite a major hurdle. Adding to this, the defintion of a request based solely on input and outputs, possibly also preconditions and results, makes it even worst. I may be way out in my argumenation of this issue, and would also really like to hear the OWL-S coalition' members' view on this. Regards Charlie -----Original Message----- From: public-sws-ig-request@w3.org [mailto:public-sws-ig-request@w3.org]On Behalf Of Jyotishman Pathak Sent: 28 January 2005 21:19 To: Adrian Walker Cc: public-sws-ig@w3.org; jyotishman@gmail.com Subject: Re: Service Discovery Hi Adrian, Thanks for your reply. But, I am still confused about how to discover a service based on IOPE's. For example, assume that the following are the inputs for the Congo service (in its profile) as part of an advertisement :- <profile:hasInput rdf:resource="&congProcess;#ExpressCongoBuyBookISBN"/> <profile:hasInput rdf:resource="&congoProcess;#ExpressCongoBuySignInInfo"/> Here, "&congProcess;#" refers to the name space of the "Process" of Congo service. Having this, can you please give me an example of a service requesting query (based on the inputs) ? In other words, if I were to specify a request query to discover the Congo service, how would it look like ? Please feel free to correct me if my question itself is wrong. I will also appreciate inputs from others in the mailing list. Regards, Jyoti. On Fri, 28 Jan 2005 13:16:39 -0500, Adrian Walker <adrianw@snet.net> wrote: > > Jyoti -- > > You wrote... > > >can you give me an example of a service request & > >advertisement which uses different ontologies ? > > Cross-ontology reasoning is complex. There's an approach to this in the > retailer-to-manufacturer example in [1]. The examples [2,3,4,5] may also > provide food for thought. > > They can be run in an online system at the same URL. > > HTH, - Adrian > > [1] > http://www.reengineeringllc.com/Internet_Business_Logic_and_Semantic_Web_Pre sentation.pdf > > [2] http://www.reengineeringllc.com/demo_agents/DataModelling1.agent > > [3] http://www.reengineeringllc.com/demo_agents/MergeOntologies1.agent > > [4] http://www.reengineeringllc.com/demo_agents/OntologyInterop2.agent > > [5] http://www.reengineeringllc.com/demo_agents/RDFQueryLangComparison1.agent > > Adrian Walker > Reengineering LLC > PO Box 1412 > Bristol > CT 06011-1412 USA > > Phone: USA 860 583 9677 > Cell: USA 860 830 2085 > Fax: USA 860 314 1029 > > > At 09:58 AM 1/28/2005 -0600, you wrote: > > >Hi, > > > >I am a beginner with the SWS technologies and have been doing some > >reading about the service discovery mechanims, mostly focussing on the > >OWL-s approach. > > > >What I can decipher is that, the "profile" (which is used by the > >service provider to describe the capabilities & service requestor to > >specify the request) forms an important part for the service discovery > >mechanism. Based on this, I have a couple of questions: -- > > > >1.) Do we assume that the service requestor and the provider use the > >same ontology to describe the IOPE's ? > > > >2.) If yes, then do we achieve "real" interoperability ? I think we > >are constraining ourselves as it is unrealistic for requestors & > >providers to have the same/shared ontologies. > > > >3.) If no, can you give me an example of a service request & > >advertisement which uses different ontologies ? > > > >4.) I believe the WSMO approach tries to address few things about > >mediation between ontologies. Should we do something like this for > >OWL-s too ? > > > >It might be possible that my questions are naive and infact may be > >wrong too. But, I will really appreciate some feedback on these > >issues. > > > >Regards, > >Jyoti. > >
Received on Monday, 31 January 2005 20:20:00 UTC