Issue #22: Missing Composite Aggregation for Code Item, Code List, Classification Item, Statistical Classification

Meeting 10/1:

There is a relationship between Node and Nodeset. Category Items etc are subtypes of Node and inherit the relationship. 

Having the relationship at this level means that nodesets can be composed of nodes of different types.

Need to discuss whether this is a closed or open diamond. We need to check the UML documentation on what restrictions the black diamond will impose. 

ACTION:

Add/check relationship from classification item to statistical classification.

Add/check relationship from code item to code list. 

We need to check the UML documentation on what restrictions the black diamond will impose. Francine Kalonji

Following discussions: 

Composition requires the whole to have exclusive ownership of the part. That precludes reusability of the part. But what does reusability mean exactly in the UML context? That the part cannot have an association to more than one whole. However, the part can still be "linked" to more than one whole, or anything really, via some other means, e.g. a dependency. A UML dependency is a very weak king of "link" between elements. Since it's not an association, composition shouldn't affect dependencies, in which case you could have multiple dependencies to a Classification Item even though it is part of a composition.

Classification Item was not a Category, it was a composite of Category + Code, i.e. there was an association between Classification Item and Category called "takes meaning from" to allow for reusability of Categories across multiple Classification Items.

There are reuse implications here. It comes back to the definition of Classification Item and what we are trying to reuse. In Australia,  they are reusing the Category/Concept rather than the Code/Classification Item. In Canada, their model supports reusability of both Categories and Classification Items, and in France, they reuse the Classification Item per se.

Conclusion? The black diamond works, as long as the UML will allow us to create a classification item before the statistical classification exists. We still need to keep the individual relationships, rather than elevating it to go from node to node net, because in the latter case there is no guarantee each kind of node set contains only that kind of Item.

ACTION: 

Add/check composite aggregation (black/closed diamond) relationship from classification item to statistical classification.

Add/check composite aggregation (black/closed diamond) relationship from code item to code list. 

OPEN QUESTION: There is an association in the model already from Node to Category. As subtypes of Node, Classification Item, Category Item and Code Item will inherit this association. Do we need to add the association to Classification Item, Category Item and Code Item explicitly? Dan Gillman Guillaume Duffes Flavio Rizzolo Alistair Hamilton Francine Kalonji

Are we talking about the relations from Classification Item, Category Item and Code Item to Category rather than from Classification Item, Category Item and Code Item to Node?

If so, in my view, the answer is "no". Classification Item, Category Item and Code Item are subclasses of Node. In UML (as well as every programming language that implements inheritance),  Classification Item, Category Item and Code Item will have all the features of Node, that includes the association to Category. Then, I don't think it is necessary to add those relations explicitly.

Yes that is what I meant. I edited the language to be more clear 

Technically, I agree with Guillaume. 

On the other hand, some less technical readers have problems automatically understanding that this means the relationship exists for each subclass of Node. 

For business areas in the ABS we tend to document the "concrete" (sub)classes with a full set of attributes and relationships (whether inherited or specific to the subclass) but this is not reflected in our UML for AIM.  Our UML looks as Guillaume suggests.

ABS achieves some of this by automated transforms on XMI exports of our UML model (eg to generate Java Object Libraries).  In the GSIM context at most this might come down to "Can we make the Clickable View friendlier for less technical readers without "dumbing down" the underlying UML definition?"        

Technically, I also agree with Guillaume & Alistair.

This issue was only a plea for consistency in documentation of the model. Inconsistenccy only creates unecessary questions in the minds of less experienced reasders.

Can we remove the explicit composite aggregation from the Category Item in the documentation since it is not consistent with the documentation for the other subclasses of Node?.

Makes sense to me to make the documentation (eg GSIM Specification Appendix C) consistent.  To be totally consistent, the diagrams in the doco are currently "vertical" for Code Item and Classification Item ("Node at the top") but "horizontal" for Category Item ("Node at the right").  

I agree that consistency is very important!

I think the team discussed that it was necessary to add the explicit relationships rather than rely on having them at the Node/Nodeset level (as it currently is). 

"We still need to keep the individual relationships, rather than elevating it to go from node to node net, because in the latter case there is no guarantee each kind of node set contains only that kind of Item."

I am not clear (or even know if it makes sense) if the suggestion was to add the explicit relationships at the sub class level and remove the relationship between Node/Nodeset. 

Actually, I think it's relevant to have the contains between the different subtypes of NodeSet and Node explicitly in the model. If we rely only on the inherited association from NodeSet, then any combination of subtypes would be possible, i.e. Statistical Classification could contain also Code Item and Category Item in addition to Classification Item because they are all Nodes. Having the association on the subtypes, although not strictly correct UML, could be understood as a restriction on the types of classes at both ends of the association. One way or the other, i.e. in the diagrams, in a constraint language or in the documentation, we need to explicitly represent those restrictions so that it's clear what combinations of subtypes are allowed.

Regarding consistency, another thing we may want to fix is the fact that there is an association between Node and Designation (and hence Code) and yet a Classification Item, a type of Node, has a Code attribute in addition to the inherited association.

Hi Flavio. I think we may be speaking at cross purposes. The title of the issue might lead to your comment, but I was responding to the open question

OPEN QUESTION: There is an association in the model already from Node to Category. As subtypes of Node, Classification Item, Category Item and Code Item will inherit this association. Do we need to add the association to Classification Item, Category Item and Code Item explicitly

In terms of your comment, in the 1.1 UML I see three separate Contains relationships each of the three sets of Node Set / Node subclasses.  Jenny noted that in the Word doco (specification), however, Contains was only shown for Category Item / Category Set.  Apart from fixing the doco, the UML might be OK here already?

Another plea from me related to this theme. Most people in statistical organisations think they know what a Code List is.

In the model you can easily og from Code List to Code Item, but then you drop off the edge of the GSIM planet trying to get to Code and Code Value via Node Set, Node, Designation and Sign.

Reading the definitions and examples for Code, Code Value and Code Item does not make it easier to know whether the Code is a short version of the Code Value or the opposite ie Is Code Item <Code, Code Value> or is it <Code Value, Code>. For example Code List: Gender. Code Item: <1, male>, but is the Code Value 1 or is it male? 

Code is subtype of Designation, Code Value is subtype of Sign and Sign encodes Designation so I suspect Code Value is 1 and Code is male, but that was a lot of work to get there. Not many people working in statistical organisations would claim that they know what a Sign and a Designation are, but they do think they know what a Code List is.

An easy solution would be to make this explicit in the Explanatory text for Code Item. A more radical solution woulld be to dispense with Sign & Designation....

Hi Jenny, we were discussing this exact issue related to Issue #50: Statistical Classifications and Code Lists. Can I copy your comment to that thread as well?

Hi Thérèse, Of course! Apologies for hopping into the middle of discussions without being formally part of the revision work. We are so busy implementing the GSIM

Not at all - we are so happy to have your comments when you have a chance to contribute!

Thanks for the correction Al. Actually, I was trying to answer Guillaume and clicked in the wrong place.

Yes, I like the UML with the separate contains for the subtypes. However, if we leave the contains also between Node and NodeSet, then we should clarify somewhere that the other three contains are restrictions of that one, otherwise we'll end up with two contains association for each subtype of Node: the inherited one and the specific one.

Inheritance or in UML terms generalisation is a binary taxonomic directed relationship between a more general classifier (superclass) and a more specific classifier (subclass). Each instance of the specific classifier is also an indirect instance of the general classifier, so that we can say "Astronaut is a Person", in our example, "Code Item is a Node", or "Classification Item is a Node".

In the case of multiple inheritance, a generalisable element (specific classifier) has more than one parent (general classifier), then its full descriptor contains the union of the features from its own segment descriptor and the segment descriptors of all of its ancestors.

Here, NodeSet does not inherit from multiple general classifiers. Even though there is a "Contains" composition between Node and NodeSet, in my understanding, that does not imply that any combination of instances of subclasses would be possible in NodeSet. It just implies the three subclasses will have all the features of Node including the composition to NodeSet. Therefore a NodeSet can only contain either CodeItems or CategoryItems or ClassificationItems in a mutually exclusive manner.

Then from a pure technical point of view, neither the restrictions are needed, nor the three explicit separate "Contains" relationships with each of the three Node subclasses.

From a practical viewpoint, as Alistair explained, it could be tempting to add them to enhance the readibility for people less familiar with UML. But then ,this comes down to both hurdles described by Alistair and Flavio, when a UML serialisation (XMI or other) is used an automated way (e.g generate Java classes or OWL classes just like DDI4 is doing currently):

• "Can we make the Clickable View friendlier for less technical readers without "dumbing down" the underlying UML definition?" from Alistair
• "[...] otherwise we'll end up with two contains association for each subtype of Node: the inherited one and the specific one" from Flavio

I am much more inclined to strictly complying with the UML rules and leaving the model without the three explicit "contains" associations. We might add a literal note in the documentation for users reminding that the three subclasses inherit the "contains" association from the Node class.

I don't know enough about UML to argue about mutually exclusiveness between subclasses. However, even if the subclasses are mutually exclusive, without the contains defined also in the subclasses there is no way of knowing which subclass of Node is allowed to be contained in which subclass of NodeSet. That is, even assuming mutually exclusiveness, if we had only the contains between NodeSet and Node there would be nothing in the model specifying that a CodeList contains only CodeItems as opposed to, say, ClassificationItems or CategoryItems.

Having said that, we don't need to have the additional contains associations, but we do need at least to make it clear in the documentation of clickable GSIM. Right now, although it seems obvious, nowhere in clickable says that a CodeSet contains only CodeItems and Statistical Classification contains only Classification Items, for instance.

ACTION:

Explicit relationships (e.g. code list/code item, classification/classification item) should be removed.

Relationship should be at Node Set/Node level.

Add note in GSIM Click and specification to be clear that Code Lists are only composed of Code Items etc.