[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]