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

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

From: Jack Berkowitz <jack.berkowitz@networkinference.com>
Date: Thu, 4 Dec 2003 09:51:39 +0000
Message-Id: <74CFC4CC-263F-11D8-8B03-000393DBBFD8@networkinference.com>
To: public-sws-ig@w3.org, uddi-spec@lists.oasis-open.org

The subsumption tests are going to be needed in order to deal with the 
complexities of the relationships expressed.  Perhaps the biggest issue 
that will be faced will be multiple-inheritance or multiple-role 
situations, so these inference processes will have a bit of complexity 
to them.  I am not sure that the short-cut you seem to describe 
(additions of properties to augment query processing) will work in the 
general case.  The complexity of deciding what to append to the query 
may actually be more than the complexity involved in using a logic 
inference engine that performs full subsumption tests.   In other 
words, regardless of the method of attack, one is probably going to 
converge on inferencing patterns that involve relatively complex logic.

However, the use and availability for logic processing in an efficient 
manner is within technology today (we are shipping one now that is 
based in description logics and OWL-DL ).  Including such an inference 
capability into the UDDI extensions would make a ton of sense as 
dynamic compositions begin to emerge.

The second point you make on complexity with a "strength" of a match is 
problematic given inferencing technology.    Either the match is 
decideable (and thus trustworthy for automatic use within an enterprise 
system) or its not (and thus would best still have a 
person-in-the-loop).   The attachment problem of "close" is something 
that would probably require a sequence of analyses to work (thesaurus + 
inference) and I would agree is probably beyond the standardization 

Best regards,


Jack Berkowitz
Vice President, Engineering
Network Inference (Holdings) Ltd
+44 (0)20 7616 0700

On 3 Dec 2003, at 23:13, Tom Bellwood wrote:

> 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 
> 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. 
> 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 04:56:17 UTC

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