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. I do like
the idea of having a really basic system that doesn't drag along legacy from
another world, too.
Relating to your new comments:
First Block
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.
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. 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.
Second Block
1. I wasn't sure if we wanted to rule out external taxonomies completely,
but I definitely wanted to include internal taxonomies.
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.
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.
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.
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.
Tony Rogers
-----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.
|