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

["Rogers, Tony" <Tony.Rogers@ca.com>]

Regarding the last question, I see this as the same as "how does the
client know that the value set has changed" - the answer we have for
that is that the publisher republishes the tModel, which tips off the
client (who, we assume, has subscribed to that tModel - right?)

Can the client just get the changes or must they get the whole thing
again? Neither answer is really attractive - the changes could get quite
ugly to describe, but receiving an entire taxonomy (potentially hundreds
of megabytes) for a one item change is not nice, either.

The APIs that have been suggested so far are:

 - fetch entire taxonomy
 - fetch root/s of taxonomy (could be treated as degenerate case: "get
children of null")
 - fetch the successors to "this" node ( = get children if hierarchical)
 - fetch the predecessors to "this node ( = get parent if hierarchical)

These are all aimed at browsing ("get" pattern). There was no previous
suggestion of "find" behaviour.

-----Original Message-----
From: John Colgrave [mailto:colgrave@hursley.ibm.com] 
Sent: Tuesday, 4 May 2004 22:06
To: uddi-spec@lists.oasis-open.org
Subject: [uddi-spec] Taxonomy Browsing/Navigation Requirements


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




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_wor
kgroup.php.