Login required to access the wiki. Please register to create your login credentials We apologize for any inconvenience this may cause, but please note that this step is necessary to protect your privacy and ensure a safer browsing experience. Thank you for your cooperation. Documents available for download: GAMSO , GSBPM , GSIM |
(Feedback from Canada)
Why is there a Code attribute and a contains association (inherited from Node) to Designation, which has a Code class as a subtype? It’s not only redundant, but it can create inconsistencies if some people choose to associate a Classification Item to a Code class and others choose to use the Code attribute instead. Besides, Code Item doesn’t have a Code attribute, and if it works for Code Item why not for Classification Item? We should try to be consistent: we could either leave only the inherited Code association (via Designation) from Node and remove the Code attribute from Classification Item, or we could remove that association and add a Code attribute to Code Item as well.
On that note, we shouldn’t have a parent-child association inherited from Node together with Parent Item and Sub-items attributes. Same argument here: we are providing two different mechanisms to do the same, i.e. represent parent-child relationships between Classification Items. Code Items have only one way to do that. We should probably leave one mechanism in place: either the attributes or the association.
It seems we originally developed the Node/Node Set pattern to represent commonalities between the ways Category Sets, Code Lists and Statistical Classifications structure and organize their members, i.e. Category Items, Code Items and Classification Items, respectively, with common associations and attributes. Adding all those redundant attributes defeats the purpose of having the pattern in the first place.
I understand that some implementations are going to favor the attributes and others the associations. That’s totally fine. However, those implementation details shouldn’t be part of the GSIM model. We should pick one approach and leave the other as an implementation alternative, as opposed to having both in the model.
2 Comments
Jenny Linnerud
22 Jan, 2019I agree that the Code attribute in Classification Item is redundant.
I plead the 5th amendment on Node and Designation - they were both too abstract to use or communicate inside our organisation!
Flavio Rizzolo
24 Jan, 2019We should remove the redundant attributes, i.e. Code, Parent Item and Sub Items, and use the inherit relationships from Node.
As side note, we might need to add more examples/guidelines on how the Node/Node Set pattern works and how to use it, given that some people might find it difficult to find the content they need.