(Feedback from Norway) 

  1. Administrative Details (AD) 
    1. The Valid Until attribute proposed in LIM is absent. Was this forgotten? Many information objects refer to a Valid To attribute as being inherited from AD, but that is not listed under AD. Note LIM proposed Valid Until, because that was less ambiguous than Valid To for non-English speakers. I recommend that Valid Until is included under AD, as it was in LIM, and that any occurrences of ValidTo are replaced by Valid Until.
    2. LIM had url as type URL. GSIM V1.5 has String. URL follows a specific syntax, and should be treated as a distinct type. (https://en.wikipedia.org/wiki/URL). We would recommend using type URL rather than String for this attribute.

  2. Identifiable Artefact (IA)
    1. IA has 7 attributes. The only mandatory one in GSIM v1.5 is Name. In LIM all attributes except LocalId were mandatory. I strongly recommend that the cardinalities in LIM are used in GSIM v1.5. An Identifiable Artefact should at least be identifiable, but currently only Name must be used. At the very least Id should be mandatory. Mistake? It is a great shame that we are not insisting on interoperability. LIM needed all attributes to be mandatory except LocalID. How will organisations collaborate on the use of CSPA services if everything except Name is optional?
    2. Given that all GSIM information objects are a subtype of IA why have so many information objects apparently only inherited Name and Description from IA i.e. they, almost without exception, only have Name and Description attributes listed with *Inherited from Identifiable Artefact? Why only these? Description is 0..1 as are the other 5 attributes. Why is Description favoured?  Mistake? It might be easier to say that they all inherit all 7 attributes somewhere rather than listing up the 7 every time, unless of course the lists are machine generated. The other distinguishing attributes might drown in the IA ones since they are all sorted alphabetically.
    3. Are all Base Group information objects subtypes of Identifiable Artefacts? If yes, why does Change Event have an attribute ‘Identifier’? It should have inherited Id from IA. If not, which are and which are not? This must then be clearly stated in the explanatory text for IA and for each Base Group information object.
    4. Agent In Role. Several information objects have attributes for Owner, Maintenance Unit, Contact Person. We recommend that these attributes are removed and that these could be mentioned as examples in explanatory text for Agent In Role. If they are as important and general as Information Provider and Information Consumer then they could be introduced as subtypes for Role.


(GSIM Information Object in Italic; Attribute in bold)

  • No labels

22 Comments

  1. InKyung Choi

    03 Oct, 2018

    (Feedback from Sweden)

    We support Jenny Linneruds input about Identifiable Artefact Identifiable Artefact (IA)

    IA has 7 attributes. The only mandatory one in GSIM v1.5 is Name. In LIM all attributes except LocalId were mandatory. I strongly recommend that the cardinalities in LIM are used in GSIM v1.5. An Identifiable Artefact should at least be identifiable, but currently only Name must be used. At the very least Id should be mandatory. Mistake? It is a great shame that we are not insisting on interoperability. LIM needed all attributes to be mandatory except LocalID. How will organisations collaborate on the use of CSPA services if everything except Name is optional?

  2. InKyung Choi

    20 Nov, 2018

    (GSIM Revision Meeting 24th October, 2018)

    1. Administrative Details

    a. To keep Valid To (was decided in previous round - Issue #96) 

    b. To keep "String" as Issue #2-1

    2. Identifiable Artefact

    a. To make ID mandatory (as GSIM is a conceptual model and LIM is a logical model, if LIM has more constraints than GSIM, it would not contradict, but the other way could be problematic. Adding more constraints except ID to GSIM does not seem necessary)

  3. InKyung Choi

    20 Nov, 2018

    (GSIM Revision Meeting 14th November, 2018)

    2. Identifiable Artefact

    b. To keep only mandatory attributes of IA in the table of GSIM objects that are sub-type of IA for consistency

    c. Change Event is not IA, at least during Ottawa Sprint, the object didn't have Name nor Description. Change Event is meant to be something that applies to IA for people to keep tract of changes. It is something that occurs to IA, not IA itself.

    => To make Change Event non-IA

    => To update definition and/or explanatory note to describe this (Francine Kalonji) 

    d. Agent In Role is also not IA itself. It is something that associates Agent and Role with Administrative Detail (AD), AD should not be linked to Agent In Role, it should be IA (which is administered by Agent In Role). 

    => To make Agent In Role non-IA

    => To update definition, explanatory note and/or attributes and check cardinality with Change Event and Administrative Details (e.g. there can be Agent In Role without having any Change Event?) (Francine Kalonji)

    c.f. LIM v0.91: 

    Change Event

    22.       The Change Event was introduced in order to have a general way to manage changes in the states of information objects.

    23a.     LIM Definition: A Change Event captures that a change has occurred. It identifies the objects that have been affected, and the new objects that have been created due to the change.

    23b.     An association to Agent In Role was introduced in order to identify all Agents, with a specific Role, involved in the Change Event.

    24a.     The Change Event has a changeDate attribute which is used to convey the event time and a changeType attribute that has a controlled vocabulary in order to accurately map to a recognized object lifecycle.

    24b.     The Change Event identifier attribute indicates which Identifiable Artefacts the change applies to.[LJ1] 

    [LJ1]

    Francine: Jenny, in this case, you do not need an Identifier attribute in ChangeEvent. The relationship already indicates that the ChangeEvent applies an IdentifiableArtificat. I thought that this Identifier was identifying the ChangeEvent instead.

    Jenny: Should we remove this text and the attribute in Figure 1?

    Agent In Role

    25.       Agent In Role was introduced in order to have a more flexible and extensible way of adding Roles to Agents without having to change existing information objects. The introduction of this object also provides a way to relate the Agent, Role and Administrative Details objects.

    26.       LIM Definition: An Agent acting in a specific Role.

    27.       An Agent In Role may apply to either type of Agent - an Organization or Individual. The object is intended to reflect a single Agent acting in a single Role and as such is a very unambiguous representation. A common example would be to identify which Individuals or departments within an Organization provide administrative data. An Agent In Role is not in itself an Identifiable Artefact.[LJ1] 

    [LJ1]

    Should we add to Figure 1 as a Note as was done in Figure 3?

  4. Alistair Hamilton

    20 Nov, 2018

    As a side note, after initially having an equivalent to Change Event in the ABS logical model (AIM) based on GSIM, we moved it a couple of years ago to be a "registry" artefact rather than a logical model artefact.

    Naturally there is still an association between a registered Change Event and the IA(s) it impacts (given a single Change Event may entail updating several artefacts).

    This also allows registration of proposed Change Events that end up not going ahead, including the reasons the proposed change was not adopted.

    Not treating Change Event as a GSIM IA therefore makes sense to me.

    We are still grappling to some degree in the space of Agent In Role. 

    Some aspects are addressed by our IAM entitlements model which draws on some aspects of AIM (eg associations between Data Sets and Statistical Programs) but does not rely on modelling in AIM every aspect of entitlements/roles.  (Organisational structures and individual employees are seen as somewhat fluid, where Statistical Programs are somewhat more stable sets of statistical production activity regardless of which part of the organisation and which specific individuals have responsibility for conducting them currently.)

    Some other aspects are addressed by our ISO 11179-6 based use of Submitters, Responsible Organisations and Registration Authorities.  This more or less covers cases where Agent In Role is more about stewardship responsibilities than access control.

    That leaves cases where identification of agents aren't about access control or stewardship, which we don't have a good way to handle. 

  5. Francine Kalonji

    04 Dec, 2018

    Based on the model, Change Event is not an Identifiable Artefact, that is why, to my opinion, this mention does not need to be there:  *Inherited from Identifiable Artefact.

    Also I am not sure why or when Name and Description attributes were added. To my knowledge, it was not discussed, but I might have missed something... Having a Type and a Date, along with an Identifier should be enough, unless one wants to describe what happened during the Change Event. But a Name? Not sure...

     

    My proposed definition for Change Event and an explanatory text:

    A Change Event captures that a change has occurred to an Identifiable Artefact. It relates to the information object(s) that has(have) been affected.

    Explanatory text: A Change Event can be applied to only one Identifiable Artefact and result in one or more Identifiable Artefact(s). On the other hand, a Change Event can be applied to more than one Identifiable Artefact and result in only one Identifiable Artefact. Change Event Tuple is used to list the Identifiable Artefacts that are the source of the change and the Identifiable Artefacts that result from that change.

  6. Francine Kalonji

    05 Dec, 2018

  7. Francine Kalonji

    05 Dec, 2018

    Based on the model, Agent In Role is not an Identifiable Artefact, and rightly so; that is why, to my opinion, this mention does not need to be there:  *Inherited from Identifiable Artefact. 

    The definition is fine to me.


  8. InKyung Choi

    03 Jan, 2019

    (GSIM Revision Meeting 5th December 2018)

    In summary

    • Change Event: not IA, attributes Name and Description, not needed
    • Agent In Role: not IA, can keep attributes Name and Description 


  9. InKyung Choi

    03 Jan, 2019

    Also see issue #81 which include discussions on identifiable/non-identifiable objects that happened after LIM sprints

  10. Jenny Linnerud

    22 Jan, 2019

    Given that we have decided to keep Valid To, could we add some text to the description of this attribute for example that "if Valid To is a day/date then the information Object is also valid on that day/date". Assuming I have interpreted Valid To correctly. 

  11. Francine Kalonji

    22 Jan, 2019

    Yes Jenny Linnerud , I think the descriptive text can be written as follows:

    Definition: The date up to which the information object is effective or valid.  It is no longer valid after that date.

  12. Jenny Linnerud

    22 Jan, 2019

    The challenge is that 'up to'.

    What about

    Definition: The date up to and including which the information object is effective or valid.  It is no longer valid after that date.

  13. Francine Kalonji

    22 Jan, 2019

    Yes, I can see the challenge... We will propose to the group tomorrow:

    The end date included in the period during which the information object is effective or valid. It is no longer effective or valid after that date.

  14. Jenny Linnerud

    22 Jan, 2019

    I agree with that proposal.

  15. InKyung Choi

    24 Jan, 2019

    Would Base Group look like this now? Francine Kalonji Jenny Linnerud

  16. InKyung Choi

    24 Jan, 2019

    GSIM Sprint (24 Jan.)

    • To remove relation "has input" between IA and Assessment
    • To add relation "associates" between Assessment and Process Step


  17. InKyung Choi

    19 Feb, 2019

    To be consistent, definition of attribute Valid From is also revised as below: 


    		BeforeProposed
    Valid FromThe date on which the information object is effective or valid.The start date included in the period during which the information object is effective or valid. It is effective or valid from that date.
    Valid ToThe date on which the information object is no longer effective or valid.The end date included in the period during which the information object is effective or valid. It is no longer effective or valid after that date.

  18. Francine Kalonji

    19 Feb, 2019

    Sure, sounds right to me!

  19. Jenny Linnerud

    20 Feb, 2019

    No, sorry! I almost agreed, but this is still not 100% clear. I suggest

    Valid to

    The last date on which the information object is effective or valid.

    The end date included in the period during which the information object is effective or valid. It is no longer effective or valid after that date.

    OK?

  20. InKyung Choi

    21 Feb, 2019

    For me, the first and third sentences are clear enough the second sentence sounds a bit confusing.. how about this?


    		BeforeProposed
    Valid FromThe date on which the information object is effective or valid.The first date on which the information object is effective or valid. It is effective or valid from that date.
    Valid ToThe date on which the information object is no longer effective or valid.The last date on which the information object is effective or valid. It is no longer effective or valid after that date.

  21. Jenny Linnerud

    21 Feb, 2019

    Sorry, Inkyung, I realise now that you & Francine are perfectly correct.

    I got confused yesterday!! Mea culpa!


  22. InKyung Choi

    28 Feb, 2019

    Related 2-b (why only Name and Descriptions are shown in the attribute table), would it make sense to 

    1. add Identifiable Artefect to diagram of all (immediate) sub-types (but NOT in the giant Group diagrams as it will be too messy)
    2. remove attributes inherited from Identifiable Artefect from attribute table

    So there won't be "Name" nor "Id" anymore. How do you think Jenny Linnerud Francine Kalonji Eva Holm

    In this way, I think we could

    1. avoid (or at least lessen) inconsistency of including attributes inherited from IA only, even when there might be other attributes from other super-types (e.g. Code Item is sub-type of Node but we don't include attributes of Node in Code Item attribute table)
    2. hopefully make it easier to associate other Base Group objects via link to IA, e.g. for time attributes removed because they are covered by Administrative Details



    		CurrentProposed
    Diagram


    Attribute table