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

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

Must we have two tModels?

There seems to be some obsession with shoving the URLs of data files
into the overviewURL as thought that's the only possible place they can
go. 

Why can't we have an entry in the categoryBag (or perhaps better - in
the identifierBag) that has a key value of the URL of the data file? Is
there some reason we can't have a URL as a keyValue? Sure, the keyValue
is limited to 255 characters, but we can fit quite a decent URL into
that space (or we can even loosen the spec for keyValue a bit). If we
did this, then we could use the tModelKey of the keyed reference to
indicate clearly that this was the URL of the data file in RDDL (or
whatever) format. We could even, conceivably, have another keyed
reference for the data in another format, should that be desirable. 

There's probably a good reason we don't do this, but I haven't heard it,
so please feel free to enlighten me :-)

Tony Rogers
Senior Architect - eTrust
Computer Associates
tony.rogers@ca.com

-----Original Message-----
From: Paul Denning [mailto:pauld@mitre.org] 
Sent: Thursday, 6 May 2004 22:59
To: uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Taxonomy Browsing/Navigation Requirements


So, you have a taxonomy tModel [A] whose categoryBag says its the
taxonomy 
(keyValue="categorization").

Another tModel [B] has a categoryBag that says tModelKey=<rddl-nature> 
keyValue=<nature-URI> and tModelKey=<rddl-purpose>
keyValue=<purpose-URI> 
and the overviewURL points to a file that I can download (then upload to

WASP-UDDI for example).

If there was a single standard (e.g., OWL) taxonomy format, then perhaps

tModel [A] could also have the rddl stuff in its categoryBag.

Given multiple formats, I need to relate tmodel [B] to taxonomy tModel 
[A].  So I can add a third keyedRef to the categoryBag of [B] where 
tModelKey=<x> keyValue=<tModelKey-for-[A]>.

So, I still have the extra level of indirection.  I have to search for
and 
retrieve [A], then search for tModels whose categoryBag refers to [A].
If I already know [A]'s tModelKey, then I do not have to do that 1st
step.

We can do both.
categoryBag for [A] can have rddl-nature saying it (overviewURL) is
RDDL, 
and follow the RDDL links to get to the taxonomy files.
Also have [B] that is related to [A] by virtue of A's tModelKey in [B]'s

categoryBag.

Or, [A] 's rddl-nature and rddl-purpose suggest that the overviewURL
points 
to OWL for the taxonomy, and have [B] point to RDDL and be associated
with [A].

The RDDL taxonomy tModel I defined was intended to use
keyValue="rddlSpec" 
if the overviewURL points to RDDL.
That is basically the rddl:nature, but does not say anything about its
purpose.
See
http://uddi.ibm.com/ubr/uddiget?tModelKey=UUID%3A49BE0F40-E9F9-11D7-B602
-000629DC0A53

keyValue="wsdlSpec" is used in the WSDL BP, which effectively is used
like 
rddl:nature, but says nothing about the purpose of the WSDL.  Would its 
purpose be for doing wsdl2java or simply to get the soap:address?  There

could be many purposes, or generically its purpose is just to "describe
the 
service".  I think rddl:purpose is meant to be a little more specific so

that applications can grok it and act accordingly.

Then there is the TN that deals with value set overview documents
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-tn-va
luesetoverviewdocument-20040316.htm

presumably the overviewURL of a taxonomy tModel points to a documents
that 
contains the info described in the TN.
This info could be in the RDDL document (its just XHTML).

It would be nice to change the template
http://www.oasis-open.org/committees/uddi-spec/doc/tn/uddi-spec-tc-value
set-overviewdocument-template20040316.htm
so it includes rddl attributes (and is XHTML).  Section 2.7 of the TN 
(section 9 of the template) may be a place to add rddl:nature and 
rddl:purpose to the links.

Paul


At 08:09 AM 2004-05-06, Anne Thomas Manes wrote:
>Rather than requiring an extra level of indirection (pointing to an
RDDL
>which points to the taxonomy), I suggest that we define tModels for the
>rddl:nature and rddl:purpose information. The overviewURL could then
point
>to the downloadable representation, and the nature and purpose info
would be
>specified in the categoryBag (allowing users to query UDDI for a
compatible
>representation of the taxonomy/ontology).
>
>Anne
>
>-----Original Message-----
>From: Paul Denning [mailto:pauld@mitre.org]
>Sent: Wednesday, May 05, 2004 1:38 PM
>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-B60
2-000
>629DC0A53
>
>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_wo
rkgro
>up.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_wor
kgroup.php.