Potential refactoring of the participant pattern for association and activity

[jamrce]

Problem

The participant_in_activity_or_association SELECT is a key pattern in the model, however the use of a SELECT can cause issues with implementations of it when trying to participate in either an activity or an association.
Problem statement: Is there a different way of creating this pattern in the model to negate the need for a SELECT?

Context

HQDM is quite keen to have two separate entities for handling participation and chiefly as stated on page 135 they have some key differences.
This pattern (association) is very similar to the pattern for activity; states of individuals play roles in the association, just as they do with the activity. There are two important differences:

1. An activity causes one or more events; an association does not (not actively at least).
2. The roles in an association are necessarily parts of the same period of time; whereas for an activity, the roles may be parts of different periods of time.

With final definitions being provided as:
Association - An individual that consists_of the participants that are associated, and where the participants are part_of the same period_of_time.
Activity - An individual that consists of its participants and causes some event.

Suggestion 1

Relax the identity of "association" to not enforce all participates are there for the full duration of the period of time to enable "activity" now be a SUBTYPE of "association". Associations that expect that full duration could be handled through a class / kind of association.

Key points:

• activity inherits from association, indicating that every activity is a specialized form of association.
• The participant entity can now participate in any association, including those that are activity.
• activity still has the additional attributes (references, determines, causes) that are specific to it and not present in association.

The EXPRESS would then become the following:

ENTITY participant
  SUBTYPE OF(state_of_physical_object);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF association;
END_ENTITY;

ENTITY association
  SUBTYPE OF(individual, state_of_association);
    SELF\individual.member_of      : OPTIONAL SET [1:?] OF class_of_association;
    SELF\individual.member_of_kind : SET [1:?] OF kind_of_association;
INVERSE
    consists_of_participant        : SET [1:?] OF participant FOR participant_in;
END_ENTITY;

ENTITY activity
  SUBTYPE OF (association, state_of_activity);
    references                     : OPTIONAL SET [1:?] OF thing;
    determines                     : OPTIONAL SET [1:?] OF thing;
    causes                         : SET [1:?] OF event;
    SELF\association.member_of      : OPTIONAL SET [1:?] OF class_of_activity;
    part_of                        : OPTIONAL SET [1:?] OF activity;
    SELF\association.member_of_kind : SET [1:?] OF kind_of_activity;
  INVERSE
    consists_of                    : SET OF activity FOR part_of;
END_ENTITY;

Suggestion 2

Introduce a new entity as an "abstract" super-type for the participation for either extension named "engagement" for the sake of an initial idea.

Key points:

• The engagement entity is abstract and serves as a common parent for activity and association.
• Both activity and association inherit from engagement, thus sharing the consists_of_participant inverse relationship.
• The participant entity now refers to engagement, which covers both activity and association.

The EXPRESS would then become:

ENTITY participant
  SUBTYPE OF(state_of_physical_object);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF engagement;
END_ENTITY;

ENTITY engagement
  ABSTRACT
  SUBTYPE OF(individual, state_of_engagement);
    SELF\individual.member_of      : OPTIONAL SET [1:?] OF class_of_engagement;
    SELF\individual.member_of_kind : SET [1:?] OF kind_of_engagement;
INVERSE
    consists_of_participant        : SET [1:?] OF participant FOR participant_in;
END_ENTITY;

ENTITY association
  SUBTYPE OF(engagement, state_of_association);
    SELF\engagement.member_of      : OPTIONAL SET [1:?] OF class_of_association;
    SELF\engagement.member_of_kind : SET [1:?] OF kind_of_association;
END_ENTITY;

ENTITY activity
  SUBTYPE OF (engagement, state_of_activity);
    references                     : OPTIONAL SET [1:?] OF thing;
    determines                     : OPTIONAL SET [1:?] OF thing;
    causes                         : SET [1:?] OF event;
    SELF\engagement.member_of      : OPTIONAL SET [1:?] OF class_of_activity;
    part_of                        : OPTIONAL SET [1:?] OF activity;
    SELF\engagement.member_of_kind : SET [1:?] OF kind_of_activity;
  INVERSE
    consists_of                    : SET OF activity FOR part_of;
END_ENTITY;

Final thoughts

Both of these approaches should ease software implementations and provide a useful mechanism to better articulate the pattern that was originally being described. Whilst submitted by myself, this was the output of an internal discussion. Happy to provide further discussion or block diagrams to aid understanding of what the implications would be.

[ClimbingAl]

This is worth addressing. I think there is at least one other aspect worth considering. Firstly, it might be worth looking at why Matthew West (author of HQDM) made use of it. As @jamrce alluded already, the EXPRESS keyword SELECT is to allow an instance of participant, including any of its subtypes, to be selected as participant in either an instance of activity OR an instance of association. It is performing an OR-like purpose (this is also implied by the name participant in_activity_or_association). Conceptually this is not too problematic. However, practically it adds a complication to an otherwise well-structured type hierarchy. I have found it to cause confusion too, as it can be interpreted that any instance of participant, including any of its subtypes, could be *participant_in* either and instance of activity OR an instance of association. However, this is not what is logically intended. It may be helpful to explain the intended interpretation in SET-like language. The SET of all participants can be divided into two disjoint subsets; the SET of all participants that are participant in associations and the other SET of all participants that are participant in activities.

This description of the issue points at an additional consideration to resolve the problem

Suggestion 3

Introduce two subtypes of participant that are activity_participant and association_participant. Each can then be *participant_in* their respective activity and association entity types.

Impacts to Magma Core

1. All affected Magma Core Java classes in the hqdm and hqdm-canonical packages need to be modified and, where needed, added.
2. An interesting side-effect of the participant_in_activity_or_association definition in EXPRESS is that it only features in one predicate direction (from participant to activity or association). It isn't present in the reverse predicate *consists_of_participant* path from each of the activity and association entity types, as they are directly to the entity type participant. However, I think this is another ragged edge in HQDM. If we want to steer towards more formal treatment of the model as a TLO I think new predicate types (or new specialisations / sub-types of them) should only be introduced to one ENTITY TYPE and ben inherited from that in its sub-types. HQDM as documented as consists_of_participant introduced to two separate ENTITY TYPEs (activity and association) that are disjoint and share the same supertype (individual). Suggestion 2 seems to me to be the best way to address this.

Suggestion 4

Implement both Suggestions 2 & 3 (with harmonised naming).

The EXPRESS would then become the following:

ENTITY participant
  ABSTRACT
  SUBTYPE OF(state_of_physical_object);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF engagement;
END_ENTITY;

ENTITY activity_participant
  SUBTYPE OF(participant);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_activity_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF activity;
END_ENTITY;

ENTITY association_participant
  SUBTYPE OF(participant);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_association_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF association;
END_ENTITY;

Impacts to Magma Core

Roughly a combination to suggestions 2 & 3.
Note that a lot of HQDM classes and kinds would need to be modified too - this is true for each of the suggestions apart from Suggestion 5.
Backwards compatibility is logically retained but previous implementations of participant would be matched to the now abstract participant entity type. A mapping to its new subtypes would be straightforward.

Suggestion 5

There is a quick way to side-step the introduction of new intermediate types and still get rid of the SELECT type. Allow the *participant_in* predicate to be linked to activity or association by committing it twice to the participant entity type.

The EXPRESS would then become the following:

ENTITY participant
  SUBTYPE OF(state_of_physical_object);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF activity;
    participant_in                          : OPTIONAL SET [1:?] OF association;
END_ENTITY;

This may not be legit EXPRESS but I don't think we are trying to formally adhere to the standard. It's a quick fix but may be unsatisfactory in the long-term.

Impacts to Magma Core

Minimal. Backwards compatibility would be retained as-is.

My preference is to combine Suggestions 2 & 3 (i.e. Suggestion 4). If not that, then Suggestion 5. Suggestion 1 is a structural change to what these entity types in HQDM are. association and activity are disjoint.

Footnote

Finally, I think we should also propose that hqdmTop's wiki, as the master data for HQDM online, should be modified with any changes agreed to address this too.

[jamrce]

Considering your suggestions I believe 4 may be the best resolution so far, albeit introducing 3 new entities whilst removing the select. That being said, there are advantages of having the ABSTRACT SUPERTYPE of engagement for querying as well as being explicit around the participation restriction being only for one or the other would aid clarity on what is being described.

One minor refinement I would make is to enhance your constraint on suggestion 4 participant to include the ONEOF in EXPRESS as this is what you and HQDM have described. In full this would be the following noting line 3. The same should be made and mirrored onto suggestion 2's engagement.

ENTITY participant
  ABSTRACT
  SUPERTYPE OF (ONEOF(activity_participant, association_participant));
  SUBTYPE OF(state_of_physical_object);
    SELF\state_of_physical_object.member_of : OPTIONAL SET [1:?] OF class_of_participant;
    member_of_kind                          : SET [1:?] OF role;
    participant_in                          : OPTIONAL SET [1:?] OF engagement;
END_ENTITY;

[twalmsley]

Something to consider is that the SELECT represents a 'sum' type, and there are programming languages that support such types, for example: TypeScript, Haskell, and Rust, and probably others (including EXPRESS of course), but unfortunately Java doesn't support sum types yet and may never support them. Since it's a Java problem I'd suggest that changing the EXPRESS is not necessary, but the Java implementation would need superclass/subclasses along the lines of suggestion 2, and languages that support sum types properly can have an implementation that match the SELECT more closely, e.g. in TypeScript:

interface Activity {}
interface Association {}

interface Participant {
    participant_in? : Activity | Association;
}

[jamrce]

Agreed with your point here, but building on this and just to be make sure I'm being clear with my meaning. It is not that all SELECT's must be removed, I'm sure there may be cases where they are useful when it gets to implementations. This suggestion came from a point of view that from the concepts Matthew described in the book as the conceptual model and the distinction between an association and activity could be better articulated than how it currently uses the SELECT feature of EXPRESS.