(Feedback from Norway)

  1. Do Assessment and Change Definition need to be shown specifically here
    1. Isn’t Assessment a type of Transformable Input /Transformed Output. It could be input from the previous production cycle and added to under the entire new production process. It could be input from the previous subprocess and updated in the current subprocess.
    2. Change Definition is the output of a process in which Statistical Need is the input. Thereafter it could be a Process Support Input or it could be updated (transformed) underway as a need for greater precision is required and acquired. 
    We cannot see that Assessment and Change Definition are special information objects that need to be shown explicitly. Moved to Issue #2-29
  2. We are puzzled by the three new ‘refers to’ associations. Maybe the descriptive text for Transformed Output, Transformable Input and Process Support Input need to be updated to explain these associations to Identifiable Artefact. I assume that these three information objects are all Identifiable Artefacts. If that is the case then what Identifiable Artefacts are they referring to? Does the Transformed Output refer to the Transformable Input and vice versa? What does the Process Support Input refer to – itself? The Process Step that it is supporting? (Note we have also copied this comment #2 under my comments to the Business Group)
  3. Is Datum actually an Identifiable Artefact or is it the exception to the rule? Datum is a value. It is only identifiable in its context of being in a Data Point. The Data Point is an Identifiable Artefact, but we do not think that Datum alone can be Identifiable Artefact
  4. Administrative Details - 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. Combined with Issue #2-1 


Resolved issues (UNECE)

  1. Under the Identifiable Artefact clickable diagram it says “Note: all GSIM objects are a subtype of Identifiable Artefact”. This is very important information and “all GSIM information objects are a subtype of Identifiable Artefact“ should be included in the explanatory text for Identifiable Artefact. The current explanatory text only says that ”An instance of any GSIM information object is an Identifiable Artefact.” I think it is easier for users to understand subtypes than to understand instances. I know I do 😊
    => The explanatory text "An instance of any GSIM information object is an Identifiable Artefact" is replaced by "all GSIM information objects are a subtype of Identifiable Artefact" in Enterprise Architect (not yet reflected on Clickable)
  • No labels

5 Comments

  1. InKyung Choi

    Regarding #2, LIM v1.0 (Figure 3) has

  2. Francine Kalonji

    The Pre Sprint model had a note indicating that ProcessInput is not an Identifiable Artefact, while the model itself was as follows. Changes were made consistently with the note. At the same time, we needed a way to show that to know more about those the Inputs and Outputs, one needed to look at IdentifiableArtefact. Concretely, for instance, object with id 254 is an Input to my process, but to know more about that object, look it up in IdentifiableArtefact.


  3. InKyung Choi

    (GSIM Revision Meeting 5th December 2018)

    2. Process Input in LIM was originally proposed to be non-identifiable. Process input itself is not versionable, but when there is an input it refers to something that is already an IA

    3. Data Point is an Identifiable Artefact, Datum alone is not Identifiable Artefact

    => To make Datum as non-identifiable


  4. InKyung Choi

    From ModernStats World Workshop 2018 discussion (see Issue #81

    "re identifiable artefacts - all objects are identifiable. Process input is an object that groups all the identifiable inputs into a process. It is not clear whether this object really needs to be identifiable"

  5. InKyung Choi

    GSIM Sprint (23 Jan)

    2. "refers to" association

    • Process Output is also not identifable
    • It was introduced because Process Input itself is not identifiable but we still want Transformable Input and Process Support Input to "refer to" something identifiable. The same for Transformed Output
    • How about others? Do we also want to make other sub-types identifiable, versionable?
      • Parameter Input - doesn't need to be identifiable
      • Process Execution Log - doesn't need to be identifiable
      • Process Metric - doesn't need to be identifiable