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

Tom,

You wrote:

>Regarding your million dollar question, I think there may be a
>misconception below on tModels.  tModels can have names,  which as you
>point out, are not unique.   What is unique though is the tModelKey
>associated with the tModel.  In UDDI V3, this is a user definable uri,
>which must be unique within the registry.
>For example:  uddi:mydomain.com:UnitedBookSellerOntology:paperback_sellers,
>or some such.  Once published, no one else can create another with this
>key.   The tModel name is just a useful string describing the tModel.  It
>should never be used as the actual (pointer) reference to the tModel.

There are two additional issues:
First, it is ok to define a unique tModelKey for paperback_sellers as in
your example. However, you still have to define a relation between the
unique tModelKey for book_sellers and paperback_sellers (ie current UDDI
does not support this automatically).

Second, the problem is not the uniqueness of the tModelKey but the content
assigned to the "keyed reference" that refers to the tModel. To our
knowledge, UDDI V3 allows for checked and unchecked keyed references. With
unchecked key references  UDDI does not enforce any type checking on the
content of the kewed reference values. For example, I can have a tModelkey
with the unique URI uddi:Katia:price with the value USD 500. Somebody else,
called Mary, may use a tModel with the same key but put an inconsistent
value, e.g. the listing of names and price of all the products she sells.
(e.g. computer1 300, computer2 250 ...). UDDI will not detect the different
use of the same tModelKey.

If instead, an OWL type was associated with the tModelKey, we could have
uddi:Katia:price with value the concept price, which could be defined as
follows: (note that for readability we are not expressing in the OWL syntax)
   price
     value: Real
     currency: WorldBank#Currency

where Real corresponds to XMLSchema real type and the WorldBank#Currency is
the concept that identifies all the known currencies in the world as
published in a World Bank ontology. 

Then a legitimate value for Katia:price  would be expressed as 
   price
     value: 500
     currency: WorldBank#USD  (which is an instance of WorldBank#Currency)

Mary will have to define her list of prices in a different ontology. If she
were to use the uddi:Katia:price tModelKey, then a "semantic UDDI" would be
able to infer the inconsistent use of the tModelKey by Mary.



You also wrote:
>Clearly, the option of having a highly sophisticated inference engine built
>into UDDI is a major step.  I'm curious about the relative value
>proposition of perhaps doing something in between, such as supporting a
>basic subsumption capability to use the defined relationship information
>within an ontology to enhance searching.  Assume we were to import a
>particular ontology including its relationship and other meta information
>into UDDI and then classify a particular service of interest with a few
>properties from this ontology (obviously a new capability, not just
>categoryBag as used today).  Making a query then to search based on a
>particular property would, without a subsumption analysis, just do a string
>based discovery - which as you point out is not an improvement.   If we had
>the ability to analyze the given properties for relationships with others
>based upon the imported ontology, the UDDI server could then augment the
>query with other properties which also should drive a match (although this
>is still string based).  I'm just thinking of hierarchical relationships in
>this example, such as recognizing that a paperback_seller is also a
>book_seller, etc.

We think that description logics (which is the logic underlying OWL and also
our OWL-S/UDDI matchmaker inference engine) provides such an intermediate
point. For some DL logics, subsumption can be computed at worst in
polynomial time, for others the worst case complexity is higher but in
practice there are very effective optimized inference engines, so they would
not be a computational bottleneck. Also there has been a lot of work in
using these DL logics in database management systems.

You also wrote:
>Of course, relationships could be infinitely complex, which is certainly a
>concern.   The sophistication of an inferencing engine can also be made
>very complex as well - such as the ability to expand a search based on the
>"strength" of the match, where a weaker relationship criteria might be
>tolerable/desired.   It would seem to me that supporting that type of thing
>would be much more complex, and could take many forms - something likely to
>remain beyond the scope of standardization within UDDI at this point.

The "strength" of a match is an interesting open research issue. In our
OWL-S matchmaker, we implement and recognize 4 different strengths of match:
(1) exact match, (2) the capability advertisement subsumes the request, (3)
the request subsumes the capability advertisement, (4) failure to match. Of
course one can envision refinements of the strength of match within the (2)
and (3) categories. In earlier work on the LARKS system, we had some
additional heuristics for these extra refinements.

You final question was:

>So back to the question, how valuable would it be to find some middle
>ground as I've described above?  Or have I missed your points entirely?

Our opinion is that DL inference provides such a middle ground.

   --Katia and Massimo

-----Original Message-----
From: Tom Bellwood [mailto:bellwood@us.ibm.com] 
Sent: Wednesday, December 03, 2003 6:14 PM
To: Katia Sycara
Cc: 'Ugo Corda'; public-sws-ig@w3.org; paolucci@cs.cmu.edu;
uddi-spec@lists.oasis-open.org
Subject: RE: UDDI and semantics: CMU OWL-S/UDDI Mapping






Katia,

I've been following this thread on and off since Max Voskob originally
posted for us a few weeks ago,  and I have a couple comments.

Regarding your million dollar question, I think there may be a
misconception below on tModels.  tModels can have names,  which as you
point out, are not unique.   What is unique though is the tModelKey
associated with the tModel.  In UDDI V3, this is a user definable uri,
which must be unique within the registry.
For example:  uddi:mydomain.com:UnitedBookSellerOntology:paperback_sellers,
or some such.  Once published, no one else can create another with this
key.   The tModel name is just a useful string describing the tModel.  It
should never be used as the actual (pointer) reference to the tModel.

Clearly, the option of having a highly sophisticated inference engine built
into UDDI is a major step.  I'm curious about the relative value
proposition of perhaps doing something in between, such as supporting a
basic subsumption capability to use the defined relationship information
within an ontology to enhance searching.  Assume we were to import a
particular ontology including its relationship and other meta information
into UDDI and then classify a particular service of interest with a few
properties from this ontology (obviously a new capability, not just
categoryBag as used today).  Making a query then to search based on a
particular property would, without a subsumption analysis, just do a string
based discovery - which as you point out is not an improvement.   If we had
the ability to analyze the given properties for relationships with others
based upon the imported ontology, the UDDI server could then augment the
query with other properties which also should drive a match (although this
is still string based).  I'm just thinking of hierarchical relationships in
this example, such as recognizing that a paperback_seller is also a
book_seller, etc.

Of course, relationships could be infinitely complex, which is certainly a
concern.   The sophistication of an inferencing engine can also be made
very complex as well - such as the ability to expand a search based on the
"strength" of the match, where a weaker relationship criteria might be
tolerable/desired.   It would seem to me that supporting that type of thing
would be much more complex, and could take many forms - something likely to
remain beyond the scope of standardization within UDDI at this point.

So back to the question, how valuable would it be to find some middle
ground as I've described above?  Or have I missed your points entirely?

Thanks,
Tom Bellwood       Phone:  (512) 838-9957 (external);   TL:  678/9957
(internal)
Co-Chair, OASIS UDDI Specification TC
STSM - Emerging Technologies
IBM Corporation

Katia Sycara <katia@cs.cmu.edu>@w3.org on 12/03/2003 03:28:30 PM

Sent by:    public-sws-ig-request@w3.org


To:    "'Ugo Corda'" <UCorda@SeeBeyond.com>, public-sws-ig@w3.org
cc:    katia@cs.cmu.edu, paolucci@cs.cmu.edu
Subject:    RE: UDDI and semantics: CMU OWL-S/UDDI Mapping





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

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?

Ugo



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

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

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 Thursday, 4 December 2003 15:30:18 UTC