(Feedback from Norway)


  1. There is a constraint on the Node Set that appears to exclude the use of one level of a Statistical Classification as a Code List. Does it? Some Statistical Classifications only have one level i.e. they are non-hierarchical. Can they not be used as Code Lists?
  2. We have a lot of trouble with Node and Node Set compared to Statistical Classification, Level and Classification Item so these comments might not be correct, but please double check the following observations from GSIM v1.5 and LIM v1.0:
    • GSIM v1.5 has 1 and only one Statistical Classification is a variant of 0 or more Statistical Classifications. LIM had 0 or more Statistical Classification is based on 0 or 1 Statistical Classifications.
    • GSIM v1.5 has 0 or 1 Classification Items are part-whole with 0 or more Classification Items, via Node if I have understood Node correctly. LIM had 1 or more Classification Items are part-whole with 0 or more Classification Items
    • GSIM v1.5 has 1 and only one Level groups 1 or more Classification Items, via Node if I have understood Node correctly. LIM had 1 or more Levels groups 1 or more Classification Items.
    • GSIM v1.5 has 0 or more Statistical Classification has 0 or more Level, via Node Set if I have understood Node Set correctly. LIM had one or more Statistical Classifications has 1 or more Levels.
  3. GSIM v1.5 has Enumerated Value Domain takes values from Statistical Classification. Shouldn’t the arrow on the relationship be the opposite way round i.e. Statistical Classification takes values from Enumerated Value Domain?
  4. Code List : Shouldn't this example be based on the same example as Code and Code Item? The definition refers to Categories. It would be an advantage if there were examples for Category, Category Item and Category Set that were also based on the same example.
  5. Described Value Domain has an attribute Data Type which is a String. There is no explanatory text. Isn’t this attribute totally superfluous? What added value does it give and what would I fill the attribute out with? Isn’t the Description attribute sufficient?
  6. Level
    • The Definition refers to Statistical Classification, but the explanatory text opens up for Code Lists and Category Sets. Is this a good enough Definition? Do we really want to reuse Level for these? Are Node and Node Set inadequate? What does Level give us that these do not?  All attributes for Level are optional except Name and Items.
    • Attribute Items: The Description refers to Categories (Classification Items), but there is a constraint that Statistical Classifications can only contain Classification Items. Is this imprecise? Should it refer to Category Items or Classification Items if we are using Levels also for Category Sets? The explanatory text also opens up for Code items. Shouldn't this be handled by the relationship to Node? Do we really expect a list of 'Items' in this attribute?
  7. Statistical Classification has a relationship 1..1 is variant of 0..*. Isn't the text/arrow the wrong way round? Are variants of or reverse the arrow? I believe a variant is based on one and only one Statistical Classification and a Statistical Classification can have zero or many variants? Or am I wrong and a variant can be based on one or many Statistical Classifications? Anyway, something is wrong here.


Resolved issues (UNECE)

  1. Is it possible to make the loops big enough to contain the start and end cardinalities? This would be on Population, Universe, Node and Node Set. At the moment it is very difficult to read these. Even when you click on the information object itself these are difficult to read.

    At least provide more space for all cardinalities near all information objects.

    An alternative would be to do as was suggested in GSIM V1.1 Specification Annex D_  Extending the model

    Relationships (repeat as needed) 
    ____________________________________________________________________________ 
    Name: 
    Target Object: 
    Relationship Type: 
    Description: 
    Source Role: 
    Source cardinality: 
    Target Role: 
    Target Cardinality: 
    Constraints: |

    These could be included under every Information Object. We realise that is a lot of additional manual work. This really should be generated from Sparx EA and not manually entered.

  2. The relationships between Dimensional Data Point and Unit Data Point to Data Point are included. Shouldn’t they be hidden? If you start including nearest neighbours to nearest neighbours of Concept information objects then you won’t know where to stop.
  3. The cardinality on the Concepts side of the relationship with Node Set has overlapped the white diamond on the relationship with Category. More space please.
  4. Statistical Classification has an attribute Name Types: “A list of the defined types of alternative item names available for the Statistical Classification. Each name type refers to a list of alternative item names.” For anyone unfamiliar with the original Neuchâtel terminology it might be useful to give some examples. “Ex.: Short titles; Medium titles.”




  • No labels

2 Comments

  1. Eva Holm

    1. Proposal: Remove the constraint on Node Set 
  2. Mikko Saloila

    2. a) Variant in GSIM is correct

        b) part-whole relationship in GSIm is right

        c) GSIM is right on the levels

        d) Proposal to change cardinality between Node set and Level to 1..*