[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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-valuesetoverviewdocument-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-valueset-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-B602-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_workgro >up.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]