|
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.
|