-----Original Message-----
From: Rogers, Tony
[mailto:Tony.Rogers@ca.com]
Sent: 08 March 2004 06:55
To: John Colgrave;
uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments
on UDDI Taxonomy Representation Requirements
Sorry, John, but I don't necessarily agree with everything you've said,
so I thought I'd shoot around the document in its unvarnished form :-)
My big reservation against choosing OWL right away is that I do not
know enough about alternatives. If we choose OWL we may never hear about the
alternatives, because their champions may well be put off. If, on the other
hand, we were to invent our own primitive system, there's a greater chance of
someone advocating something else. Well, that was my theory, anyway. <JC>This makes no sense to me.
If there is something better than OWL then I see no reason why someone would
choose to keep quiet about it if we chose OWL but would speak up if we chose to
spend time inventing something “proprietary”. If there is
nothing better than OWL then we made the right decision. J</JC>I do like the idea
of having a really basic system that doesn't drag along legacy from another
world, too.<JC>You see legacy,
I see reuse, tool support etc.</JC>
Relating to your new comments:
1. absolutely. Let's have a basic level that lets us enter a simple
value set with as little fuss as possible. If I have a value set of five
values, let me save it very simply in the UDDI server. Ideally, I'd like to be
able to save it without having to support another server (like a validation
server, for example).
2. selectability relates to a hierarchical taxonomy, and makes it
possible to have nodes in the hierarchy which exist purely for structural
reasons. Consider the taxonomy uddi-org:types (our old friend from 11.1.1 in
the V3 spec). In this taxonomy there are two values (tModel and
bindingTemplate) which are explicitly listed as not allowed - they would not be
selectable. I do agree that in some cases the selection of non-leaf nodes is
desirable - it can perform the function of range selection - however, not
all hierarchies work like that, hence the idea of allowing the publisher to
specify if a particular non-leaf node is selectable.<JC>I do not know why those two values are not allowed
but I am loathe to impose a general requirement because of two specific values
from one of the built-in taxonomies. I guess as long as the indication of
whether or not a node/value can be used is optional and defaults to allowing
its use then it will not have an impact in the vase majority of cases.</JC>
3. I was not considering equivalence when I wrote about aliases (I was
deliberately avoiding any semantic concepts). I thought of it as a way of
providing synonyms for human consumption, and a way of supporting multiple
languages - synonyms were, I thought, the reason we removed the restriction of
one name per language in Version 3. <JC>I
am not sure it was intended to be as general as this but I don’t think it
will be a big deal to specify how multiple names interacts with equivalence, if
at all.</JC>I was intending that the names and descriptions
used for a node be the same as names and descriptions used for businesses, etc.
The value of a node, on the other hand, would be what was used in any keyed
reference - much as the key is the unique identifier of a business.
4. The keyValue in a keyed reference would be the value of the node,
not one of the names (for the same reason that we use the key of a business
rather than one of its names). I suppose you could use the name in the keyName
field, but I think that would be a bad idea, because it would allow the
production of keyed references that were different, even though they referred
to the same node. I guess you could leave the keyName empty, or have some other
convention.<JC>We will have to
establish some convention here, as people like to see keyName used. The
V3 spec. says that the first name should act as a default so I guess that would
be the one to choose.</JC>
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>
2. the document is a zeroth draft, and one that was not
intended to be circulated - we can change the language easily, and this is
a good indication of an area we should change.
3. if a publisher is supposed to be uploading a taxonomy into a
registry (internal taxonomy), then there's a need for more than a tModel - the
values are required, at least. <JC>For
an internal taxonomy that is true, and I guess I was taking that as read.
What I was thinking of here was whether we need to use (something like) RDF or
invent a schema just for the metadata about the taxonomy. I just wanted
to push back a little on the requirement to have multiple names for the
taxonomy itself as that would preclude using the regular tModel structure as
the UDDI metadata about the taxonomy.</JC>
4. That sentence was part of an idea that we may provide a means for a
client program to obtain only a small part of the taxonomy at a time - there
has been talk of a navigation API, after all. A navigation API could be as
simple as a "give me the children of this node" call. We will
probably want the "give me the entire taxonomy" call, as well.<JC>Right but I am trying to tease
out what the requirements are, and whether “get me all the names of this
particular node” is a specific API that should be supported.</JC>
5. I would have thought that the details of API calls to save / change
/ delete a taxonomy were part of a proposal rather than part of the
requirements - that's why I was deliberately sparing in describing them.<JC>I think we need to be more
precise about the requirements for these APIs before we can come up with a
proposal.</JC>
6. The requirement to save a taxonomy at a single node came out of
discussion at the face-to-face meeting, and I don't really understand it myself
- it seemed a bit odd, at least in my imagining of the save API being presented
with the entire taxonomy at once. Perhaps if the taxonomy were being saved in
pieces, there would be a need to be concerned about the idea of pieces being
saved on multiple nodes simultaneously (that's a horrible idea!). As for
replication, I had imagined the entire taxonomy being replicated as a unit - I
was thinking mostly of small taxonomies, not huge ones.<JC>This is one area where the internal/external
aspect is relevant, and also whether we split the taxonomy from the metadata, I
think. I think that requiring the taxonomies themselves to be replicated
will add significantly to the cost and complexity. I am afraid we will
have to deal with huge taxonomies as well as small ones!</JC>
-----Original
Message-----
From: John Colgrave
[mailto:colgrave@hursley.ibm.com]
Sent: Fri 05-Mar-04 21:55
To: Rogers, Tony;
uddi-spec@lists.oasis-open.org
Cc:
Subject: RE: [uddi-spec] Comments
on UDDI Taxonomy Representation Requirements
Actually, I had hoped that you would
rewrite the document to incorporate my comments, but never mind J
As I said in my earlier note, I think we
should separate out the requirements for the taxonomy/ontology language from
the requirements for the UDDI-specific metadata about the taxonomy/ontology and
the management of the taxonomy/ontology. Given this, I think that we should
have either three documents or one.
I think all of my comments below still
apply so I will restrict myself here to new comments, largely prompted by the
document.
I think it would be useful to have a
statement of the scope of each of the sets of requirements, before getting into
the details of the individual requirements.
With regard to the taxonomy/ontology
language:
1) I think we should consider different
levels of functionality, with the minimum level being equivalent to what we
have today, as I described it below. Other capabilities that we may want
to consider are: equivalence, support for instances as well as classes; support
for “multiple inheritance”. Some of these are driven by other
of our requirements; some of them may be driven by the adoption of a standard
language that goes beyond what we need. For example, OWL offers all of
these features so it may be part of the price of supporting a standard
language, and standard ontologies written in that language, that we have to say
something about how UDDI will handle things like multiple inheritance, if at
all.
2) The value of specifying whether a
particular node can be “selected” is not clear to me. It has
occurred to me that if we are talking about an enhanced query capability that
it may well be the case that even non-selectable non-leaf nodes may need to be
used in a query, and may even be the most useful types of node to include in
the query.
3) Is the requirement for multiple names
of a particular node intended to be use instead of equivalence or in addition
to it? I imagine that combining this simple alias facility with the
requirement for names in multiple languages could get a bit confusing.
4) The paragraph beginning on line 134
says that the alternative names would not be used in keyedReferences, which I
assume means the keyValue part of a keyedReference. Does this, and the
following paragraph, mean that the keyName attribute will not be used?
With regard to the management:
1) I think we need to be clear whether we
are going to support both internal and external taxonomies/ontologies as I
imagine the requirements will be different in these two cases.
2) The Scenario Details should not talk
about proposals (second paragraph). If it is a requirement to continue to
have a tModel to represent the taxonomy then that should be stated as a
requirement, and it should be clear whether this is only for backwards
compatibility or whether it is a requirement that new uses of the taxonomy also
use the existing tModel/keyedReference approach.
3) It is not clear to me that a publisher
needs to provide more than a tModel to a UDDI registry, as I said below, I
think this comes down to whether it is a requirement to have multiple names for
the taxonomy.
4) The sentence beginning on line 136
suggests that a client program can query the UDDI registry to get the various
names for a particular node but I am not convinced of the need for this and
would like to see more details such as whether a capability to query the full
information about a particular node is required, or simply downloading the
entire taxonomy to a client, or something else.
5) I would like to see more details of the
requirements for standard APIs to save/change/delete a taxonomy.
6) I would like to see more details of the
replication requirement, and the related requirement for a taxonomy to be
published only at a single node. If we split the taxonomy from the
metadata about the taxonomy then do these requirements only relate to the
metadata? If they are talking about the actual taxonomy data itself then
I don’t understand how this relates to a standard management API, and I
think it would be a non-trivial change to replication to replicate an entire
taxonomy.
-----Original Message-----
From: Rogers, Tony
[mailto:Tony.Rogers@ca.com]
Sent: 04 March 2004 05:45
To: John Colgrave;
uddi-spec@lists.oasis-open.org
Subject: RE: [uddi-spec] Comments
on UDDI Taxonomy Representation Requirements
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.
-----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.