W3C home > Mailing lists > Public > www-ws@w3.org > November 2002

RE: Service Disovery using DAML-S

From: Terry Payne <trp@ecs.soton.ac.uk>
Date: Thu, 14 Nov 2002 16:33:32 -0000
To: <www-ws@w3.org>
Message-ID: <000d01c28bfb$922c3ca0$76be4e98@scs.ad.cs.cmu.edu>
[This is essentially my response to Vikas - I thought I'd cc it to the
list]

 

Vikas,

 

I have to create a system, which can accept a request for service from
an agent. This agent will send me a DAML-S formatted message, using
FIPA-ACL protocol. This can either be an advertisement or request for
service. If it is an advertisement - than you have to add the service to
the advertisement database. And if it's a request for service than you
have to search for the appropriate services and return a list of agents
that can provide the requested service.

 

Ok - this is the essential idea of a matchmaker discovery service, yes.

 

Thing is I am not sure of what I am thinking if it is right or wrong.
From what I have read till now it looks like, that the advertisement
database can be any database - can be Oracle , SQL, UDDI, XML based DB.
Basically the database will be used for the persistent storage of the
advertisements for services which are daml-s documents.

 

The choice of database really depends on what your requirements are, and
how you intend to design your matching engine.  If you plan to simply
traverse the store sequentially to compare each stored advertisement
with a request, then it probably doesn't matter how you store the
advertisements.  However, if you want to make use of some intelligent
way of querying a DB, then you might want to use a DAML+OIL or RDF based
db with an associated query language (the two things that come to mind
are Squish from Bristol's ILRT and some stuff Pat Hayes was recently
discussing wrt a DAML+OIL query language.

 

Finally, you might want to devise a way of performing some reasoning at
the time an advertisement is received, in which case you would want to
store this information rather than (or in addition to) the DAML-S
advertisement.  For example, you might want to convert the
advertisements into triples and stores these rather than in an XML
format.

 

 Also you will need a DAML+OIL reasoner, this can be either FaCT, RACER,
XSB or TRIPLE.

 

Yes, or any DL reasoner that is consistent with the DAML+OIL spec.

 

Also you will need to develop service ontology - for which I am thinking
of using the JENA toolkit.

 

I'm not sure if I understand you here - do you mean that you need to
write a service ontology, or to parse one?.

 

What I am thinking is once the message is received it will go to some
form of Matchmaking programs- written in Java - I think so - and it will
see if its an advt, it will simply add it to the database. 

 

[ VERY IMPORTANT PLEASE CHECK IF I AM CORRECT] But if it's a request for
service than it will use a DAML+OIL reasoner to check the ontology for
services for services which are not just syntactically similar but also
semantically mean the same. For example it can search for services which
can provide him with a stock quote service. But a stock quote service
can be provided also by someone who can provide financial service. Thus
both of these services name will be returned to the matchmaking
programs. Now the matchmaker searches the advertisement database for
services that names are returned (in this case it is financial service
and stock quote service) and return the name and description of all the
agents who can provide either of the services. 

 

Ah, you are hitting some of the interesting issues here!  Yes, you are
right that one should determine from the message whether it contains and
advertisement or request.  One should also consider the performative
here as well, and not just make assumptions about the role of the
request based on the payload.  For example, somebody else might write a
"wanted-ads" matchmaker, whereby requesters register their requests with
a repository, and then providers submit an advertisement describing
their capability to the repository.  In this case the repository would
look to see if there are any outstanding requests for service that match
the advert, and return the details to the provider (i.e. in response to
the advertisement) about the matching requester.

Ok, this is not what you are doing, but illustrates that just because
the ACL message contains an advertisement as the payload (i.e. content),
that doesn't necessarily mean that the matchmaker should store the
advertisement.  Ok, in your case it does, but you need some more
explicit mechanism to indicate this, such as the choice of performative,
etc.

 

The matching engine would typically use a reasoner to determine if a
request and an advertisement were semantically similar.  Now, an
important consideration is what the matchmaker returns.  If the matched,
stored advertisement has an associated URI pointing to the original on
some web site, would it be sufficient simply to return the URI of that
advertisement?  Or perhaps the URI of the resource that provides the
service (or the service itself)?  Or should the whole advertisement be
sent (i.e. there may not be a http retrievable version of the
advertisement at its associated URI).

 

But an issue that most people overlook is that to perform the matching,
the reasoner "did some reasoning based on the ontologies and concepts
that were loaded at the time"!  Thus, the association between the
matching advertisement and the request might not necessarily be apparent
to the user without repeating the reasoning.  Also, there ma have been
additional axioms present at the matchmaker that are not present when an
agent tries to recreate the reasoning that matched the advertisement and
the request.  Hence, it might be necessary to generate and include some
additional axioms or whatever with the reply message, so that a calling
agent can see how and why an advertisement matches a request.

 

Another thing to consider is what happens when several advertisements
match a request.  Are they all returned?  Or does the requester receive
a subset - in which case how is that subset determined?  Does one use a
stochastic selection mechanism or knowledge about current service
loading?  Or does one simply rank the likelihood of match and return
them in order (and then what is the ordering criteria if the similarity
of match is equivalent across several advertisements)?  Also, what
criteria should the requester use to determine the best match based on
the list of returned matches? 

 

Can you please comment on what I am thinking if it is right or wrong.
Also I am not sure if anyone has already written any programs to do
this. As I think CMU has this system running. I am not sure which
database should I use for advertisements and if it will support daml-s,
any recommendation will help. Also I am not sure on the DAML+OIL
reasoner to use, which can also interact with java programs. So any
comments will help a lot. 

 

You have the basic idea here, but there are many other issues involved.
Ok, so many of these issues are for further research and would not
necessarily require investigating to get something working for now..

 

I hope this helps?

            Terry

 

 

_______________________________________________________________________
Terry R. Payne, PhD.      | http://www.ecs.soton.ac.uk/~trp/index.html
University of Southampton | Voice: +44(0)23 8059 8343 [Fax: 8059 2865]
Southampton, SO17 1BJ, UK | Email: terry@acm.org / trp@ecs.soton.ac.uk

-----Original Message-----
From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of
Vikas Deora
Sent: 14 November 2002 14:30
To: www-ws@w3.org
Subject: Service Disovery using DAML-S

 

Hi,

 

I had a query. I have to create a system, which can accept a request for
service from an agent. This agent will send me a DAML-S formatted
message, using FIPA-ACL protocol. This can either be an advertisement or
request for service. If it is an advertisement - than you have to add
the service to the advertisement database. And if it's a request for
service than you have to search for the appropriate services and return
a list of agents that can provide the requested service.

 

Thing is I am not sure of what I am thinking if it is right or wrong.
From what I have read till now it looks like, that the advertisement
database can be any database - can be Oracle , SQL, UDDI, XML based DB.
Basically the database will be used for the persistent storage of the
advertisements for services which are daml-s documents.

 

 Also you will need a DAML+OIL reasoner, this can be either FaCT, RACER,
XSB or TRIPLE.

 

Also you will need to develop service ontology - for which I am thinking
of using the JENA toolkit.

 

What I am thinking is once the message is received it will go to some
form of Matchmaking programs- written in Java - I think so - and it will
see if its an advt, it will simply add it to the database. 

 

[ VERY IMPORTANT PLEASE CHECK IF I AM CORRECT] But if it's a request for
service than it will use a DAML+OIL reasoner to check the ontology for
services for services which are not just syntactically similar but also
semantically mean the same. For example it can search for services which
can provide him with a stock quote service. But a stock quote service
can be provided also by someone who can provide financial service. Thus
both of these services name will be return to the matchmaking programs.
Now the matchmaker searches the advertisement database for services that
names are returned (in this case it is Financial service and stock quote
service) and return the name and description of all the agents who can
provide either of the services. 

 

Can you please comment on what I am thinking if it is right or wrong.
Also I am not sure if anyone has already written any programs to do
this. As I think CMU has this system running. I am not sure which
database should I use for advertisements and if it will support daml-s,
any recommendation will help. Also I am not sure on the DAML+OIL
reasoner to use, which can also interact with java programs. So any
comments will help a lot. 

 

Thanking you

Vikas Deora

 
Received on Thursday, 14 November 2002 11:41:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:41 GMT