OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[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]