W3C home > Mailing lists > Public > public-sws-ig@w3.org > December 2003

RE: UDDI and semantics: CMU OWL-S/UDDI Mapping

From: Katia Sycara <katia@cs.cmu.edu>
Date: Wed, 3 Dec 2003 16:28:30 -0500
To: 'Ugo Corda' <UCorda@SeeBeyond.com>, public-sws-ig@w3.org
Cc: katia@cs.cmu.edu, paolucci@cs.cmu.edu
Message-ID: <007301c3b9e4$663fb8c0$d1bd0280@scs.ad.cs.cmu.edu>
 Jeff and Ugo,

   Jeff wrote:

> Given that UDDI is not going to do reasoning, and given that it is 
> already possible to register taxonomies (including OWL ontologies) to 
> associate services with categories (including with the entities and the 
> properties in an OWL ontology), and to find the services for a category 
> or the categories for a service, what more is there? 
> Or rather, what other benefit could there possibly be? 
> Jeff 

Since the current UDDI does not do any reasoning, this is why our OWL-S
group at CMU created the OWL-S/UDDI matchmaker to allow this "enhanced UDDI"
to do reasoning. In addition, the OWL-S/UDDI matchmaker (1) implemented the
inclusion of OWL ontologies in the current UDDI and (2)  how to do
ontological reasoning on those ontologies for finding appropriate services. 


Your notion of finding a service seems to imply that it is simply a matter
of matching strings. In practice, one needs to match concepts not simply
strings. The difference between string matching (which is the only way
current "vanilla" UDDI operates) can be illustrated as follows, as we
presented   in a previous message:

Amazon and B&N may advertise their service category as "book_seller".

 Suppose I look for somebody that sells me paperbacks

 and I express that as "paperback_seller". Now, even if the category
"paperback_seller" exists in the taxonomy, the current mechanism of UDDI
based on the category bag will fail to find Amazon or B&N as potential
matches to my request. This is because there is no inference mechanism that
can do subsumption reasoning. On the other hand, concept matching implies
there is an ontology (not just a taxonomy) and a subsumption inference

Ugo Corda wrote:

Let me try to turn around my original question and see if we can get a
better understanding of the issue. The paper "Importing the Semantic Web in
UDDI" describes the mapping of the DAML-S Profile to UDDI data structures.
From the diagram in Fig. 5, it seems that most of the Profile information is
simply mapped to existing UDDI structures, so that what is already available
in UDDI is sufficient for a faithful mapping. 

So a question could be: are there other elements of the DAML-S Profile (not
shown in that picture) that currently do not easily map and that would
benefit from the creation of new data structures in UDDI? Alternatively, is
it useful to come up with a more complex Profile that, while currently
difficult to map, would easily map with the addition of new data structures
to UDDI and would provide more reasoning power?



Since the Tmodel mechanism of the "vanilla" UDDI is an unconstrained list of
attribute value pairs, of course one can "map" anything into it. The million
dollar question is the guanrantee of semantic consistency of the content of
TModels. For example, we define an "input TModel" that contains OWL-S inputs
for a particular associated service. Somebody else may use a TModel with the
same name to express some other concept. UDDI will not detect the

So, although we mapped the whole  DAML-S/OWL-S profile to UDDI structures
(ie TModels), that fact in itself does not endow UDDI with semantics. UDDI,
by using the TModel mechanism, which is not constrained, misses the notion
of an object whose attributes and values represent the capability of a
service. Note here that the DAML-S/OWL-S notion of capability is richer than
simply the string representing a service category in some taxonomy. The
OWL-S profile provides the "richer" notion of service capability.

The second thing that is missing from UDDI is an inference mechanism. The
CMU DAML-S matchmaker contains an engine that provides an inference

So, the take  home message as to future  enhancements of UDDI is :

a.       a mechanism/data structure for  an explicit representation of a
service capability

b.       an inference engine possibly based on OWL 

c.       strong "ontological" typing on TModels, ie typing based on OWL
rather than just XMLSchema.

Katia and Massimo
Received on Wednesday, 3 December 2003 16:29:13 UTC

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