Meeting notes Feb 1, 2023

[InKyungChoi]

Participants: Francine Kalonji, Flavio Rizzolo, Zoltan Vereczkei, Jenny Linnerud, Andrea Petres, Juan Munoz, Daan Swinkels, Florian Vucko, Daniel Gillman, Ayman Hathoot, Raul Mejia, Christopher Jones and InKyung Choi

• Team welcomes a new member Daan Swinkels (Statistics Netherlands)

• Finalisation of Base Group: explanatory texts are missing for three classes in Base Group (Contact, Individual and Organisation), volunteer needed for explanatory text.

• Issue list: issues to finalise for this version is tagged as “V2.0” and backlog as “R2.1”

• Latest models can be checked via google doc (for the latest definition and explanatory text) and diagrams (for the latest relationship and cardinality)

Issue #31 GSIM Exchange Group definition / explanatory text update: make sure to leave comment if you have any counter proposal, decision will be made through github issue

Issue #39 Consider removing/redefining Change Event Tuple (Base Group)

Change Event

• We don’t need Change Event Tuple. For physical models, we would need individual Tuple for provenance and change management. GSIM is a conceptual model, besides Change Event Tuple itself does not have any attributes (so there is no additional information attached to it), we can link Change Event directly to Identifiable Artefact.
• Action: to delete Change Event Tuple, move relationship “target” and “source” directly to Change Event, to change cardinality from 0,1 to 0..n (there can be multiple Change Events for an Agent In Role)
• Also Change Event is disconnected from other parts in the model, what “activity” represents in the proposal can be done through Process Step
• Action: to link Change Event to Process Step

Software Agent

• PROV ontology has “Software Agent” and DDI has “Machine” as a sub-type of Agent
• “Software” (removing “Agent”) is not enough as it is beyond a piece of codes
• Software Agent make decision and carry out tasks based on business logic or control flow.
• Action: to add “Software Agent”, check PROV for definition

Relationship and Responsibility

• We can use association between classes to indicate what relationship two classes have, introducing a separate abstract class for relationship does not seem needed. Also, addition of Relationship has impact on all classes that have relationship with another (e.g., Node-Node Set).
• In PROV, a property “influence” is used to represent the generalisation of the relationship (it has subtypes such as association, attribution), do we go that far with the abstraction that PROV gives?
• Decision: not to add Relationship
• Responsibility seems belong to Role itself rather than Agent In Role
• Action: to add an attribute “Type of Role” to Role with controlled vocabulary (RASCI as an example).

Role

• Current definition of Role says it is “responsibility”, this is confusing with RASCI “responsibility”.
• Action: to change “responsibility” in definition of Role back to “function”
• Action: to link Role to Business Process (Role applies to Business Process)

Issue #36 GSIM Concept Group definition / explanatory text update #1

• The idea of Category Item is that it is an element / node in Node Set when Node Set is a Category Set (so an element in Category Set is a Category Item). Category is conceptually what Category Set contains.
• Category – Category Set – Category Item servers as a machinery of building containers that are linked and put together for mapping/hierarchy.
• There is a mismatch between what is being modelled and what the model says. To work on definition – it does not say what we need.