Working Group meeting 13/10/2020

Participants: Ana Aido, Paloma Arillo Aranda, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 6th and 8th October

  • To add examples for the redundant properties between the classes representing roles

  • To rephrase the WG also discussed the need for not to mix process and concept…

  • Add the diagrams of the discussions.

  • Add ContactPoint in the sentence agent7role behind the award decision…

Topic of discussion: Roles and Subroles

The WG continued discussing the new approach on how to model the roles and subroles. From the last WG meeting, the group proposed to everis to create a diagram that clearly shows the Involvements:

Award Reification

Also created a simplified version of the above diagram:

Award Decision Involvement Simplified

The WG making use of the diagrams created, continue the discussion on the usage of the reification class. The following decisions raised from the discussion were:

  • The definition of AwardDecision was not correct, since it applied to the whole process instead of to particular lot or lots. The origin of this previous (misleading) definition was that we tend to see the AwarDecision as a Document. We agreed that the class "epo:AwardDecision" is to be seen as a class (data), and this class will be linked to an AwardDecisionDocument (in the future - we will add this to the mid-long-term action point list). The WG proposes to create 'labels' to identify issues related to 'award decision' and to 'mid-term action point' and 'long-term action point', so we do not forget addressing them timely. The minutes, too, should refer to issues particularly connected to, for example, 'award decision'. This would also allow the link, more effectively, to the diagrams and examples that contribute to explain and illustrate the issue and the decisions.

  • The new definition of AwardDecision reads, thus, as follows: "Resolution of the buyer as to the result of a given Lot.". This decision has the following implications for the design and implementation of the ontology:

    • Recall that one procedure has always at least one Lot and may be divided into several Lots;

    • One object (individual) of the class AwardDecision will have to be instantiated per winning Organisation, its Role ("Winner"), the Lots awarded to this Organisation, possibly a contact point inside the winning Organisation, and the date of the awarding;

    • This AwardDecision class becomes, as a matter of fact, a 'reification' class that is based on the more generic pattern already proposed for the linking of different concepts participating in a procurement situation. The AwardDecision will be then designed as a subclass of that other generic reification class;

    • The generic reification class connects, by default, the following concepts:

      • One Agent (and only one)

      • One Role (and only one)

      • One Lot (and only one)

      • Contact Point (optional)

      • Period (optional)

      • Activity (codelist) (optional)

  • There is no need for involving the Procedure in the reification since this can be reached through the Lot.

  • OP explained that the role of Buyer is currently being approached inside the Commission (DG GROW + OP) as two different 'activities', thus the relevance of connecting the generic reification class to 'Activity', too. These two activities would be 'the buyer for this particular procedure' and the 'buyer for subsequent procedures resulting from this particular procedure'; (this is still an ongoing work within COM). The role buyer will be connected to one of these two codes via the predicate "isResponsibleFor';

  • This makes it necessary to connect back again the Buyer role to the AwardDecision reification since the link between Procedure and Buyer will be removed as a consequence of having the 'responsibilities' of the buyer codified inside the codelist.

  • A pending task for the Working Group is to come up with a better name for the generic reification class: the term 'involvement' does not seem appropriate because not all agents are involved in a given reified situation (ASAP Action Point for the WG). This naming aspect affects also the predicates of the object properties linking the reification to its 'things'.

  • Diagrams, examples, and queries to better understand the functioning of this approach can be found (here)[url] (through the issues workspace).

  • Next steps related to the design and implementation of roles and subroles are:

    • Finish reviewing the casuistry about Award Decision;

    • Apply the reification pattern to other situations affecting the agent and its roles, whilst [re]considering, case per case, the naming of the reifications and their property predicates.

Action Points:

  • To check the involves predicates in the reification about "involves" (WG)

  • To discuss if the Organisation should be with "s" or "z" (WG)

  • We need to create a document showing an AwardDecision (WG)

  • To create a long discussion topics file on GitHub