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

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

Title: [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.

 

John Colgrave

IBM

 

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

 

Tony Rogers

tony.rogers@ca.com

 

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