[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [uddi-spec] Comments on UDDI Taxonomy Representation Requirements
I am fairly sure that John was talking about taxonomies stored in the UDDI registry vs those stored outside. Nonetheless, your points are interesting. The idea of marking keyedReferences as invalid is discussed in the proposal relating to data revalidation (what do you do after it fails validation?) - I'd appreciate your feedback on that proposal - it is http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/5963 /uddi-spec-tc-prop018-revalidation-20040309.doc Tony Rogers Computer Associates Senior Architect tel +61 3 9727 8916 fax +61 3 9727 3491 tony.rogers@ca.com -----Original Message----- From: Paul Denning [mailto:pauld@mitre.org] Sent: Friday, 26 March 2004 9:18 To: uddi-spec@lists.oasis-open.org Subject: RE: [uddi-spec] Comments on UDDI Taxonomy Representation Requirements At 08:08 AM 2004-03-08, John Colgrave wrote: >1. I wasn't sure if we wanted to rule out external taxonomies completely, >but I definitely wanted to include internal taxonomies.<JC>I agree. Most >of the support to date has been for internal taxonomies.</JC> I'm not clear what you mean by internal and external taxonomies. I think you may be referring to checked taxonomies where they are checked within the registry (internal) versus checked by an external validation service (external). I think unchecked taxonomies would also benefit from a standard taxonomy representation. 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. If people actually start using the unchecked taxonomies, the registry operator could approach the owner of the taxonomy tModel to see if they want to make it checked. (Just had a thought, if a bunch of published keyedReferences us an unchecked taxonomy, but have invalid keyValues, what happens to those entities if we then make the taxonomy "checked"? How do we flag an keyedReference as being invalid?) Learning a taxonomy, for publishing or for searching, is a significant barrier to UDDI adoption. A standard taxonomy xsd might then result in tools that break down this barrier. Whatever the format, it should support a description to elaborate on the semantics of the keyValue. 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_wor kgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]