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

[Paul Denning <pauld@mitre.org>]

Thanks for the insight.

But it will be at least a year, probably more, before the v4 specs are 
nailed down and this API is implemented in products.

The reality now, with UDDI v2 implementations, is that there are multiple 
formats being used to import taxonomies.

The RDDL approach I suggest can be used now.

Presumably the owner of the tModel also owns the taxonomy, or at least 
makes a commitment to maintaining it.
I don't want to get into versioning issues here.

If the tModel is "checked", then the registry can check it internally or by 
using an external validation service.
If it is checked externally, then we can assume that the validation service 
stays in sync with the taxonomy files referenced from the tModel.

Perhaps they even subscribe to the tModel, and if it gets re-published they 
can be notified and trigger a download of the revised taxonomy.

Internally checked taxonomies could do something similar.

I understand the concern that the files pointed to by RDDL (in my approach) 
could change without updating the tModel, and the taxonomy version checked 
internally by the UDDI registry may be different than the latest files 
pointed to by RDDL.

The built-in taxonomies (NAICS, ISO-3166, UN/SPSC) could point to a RDDL 
file maintained by the registry, so they stay in sync.

If a new representation of the taxonomy (e.g., in OWL, XTM, etc) becomes 
available, it can be added to the RDDL with an appropriate rddl:nature and 
rddl:purpose.

Perhaps a rddl:purpose could be defined to indicate the file used by a 
particular registry for internal checking/validation.

E.g., rddl:purpose="http://uddi.ibm.com/taxonomy-validation"; would be 
associated with a file that IBM uses to define the taxonomy it checks.

rddl:purpose="http://uddi.sap.com/taxonomy-validation"; could be associated 
with a file that SAP uses.

rddl:nature allows the two formats to differ, but presumably they are 
semantically equivalent.

In UDDI-ng, e.g., 
rddl:purpose="http://taxonomy.uddi.org/v4/taxonomy-validation";  and 
rddl:nature=<URI-for-OWL-format-defined-by-TC>

This seems orthogonal to defining an API to retrieve or add subsets or 
diffs of a taxonomy.

Paul

At 04:36 AM 2004-05-06, John Colgrave wrote:
>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.
>
>
>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.