Re: DAML-S and UDDI

Jeff Lansing writes:

 > Ok, this looks pretty good. So, given your mapping to UDDI, how will I 
 > get a bunch of services registered in this way? Perhaps there should be 
 > a Protege plugin?

There is a server running at CMU (www.damlsmm.ri.cmu.edu) which we try
to keep constantly running.  Unfortunately, at the time of the
implementation we did not have access to any open source UDDI server
which could support the mapping.  Therefore we used the IBM public
site first, and then we installed a publicly available UDDI server
which was not open source.  Currently we are considering whether to
use JUDDI and integrate our matching engine more closely with the UDDI
server.

 > Also, there seems to be a lot of room for making type/instance 
 > confusions. For example, a service type will have a certain set of 
 > inputs, outputs, and preconditions. But the instances of services of 
 > that type could (probably would) have different geographicRadius's. So 
 > some tModels would be shared, and others not.

The mapping you looked at is based on DAML-S 0.6, the mapping has been
cleaned up quite a bit in 0.7 and more recently in 0.9, so hopefully
some of the confusion may be solved that way.  

I am not sure what you mean with "instances of services", since the
DAML-S Profile advertises instances of services, not classes.
Nevertheless, I think that what you are asking is the following: let's
assume that the advertisement of a service and the request for the
service indicate the same functional capabilities (the two services do
the same thing) but different geographic radious, is there a match?
At the moment our matchmaker ignores geographic radious and
concentrates only on capability matching (matching inputs and
outputs).  But this is only a temporary solution, the problem is that
there is a trade-off between quality of matching and effort spent by
the matchmaker: by minimizing the features used for matching, we can
reduce the matching time, at the cost of loss of precision.  So far we
concentrate on matching inputs/outputs, but if evidence emerges that
other features are vital also, we can easily extend our range.  For
example Li and Horrocks, in their www2003 paper) show how geographic
radious can be used in Web services matching.

 
 > Also, there isn't really a lot of information about the actual tModels 
 > in the mappings, and what they are supposed to be doing. For instance 
 > the DAML-S tModel: what's that? Would there be just one of these for all 
 > services?

The TModels we adopted store values of the DAML-S Profile that are not
directly rapresented in the UDDI API.  In the example of the
Geographic-Radious if the value in the Profile was http://some-uri#USA
that is the value stored in the TModel.  The DAML-S tModel is used
only to mark that the service has a DAML-S description, and to record
where such a description is.  It can be used to retrieve description,
or to query UDDI for all the Web Services with a DAML-S description.

Thanks for the good questions,

--- Massimo


 > 
 > Thanks,
 > 
 > Jeff
 > 
 > 
 > Katia Sycara wrote:
 > 
 > >Jeff, in my lab at CMU, besides publications like the one Terry referred
 > >you to, we  have an implementation of a DAML-S matchmaker integrated
 > >with UDDI.
 > > Please check www.cs.cmu.edu/~softagents under Semantic web research, in
 > >particular Daml-s matching engine. 
 > >
 > >-----Original Message-----
 > >From: www-ws-request@w3.org [mailto:www-ws-request@w3.org] On Behalf Of
 > >Jeff Lansing
 > >Sent: Friday, August 01, 2003 11:07 AM
 > >To: www-ws@w3c.org
 > >Subject: DAML-S and UDDI
 > >
 > >
 > >Hi,
 > >
 > >Has anyone proposed a mapping for storing DAML-S in a UDDI registry? Or 
 > >is this just a totally bad idea, that I haven't seen why it is such,
 > >yet?
 > >
 > >My thought was: Hey, if web services is UDDI + SOAP + WSDL (and, 
 > >implicitly, if you believe the hype, that's all it is), and we know that
 > >
 > >you can't even begin to figure out what a service does from its WSDL, 
 > >then why not.
 > >
 > >Jeff
 > >
 > >
 > >
 > >
 > >  
 > >
 > 
 >

Received on Monday, 4 August 2003 01:21:53 UTC