I think I get the hint :-)
Attached please find the early draft of Requirement 028, relating to
taxonomy managment. I claim complete responsibility for any and all errors,
omissions, misconceptions, and mistakes in this document because my co-authors
have had no chance to contribute any corrections.
I would like to point out that the idea of using an existing taxonomy
language was discussed at the face-to-face, albeit not in the way that John is
suggesting. The idea of concocting a simple language to allow the uploading of
basic taxonomies was suggested as a way of putting a stake in the ground (it was
even suggested that this might prompt action from other groups, so that they
might make themselves known and push the adoption of their standard in place of
our own - not that we'd ever plan such a diabolical scheme, of course...).
Please feel free to suggest anything up to a complete rewrite of this
document - it is a very early draft.
Tony Rogers
-----Original Message----- From: John Colgrave
[mailto:colgrave@hursley.ibm.com] Sent: Thu 04-Mar-04 1:32
To: uddi-spec@lists.oasis-open.org Cc: 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_workgroup.php.
|