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

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

From: Max Voskob <max.voskob@paradise.net.nz>
Date: Fri, 05 Dec 2003 00:07:36 +1300
To: public-sws-ig@w3.org
Message-id: <002b01c3ba56$d34341e0$0200a8c0@johnson69biiow>
I think that if UDDI entities had some metadata as RDF/OWL/DAML/XTM/... that describes the entities than it would be already a step forward. 
Assume the following example:

A service is described using RDF/OWL vocabulary as an online book selling service with books from almost every publisher . An external inference engine receives a request for a paper-back published by Prentice-Hall. Given the distance of the most remote match it figures out 25 possible options how this thing can be classified, including a book selling service. It submits this broad query to UDDI and gets a list of services that match, including our service in question. Then it retrieves the detailed information about the found services and rates them or picks the best match.

Is it a valid scenario?
Does this scenario provide an improvement to warrant the inclusion of semantic metadata and new search capabilities?

This is a rather simplistic solution and can be fit into the existing UDDI structures with only minor or no modifications. All we need is a flat list of RDF triples to say that thing A is B, sells C and conforms to D. An external ontology would have all relationships and class hierarchies to say that P, Q and R are also relevant classifiers for thing A because of their relationships with B, C and D. This conclusion would be done outside of UDDI.

A more complex issue here are one-to-many and many-to-many relationships.
Lets say that a service has relationships of some sort with other services or other UDDI objects of a different type or even external to UDDI objects whatever they could be. It is not practical to describe such relationships outside of UDDI as it involves a particular instance of a UDDI registry - it is not practical to point from ontologies to UDDI objects (in my opinion).
Another example is when a group of businesses have a relationship to another group of businesses (many-to-many). It can be handled by RDF, XTM, OWL, but those structures cannot be easily fitted into the existing UDDI structures at this stage.

A possible solution here is to include RDF/OWL/XTM/...with UDDI entities again, but in a separate bag where they can form more complex structures than just a flat list of triples, e.g. a hierarchy of RDF/OWL/XTM elements.

Does it all make sense? (feel free to say it doesn't)
Would it be practical for external reasoning engines to work with UDDI this way?

Cheers,
Max Voskob


  ----- Original Message ----- 
  From: Jack Berkowitz 
  To: public-sws-ig@w3.org ; uddi-spec@lists.oasis-open.org 
  Sent: Thursday, 4 December 2003 22:51
  Subject: Re: UDDI and semantics: CMU OWL-S/UDDI Mapping


  Tom,

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

  Best regards,

  Jack

  Jack Berkowitz
  Vice President, Engineering
  Network Inference (Holdings) Ltd
  +44 (0)20 7616 0700
  jack.berkowitz@networkinference.com


  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 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 06:07:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 16 March 2008 00:10:53 GMT