RE: [uddi-spec] Taxonomy Browsing/Navigation Requirements

["John Colgrave" <colgrave@hursley.ibm.com>]

Paul,

The main purpose of this piece of work is to standardize on OWL/RDF/XML as a
serialization format for taxonomies so there is no need to support multiple
formats.  A UDDI registry is expected to build any other internal
representations, such as a list of valid values, from the OWL representation
of the taxonomy/ontology.

The main purpose of this browse/navigation API is to allow clients/tools to
incrementally obtain a representation of the taxonomy from the UDDI
registry.

It may be the case that there is no single OWL file that represents the
ontology, or it may not be known to the UDDI registry.  Some other
requirements that were discussed at the FTF included the ability to add,
remove or update the taxonomy without having to upload a completely new
version.  With this kind of capability, any external file that the tModel
points to may not represent the current state of the taxonomy within the
UDDI registry itself and the only way that a client can be sure of having
exactly the same taxonomy that the UDDI registry has it to get it from the
registry.

John Colgrave
IBM


> -----Original Message-----
> From: Paul Denning [mailto:pauld@mitre.org]
> Sent: 05 May 2004 18:38
> To: uddi-spec@lists.oasis-open.org
> Subject: Re: [uddi-spec] Taxonomy Browsing/Navigation Requirements
> 
> At 08:06 AM 2004-05-04, John Colgrave wrote:
> >1) Representation of taxonomies
> >
> >How should taxonomies be presented to clients when returned from the new
> >browse/query API?
> >
> >I would imagine that client/tool vendors would want to be able to load
> the
> >same taxonomy file that a registry loads (that is the approach that the
> IBM
> >tooling adopts) so I imagine that clients/tools will be written to
> support
> >OWL in RDF/XML, which means that returning RDF/XML from the UDDI API
> would
> >be a good thing as a client would only have to support one format.  The
> >RDF/XML would probably have to be generated from the current state of the
> >taxonomy in the UDDI registry, so this is effectively the export function
> >that I mentioned in the FTF.
> >
> >Alternatively, we could define a schema very like Tony's proposal and use
> >that as the UDDI-specific exchange syntax between a UDDI registry and a
> UDDI
> >client.
> 
> As I said before [1],
> 
> 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.
> 
> As an example, see tModel [2].  Follow its overviewURL in a browser (works
> in IE, but Firefox renders per MIME text/plain).  View source to see
> rddl:nature and rddl:purpose.  Links to taxonomy files that can be
> uploaded
> to MS and Systinet UDDI servers.
> 
> [1] http://lists.oasis-open.org/archives/uddi-spec/200403/msg00088.html
> [2]
> http://uddi.ibm.com/ubr/uddiget?tModelKey=UUID%3A49BE0F40-E9F9-11D7-B602-
> 000629DC0A53
> 
> Paul
> 
> 
> 
> To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/uddi-
> spec/members/leave_workgroup.php.