Taxonomy Browsing/Navigation Requirements

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

I have been giving some thought to the possible requirements for the
browsing/navigation of taxonomies and I think this could be the trickiest
part to specify and implement.  I think we need to consider whether we are
trying to do much here.  Hopefully we can discuss this on the call next
week.

My concerns are in three areas:
1) The representation of taxonomies to clients.
2) The style of queries to support.
3) Tracking changes.

I will expand a little on each of these below.

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.

We could choose a format similar to a database result set, which would be
the best fit with at least some of the proposed OWL/RDF query languages (see
next section).

2) Style of queries

The adoption of OWL would present the opportunity of supporting one of the
proposed RDF/OWL query languages, but it is not clear to me that this would
be a good fit for the types of query that a client may want to do to build
up a complete taxonomy.

The alternative would be to define a new API similar to the existing inquiry
API in that it may have find operations and get operations, depending on the
details of exactly what calls we want to support.  I think we should support
at least the following:
a) retrieve the root classes of the taxonomy
b) retrieve the tree rooted in a particular class

I am assuming that if a client wanted the entire taxonomy they would load
that from a file, assuming there was a single file with the correct version
of the taxonomy in it.  If not, they we should probably provide an API to
retrieve the entire taxonomy.

3) Tracking changes

If we set the expectation that a client obtains a taxonomy from a UDDI
registry, then we have to allow the client to at least discover that a
taxonomy has changed, and probably to retrieve just the changes.

Suppose, for example, that a new class is added to the taxonomy: how does
the client discover this and can they download just the new value or do they
have to download the entire taxonomy again.  Another example is the moving
of a value from one position in the hierarchy to another.

John Colgrave
IBM