[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