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

 


Help: OASIS Mailing Lists Help | MarkMail Help

regrep-query message

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


Subject: Discussion of getPath() method



Registry Query team,

During last Friday's teleconference we discussed the getPath() method 
defined for the ClassificationNode class in ebRIM (cf Section 10.2.4 page 38).

At present this method is only superficially specified in ebRIM. I think 
the confusion we're all having in trying to understand what one another is 
saying is a direct result of the lack of specification for the getPath() 
method. Can we have a discussion in the Query team as to what we think 
should get returned by getPath()?

Consider a few examples:

1) ClassificationScheme
      id="urn:org:un:spsc:cs2001"
      name="UNSPSC"

    ClassificationNode
      id="UUID1"
      name="Electronic Components and Supplies"
      code="32"
      parent=???

    ClassificationNode
      id=UUID2"
      name="Diodes and transistors and semiconductor devices"
      code="11"
      parent="UUID1"

    ClassificationNode
      id=UUID3
      name="Integrated circuit components"
      code="18"
      parent="UUID2"

  What string value should getPath() applied to node UUID3 return?

   a) "urn:org:un:spsc:cs2001/321118"

   b) "urn:org:un:spsc:cs2001/32/11/18"

   c) "UNSPSC/32/11/18"

   d) "UNSPSC/321118"

   e) "321118"

   f) "32/11/18"

   g) "UNSPSC/Electronic Components and Supplies/Diodes and transistors
               and semiconductor devices/Integrated circuit components"

I don't think there's any value in trying to carry along the names for the 
classification scheme or the names of the various nodes in its hierarchy. 
There's just too much chance for error. So I think we should concentrate on 
id's and/or codes.  That would eliminate choices c), d) and g). Next, I 
think we should make a clear distinction between the classification scheme 
itself and the nodes in its hierarchy. I see no value in a) or b) since we 
can use separate methods to get at that scheme information. That leaves e) 
or f).  My vote goes for e), because f) would require people to remember 
how many digits are in each level of the path and sometimes (e.g. NAICS) 
that varies.

CONCLUSION: For multi-level coded classification schemes, i.e. 
classifications schemes for which each node's "code" is an embedded 
representation of the path leading to that node, getPath() should return 
just the "code" for that node.


2) ClassificationScheme
      id="urn:ebxml:trees:v1"
      name="Modern Day Tree Types"
      description="This scheme defines the Genus and Species of modern day 
trees"

    ClassificationNode
      id="UUID4"
      name="Acer"
      code="Acer"
      parent=???
      description="<enUS> Genus name for any maple tree"

    ClassificationNode
      id=UUID5"
      name="barbatum"
      code="barbatum"
      parent="UUID4"
      description="<enUS> Species name for Southern Sugar Maple"

  What string value should getPath() applied to node UUID5 return?

   a) "Modern Day Tree Types/Acer/barbatum"

   b) "urn:ebxml:trees:v1/Acer/barbatum"

   c) "Acer/barbatum"

   d) "Genus:Acer/Species:barbatum"

For the same reasons as above, I think we should rule out a) and b).  I 
don't like d) so much because I don't think we should mix level names with 
the path leading to a node. Instead, if level names are important, we 
should extend our model to allow the user to define level names, with a new 
method on ClassificationScheme to getClassificationLevels() and a new 
method on ClassificationNode to getLevelName(). I think c) is the proper 
result for getPath().

CONCLUSION: For a general purpose multi-level classification scheme, where 
it is not known whether or not the code attribute for ClassificationNode 
carries an embedded path representation, getPath() should return a sequence 
of codes from the first to last levels of the classification scheme. Each 
code should be separated from the others by a "/".


c) Any 1-level Enumeration Classification Scheme

CONCLUSION: For any node N in a 1-level classification scheme, e.g. all 
enumeration domains, the getPath() method should return a value equal to 
the "code" attribute for that node.

d) Consider the Library Classification Scheme discussed in a previous email 
message.

    http://lists.oasis-open.org/archives/regrep-ex-scheme/200109/msg00004.html

This example defines a multi-level external classification scheme.

CONCLUSION: For external classifications, the submitter of the 
classification should be allowed to provide as much information as possible 
to help the Registry determine what is the intended "code" and "path" and 
"pathDepth" of each node referenced by the Classification instance. For 
example, the submitter should be allowed to say that the path for the 
classification of a book is "TA357.5", since that is the preferred 
embedding for the entire path of the node. But the submitter should also be 
allowed to submit a pathDepth value of 3, or a pathRepresentation like 
"TA/357/5", so that the Registry can support queries over the separate levels.

Any other opinions?

-- Len


**************************************************************
Len Gallagher                             LGallagher@nist.gov
NIST                                      Work: 301-975-3251
Bldg 820  Room 562                        Home: 301-424-1928
Gaithersburg, MD 20899-8970 USA           Fax: 301-948-6213
**************************************************************



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


Powered by eList eXpress LLC