OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

uddi-spec message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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

Tony,

 

Comments inline below, <JC>like this</JC>.

 

John Colgrave

IBM

 

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

 

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

 

Second Block

 

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>

 

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.

 

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

 

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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]