W3C home > Mailing lists > Public > public-sws-ig@w3.org > January 2005

RE: Service Discovery

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
Message-ID: <001b01c507c9$87902940$d1bd0280@cimds.ri.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

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

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.



-----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.


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]
> [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]
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:54:14 UTC