UDDI and Semantics: Checked Value Sets

I have only just subscribed to the SWS-IG mailing list so I am trying to
catch up with this discussion.

In a message in the thread with the subject "UDDI and semantics: CMU
OWL-S/UDDI Mapping" Katia Sycara said:

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

This description of the behavior of unchecked taxonomies is correct but if
you want UDDI to check the value used in a keyedReference then you should
use a checked taxonomy.

If there is a set of fixed values that can be used with a particular
taxonomy and the checking required is simply that one of those values is
used, then there are UDDI products that support this now with UDDI V2.

For more complex validation requirements, there is a concept in the UDDI
Specifications, both V2 and V3, of external checked value sets, although
this has not been widely implemented.  With this approach, the provider of a
taxonomy can register a web service with a UDDI registry and this web
service is invoked whenever a publish request is received by the UDDI
registry that includes a reference to the taxonomy.  This validation web
service has access to the entire UDDI entity and so can check not only each
individual keyedReference but can check the entire categoryBag and/or
identifierBag for inter-keyedReference consistency.

John Colgrave
IBM

Received on Friday, 5 December 2003 05:13:49 UTC