RE: [uddi-spec] Comments on UDDI Taxonomy Representation Requirements

["John Colgrave" <colgrave@hursley.ibm.com>]

JP,

You seem to be following along just fine, but your questions cover both
REQ-028, and one proposed solution for it, and REQ-029.  I was trying to
limit my comments to REQ-028.

Backwards compatibility is a requirement but there is a conflict with that
requirement and the requirement to be XML-based, as I think that any
XML-based solution will probably end up with an NCName [1] as an identifier
of a node in the taxonomy and, as has already been pointed out with respect
to UNSPSC, an NCName has to begin with a Letter or the underscore character,
which means that you cannot have "numeric" identifiers.

As part of the backwards compatibility requirement, I think it is assumed
that there will continue to be a tModel to represent the taxonomy.  As I
pointed out in [2], one option is to associate a UDDI entity with a class in
the taxonomy in just the way you describe, so if there is an ontology of
business types with a class "Wholesalers" then you could indeed construct a
keyedReference with the key of the tModel and the value "Wholesalers".

The possible enhancement to the query capabilities is where we stray into
the territory of REQ-029 and I have not given that much thought yet.  At the
moment, I think there are two options:

1) Query the taxonomy separately and then construct a standard UDDI query.

2) Enhance the standard UDDI query to embed in some way the taxonomy query.

To take your example of a "Retail Outlet" and a Wholesaler, then taking
option 1 you would query the taxonomy for all "children" of Wholesaler and
get back "Retail Outlet" so you could then issue a standard UDDI query for
"Retail Outlet"s.  If you took option 2 then you would issue an enhanced
UDDI query passing in Wholesaler and an indication that you would accept any
and all "children" of Wholesaler.

[1] http://www.w3.org/TR/REC-xml-names/#NT-NCName
[2] http://www.oasis-open.org/archives/uddi-spec/200402/msg00076.html

John Colgrave
IBM


> -----Original Message-----
> From: Morgenthal, JP [mailto:JP.Morgenthal@softwareagusa.com]
> Sent: 04 March 2004 16:08
> To: John Colgrave; uddi-spec@lists.oasis-open.org
> Subject: RE: [uddi-spec] Comments on UDDI Taxonomy Representation
> Requirements
> 
> John,
> 
> 	Following this stuff on email makes my head spin.
> 
> 	I'm curious, based on your assessment below, would there be any
> problems with supporting an Ontology definition, OWL for example, on a
> tModel and then referencing a particular class within that OWL definition
> as
> part of a keyedReference? For example, you could define that a
> businessEntity references the class of businesses known as Wholesalers,
> where Wholesalers is defined as a class in an OWL ontology.  To me, this
> just seems like an extension of the current environment that facilitates
> more informational querying rather than flat categories that are available
> today.  For example, Retail Outlet may be derived from Wholesaler and
> therefore, it would respond positively to a query for Wholesalers.
> 
> 	Let me know if I'm totally lost on this point.
> 
> JP
> 
> -----Original Message-----
> From: John Colgrave [mailto:colgrave@hursley.ibm.com]
> Sent: Wednesday, March 03, 2004 9:33 AM
> To: uddi-spec@lists.oasis-open.org
> Subject: [uddi-spec] Comments on UDDI Taxonomy Representation Requirements
> 
> I have not yet seen the REQ-028 document so these comments are based on
> the
> minutes from the FTF and subsequent discussions.
> 
> I think we should clearly separate the taxonomy from the UDDI metadata
> about
> the taxonomy.  This will aid in using a standard representation/language
> to
> express the taxonomy, and in using taxonomies that were created without
> UDDI
> in mind.
> 
> I think we should use a (subset of a) standard representation/language
> rather than inventing our own schema.  This will aid in using tools and
> other infrastructure that can be expected around a standard, and in using
> taxonomies that were created without UDDI in mind.
> 
> I think we should not impose the restriction of a single explicit root.  I
> see no reason for this restriction and I think it will require unnecessary
> work to use taxonomies with UDDI.  If someone produces an OWL version of
> UNSPSC for example then it will probably not have a single root, as UNSPSC
> does not, and so we would not be able to use that as the representation of
> UNSPSC that was used by/with UDDI.
> 
> Leaving aside the question of equivalence, and other requirements relating
> to REQ-029, I think the requirements for a representation/language for
> simple taxonomies within UDDI are the following:
> 
> 1) Each node is uniquely identified by a string that can be used as a
> keyValue in a keyedReference.
> 
> 2) Each node can have one or more descriptions associated with it.
> 
> 3) Each node may have a single parent node.  A node without a parent node
> is
> a root node.  Multiple root nodes are possible.
> 
> Note that only the first of these is necessary as far as the UDDI API is
> concerned.  The other requirements are to help a GUI to display the
> taxonomy
> as a tree, or set of trees, and to aid the user in choosing the
> appropriate
> value(s).
> 
> Do we need to be able to indicate whether a particular node identifier can
> be used as a valid keyValue?  I have not come across this idea of valid
> and
> invalid nodes in the general taxonomy literature so this may be a
> UDDI-specific thing.
> 
> Turning to the question of the UDDI metadata about a taxonomy, I don't see
> anything about that in the FTF minutes, but looking at Luc's example, and
> the various proprietary schemes that have been developed, the metadata
> about
> a taxonomy is the following:
> 
> 1) one or more names
> 
> 2) one or more descriptions
> 
> 3) information about the UDDI tModel that represents the taxonomy, either
> just the key or a full tModel.
> 
> Are the names really necessary?  Looking ahead to a proposal, an obvious
> one
> is to use the existing tModel element where the name is the URI of the
> taxonomy, and descriptions of the taxonomy are mapped to the descriptions
> of
> the tModel.  The tModelKey attribute obviously holds the key of the
> tModel.
> The overviewDoc of the tModel points to the location of the taxonomy.  As
> much or as little of the other content of a tModel element can be used as
> required.
> 
> John Colgrave
> IBM
> 
> 
> 
> 
> 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.
> 
> 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.