RE: [uddi-spec] Comments on UDDI Taxonomy Representation Requirements

[Paul Denning <pauld@mitre.org>]

At 08:08 AM 2004-03-08, John Colgrave wrote:
>1. I wasn't sure if we wanted to rule out external taxonomies completely, 
>but I definitely wanted to include internal taxonomies.<JC>I agree.  Most 
>of the support to date has been for internal taxonomies.</JC>

I'm not clear what you mean by internal and external taxonomies.  I think 
you may be referring to checked taxonomies where they are checked within 
the registry (internal) versus checked by an external validation service 
(external).

I think unchecked taxonomies would also benefit from a standard taxonomy 
representation.

I think the overviewURL of a taxonomy tModel should point to a RDDL 
document, which then points to downloadable representations of the taxonomy.

The rddl:nature would tell you whether its OWL, XTM, or some other form.

The rddl:purpose would tell you the primary usage for that representation 
(e.g., client side GUI, simple keyValue validation, etc.)

A client-side tool can search UDDI for taxonomy tModels, follow the 
overviewURL to the RDDL,  look for rddl:nature attributes that they can 
grok, and download the XML file pointed to by the RDDL.  The tool can then 
render the taxonomy in the tool GUI and provide better response time to the 
user than drilling down with a browser through the limited set of checked 
(internal or external) taxonomies supported by a UDDI registry and its web GUI.

If people actually start using the unchecked taxonomies, the registry 
operator could approach the owner of the taxonomy tModel to see if they 
want to make it checked.

(Just had a thought, if a bunch of published keyedReferences us an 
unchecked taxonomy, but have invalid keyValues, what happens to those 
entities if we then make the taxonomy "checked"?  How do we flag an 
keyedReference as being invalid?)

Learning a taxonomy, for publishing or for searching, is a significant 
barrier to UDDI adoption.  A standard taxonomy xsd might then result in 
tools that break down this barrier.

Whatever the format, it should support a description to elaborate on the 
semantics of the keyValue.

Paul