RE: DAML-S and UDDI

Jeff,
	Following on with the rest of your email...

Finding some sort of synergy between DAML-S and UDDI makes a lot of
sense.  The Agents community have done a lot of work on locating Agent
services through signature descriptions - Katia Sycara and Matthias
Klusch wrote an excellent survey on Agent matchmaking and brokering [1],
which lead onto the work on LARKS.

The rationale that one could utilise signatures was the basis of much of
the work on the DAML-S profile.  Whilst it is important to provide white
and yellow page information for service discovery, it typically requires
human mediation to locate services.  Signature information (such as that
used by WSDL) was found to be successful in locating services within
Agent communities, but was somewhat limited by the lack of semantics -
unless there was an a-priori agreement on the use of terms, automation
was all but impossible.

DAML-S certainly is trying to address this, as you know, and a
hybridised approach combining DAML-S profiles and UDDI made a lot of
sense (hence the work at CMU).  UDDI 1.0 was somewhat limiting in what
we could do because of its restrictions on T-Models.  This limitation
led onto the work on UDDI-e (primarily from the eScience and Grid
community in the UK), which provided a mechanism for adding large
amounts of metadata to UDDI records (although UDDI 3.0 provides far
better support for managing largescale metadata), and the more recent
UDDI-mT [2], which investigated a hybrid approach for storing both UDDI
and DAML-S descriptions within an RDF store (kinda the opposite approach
to the CMU work), thus supporting traditional UDDI queries and DAML-S
semantic queries.  Incidentally, this approach has also been augmented
to support semantic discovery of bioinformatics services such as bioMoby
services, etc [3].

The bottom line here is that by combining information about the type of
service one has (e.g. its white and yellow pages descriptions) and the
signatures it exposes (i.e. green pages/WSDL), then this can facilitate
better service discovery.  DAML-S not only offers this, but combines the
ability to refer to service or business types (i.e. similar to using
T-models for representing NAICS types), with the ability to parameterise
service classes (i.e. DAML-S profile hierarchies) [4,5].

Hope this helps,

	Terry

[BTW - I just realised that the pdf for [2] is not available on the web
- I'll see if I can rectify this...]

[1] http://www-2.cs.cmu.edu/~softagents/papers/mm-broker-survey.pdf
[2] http://eprints.ecs.soton.ac.uk/archive/00007658/
[3]
http://twiki.mygrid.info/twiki/pub/Mygrid/ServiceDirectory/AHM2003Servic
eDiscovery.html
[4]
http://www.daml.ecs.soton.ac.uk/notes/DAML-S0.7DraftPrimer_files/frame.h
tml - Slides 26/27
[5] http://www.daml.org/services/daml-s/0.7/ProfileHierarchy.html



_______________________________________________________________________
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
> Jeff Lansing
> Sent: 01 August 2003 17:07
> 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 Saturday, 2 August 2003 13:49:22 UTC