Action Item on External Coding Scheme

[Nikola Stojanovic <nhomest1@twcny.rr.com>]

Here is the summary of what Lisa and Nikola have done so far.

Objective of this exercise is to provide functionality whereby Submitting Organizations (SOs) can provide registry users with coding (classification) information related to a repository item where two conditions may exist:

(1) the coding scheme values are not native to the registry or

(2) the SO does not wish to contribute the classification value to the ClassificationNode tree.

It is assumed that repository items could be classified by providing just 2 pieces of information: "Classification Scheme Name" and "Classification Code". This name/value pair might be something like: "NAICS/521112" or "Geography/Japan". It is also assumed that the SO does the validation of the name and the value of the "Classification" and that this validation is not a responsibility of the ebXML Registry itself.

 

Current RIM does provide very generic and powerful classification mechanism where classification is done by associating any RegistryEntry with any node(s) in a ClassificationNode tree(s). Precondition is the existence of both objects in this association. Also, ClassificationNode is itself a RegistryEntry (by inheritance). Notion of "Scheme Name" is implied by the notion of the root node, which means that the root node's getName method would return a "Scheme Name" for the whole scheme. In the above examples root nodes of the ClassificationNode tree shall be submitted with "name" attribute of "NAICS" and "Geography" respectively. One would then imagine that it would be possible for ebXML Registry to build one additional layer under the root nodes where nodes at that level are "521112", "91", ... and "Japan", "Asia"... Very important characteristic of the ClassificationNode tree is that the tree itself reflects the isKindOf relationship between children and parent nodes. Premise that External Coding Schemes are not native to the ebXML registry (structure of the levels inside the scheme tree is not known) forces flattening of the tree and disabling of this powerful concept. There is another aspect of the current RIM that might need attention. Currently full path of the node is built by appending name attributes separated by ".". It seems that it would be justifiable to add a new method(s)/attribute to a ClassificationNode interface that would distinguish between the "fullPath (absolutePath)" and the "code" at the particular node. If we look at two examples above we can see the distinction between the two "codes". In "NAICS" scheme, code "521112" embeds/carries all the parents and in "Geography" scheme, code "Japan" doesn't. BTW, there was already discussion during the Vancouver meeting about formatting "absolutePath" as XPath expression instead of "." separated string.

 

Going back to Objectives and Requirements for External Coding Scheme, we might think of a classification approach that is somewhat "lighter" then the current approach. In that regard, we suggest that we introduce the concept of "Classification Slots" (or just Slots). Relationship between a RegistryEntry and a Slot would be by composition (by value => slot instance wouldn't exist on its own). RegistryEntry would have 0..n (zero or more) Slots. Slots would have a "name" and a collection of "values". Name of a Slot would be locally unique to a RegistryEntry. Similarly, a Value of a Slot would be locally unique to a Slot. It would be possible to add/remove/get Slots to/from a RegistryEntry. It would also be possible to add/remove/get Values to/from a Slot. "Slots approach" would introduce some changes to the specs, but we hope not too drastic that we shouldn't consider it at this point.

 

 

Nikola Stojanovic

Lead Technologist, Research and Development
Encoda Systems, Inc.
101 Pineview Terrace
Ithaca, NY 14850 USA
nikola.stojanovic@encodasystems.com
Tel: 607-273-2224