Cumulative content of Working Group Meetings in 2020

Working Group meeting 17/12/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Issues of the v2.0.1 and next steps

  • The WG discussed some issues discovered from the latest version of the OWL;

  • As next steps of the Ontology, the WG indicated that the Norwegians want to explain DCAT and facilitate discusion. The WG started discussing topics related to DCAT and the new release that is still under development from W3C.

  • Some members of the WG saw the need to take into account dcat and we recommend to use DCAT for the datasets generated.

Working Group meeting 15/12/2020

Participants: Paloma Arillo Arand, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: LocationCoordinate

Giorgia Lodi explained an issue in the BDTI pilot when querying addresses. The queries get very complicated because there are many indirections between classes and properties, as well as redundancies between properties (like, for example, longitude and latitude degrees and Measure unitCodes, etc.

One simplification proposed by Giorgia for the location of a specific spot in geometry/geography would be:

  • epo:LocationCoordinate epo:Latitude rdfs:Literal

  • epo:LocationCoordinate epo:Longitude rdfs:Literal

  • epo:LocationCoordinate epo:Altitude rdfs:Literal

The WG agreed on having the attributes epo:Altitude, epo:Latitude, epo:Longitude as epo:Text.

The WG decided to change the cardinality of the attributes to reflect what is in the predicate.

The WG agreed that we need to define the cardinalities of the attributes. 0..* by default. Indicators 0..1, the rest of attributes we need to check them one by one.

Topic of discussion: Roles and Subroles

  • TC440 eCatalogue convenor attends the meeting to contribute with Postaward Roles and Subroles.

  • The WG explained the current situation and approach using the reification class for the roles and subroles.

  • TC440 eCatalogue convenor contributed saying that the Organisation that provides a catalogue, and the organisations that receives and process the catalogue. The rest (originator, etc. would be there):

  • Catalogue Provider

  • Catalogue Receiver

  • TC440 eCatalogue convenor asks "what does procurement situation refers to? to specific processes/transactions, or what?. The WG replied that the ePO ontology does not model proceses, but relationships between concepts.

Topic of discussion: Modelling activities

The Wg discussed on how to model the different roles activities in the ontology. The following discussion took place:

  • The WG proposes to be flexible and open so linking as many different code lists to the generic reification.

  • The decision about certain roles like the organisation providing tax information, and similar, had been that these should go linked to the Agent (as in the ePO version 2.0.1).

  • In general the rule would be: if the agent is not directly involved in a procurement situation, but the procurement situation needs to use that agent or any other participants needs to be aware of their existence and activity, then these agents should not be linked to the reification as a role. In ePO 2.0.1 this works like this: the Agent is linked to another [range] class via a particular "predicate" (property) that explains/describes the activity developed by the Agent. In any case these properties MUST be attached to the Agent, not the role classes.

Working Group meeting 10/12/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 1st December and 3rd of December

  • Some modifications were done during the meeting

Topic of discussion: [Issue 60](https://github.com/meaningfy-ws/model2owl/issues/60) from the model2owl GitHub repository

Action Point:

To compare owl files generated and to see if the model used is the correct one.

Working Group meeting 03/12/2020

Participants: Ana Aido, Paloma Arillo Aranda, Eugen Costezki, Maria Font, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura, and Enric Staromiejski.

Topic of discussions: OWL script errors

The WG used the attendance of a consultant to analyse how to improve/correct the scripts for the transformation of the UML diagrams into OWL files:

  • Some errors still persisting were discussed and marked as 'action points':

    • duplicity of the same property as DataType and ObjectType;

    • class attributes of type 'Code' are pointing to classes representing codelists, when they should be pointing to "skos:Concepts";

  • Concerning the datatypes listed in the UML2RDF mapping (https://github.com/meaningfy-ws/model2owl/blob/master/config/ePO-default/umlToXsdDataTypes.xml) XSL-T artefact, the WG decided to change the data type marked as "epo:Text" (which ended up previously into "rdf:langString") into "rdfs:Literal". Confirmed that this does not impact on the TED-RDF mappings.

After this discussion, the script will be reviewed and the errors reported fixed by end of the week. Once the errors fixed and a new updated version of the script available, the OWL files will be generated again (this is an action point for everis).

Topic of discussion: Roles activities

The WG discussed the activity roles and how they should be modeled into the ePO ontology. For that purpose, the WG analysed the different existing codelists used in the ontology and which includes activities that are performed by roles. For example, the codelist organisation-subrole was analysed and the WG discussed whether the different activities listed in this codelist should be moved into the activity-type codelist which is linked to the reification class. The same discussion took place for the eo-role-type codelist that comes from ESPD.

The WG asks to retrieve the analysis done in previous sessions about the roles and subroles, and to present a proposal in the context of the works done around the reifications reuniting "Agent, Role, Lot, Activities, other".

ACTION POINTS:

  1. To correct the UML to OWL transformation scripts, due beginning of the next week → this task was completed on Sunday, the 6th Nov. 2020;

  2. To regenerate the TBox of ePO v.2.1.0, due next week (7th to 11th Nov. 2020) → this task is completed as per today, 10th Nov. 2020.

  3. To present a proposal on the inclusion of activities in the reification(s) identified so far, due next week(s) → this task is not started yet.

Working Group meeting 01/12/2020

Participants: Paloma Arillo Aranda, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 24th and 26th November 2020

  • We modified the minutes from the past 24th of November 2020 to reword some sentences that needed clarification.

  • The axiom "epo:CentralPurchasingBody epo:has epo:Buyer profile" was finally removed from the EAP file, since it had been indicated in the minutes but was not applied yet.

  • A new axiom "epo:Buyer epo:hasBuyerProfile epo:BuyerProfile" has been created in v2.0.2, this way this version is harmonised to v2.0.1 (in the previous v2.0.2 version the subject was epo:Agent). In v2.0.1 the predicate is still "epo:has", since we cannot change it due to the TED-RDF mapping (currently ongoing).

  • The property "usesBuyerProfile", between "epo:Agent" and "epo:BuyerProfile" has been removed: it does not bring any semantics that can be correctly interpreted in eNotification.

Topic of discussion: Issues

The following issues were discussed, and many of them closed. Follow the links to get into the discussion and how it has been/is being solved:

Working Group meeting 26/11/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: OWL files

The meeting was focused on the review of the datatypes used in v2.0.1 and the generation of the OWL files. The need for this discussion came from some errors detected in the OWL files generated automatically with the OP scripts: https://github.com/meaningfy-ws/model2owl

In this sense, the WG worked exclusively on version 2.0.1 of the ontology to see which datatypes are used and which ones are not needed. See the common package ( https://eprocurementontology.github.io/v2.0.1/HTML/index.html).

The WG also reviewed the datatypes listed in the transformation file for the production of the OWL files. See https://github.com/meaningfy-ws/model2owl/blob/master/config/ePO-default/umlToXsdDataTypes.xml the corresponding file. The WG changed the mapping and the UML (we removed unnecessary Datatypes) and produced new OWl core, restriction, and shacl files for the version 2.0.1 UML. These changes will be applied in v2.0.2, as well.

Working Group meeting 24/11/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from 17th and 19th of November

  • The WG discussed the point on the minutes about the removed property "ownedBy", between Channel and BuyerProfile. The WG said that further discussions are needed and to decide if the "ownedBy" should be kept or not.

  • To add the image of the diagram to show the cardinality of the "hasRole" between the ProcurementSituation and the Role.

Topic of discussion: Channel class

  • The WG discussed whether the channel should be also linked to the ProcurementSituation.

  • The WG indicated that if we adopt the reification in a future version, the property "has" between Role and ContactPoint should be removed, because too generic in its semantics.

  • The WG discussed whether the class BuyerProfile should be removed or not. The WG indicated that this class has been used in the TED-RDF mappings. The WG saw that the BuyerProfile is used differently in the v2.0.1. The WG discussed which way is the proper one to use the BuyerProfile class. The WG also indicated that using the BuyerProfile we are losing the consistency to the CPSV.

    • In v2.0.1 the Buyer is directly connected to the BuyerProfile, whilst in v2.0.2 it is not. The WG decided that v2.0.2 should be connected also be connected to Buyer directly.

    • The BuyerProfile is a type of Channel, which is correct and it was not modelled like that in v2.0.1. However, in v2.0.1 this cannot be changed (and will be kept as it is now).

    • Will remove the axiom "epo:CentralPurchasingBody epo:has epo:BuyerProfile" in all versions where it is still remaining, starting with v.2.0.1.

Working Group meeting 19/11/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

The dicussions focused on solving the somme pressing issues. The conclusions can be found in each issue:

Working Group meeting 17/11/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjolset, Thor Moller, Giorgia Lodi, Natalie Muric, Roberto Reale, Helder Santos Giampaolo Sellitto, Juan Carlos Segura, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 10th and 12th of November

  • The WG requested to have a link in the minutes to the ttl and SPARQL queries used to test reification pattern approach (but the link was already there).

  • The 3rd. November’s minutes were slightly changed. The paragraph starting with the following sentence was added (just below a UML diagram): "The inclusion of the role and the agent in the generic reification class "ProcurementSituation" makes unnecessary the axioms that we have in versions 2.0.1 and 2.0.2 "epo:Agent epo:playsRole epo:Role and the inverse epo:Role epo:isPlayedBy epo:Agent".

Topic of discussion: OWL files – OWL script

The WG discussed two issues related to the script developed by OP to transform the UML into OWL:

After that, the work on analysis for testing the reification approach(for which use a copy of v2.0.2) was resumed:

  • The diagram on Buyer and Organisation was re-discussed and the question of whether this diagram is needed or not was raised, since in the Agent diagram most of the classes related to Organisations are already covered there. The decision was to keep it, since the Agent diagram does not refer to Buyer nor BuyerProfile (and these are relevant from the Buyer perspective).

  • The object property “ownedBy” from Channel to Agent was removed. It seemed not necessary.

  • The cardinality of the object property "hasRole" between the ProcurementSituation and the Role was modified. Now it is: “*” situation has just “1” role, meaning that one instance of situation involves/affects just 1 Role and, in the opposite sense, one Role may be involved in more than one Procurement Situation

  • The relationship between Buyer and Procedure has been also removed, since what is important is getting to the Agent playing the role of Buyer (see figure below). Roles are not connected directly to the Agent anymore (they do indirectly through the Procurement Situations). Therefore, a solution needs to be found to connect the Agent playing the role of Buyer to the Procedure.

100096445 500f9700 2e5c 11eb 9296 093c7f1a76c0

The corresponding Conceptual Model file can be consulted at ePO CM roles as classes

Working Group meeting 12/11/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Award Decision-related reification

The WG continued discussing on the reification class and its use in the award phase. The main discussions and modeling actions were:

  • The name of the Class AwardDecisionDetails has been changed to AwardDecisionAssignation, since the semantics of this class is rather about the assignation of the Award to the role Winner (and the agent behind this role).

  • Also the predicates related to the AwardDecision reification class, as well as the predicates used by the generic ProcurementSituation have been revised and defined.

  • While working with the naming of these predicate, the following action point was raised: Create two Issues asking (1) how the transformation artefact could be able to generate object properties when the domains are multiple and different (and possible disjoint); and (2), are object subproperties being automatically and inherit from the appropriate parent object property?

  • The WG has relinked Subcontract to the reification AwardDecisionAssignation instead of to the AwardDecision class.

  • The WG defined the class cav:AwardDecisionAssignation as: "The attribution of something that is assigned to something else "The situation where one Lot is awarded (or not) to a Winner’s TenderLot and its subcontracted part(s)."

The corresponding Conceptual Model file can be consulted at ePO CM roles as classes Action Points:

  • Create an Issue with this inference about whether a property affects multiple domains and one range it is also created, and also to introduce the possibility of subclassing them (the properties).

Working Group meeting 10/11/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 3rd and 5th November

  • Relationship between AwardDecisionDetails and AwardDecision an arrow is missing. To be added

  • The WG discussed whether the AwardDecisionDetails is needed or not. The Award step is who produces the AwardDecision, we do not need to provide more details they could be in the AwardDecision class. The WG did not see the AwardDecisionDetail is a Situation.

  • The WG discussed on the name of the reification AwardDecisionDetails and the decision came when analysing the ordering.

  • The WG saw that we have a problem with the naming. To be solved in the future.

  • The WG discussed why we need reification. For that purpose indicated that with the example produced the need to have the reification was confirmed. Everis showed the example to WG due to some members were not attending the last meeting.

Topic of discussion: Award reification

  • Through the example prepared for the last meeting prepared a set of SPARQL queries.

  • The WG continued discussing the example to understand properly the data to be retrieved through the queries.

  • The WG modify the example together and fixed some errors discovered.

  • The WG discussed what exactly refers to the AwardDecision. The conclusion was that it refers to a lot.

  • The WG points the importance to discuss the naming of the concepts.

  • To conclude the discussion, the WG said that the reification and the model as it is, works, but the names and properties need to be reviewed.

  • The final decision about the reification name was:

    • The WG agreed to change AwardDecisionDetails by AwardDecisionAsignation

ActionPoint:

Working Group meeting 05/11/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Natalie Muric, Helder Santos, Juan Carlos Segura, and Enric Staromiejski

Topic of discussion: Roles and Subroles

  • A quick recap was done explaining that in the last meeting the WG worked on the eOrdering and the reification classes, putting together the agent, the roles, and the order. The WG during such meeting came up with a final decision indicating that the ontology is reusing the class participation from the cpsv and making the epo:ProcurementSituation as an extension of it.

  • Taking into account the same above approach, prepared a diagram with the same point for the AwardDecision situation. Everis also created a set of examples to test the model. So the purpose of the meeting was to test the model.

  • Explanation of the turtle file created for the testing purpose. Doing this test, everis saw important things to be commented on with the WG. For example, the namespace of the cpsv goes to the core vocabularies landing page. The WG tried to get the owl file but the system retrieves the html page and not the cpsv-ap turtle fie.

  • Another thing discovered was the epo:Agent inherits from foaf:agent, but was decided to inherit it from cpsv:Agent and the WG said that the cpsv:Agent inherit from foaf, but that is not true, they inherit from dct:Agent. The WG indicated that CPSV is changing this, so for the time being the WG agreed to come back and to inherit the epo:Agent from the foaf:Agent.

  • The WG went through the Abox example created to see how the model would be represented in RDF. Everis confirmed that the current model works if. From the discussion, the WG proposed why not to rename the AwardDecisionSitutation as AwardDecisionDetail since it provides the details of the AwardDecision of the Procedure:

  • The WG after the example explanation continued analysing other situations where the reification could be needed. They worked on the Buyer and Organisation diagram. We added to the diagram the ProcurementSitutation reification class, since it is the link between agent and role:

  • The meeting ended with the discussion about the skos:Concept buyer-legal-type.

Working Group meeting 03/11/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Juan Carlos Segura Fernández-Carnicero, and Enric Staromiejski.

Topic of discussion: Review of the minutes from 27th and 29th October

  • Concerning the Ordering term, the WG indicated that the decision was not to have the Ordering term. Action for everis to include the final decision on the minutes.

Topic of discussion: eOrdering

Once reviewed the minutes of the last week, the WG continued with the discussions on the eOrdering model. Based on the minutes from the 27th and 29th of October, the following discussions took place:

  • The WG saw that the properties from OrderingSituration to the different roles are not needed because the OrderingSituation which a ProcurementSituation already involves roles:

  • The inclusion of the role and the agent in the generic reification class "ProcurementSituation" makes unnecessary the axioms that we have in versions 2.0.1 and 2.0.2 "epo:Agent epo:playsRole epo:Role and the inverse epo:Role epo:isPlayedBy epo:Agent". The inclusion of the epo:involvesRole in the reification, subclasses now the CPSV-AP property "cps-av:role" (we are reusing the cpsv-ap:Participation class and its attibute "role", which points to a "skos:Concept" (see the UML diagram for more details). Therefore, if we end up implementing the reifications as represented in the UML diagram above, the relation between roles and agents would have to be removed.

  • The WG asked why we are inheriting Agent and ProcurementSituation from the CPSV and the conclusion was that we are inheriting Agent and ProcurementSituation from the cpsv:Agent and cpsv:Participation for two reasons/benefits: (1)for the benefits of alignment ontologies (e.g. SDG), (2) doing this alignment we also solve other problems like how the agent is being modeled through the reuse of the cpsv agent.

Topic of discussion: Issues

Working Group meeting 29/10/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: eOrdering

  • The WG discussed what are the objectives of the RoleAssignment class and how to use it. The WG indicated that the RoleAssignment links an Agent to a Role for a given planned action or rule that will need to be executed. Also, the assignments are expected to become situational facts during the fulfillment of the planned actions. From this discussion the following points were also discussed:

    • The WG discussed which is the rule that says that an organization is a deliveree.

    • The WG indicated that there missing elements in the model to describe the workflow that happens in the execution of some ordering activities.

    • The WG saw and discussed the need to model all the rules related to the Ordering. First of all, the WG asked what is a rule. The WG discussed the meaning of rule and indicates that it is an ordering term. Then they clarified what is a term defining it as a very particular rule or a collection of rules. Therefore the difference between Term and Assignment is that a term is a collection of rules while the assignment plan from role to an agent is capture between properties that link the term to this Procurement situation. From this discussion, the WG decided the Ordering situation is the reification allows us to connect the ordering rules to the different roles.

    • The WG added predicates to the properties that link OrderingSituation class to the different roles that already exist, like Seller and Buyer. The deliveree and the deliverer and the originator are not planned, the predicates contain the Planned concept.

    • The WG indicates that the OrderingSituation does not describe facts, but intentions.

    • The delivery term was associated with Period and the class location to define the delivery location.

After discussions, the resulting model is as follows:

Action Point:

  • Ask Peter Borrensen and any else in the post-award committee to provide real invoice and ordering examples.

  • To have examples of eOrdering to test for next Thursday

Working Group meeting 27/10/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Roberto Reale, Hector Rico, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 20th and 22nd October

  • There were no comments from the WG.

Topic of discussion: Lessons learned when creating ontologies – by Giorgia Lodi

  • Presented to the WG the lessons learned when creating ontologies in Italy. The same presentation was also shared during the SEMIC conference

Topic of discussion: eOrdering

The WG continue discussing on eOrdering. The meeting was focused on the email sent by one member of the WG which explained that the CPSV-AP gone through a similar situation to our about the concept situation and that is a class called participation.

This participation class from the CPSV vocabulary was analysed to see how it is related to our situation (Procurement Situation). As a conclusion of the analysis, the WG decided to add this class into our model and reuse the CPSV vocabulary. This class is used for the generalisation of the ProcurementSituation. The WG also added to the UML diagram the class skos:Concept to be coherent to the CPSV and to align the ePO Role to the fact that in the CPSV-AP the roles are skos:Concept(s). The WG also agreed to remove the relation between roles and agent because we are adopting or reusing the CPSV participation class.

Also the WG indicates that we are inheriting Agent and ProcurementSituation from the cpsv:Agent and cpsv:Participation by two reasons/benefits: (1)for the benefits of allignment ontologies (e.g. SDG), (2) doing this alignment we also solve other problems like how agent is being modeled through the reuse of the cpsv agent. The WG indicates that we need to test this asap to see if it works:

Working Group meeting 22/10/2020

Participants: Ana Aido, Cécile Guasch, Giorgia Lodi, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: eOrdering

The WG continued the discussion from the 20th of October concerning electronic ordering terms. The idea that we may be in front of two different patterns or models emerged a couple of times: one for ex-ante "rules and terms" (e.g. what needs to be done for eOrdering), and another for ex-post "situations" (what was actually done during the eOrdering). The general feeling of the WG was, however, that both situations are very complicated and that there should be one single and coherent model to represent both situations. The WG had the feeling that the eProcurement process will need information about the ex-ante and ex-post, maybe having two reification class, but this needs more discussions.

The analysis of "Ordering Terms" led to consider whether the class "Term" could become a reification class or not, since some of the attributes of the class seem to be necessary in the reification (at least those referring to Agent and Role). This analyses was not covered during the meeting, since the WG ran out of time. It was proposed to take examples from invoicing to complete the analysis in subsequent meetings, since the Invoice may have more terms and data relating Agent to Role and, possibly, to other data necessary in the reification. Cécile Guash commited to send examples on this (which we did: see CG email to the WG, subject "example invoice", 22 Oct. 17:25).

From this meeting the main discussed points were:

  • The WG though that we need to have the ex-ante assignment of roles to agents because it is needed for the notification phase (a class RoleAssignment was originally proposed for this, but was not added to the UML diagram since it needs further analysis). This assignment would be differentiated from the Terms in eOrdering.

  • The WG saw examples of ordering and some roles involved in it. Looking to the examples, the WG saw that it is possible to map them with the current model, but there is more content where we will need to add more entities to the model to cover the entire Ordering data that may or may not be related to eOrdering Terms.

    • The WG saw also from the example the possible need to add the 'Period' which is an informational data. This Period should be part of the reification ordering class.

    • Comparing what is in UBL and CEN TC 440, the WG thought that maybe it is not needed to map the XML models to the ePO is not possible nor convenient. Thus, for example, according to one of these XML-based models, the delivery term has an attribute "location", whilst in ePO we already have the class Location.

  • The WG agrees that as soon we come up with a solution we need to test it immediately with real data samples.

Working Group meeting 20/10/2020

Participants: Ana Aido Cécile Guasch, Giorgia Lodi, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 13th and 15th of October

  • In the minutes from the 15th of October, instead of pointing to the eap file, better to add a picture of the diagram;

  • Typo in the second bullet, "discussed" is missing;

  • To add why the property relatesTo;

  • To add a bullet point that we end the meeting with the discussion if the AwardDecsion is the reification class;

Topic of discussion: eOrdering

The WG continued working on the creation of the eOrdering diagram. The WG merged the Model were there was the eOrdering with the model where the work about roles and activites (subroles) is also being developed.

The EAP file can be found at ePO CM roles as classes

In this EAP file the WG created a new diagram named 'eOrdering'. A png of this diagram is

In the above mentioned diagram it is possible to observe that WG was focused on the development of the eOrdering from the Roles perspective. Hence WG has added classes such as Deliveree, Deliverer, Originator, etc. When adding these classes the WG has reflected about the facts that:

  • The information relative to which roles intervene in the eOrdering phase are normally specified as "Order Terms";

  • At the stage of eOrdering, the roles do not seem to carry very much information, however we foresee that the actions and other properties related to the agents playing those roles will emerge when "fulfilling" the Order;

  • This reflection has led the WG to identify that we may be in front of two different types of reifications:

    • Reification to specify "information", "terms" or "conditions" anounced by the buyer related to the ordering; and

    • Reification to describe "situations" related to the fulfilling of the order;

  • In the first case, some members of the WG proposed to name the reification "RolesAssignment", since in their opinion this is merely about to identify which roles play one specific (and only one) Agent, and nothing else. Other alternatives were suggested for the naming of this reification (Ordering, OrderingInformation, OrderingTerms even).

  • The discussion ends at this point (16:30), and the WG proposes to go on discussing on the Roles in the context of eOrdering.

Action Point:

  • To add the link to the eOrdering file in the minutes.

  • To check what is happening with the class Lot. It is in grey.

Working Group meeting 15/10/2020

Participants: Paloma Arillo Aranda, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiesjki.

Topic of discussion: Roles and Subroles

The approach of the meeting was focused on the discussion of roles and subroles. The meeting started with the last decisions made on the 13th of October.

The WG continues with the review of the generic diagram and worked on it:

See the Award Reification diagram:

From the discussion of the diagram the following decisions were made:

  • The WG decided to change ProcurementInvolvement by ProcurementSituation. This class is connecting the agent to a particular role.

  • The WG the need or not to have the class PlannedProcurementPart within the generic diagram (see above). It comes from a previous analysis of when procurement is in the planning phase or whether it has been planned and design in terms of procedure, lots, etc,. When mapping ontology to eForms we needed to model the planning phase in the procurement. The WG concluded that this class is not needed in the diagram because in the end it will not exist and the class was removed.

  • The association property was changed because it should go from ProcurementSituation to Period and cardinality 0..1

  • The WG discussed the involvesActivity (activity-type). For example, there is an awards contract activity and there are two roles, the buyer and the winner, so how to know that this activity is related to one of the roles. With a query, the activity and the role and agent performing that activity is retrieved.

  • The generic class owl:Thing was removed after discussion with the WG. The specialisation of ProcurementSituation profile the situation, meaning by profile that extends and customises the situation. One customization could be the restriction of cardinality, and one example of example could that the AwardDecision needs to extend the subcontract.

  • The Buyer class was removed from the Award-Reification diagram and the property from AwardDecision to Winner was renamed by epo:hasWinner 0..1 instead of epo:involvesWinner. Also, the property AwardDecision involvesBuyer Buyer was removed.

  • The bidirectional property from Subcontract to AwardDecision was modified. Instead to say AwardDecision epo:isReferredToIn Subcontract, and Subcontract epo:acceptsProposalOf AwardDecision, the direction was changed saying that AwardDecision epo:acceptsProposalOf Subcontract, and Subcontract epo:refersToAwardDecision AwarDecision. Moreover, the WG saw that already exist in the model that Subcontract refersToAwardResult AwardDecision, and AwardDecision has Subcontract. This property was removed since the bidirectional property AwardDecision epo:acceptsProposalOf Subcontract, and Subcontract Subcontract epo:refersToAwardDecision AwarDecision means the same.

  • The property from ContractAwardNotice to AwardDecsion was also changed to notifiesAwardDecision instead of notifiesAwardResult, and the multiplicity was changed from 1 to 1..*.

  • The property refersTo from ProcurementSituation to Lot was also removed.

  • The meeting ends with the discussion if the AwardDecsion is the reification class.

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:

Also created a simplified version of the above diagram:

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

Working Group meeting 08/10/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski

Topic of discussion: Roles and Subroles

The WG started the discussion with proposing some clarification examples from the discussion on the 6th of October. From the clarifications, The WG made a general question about how a business person could understand what is represented in the UML. The WG, as an example to understand this need, said that if we are doing a mapping we need to understand from the UML to what we are mapping. One possibility could be the addition of notes in the UML to explain what is represented in the diagram.

For example, the creation of a note in the eAward diagram to explain which roles are involved in the awarding process. This note could say that the award decision involves only 2 roles: 1. The buyer, the one that awards; 2. The winner, the one that is awarded. Moreover, everis indicated that in this note can be added a reference to a ppt with more details of the roles-taxonomy representation, for instance. The WG replied that the problem is that we will end with a lot of notes in different diagrams and what will happen when it is automatized.

The WG also asked how the reification is helping in the eAward diagram. The reply was that the function of the reification is to link one agent/role with a specific activity. The WG thought that the reification is not needed in the AwardDecision and the AwardDecision could be considered as the reification. Everis indicated that the reification is needed because of the existence of the Agent and there are no other ways to know who is the agent/role/contact point behind the award decision. The WG did not see the need to have the reification in the AwardDecision diagram. There could be different winners in the decision 1 or 10, there is no problem, and the Buyer does not have other or more activities in the award decision. Everis said that if there is no reification and you want to instantiate the agent that wins the lot, to do that you need to have multiple instances of the winner and to see which instance is connected to one agent. The reification solves the problem to instantiate a role multiple times.

The conclusion and decision were that the reification will not point anymore to the taxonomy, it will point to the classes. The WG worked in such a solution, instead to have the class "AwardInvolvement" linked to the "role-taxonomy", now such class is linked to the winner through the property "involvesWinner". The discussion came from the need that the award decision/award involvement only involves 2 roles, the buyer and the winner. The buyer is not connected to the AwardInvolvement because it belongs to the responsibility of the procedure.

Working Group meeting 06/10/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile,Hilde Kjølset, Natalie Muric, Robert, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giovanni Paolo Sellitto, and Enric Staromiejski

Topic of discussion: Review of the minutes from 29th September and 1st October

  • To rephrase the minutes with the mention of the maximum score and the minimum score and the cccev

Topic of discussion: roles and subroles

The WG started listing the topics inside the roles and subroles to be discussed:

  • Which classes are to be removed and how these concepts end up in the model (e.g. Winner, Buyer are to be removed because we would have them as role codes in the role-taxonomy);

  • What shall we do with the attributes in those classes? E.g. WinnerRank, or the attributes of the class buyer;

  • Do we need a reification class, or is the class “AwardDecission”?

  • Redundant properties between the classes representing Roles (v2.0.2)

The WG started with the discussion of the first bullet. The WG analyses the conceptual model and saw that the AwardDecision refers to Lot and also the EvaluationResult is connected to the AwardDecision, and then AwardDecision is referredBy a Contrac and the AwardDecision has a Winner. Moreover, the Buyer is connected to the AwardDecision who makes decisions in the AwardDecision:

According to this discussion, the WG identified examples of situations for the usage of the reification class. One first observation is that the action performed by the role is frequently (but not always) connected to a relevant entity of the ontology.

For example (1)the AwardDecision is connected to the AwardResult and is ‘made by the role Buyer’; (2)The Tender is connected to the agent that submits it, which in eProcurement we know it as ‘eSubmission’; (3)The contract, which is resulting from a situation involving the signatory parts; (4) Other situations that do not connect the agents to a result. For all these cases, the WG proposes to have a Generic Pattern Structure that can be specialized per situation.

The topic of whether the ontology should model processes was raised once again because the reifications of the type ProcurementInvolvement (e.g. eSubmission) look very much like processes. The WG checked that this is not the case for at least the only reification we have for the time being (AwardDecision).

The WG continued discussing what to do with the AwardDecision. For that purpose, it was presented and explained a diagram that contains a new reification class named “AwardInvolvement”, it is the class that connects the Agent, with the roles, with other classes. In this model, it is not possible to know who is the Agent that is performing something until we state what is the role and the type of Organization.

From this discussion, the WG concluded that we need to find a good term for the reification(s), neither ‘ProcurementEvent’ nor ‘ProcurementInvolvement’ is good enough. In the case of AwardDecision, the involvement entails active participation (and the Winner does not participate in the decision-making). Moreover, in the generic case, the Event concept does cover many more aspects that were never intended to be represented in the ePO (processes, for example, and events in general).

Working Group meeting 01/10/2020

Participants: Ana Aido, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Definitions

The following concepts were defined during the meeting:

  • SelectionCriterionType. Now the type of the criteria is in the class Criterion and the definition for the type is there.

  • ThresholdValue. The WG discussed the need to rename this as "Threshold" and to remove the ThresholdValueType. Same actions should be replied in the AwardCriterion class. For this discussion, the WG check within the eForms mappings, how the ThresholdValue was used. The BT-7532 Selection Criteria Second Stage Invite Number Threshold was the concept used for the mapping to the ThresholdValue. The definition of this BT was also took into account by the WG for the creation of a new definition for the concept "Threshold". The WG created a document to understand what is a threshold, based also in the definition of the eForms BT-7532.

Pending tasks related to this work, which will need to be tackled when resuming the work on definitions, are:

  • Analysis of the connection between the 'MultistageProcedureTerm' property 'ThresholdValueType' (e.g. max-pass) to the class Criterion

  • Similarly to the reflection/decision about the fact that we do not necessarily need a field named 'Threshold' (because it is already solved in the CCCEV in an abstract way), the model 'CAV' being developed by CAMSS/SEMIC could be used to solve the requirement/business need reflected in the current ePO 'MultipleStage' class (e.g. by using cav:Scenario, cav:CriterionEvaluationContext, cav:Score, cccev:Criterion). This topic should be a subject of analysis for the ePO Working Group (to be discussed ASAP).

Working Group meeting 29/09/2020

Participants: Ana Aido, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura, Gaimpaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the 22nd of September

  • The reification is not a taxonomy. To change the sentence. The reification is a class that connects the roles taxonomy.

  • The final proposal of the elements repeated in a taxonomy was to put them out from the taxonomy.

  • The sentence nonetheless, they will have different tags… to be removed is not true anymore.

  • The sentence The WG asked why not do add the attributes… to be rephrase.

  • To add examples to the minutes.

Topic of discussion: Organisation and Organisation group error get from the conventions script

  • OP explained that through the convention script was got the following error concerning the classes Organisation and OrganisationGroup: The classes epo:Organisation and epo:OrganisationGroup inherit one another. Sub-class relation must be established in one direction only, forming a hierarchy.

  • According to the WG there is not an error on the model and therefore it should be checked with Eugeniu to see if there is bug in the script.

Topic of discussion: FinancialOfferValue

  • The WG discussed which is the best modelling approach if to have the FinancialOfferValue as an object property or as a class.

  • The WG asked if this class is needed for the eOrdering. The WG justified that it is not needed if in eOrdering we have the Value, then the FinancialOfferValue can be got from it.

  • The WG decision was to remove the class the FinancialOfferValue and to convert it into an object property as in v2.0.1 in the model

Topic of discussion: Roles and Subroles

The WG continued with the discussion of roles and subroles.

The WG started the discussion mentioning that the solution proposed in the last meeting is very generic. For example, the WG was not completely convinced with the name "event" for the reification. The WG discussed alternatives of it, but previously we need to understand where we need data of organisations, activities, etc.

The WG also indicates that the name "Event" is very generic object and the implications is that it can be used for anything in any situation. In terms of querying, the WG indicates that the results on a query in a reification retrieves a lot of entities in the result since it is very generic. For the purpose to see different query results, the WG saw the need to define user stories to define competency questions.

After different points of discussions on how to model the roles and subroles, the WG agreed on the approach of the reification, codes and taxonomies, but also was identified the need of simplify the reification and use them only in a given a context with only those classes that need to be reified for that context. The WG agreed on the fact that the reification should be specialised.

The WG, concerning the "ProcuremenEvent" class reification, decided as an action point to see which are the "events" that the ontology currently has.

Action Point:

  • To review the minutes of the 22nd of September

Working Group meeting 22/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Sofia Berenguer, Didac Cabus, Maria Font, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Hector Rico, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Helder Sousa Santos, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Review of the minutes from the last week

Some mistakes were detected:

  • Instead of Public Procurement Documents, should be Public Procurement Directives

  • Instead of the Financial Offer class, should be Financial Offer Value class.

  • There was a typo in the AwardCriterion (minutes from the 15th September)

Topics of discussion: Roles and Subroles discussion

  • Everis prepared a presentation for the discussion of the new approach roles and subroles. (Roles Taxonomy and Procurement Events)

  • Everis explained how the roles and subroles are currently modelled. The current model of roles and subroles represents them as classes.

  • Everis explained that as an alternative to the current model design of roles and subroles was to remove all the roles and subroles simplifying the ontology. The alternative solution is to use the reification taxonomy to represent the roles and subroles.

  • Everis explained that eu vocabularies have different codelists related to the role: "role", "organisation-subrole", "buyer-legal-type", "role nature" and "role qualifier".

  • Another activity that everis did for the preparation of the new approach on how to model the roles and subroles was to review the "Organisations, Roles and Activities as per the Directives" model using a model created in previous analysis by OP

Roles and Subroles
  • Based on the above model which depicts the different main activities of the contracting entity and the contracting authority, everis created a sample model on how to model the different activities performed by the tenderer, the winner, and the subcontractor:

Activities and Tenderer
  • Everis explained and said that the model includes the main roles which are the Buyer, the Economic Operator, and the Procurement Manager (this is a temporary name until a new one will be agreed). Everis also indicated that the concept scheme of the model, which is representing a taxonomy, is the Role.

  • Following the everis proposal about the activities, everis explained that the different activities will be taxonomies associated with the different top concepts (e.g. Economic Operator, Buer, Procurement Manager). However, everis explained that with this solution is difficult to query, and does not solve all the situations unless the activities are involved separately in the reification, which entails specific rules for the association between role and subrole-activity.

  • One of the exercises that everis performed is to try to model all the roles and subroles in taxonomy with the inclusion of the alignment to the Directives. The problem identified was that some elements will be repeated in taxonomy since for example the contracting authority and the contracting entity authority have the same types but they need to be represented separated in the taxonomy. Nonetheless, they will have different tags for their representation.

  • Regarding the "Procurement Manager" role, everis identified two types: "Procurement Service Provider" and "Central Purchasing Body". The WG indicates that the Central Purchasing Body was decided that it is a Buyer. Everis indicated that it is also modeled in the taxonomy as a buyer. The Central Purchasing Body plays the role of awarding and the role of managers.

  • Moving on the presentation, everis introduced to the WG the reification proposal. The reification is a class that connects everything amongst itself. This reification connects the agent with the role and with a thing that is being affected by an activity performed by a role. The reification approach includes a "RoleTaxonomy" with all the roles and their activities:

Reification
  • The WG discussed then what to do with the attributes that are right now in the different role classes that will be removed if the reification approach is implemented. The WG asked why not to add the attributes in the reification. Everis indicated that then we will null the effect of the reification. The WG will discuss it later.

  • The WG also discussed the name of the reification, the WG is not convinced at all with the name "ProcurementEvent".

  • Concerning the "RoleTaxonomy", the WG said that the taxonomy is mixing the roles, subroles, activities, and functions in one single element. The WG proposed that maybe another possible solution is to have another taxonomy for the activities associated with the reification. Everis indicated that if we do that, we will need rules to ensure the association between role and subrole-activity.

  • Everis presented to the WG different examples to show how the current model with roles and subroles as classes work and examples to show how the reification solution would work.

Working Group meeting 17/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Robert, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: eOrdering

  • The WG created a new diagram named "eOrdering" for discussion of the phase. The following picture shows the classes added into the diagram:

eOrdering
  • Regarding the AdditionalDocument, the WG raised the need to discuss it because eOrdering is also a ProcurementDocument. The doubt is if the AdditionalDocument can be used also for Order. According to the ProcurementDocument definition, these documents are created for the Procedure by the Buyer (it is defined by the directive). Therefore an order cannot be considered as a Procurement Document as defined in the ontology and the Public Procurement Directives.

  • The WG also said the eOrdering does not always start at the procedure level, they used quotation to define the tender. The WG said that this quotation could be the FinancialOfferValue class that already exists in the model. The definition of the FinancialOfferValue class has been changed: "Monetary amount for which the economic operators commits to fulfil a given request". The WG saw the need to have another class that aggregates financial offer values. Due to the different discussions, the WG proposed why not to start modelling Order.

  • The WG explained that Order is the result of a tender, and this tender maybe a quotation. A new class named "Order" was created and which is a "Contract". The WG also said that Order has "OrderLines", there is a structured way to express what is bought. The WG created the class "Line" to represent the order line and also drop in the model the "Item" class because the order line defines Item. The Line class was connected to Order with the property "epo:hasLines". Also, the "Line" was associated with the "Item" through the property "epo:specifiesItem".

  • The WG discussed the different Value classes existent in the model. The WG remember that there was a discussion where the decision was just to keep the Value class since the rest of the classes did not add many details. WG will check the previous version of the diagram to see how the Value was modelled.

  • The WG asked what is the meaning of the datatype "Amount", "Quantity", "Measure". Everis explained that these datatypes come from the UBL 2.3 standard. The definitions of the datatypes were added into the model.

Action Point:

  • To check the ccts definitions and where the measure and amount are used in the model. Maybe in some cases, they are used wrongly.

Working Group meeting 15/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Helder Santos, Giampaolo Sellitto, Juan Carlos Segura Fernández-Carnicero, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Review of the summary conference call of the 8th and 10th of September

  • Everis explained briefly the summary of the WG meeting on the 10th September.

  • No comments from the WG

Topic of discussion: Definitions

  • The WG decided to move the SelectionCriterionType to Criterion with a generic name "Type". Therefore the AwardCriterionType was also removed from the AwardCriterion. The codelists AwardCriterionType and SelectionCriterionType are kept in the SelectionCriterion class and also in the AwardCriterion class since the Type attribute is inherited from the Criterion class.

  • The WG asked why we have the name and description in the Procurement class and not in the Criterion class. Everis confirmed that criterion has both attributes, therefore the WG decided to move name and description into the criterion class.

Action Point:

  • To check that all the description classes are using the same definitions

Working Group meeting 10/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Mappings TED forms - Standard Form 17 (Defence), section III.2 Conditions for participation

  • The WG discussed the final decision on the conditions for participations topic discussed on the 3rd of September. The WG indicated that the conclusion was that the concept should be placed in exclusion criterion with a note that this is only used in the specific case of this standard form.

Topic of discussion: Central Purchasing Body

  • The WG said that there is an issue created in GitHub discussing the CentralPurchasingBody.

  • The WG proposes to reopen the discussion taking into account such issue in GitHub.

  • The WG indicated that the CentralPurchasingBody is independent of the roles and subroles discussion. The WG agreed that the discussion of roles and subroles will take place after the eOrdering discussion on the 17th of September. The WG also agreed to discuss: (1)roles and subroles diagram; (2)to test roles and subroles solution into EvaluationReport showing how the winner is represented; (3)how to address the Central Purchasing Body; (4)other buyers. Note that the point 1, 2 and 4 is in the context of the roles and subroles solution.

Topic of discussion: Definitions

  • The WG decided to remove the code usage from the selection criterion class (hasApplicability). Instead of this code list, the decision was to create an indicator as an attribute of the class selection criterion (UsageNotYetKnown).

  • The WG asked why the Procurement Criterion is used if there is a Criterion class in the core criterion and core evidence vocabulary (cccev). Everis and OP explained that as the cccev was under evolution, the decision was not to use the cccev and move all the classes to the epo namespace until there will be a stable version of the cccev. The WG also indicates that the ProcurementCriterion class is needed because some dependencies and properties are from the eProcurement domain and they cannot exist within the cccev. Moreover, the WG argued that not only the selection and exclusion criteria are related to the Lot, the ESPD also relates the exclusion criteria to the Lot.

  • The WG asked why the ProcurementCriterion has the attributes “name” and “description” if maybe the Criterion class has them. Everis will check if the criterion class has both attributes in the cccev

Action point:

  • To check whether cccev has name and description in criterion class.

  • To implement the solution discussed about Standard Form 17 (Defence), section III.2 Conditions for participation

Working Group meeting 08/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Sofía Berenguer Romeu, Cécile Guash, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Definitions

  • The concepts defined were:

    • ReviewDeadline within the class ReviewTerm

    • ReviewProcedure within the class ReviewTerm

    • Formula within the class ReviewTerm

Action point:

  • To check how the review deadline and the review procedure are used as the deadline for requesting a review or the deadline within which a review should be carried out and the procedure for the review.

Working Group and TC 440 joint meeting 29/09/2020

Participants: Working group members of eProcurement Ontology and TC 440

TTC440 explains it was in the early process of establishing an eProcurement terminology to be used by each specification that needed a term. TC440 recognizes the eProcurement ontology and therefore their deliverables intend to align with the eProcurement Ontology. This meeting aimst to set an organization that ensures this alignment. The proposed idea is to reuse the definitions developed by the eProcurement Ontology instead of creating a competing activity to establish a competing terminology.

The OP presents the eProcurement ontology. OP explains that the eProcurement ontology aims to cover the whole life cycle of the procurement from eNotification to eInvocing. Currently, the eProcurement ontology development is limited to the eNotification but this phase provides the backbone of information from the rest of the procurement phases. Presentlly the eProcurement ontology defines the terms and definitions of the data that is needed in the eNotification phase. A human-readable representation (a conceptual model) of the ontology depicting its concepts and how they interrelate has been created and it is publicly available for consultation. Recently the team created the OWL and SHACL files that provide a machine-readable representation of the conceptual data model.

OP explains that the work produced for the ontology has been checked through the mapping to eForms, ensuring that the eForm business terms are mappable in the eProcurement Ontology. There is another project that is the mapping to the current TED forms. This work is not complete but should be finished by the end of this year.

The ontology is built on the eProcurement directives so its focus is European and B2G, even though B2B has been taken into account in the fact that the Buyer can be a business. The ontology uses ccts components. OP indicates that all the related information and files of the ontology are publicly available on GitHub.

The OP presents the roadmap. It started with producing the Glossary. The eNotification phase is planned to be finished by the end of 2020. Then the plan is to start the eAccess phase. OP indicates that the roadmap is presented in the following order but it can be changed according to different needs.

OP explains how to access the different files related to the eProcurement Ontology. OP also presents the HTML version of the conceptual model and the different diagrams that represent the ontology, and how the classes, code lists, and attributes of a class are represented in the model. OP shows an example of how the definition of a class and attribute is defined in the model.

TC440 asks OP that if the Ontology is based on the directives it means that the Ontology is focused on public procurement. OP indicates that the Ontology is focused on public procurement, but it can be extended in a larger scope.

Cécile Guasch explains the reasons for using the eProcurement Ontology and the rationale of the eProcurement Ontology: 1. Reuse terms and models defined by the eProcurement Ontology (ensure that legislation is consistently taken into consideration, the work done by the eProcurement Ontology working group is highly resource intensive); 2. Adopt the same methodology (the activity started from a conceptual model which has been improved and updated with the working group); 3. Feed the eProcurement Ontology (change request, new concept).

The proposal is that the WG from the different projects can take the current version of the model, the v2.0.2, which is being evolved and request to the eProcurement Ontology WG the extension or creation of definitions for some concepts. The approach consists in the steps listed below:

  • Identify the information elements of CWA transaction specification that can be found in the eProcurement ontology.

  • Check for coherence of meaning of the common subset

  • Identify gap and for the gap solve following 3 items:

    1. Propose change requests to the eProcurement ontology: To update existing elements of the ontology To create new elements (concepts, property or attribute)

    2. Propose specialization or extension of the eProcurement ontology

    3. Meet with the eProcurement ontology to discuss the proposal to solve the gap and the Change requests

  • Refer to the eProcurement ontology elements in the specifications also copying the definition of the term.

Working Group meeting 03/09/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Mappings TED forms - Standard Form 17 (Defence), section III.2 Conditions for participation

OP asked the business people, whether they could check in their respective countries if the conditions for participation are used as selection or exclusion criterion. OP indicates that this is a need found doing the mappings to the TED forms and it is not represented in the model due eForms is not going into this detail.

The discussion about this topic was to use the “ProcurementCriterion” to instantiate these type of criteria. The WG detected a problem if the “ProcurementCriterion” is used because it is an abstract class and therefore querying the criteria the data retrieved will be from selection and exclusion criterion. Therefore, there is no way to differentiate it. The WG indicated that the conclusion was that the concept should be placed in exclusion criterion with a note that this is only used in the specific case of this standard form.

Topic of discussion: Group of economic operators

OP explained that in the TED forms mappings to the ePO Ontology there is the need to know how a tenderer is a group of economic operators. Currently, the mapping is through the property “isMemberOf”. The WG indicates that the correct mapping is thought the inheritance property therefore the mapping is:

  • Tenderer isA Economic Operator, Economic isA Role, EconomicOperator isRoleOf OrganisationGroup.

OP also asked if the address to be provided is the address of the group or the address of each member. The WG check the form and said that the address of each member is the one to be provided, then how it is possible to know that it pertains to the same group. The WG explained that as the contract number is repeatable in the form but can only be awarded to one winner, whilst different winners (as in FrameworkAgreement) should have different ContractNumbers. When the Contractor is repeated it means that it belongs to the same winner (as in a Consortium).

Topic of discussion: Definitions

Working Group meeting 01/09/2020

Participants: Paloma Arillo Aranda, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Ioannis Rousochatzakis, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Values of the subcontract parts

OP commented that in the lasts working group meetings there were some discussions about the value of every subcontract part of the TenderLot and how to represent the total value subcontracted. In one of the discussions, the decision was to add the total value subcontracted as an attribute of the Statistical Information class. However, in the other discussion, the decision was to remove the attribute from the StatisticalInformation and to add a new definition in the property “hasEstimatedValue” which links subcontract and value. OP, indicates that this second solution does not solve the problem because then with that definition is not possible to know the estimated value of a single subcontract.

The WG agreed on the OP statement and the decision was to add the attribute “TotalValueSubcontracted” in the StatisticalInformation class. Now, the statistical information subcontract value is the aggregation of the different values subcontracted. Moreover, the WG indicates that a business is needed to verify that the total value subcontracted is exactly the sum of the different subcontracted parts. As a matter of fact, all the data in the statistical information needs to be verified against the particular data held by the model.

Topic of discussion: Mappings TED forms - Standard Form 17 (Defence), section III.2 Conditions for participation

OP asked the business people, whether this is Exclusion, Selection criteria, both or what and whether this should go to the ESPD or in the Procurement Documents. The WG decided to use the “ProcurementCriterion” to instantiate these type of criteria, instead of using the Exclusion or Selection criteria classes. In this way, it is possible to map the current Forms to the Ontology.

Topic of discussion: Definitions

Action Points:

  • To replace all the definitions of "name" by the one from name of organisation

  • To check how the review deadline and the reviewprocedure are used as the deadline for requesting a review or the deadline within which a review should be carried out and the procedure for the review.

Working Group meeting 30/07/2020

Participants 30th: Ana Aido, Paloma Arillo Aranda, Cécile Guash, Giorgia Lodi, Thor Møller, Giampaolo Sellitto, Héctor Rico and Enric Staromiejski.

Topics of Discussion: CPB, Framework Agreement Technique, Pending Topics from the current TED forms mappings.

Central Purchasing Body: (Issue 245 CPB can be responsibleOf procedure) For the pilot, it was needed to know who is responsible for a procedure. The Central Purchasing Body can be responsible of the procedure and the model until today’s meeting did not reflect this clearly. Before the modification the CPB actAs Buyer and is responsibleOf the procedure. The discussion went around the need to add or not the object property responsibleOf also between CPB and Procedure.

The WG final conclusion:

  1. Remove the property actAs

  2. CPB is a subclass of Buyer

  3. Remove the attribute and property related to the SubRoleType for the CPB. It inherits from buyer.

JointProcurement discussion:

The main question was how to express the leader of the procedure when it is a JointProcurement. To have a consistent representation of the organisation roles in the case of Joint Procurement it was agreed to have role for the different organisations involved in an “OrganisationGroup”. Thus, the Group-member role was included in the epo:organisation-subrole code list. Then Group Leader and Group Member are the expected roles for organisations within an “OrganisationGroup”.

It was decided to review the model in September.

FrameworkAgreementTechnique Discussion

The discussion started with whether a lot uses frameworkAgreementTechnique in a frameworkAgreement. As the FrameworkAgreement establishes a Technique then a FrameworkAgreementTechnique is ConcludedBy a FrameworAgreement. The inverse property was missing in the model.

The WG agreed on the addition of “epo:concludesFrameworkAgreementTechnique”.

Pending topics for the mappings of current TED Forms:

  • Tender Validity Duration:

During past sessions of WG it was discussed about “SubmissionTerm” attributes, where TenderValidityDuration was deleted and it was only kept the ValidityEndDate with data type Date.

As in the Validity is representing a period, the data type Date was not correct in the model. It was changed to ValidityPeriod. As the period Includes EndDate and DurationMeasure the needs of the mapping are covered.

  • SecurityClearanceTerm:

It was necessary to reformulate the “Deadline” definition for the SecurityClearanceTerm to represent better what is needed and requested by the CA when tendering. The definition was changed to: “The time limit by which the security clearance must be received.”

The meeting ended with a brief discussion about the BDTI

Action Point:

  • To do an exercise for the phases and other needs of the BDTI (Procedure, Proceduretype, Buyer/CPB, Role-Organisation, Location/Address, Nuts, Lot)

Working Group meeting 28/07/2020

Participants 28th: Ana Aido, Paloma Arillo Aranda, Cécile Guash, Giorgia Lodi, Thor Møller, Helder Santos, Giampaolo Sellitto, Roberto Reale, Héctor Rico, Ioannis Rousochatzakis and Enric Staromiejski.

Topic of discussion:

#242 TenderReceivedPerLot

Only acceptable tenders are countable and this is mapped within the "StatisticalInformation". To ensure that the complete information needed is provided, the WG revisited the class and its attributes. Before modifying the attributes the WG agreed that there was no need to add the AcceptableTenderLots as it can be inferred from the operation: TenderReceived - InadmissibleTenders.

Related to "StatisticalInformation" the attributes were renamed to ensure the proper scope. Also definitions were updated according to the changes done to the attributes. The final result for the StatisticalInformation (Attributes rename and definitions) is below:

  • epo:AbnormallyLowTendersLot

  • epo:CleanVehicles

  • epo:EEAReceivedTenderLots

  • epo:ElectronicTenderLots

  • epo:HighestReceivedTenderLotValue

  • epo:InadmissibleTenderLots

  • epo:LowestReceivedTenderLotValue

  • epo:ReceivedMediumTenderLots

  • epo:ReceivedMicroTenderLots

  • epo:ReceivedNONEEATenderLots

  • epo:ReceivedParticipationRequests

  • epo:ReceivedReviewRequests

  • epo:ReceivedSmallTenderLots

  • epo:ReceivedSMETenderLots

  • epo:ReceivedTenderLots

  • epo:TotalVehicles

  • epo:UnverifiedTenderLots

  • epo:ZeroEmissionVehicles

It was agreed:

  • to delete both TotalEstimatedSubcontractedShare and TotalEstimatedSubcontractedShare from Statistical Information and

  • to add definitions for data properties from Subcontract to TenderLot to represent the information.

In the context of “Value”, it was already agreed that CurrencyType is not needed as it is specified by Amount.

Action Point:

  • The mapping of the changes made will be taken into account on eForms mapping to be aligned.

  • To check what has happened with the values and if we are using the correct version of the model (frozen or ongoing) during the WG meetings.

Working Group meeting 23/07/2020

Participants 21st of July: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Héctor Rico, Helder Santos, Giampaolo Sellitto, Enric Staromiejski.

Participants 23rd of July: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Héctor Rico, Helder Santos, Giampaolo Sellitto, Enric Staromiejski.

Topic of Discussion: Pending Actions from the mappings of the current TED forms / Definitions

Both meetings were focused on the discussion of pending action points that arose from the mappings of the current TED forms to the ePO Ontology. The pending actions and the discussions were the following:

  1. SubmissionTerm Deadline to change the definition of the attribute.

    • The class Submission Term was revised and the attributes were made generic to allow the representation of the different Document Types (Tender, Request to Participate, etc)`

    • The definitions of the attributes were changed accordingly.

    • epo:DeadlineRequestToParticipate: DateTime has been removed as it is represented by the epo:ReceiptDeadline DateTime.

  2. To discuss with the WG if the Lot epo:hasContractEstimatedDuration should be ContractEstimatedDuration or ContractDuration.

    • In the mapping of eFoms the attribute hasContractEstimatedDuration Period is only applied to Contract Modification

    • It should be hasEstimatedContractDuration Period for CN and PIN CFC. Other PINs and CAN and Contract modification require further analysis.

    • For the mapping which arose the discussion, F2-2.2.7 Should be Lot hasContractDuration Period

  3. To discuss "How do you account for when a TenderLot has more than one subcontract" (Form 03)

    • It should be done through Statistical Information.

    • By adding TotalSubcontractedValue and the TotalSubcontractedShare to the Class "StatisticalInformation".

    • Also to be checked the mappings in eForms to see whether it was well addressed in the eForms.

  4. Discussion Notice on a Buyer Profile.

    • The WG saw that Notice in a Buyer Profile is a type of PIN.

    • Therefore it should be connected to other PIN or Notices.

    • The WG saw that Document Diagram contains two classes, the first one defining eForms big phases and a second one which contains more granularity “epo:notification-phases-types” (Planning.pin, Competition.pin, etc). However the WG had missed a third more granular level, taking into account the sub-sub-types specified in eForms such as Planning.Pin.BuyerProfile, Planning.PIN.TimeReduction, etc.

  5. Additional Topics:

    • The WG stated the need to check out the relationships between Notice, Document, and Procedure. “notifies” “announces” and “relatesTo” seem to have many domains.

    • "notifies" has three domains: PIN, Document, and Notice. And also three ranges: Procedure, PlannedProcurementPart, and CallForCompetition.

    • The WG proposed to remove "announces" between Document and Procedure, and to add it between Notice and Procedure.

Working Group meeting 16/07/2020

Participants 07th of July: Paloma Arillo Aranda, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Participants 09th of July: Ana Aido, Paloma Arillo Aranda, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Participants 14th of July: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Helder Santos, Giampaolo Sellitto, and Enric Staromiejski.

Participants 16th of July: Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Helder Santos, Giampaolo Sellitto, and Enric Staromiejski.

Topic of discussion: Pending Actions from the mappings of the current TED forms

The approach of 4 meetings was focused in the different actions points came up from the mappings of the current TED forms to the ePO Ontology. The pending actions and the discussions were the following ones:

  1. Values with VAT or without VAT

    • According to the current TED forms all the values are without VAT. However in the ontology that differentiation is not properly modelled.

    • Currently the ontology has three different types of values "Financial Offer Value", "Procurement Value" and "Value". According to latest discussions the WG asked why these three classes are needed.

    • Everis presented a new version of the diagram which only includes the class Value.

    • Everis proposed to create a new codelist which will list different type of taxes.

    • The WG reviewed the attributes of value, they considered a description attribute for the "OtherCharges".

    • The WG decided to do the financial Offer value as a property that links the "TenderLot" with "Value".

  2. To discuss with the WG if epo:hasEstimatedTenderInvitationDate Date should be at the Lot Level. Also the DPS termination (in Procedure we have “CompetitionTermination” and according to its definition it is the same as the “DPSTermination”).

    • The WG decided whether the EstimatedTender… should be at lot level and not procedure level. The WG agreed and then in the ontology we have to include it in the Extension

    • Concerning the DPS (in Procedure we have “CompetitionTermination” and according to its definition it is the same as the “DPSTermination”), we have changed the definition of the CompetitionTermination attribute: No further contracts will be awarded in this procedure. Additional Information: PIN for Competition needs to be signaled. This field can be used even if no contracts are awarded in the contract award notice.

      • The WG decided to remove the note in the DPS termination class.

      • For the mappings the decision was to use the DPS termination.

  3. Winner and how to know its relation with contract

    • Giorgia explained her proposal as resolution of how to know the relation of the winner with the contrat. The proposal is to have a Consortium class in order to be aligned with the W3C Organization ontology. In the W3C ontology Consortium is equal to CollaborationOrganization. However, we can extend the class with our own name that could be "Consortium". The WG agreed.

    • Eo-group type has been linked to the OrganisationGroup (new class).

    • The skos concepts sole contractor lead entity, lead entity, group member and sole contractor , where removed from the eo-role-type code list.

Working Group meeting 02/07/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Roles and Subroles

Everis presented, as an action point assigned to them, another solution on how to map the roles and subroles without having the subroles as properties and also an example to check whether the model based on properties for the subroles works or not. Everis explained that the current solution works and showed to the WG a query example to confirm it. However, this solution needs more works around and everis is proposing to have a reification as a better solution.

The WG also discussed whether the different subroles should be linked to the Agent and not to the Role. The WG also said that if the different subroles are linked to the Agent, we will not know if the subroles is executed by a Buyer or an Economic Operator, for example. The WG said that this always will happen and maybe the best solution will be to have a reification with a taxonomy for the subroles, but rules will need to be defined to control the relationships. The WG still need to discuss further on the different solutions proposed. The WG agreed that the current solution solves the problems for the TED mappings, but the solution difficult to maintain the coherence between the roles and subroles.

Working Group meeting 30/06/2020

Participants: Paloma Arillo Aranda, Giorgia Lodi, Thor Møller, Natalie Muric, Ioannis Rousochatzakis, Juan Carlos Segura Fernández-Carnicero, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of discussion: Roles and Subroles

Everis presented the diagram roles and roles which was updated according to the decision made on the 25th June, to implement the subroles as properties.

Roles and Subroles

Everis expressed its concerns with the temporary solution. Everis indicated that with this solution the same properties have been created for the different roles which complicates the model. Moreover, some disjointness needs to be included in order to say when to use one property or the other one. The WG agrees that the many properties complicates the understand-ability of the model. However, as there is an urgency with the TED mappings for the pilot project the WG agreed to go with this approach, but to make clear that this is a temporary solution. The WG also asked if the temporary solution works. One action point was assigned to everis to provide to the WG an rdf example to see if the model works.

Everis proposed another possible solution which is gathered in this presentation: Roles and Subroles (see slide 4).

Action Point:

  • Everis generate the owl turtle of the roles model.

  • Everis to check if the model works with the new approach.

Working Group meeting 25/06/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Roles and Subroles

The meeting was focused on the everis presentation on how to model the roles and subroles in the ontology. Everis created a presentation (Roles and Subroles) to gather different possibilities on how to model the roles and subroles. The Everis proposal is to create a reification that allows to link the roles and subroles with Lots. A reification is the ability to treat a Statement as a Resource , and hence to make assertions about that statement. A statement may be reified as many different resources, allowing different manifestations (“statings”) of that statement to be treated differently if required.

After the presentation of the everis solution, the WG said that the solution lacks the relationship between the Agent and the new reification class. Everis did not agree because in the end the class agent is a metaclass, and therefore a Role is at the end an agent.

Everis also presented an example in RDF to show how the roles and subroles model should be solved. The WG asked that according to the RDF presented, how the users will know that the Agent is uniquely identified by a role. The WG thoughts that the Agent needs to be linked to the reification. The WG also discussed whether the contact point should be linked or not to the role and agent.

The WG discussed the name of the reification class. The proposed name is "ProcedureRoleActivity". The WG says "ProcedureInvolvement". WG by the moment to use the Cécile solution from last week.

Some other discussions were:

  • It is needed to remove the link between role and contract point.

  • The reification needs to link Agent, role, subrole, lot, and contact point.

Conclusion:

As the everis proposal is not enough clear and needs more discussion, the WG decided to create a temporary solution that is based in to create the subroles as properties that link the different roles to the Lot.

Working Group meeting 18/06/2020

Participants 16th June: Ana Aido, Paloma Arillo Aranda, Maria Font, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, and Giampaolo Sellitto.

Participants 18th June: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of discussion: Roles and Subroles

The OP explains the need to change the roles and subroles due to the mappings of the current TED forms to the eProcurement Ontology. The OP explains that as the model is now, it is not possible to know which subrole (e.g. recipient, execution of the payment, etc.) is playing a role and its participation in a Lot. For that purpose, Giorgia Lodi explained a couple of examples created to solve the situation. After the explanation of the examples, the WG continued discussing and trying to solve the problem with the usage of examples. The following presentation captures some of the possible solutions to the problem. However, the WG did not arrive at an agreement and everis will propose a solution for the next 25th of June.

Roles and Subroles presentation (Roles and Subroles)

It was also suggested to make predicates from the subroles. The predicate "acts on behalf of" between Buyer and Central Purchasing Body is to be removed.

Working Group meeting 11/06/2020

Participants 9th of June: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, and Giampaolo Sellitto.

Participants 11th of June: Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Jalini Srisgantharajh.

Topic of discussion:

During the meeting the following concepts were defined:

  • EstimatedContractNoticeublicatinoDate

  • AcceleratedProcedureJustification

  • ProcedureType

  • AdditionalInformationDeadline

  • CurrencyType

  • AvailabilityDate

  • NonpublicationJustification

  • MainClassification

  • AdditionalCategory

  • ContractNatureType

  • AdditionalContractNature

Submission terms are to apply to lots because all procedures have at least one lot and the terms can be different per lot.

Tender receipt deadline was removed from ProcedureTerm because it is covered by SubmissionDocumentType and SubmissionDeadline in the class SubmissionTerm.

Working Group meeting 04/06/2020

Participants: Ana Aido, Paloma Arillo Aranda, Maria Font, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, and Giampaolo Sellitto.

Topic of discussion: Roles and Functions

The WG discussed a new way on how to model the different roles. Currently, the way to do it is through the class “Function” which is linked to the Agent. This class has a dependency on a codelist named “function-taxonomy” which indicates the function that for example, an organization is executing. The problem identified was that different functions are grouped in the same list and it is very difficult to distinguish which one is executed by an Organisation or by a Buyer for instance. Moreover, some functions can only be executed by one specific role.

In order to propose a new way of modelling the roles and functions, a presentation with a new proposal was created and discussed. The WG agreed on the new way and it will be implemented in the model. This presentation (Roles, Subroles and Regulatory Framework Providers) gathers the final decision, excluding the Evaluator that also needs to be added as a role. The Evaluation board is composed of evaluators.

Topic of discussion:

During the meeting the following concepts were defined:

  • AdditionalActivityType

Action Point:

  • @WG to discuss on the national/international law to be used for the crossborder law. The Core Public Service Vocabulary and the Legal Framework in the CCCEV could perhaps be reused or be sources of inspiration.

Working Group meeting 02/06/2020

Participants: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Jalini Srisgantharajh.

Topic of discussion:

During the meeting the following concepts were defined:

  • epo:Name

  • epo:AdditionalInformation

  • epo:Description

  • epo:Title

  • epo:Justification

  • epo:AbnormallyLowJustification

Concepts and instances were removed from these definitions because concepts and instances are inferred by the semantic world.

The exclusion criterion was removed from Exclusion ground type.

Identifier and classification were removed from the item class and are to be dealt with when dealing with eCatalogue.

Action points:

  • @OP, to relook the AwardCriteria and the AwardDimensionType

  • @WG to check item when dealing with eCatalogue

Working Group meeting 28/06/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Natalie Muric, Thor Møller, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto.

Topic of discussion:

During the meeting the following concepts were defined:

  • epo:AwardCriterionType

  • epo:FixedValue

  • epo:Size

  • epo:JustificationType

Other modelling actions:

  • epo:EOSizeType was moved from EconomicOperator to Business.

  • epo:CountryIdentification class was removed.

Action Points:

  • @OP: To find a definition for the AwardDimension

  • @everis: Use the common definition for the NonAwardJustification

  • @everis: To check some attributes if they are used in TED

  • @everis-ESPD: Definitions for CriterionPropertyGroup

  • @OP:DesignContestRegimeTerm to check definition in TED

  • @OP: To check EOGroupType

Working Group meeting 26/05/2020

Participants 19th May: Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, and Jalini Srisgantharajh.

Participants 26th May: Ana Aido, Paloma Arillo Aranda, Maria Font, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura Fernández-Carnicero, and Giampaolo Sellitto.

Topic of discussion: Procurement Documents Access

During both meetings the WG discussed whether there was a need to have the class Access Terms to indicate the access to some parts of the restricted procurement documents. The WG discussed creating a new class named DocumentCollection whereby all the procurement documents could belong to a collection. This class would have two properties that link the Document collection to the Channel. One of the two would be the property for the restricted access of the Procurement Documents.

The WG discussed the sense to have the Document Collection class or not. The WG also noted that the goal of this class was to remove the relations from an individual document. For that purpose, the WG worked on an example in order to see the differences between a Document and a Document Collection, and if this last one is really necessary. See here the example Document Collection. After the discussing example the WG saw that the DocumentCollection class creates complexity and is not needed.

Moreover, and to detail the discussions that took place in both meetings, the following points were discussed:

  • The WG discussed whether the Access Term and landing page are needed. The WG said that it is needed however some of its attributes should be moved to Procedure (e.g. Additional information deadline should go to Procedure).

  • Landing page is a webpage to indicate where you can find all the documents, and inside you have all documents URLs. This landing page can be always applied to a procurement document.

Working Group meeting 14/05/2020

Participants: Paloma Arillo Aranda Maria Font, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, and Jalini Srisgantharajh.

Topic of discussion:

The WG started the meeting with the discussion of the epo:RectrictedCommunicationJustification which is an attribute of the class Document. The WG analysed where this restriction is used in other classes. For that purpose, the eForms mapping was checked and the epo:RestrictedCommunicationJustification was also used in the AccessTerms. The WG discussed which is the meaning of the AccessTerms and whether these terms should be linked to the Documents since they refer to conditions and stipulations about where and how to access the procurement documents. The only association in the ontology between the AccessTerms and the Documents is through the class Channel. The WG said that through the AccessTerms the only Documents that can be consulted are the restricted ones, but they asked how the full Documents that not restricted can be consulted. For that purpose, the WG made an exercise, through a real case, to see how the model should be. After this exercise the following modelling actions took place:

  • In the AccessTerm class SomeProcurementDocumentsRestrictedJustification the datatype was changed from Text to Code.

  • In the AccesTerms class a new attribute was created ProcurementDocumentLandignPage. This attribute means the internet address for accessing unrestricted procurement documents and replaces the property epo:hasDownloadURL that linked AccessTerms and Channel.

Working Group meeting 12/05/2020

Participants: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Vibeke Engesaeth, Maria Font, Giorgia Lodi, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Jalini Srisgantharajh.

Topic of discussion:

During both meetings the following concepts were defined:

  • epo:FormalOrganization

  • epo:RegisteredOrganisation

  • epo:RecurrenceIndicator (epo:ContractNotice)

  • epo:PreferredPublicationDate (epo:Notice)

  • epo:FormType (epo:Notice)

  • epo:NotificationPhasesType (epo:Notice)

  • epo:NotificationPhasesContentType. The enumeration name, the property and the mapping were changed.

  • epo:DPSUsage (epo:DynamicPurchaseESystemTechnique)

  • epo:DPSCondition (epo:DynamicPurchaseESystemTechnique)

  • epo:ReceptionDate (epo:Document)

  • epo:DispatchDate (epo:Document)

  • epo:UUID (epo:Document)

Working Group meeting 07/05/2020

Participants 5th of May: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Giampaolo Sellitto, Juan Carlos Segura, Jalini Srisgantharajh, and Enric Staromiejski.

Participants 7th of May: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Natalie Muric, Helder Santos, Giampaolo Sellitto, Juan Carlos Segura, and Enric Staromiejski.

Topic of discussion:

During both meetings the following concepts were defined:

  • epo:BuyerLegalType. The concept was renamed by "BuyerType". In addition, the WG added the following information to clarify the roles usage:

"This is the legal form of an agent when it plays the role of the buyer. The reason why this classification is associated to the buyer and not to the agent is that these categories are included in the procurement legislation and to avoid the misunderstanding that these categories define the legal nature of the organisation. This may not be necessarily the case, since the categories refer to the agent exclusively when playing the role of buyer but not to the "legal form" of the buyer."

  • epo:MainActivityType. This attribute was moved to the "Organisation" class since a Buyer that is a role can be the role of an Organisation.

  • epo:ActivityDescription. It was also moved to the Organisation class by the same reasons than the "MainActivityType".

  • epo:BuyerLegalTypeDescription. The WG decided to remove this attribute from the Buyer class since eForms does not use this term for other types of Buyer.

  • epo:Channel

  • epo:endPoint

  • epo:FunctionType

Action Points:

  • @everis to propose definitions for common concepts (Additional Information, Description, endpoint, name, title (see DC terms also for ID))

  • @everis to change in the eForms mappings that endpoint is not anymore URI, it is now text

  • @everis to update mappings for buyer role and main activity

Working Group meeting 30/04/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of Discussion: Buyer Profile

During this meeting, the WG discussed whether the Buyer Profile was needed or if it could be replaced by another existing class. In the course of this discussion the following exchange of ideas were debate:

  • According to the model, a Buyer has a Buyer Profile which is a "Website address where the buyer publishes information on its procurement procedures and general information.". According to this definition, the WG saw clearly that a Buyer Profile is a Channel. With that proposal, the Buyer which is a role and plays the role of an Agent and the Buyer uses the Buyer Profile, which is a Channel.

  • The WG proposed that there is no need to have a URL attribute for the Buyer Profile since the Channel already has a URL.

  • The WG proposed to link the channel and the agent through the property "ownedBy". The WG was inspired by the Core Public Service Vocabulary. This property has to be understood as who is the responsible of the channel.

The WG after a long discussion agreed on the following decisions:

  • Keep buyer profile which is a Channel.

  • We use the buyer profile at the Notification time.

  • After a discussion on the property "ownedBy" the WG decided to keep and added a definition to clarify what OwnedBy means.

Working Group meeting 28/04/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Maria Font, Giorgia Lodi, Thor Møller, Roberto Reale, Juan Carlos Segura Fernández-Carnicero, Giampaolo Sellitto, Jalini Srisgantharajh.

Topic of Discussion:

During the meeting the Working Group was working on the definitions of the following concepts:

  • epo:Agent

  • epo:RegisteredOrganization

  • epo:Business

  • epo:EconomicOperator

  • epo:System

  • epo:PublicOrganisation

  • epo:Person

  • epo:Location

  • epo:OpeningHoursSpecification

  • epo:Period

  • epo:Address

  • epo:Buyer

  • epo:ContractingEntityIndicator (Attribute of the class epo:Buyer)

  • epo:ProcurementServiceProvider

The above concepts can be also consulted in the diagrams "Agent" and "Buyer and Organization", see https://eprocurementontology.github.io/CDM_Report/HTML/index.htm.

Working Group meeting 23/04/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, and Jalini Srisgantharajh.

Topic of Discussion:

During the meeting the followings BTs were discussed: BT-71 and BT-79

Topic of Discussion: Definitions

During the meeting the WG worked on the definitions of the Procurement Criterion. The definition decided for this concept was:

A criterion specific to Procurement.

Additional Information:

This Procurement Criterion can be only Exclusion Ground, Selection Criterion or Award Criterion. Each of these criteria can contain subcriteria (Criterion class).

During the creation of the definition of the Procurement Criterion, the WG detected that the attribute Procurement Criterion Applicability is not needed since it already used in the Selection Criterion and Exclusion Ground.

Action Points:

  • @everis to change the mapping of the Procurement Criterion Appplicability based on its usage in the Seclection Criterion and Exclusion Ground.

Working Group meeting 21/04/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh and Enric Staromiejski.

Topic of discussion:

Action Point:

  • @everis to finalise the definition of the "Function" class with the addition of examples.

Please find below the minutes of the 14th, 15th, 16th and 17th of April 2020:

Participants 14th of April: PAna Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Participants 15th of April: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Participants 16th of April: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Helder Santos, Juan Carlos Segura, and Enric Staromiejski.

Participants 17th of April: Paloma Arillo Aranda, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of Discussion:

Action Points:

  • @everis to finalise the mappings of the BT-08 Organisation Roles for Planning, Competition, Direct Award Prenotification, Result and Contract Modification phases.

  • @everis to complete the functions taxonomy

Working Group meeting 07/04/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Maria Font, Hilde Kjølset, Giorgia Lodi, Thor Møller, Natalie Muric, Timo Rantanen, Roberto Reale, Hector Rico, Marc Christopher Schmidt, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh and Enric Staromiejski.

Topic of Discussion:

Action Point:

  • @everis to check the relationship between Location and Channel.

Topic of Discussion: Evaluation Method Type

The WG discussed the need of whether it is correct to have a code list with pass, fail, weighted. OP explained that the other day there was a discussion where the PASS-FAIL topic was discussed. In this meeting it was suggested contrary to some participants understanding that a tenderer does not have to pass all selection criterion first, a weighting was used to see who passed or fail otherwise there would always need to be a minimal value for the criterion. During the aforementioned meeting it was decided to ask implementers in the ontology group of their thoughts. The opinion in the WG was that a criterion needed to pass the selection criterion first, and the second step in a multi-stage procedure was to apply the weightings to see which economic operators could proceed to the award phase.

As a conclusion of the discussion the WG decided that, for the time being, it does not affect the ontology at this point in time and that the discussion should be passed back for discussion in the ESPD. Marc Christopher agreed to seek a legal opinion on the situation.

Working Group meeting 02/04/2020

Participants 31st of March: Paloma Arillo Aranda, Sofia Berenguer, Cécile Guasch, Laszlo Ketszeri, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, Enric Staromiejski and Arleta Wlodarcyk.

Participants 02nd of April: Paloma Arillo Aranda, Giorgia Lodi, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of Discussion:

Action Points:

  • @everis check code legal-form-type. This code is not in euvocabularies. It comes from a directive. To take in the future.

  • @everis apply similar mapping of the BT-165to BT-706 and BT-746.

  • @everis completation of the mediation body and review body.

  • @everis change the porperties that link Procedure Terms and Organization.

Working Group meeting 26/03/2020

Participants 24th March: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Participants 26th of March: Ana Aido, Paloma Arillo Aranda, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of Discussion:

Action Point:

  • Add attributes to Business from the Core Business Vocabulary

Working Group meeting 19/03/2020

Participants: Paloma Arillo Aranda, Cécile Guasch, Vibeke Engesaeth, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of Discussion:

Registered Organization

OP explained that everis carried out an analysis to identify those classes that have not been used in the eNotification phase. One of these not used classes is RegisteredOrganisation. OP asked the WG if we did not use this class and the WG replied that this class was indirectly used because it is a parent class of the class which is used in Result for example. The RegisteredOrganization class appears on the Agent and Procurement Roles diagrams.

Action Points:

  • @everis: Check that the classes identified as not used are not used indirectly.

  • CG to check on how the term Nationality is defined by the Anti-Money Laundering Directive

Topic of Discussion:

Mappings (Mappings)

The discussion points of the topic can be found on the mappings file in the BT-706 Winner Owner Nationality.

Action Points:

  • @everis: Create an issue in the Core Person Vocabulary asking about how the Nationality of a person is represented.

Working Group meeting 17/03/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Timo Rantanen, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of discussion: Buyer

The WG discussed the issue "topic of discussion" that was created in GitHub and commented. For more details see https://github.com/eprocurementontology/eprocurementontology/issues/237.

In this issue was reflected the discussion that took place in the last meeting. According to Jachym’s reply is possible that Buyer has activities in the Public Sector and Private Sector at the same time. Taking into account this response the WG said that if it is needed to know if the buyer has another activity that is not the one specified in the code list main-activity or other main activity the following ideas were proposed:

  • to call the code list “other main activities” as "NACE".

Also, the property linking the Buyer to the code was named “hasEntityActivity”. Additionally, the WG discussed the need to have two attributes, one for the mainactivity code and the other one for the NACE code. According to the disjointness, this is not possible, we should have just one and then the user selects which code is used. The final decision was to have these two codes and the same predicate with a disjoint to both codes, or the main activity is one or the other one. The attribute in the Buyer class for the codes was named "MainActivityType" code.

Concerning to the attribute in the Buyer class named "OtherActivityDescription", the WG decidedd to rename it “ActivityDescription” and the following note of when this should be used was added in the model:

  • “In the ePO ontology a taxonomy with all activities, based on different classifications (COFOG, UTILITIES, NACE), will be provided. In ePO, this element is to be used exclusively to complement the definition attached to the MainActivityCode. However, in eForms, there is the code "other" to cover undefined activities. For mapping to this eForms feature, one could also use this property.”

Action Points:

  • TR: Provide an example of where a buyer would have difficulty choosing from the codes in the main activity table and where it would be advantageous to use the NACE code.

Working Group meeting 12/03/2020

Participants: Ana Aido, Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Timo Rantanen, Roberto Reale, Giampaolo Sellitto, Helder Santos, Juan Carlos Segura, and Enric Staromiejski.

Topic of Discussion:

Action Point:

@everis: Add a link to the EU Vocabularies where the code list is available and just add three codes the rest no needed. It is just to avoid a lot of work mantaining them. See the buyer diagram.

Working Group meeting 10/03/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Helder Santos, Juan Carlos Segura, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of Discussion:

The following BTs were discussed:BT-768 Contract Framework Agreement

Topic of Discussion:

Old definition

Condition that aims to reduce the environmental impacts of the procurement, fulfil social objectives and/or buy an innovative work, supply or service.

Additional Information: The conditions must be achieved via either technical specifications, selection criteria, award criteria and contract terms.

New definition

Public procurement that contributes to achieving pressing policy goals.

Additional Information: Specific strategic goals could be, for example, environmental protection, innovation, job creation and the development of small and medium enterprises.

Based on https://legalinstruments.oecd.org/en/instruments/OECD-LEGAL-0411 (see paragraph on "background information".

WG Approval 10/03/2020

Topic of Discussion:

Old definition:

Approach whereby public authorities seek to procure goods, services and works with a reduced environmental impact throughout their life cycle when compared to goods, services and works with the same primary function that would otherwise be procured.

Additional Information: Tightly related are article 68 - Life-cycle costing and article 67 - most economically advantageous tender (see GPP handbook) https://ec.europa.eu/environment/gpp/pdf/Buying-Green-Handbook-3rd-Edition.pdf An instance of the class GreenProcurement is represented in eForms with the code "env-imp" defined in the codelist strategic-procurement.

New definition:

Approach whereby buyers seek to procure with a reduced environmental impact.

Additional Information:

The approach may apply to the complete life cycle. The reduced environmental impact is in comparison to goods, services and works with the same primary function that would otherwise be procured.

Tightly related are article 68 - Life-cycle costing and article 67 - most economically advantageous tender (see GPP handbook) https://ec.europa.eu/environment/gpp/pdf/Buying-Green-Handbook-3rd-Edition.pdf

An instance of the class GreenProcurement is represented in eForms with the code "env-imp" defined in the codelist strategic-procurement.paragraphs, https://ec.europa.eu/environment/gpp/pdf/Buying-Green-Handbook-3rd-Edition.pdf

Working Group meeting 05/03/2020

Participants: Paloma Arillo Aranda, Giorgia Lodi, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajh, and Enric Staromiejski.

Topic of Discussion:

The working group checked that the eForms issue 329 was correctly implemented in the eProcurement Ontology it was concluded that the implementation met the requirements.

Topic of Discussion:

The WG checked the reply from eForms and according to it. The WG said that the mapping was performed properly so no further actions were needed concerning the mapping in ePO. However, from this discussion the following modeling actions took place:

  • The attributes of the StatisticalInformation class refer to the TenderLot. This is concluded from the fact that the eForms statistical information is aggregated from the + Notice Result; BG-137 Procedure Lot Result; + BG-712 Received Submissions; ++ BG-320 Tender. Therefore the attributes have been renamed in order to clarify that they refer to TenderLot.

Action Points:

  • @everis - Add TenderLot in the attributes of the Statistical information class.

Working Group meeting 03/03/2020

Participants: Ana Aido, Paloma Arillo Aranda, Sofia Berenguer, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajah and Enric Staromiejski.

Topic of Discussion:

The following BTs were discussed: BT-541, BT-5421, BT-5422, BT-5423, BT-543, BT-752, BT-7531 and BT-7532

Action Points:

  • @everis - change the mapping according to new agreements on selection criterion and that affects to the award criterion: "The WG discussed about the attributes of the "criterion" class. The WG decided to remove those attributes that are not used in ePO (e.g. Objective attribute). Since the CCCEV is not finalised the WG analysed the attributes of the Criterion class and it was decided to move them to Procurement Criterion, Selection Criterion, Award Criterion, they can be moved to the CCEV later if necessary.

  • @WG - Pay visit to the UBL communication channel

Working Group meeting 27/02/2020

Participants: Ana Aido, Paloma Arillo Aranda, Sofia Berenguer, Jerry Dimitriou, Maria Font, Cécile Guasch, Giorgia Lodi, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, and Enric Staromiejski.

Topic of Discussion:

Topic of Discussion:

Mappings (Mappings)

The following Business Terms were discussed: BT-748, BT-40

Working Group meeting 26/02/2020

Participants: Paloma Arillo Aranda, Sofia Berenguer, Giorgia Lodi, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto

Topic of Discussion:

Discussion Procurement Criteria Discussion Procurement Criteria

In order to finalise the mapping, an extra meeting was needed with the OP and some WG members to discuss the Selection Criteria. During this meeting a way on how to model and map the Selection Criterion, whether using CodeLists or representing the subcriterion as subclasses of the Selection Criterion class.

Action Point:

  • @everis, to create two diagrams. One includes code lists and the other one the subcriteria are represented as subclasses.

Working Group meeting 25/02/2020

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellitto, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of Discussion:

The following Business Terms were discussed: BT-67, BT-747, BT-748, BT-749, BT-750, BT-40

Action Points:

  • @everis, @OP, @WG: Extra session to discuss how to map the selection criterion.

Working Group meeting 20/02/2020

Participants: Paloma Arillo, Giorgia Lodi, Thor Møller, Natalie Muric, Claudia Ribeiro, Juan Carlos Segura, and Enric Staromiejski.

Topic of Discussion:

Action Point:

  • @everis: Remove all those classes and properties that come from external vocabularies and are not used in ePO.

Working Group meeting 13/02/2020

Participants: Vibeke Engesaeth, Cécile Guash, Giorgia Lodi, Jade Maana, Thor Møller, Natalie Muric, Roberto Reale, Giampaolo Sellitto and Enric Staromiejski.

Topic of Discussion:

Mappings (Mappings)

The approach of the meeting on the 13th of February was focused on the pending mappings of the Result Phase. The following Business Terms were discussed:757, 165, 706, 746, 151, 774, 775, 776, 715, 725, 716, 712, 635, 636, 634, 756, 195, 197, 196, 198

Working Group meeting 11/02/2020

Participants: Paloma Arillo, Vibeke Engesaeth, Cécile Guasch, Giorgia Lodi, Juan Carlos Segura, Natalie Muric, Giampaolo Sellito, Jalini Srisgantharajah, and Enric Staromiejski.

Topic of Discussion:

Topic of Discussion:

Mappings (Mappings)

The WG checked which the pending mappings to be discussed are. Everis proposed to discuss the BT-34 Recurrence (see the corresponding mappings and decisions [here](https://github.com/eprocurementontology/eprocurementontology/tree/v2.0.1/v2.0.1/03-Analysis%20and%20design/Mappings)).

Working Group meeting 26/02/2020:

Participants 4/02/2020: Cécile Guasch, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Giampaolo Sellito, Jalini Srisgantharajah, and Enric Staromiejski

Participants 06/02/2020: Paloma Arillo, Ana-Maria Babaligea, Vibeke Engesaeth, Giorgia Lodi, Thor Møller, Natalie Muric, Juan Carlos Segura, Giampaolo Sellitto and Enric Staromiejski.

Topic of Discussion:

Action Point:

  • @everis: Change the mappings between the ontology and the eForms according to the proposal on procurement roles and the cagv: Agent. Try to be pragmatic. We need something urgent for discussion where the properties required by eForms can be clearly identified.

  • @everis: Modify the diagrams with the inclusion of the new approach of agent and roles.

  • @everis: Modify the mappings according to the new approach of Organization and agent classes.

Topic of Discussion:

Action Point:

  • WG: Rediscuss assets after maturity of DCAT

Topic of Discussion:

Mappings (Mappings)

The WG checked the mappings in order to see what is pending and what is needed to be discussed after the new agreements took during the last WG meetings (roles, organization, planning, etc.).

Working Group meeting 30/01/2020:

Participants: Paloma Arillo, Ana-Maria Babaligea, Cécile Guasch, Giorgia Lodi, Vibeke Engesaeth, Natalie Muric, Roberto Reale, Giampaolo Sellito, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The approach of the meeting on the 30th January was focused on the continuation of the discussion of the everis’ proposal regarding the “Agent” class.

Everis and OP shared with the WG a copy of the old and new Buyer version as well as a view of the agent diagram that it is suggested to replace the organisation diagram, along with the organisation diagram. The WG used the occasion to discuss the email sent by Georgia regarding the usage of “Agent” and/or the “Organisation” classes and some doubts raised up after her analysis.

The WG proposes to have a base class that inherits from Agent which represent the legal status. This coul be a legal entity since att the end a legal entity can be an organization. However, in ePO we need to represent also a system and therefore it can not be considered a Legal entity.

The WG discussed what is a “ProcurementServiceProvider”. The WG said that a good example of it is an eSender and it can act on behalf of Buyer. This clarification raised up a discussion about the usage of “role” properties. The WG explained that we did not focus on processes during the development of the ontology and we did not use roles. Now the problem is what happens when a buyer is an agent. In order to solve this problem, everis proposed to use the property "isA" instead of to use "Role". Moreover, another proposed solution was to create a role class that could act as the role of the buyer, and therefore, there is no need to use the property role. The WG created a new diagram to reflect the different possible solutions proposed.

After the reflection, the WG decided to create the new class “Role” which is an abstract class. In addition, it was point out that an abstract class organisation role was needed between the different classes ie “buyer” and “agent” to allow an organisation in different cases to be either buyer or economic operator without having to have its information introduced twice and therefore leaving open the opportunity for error conflicting information.However, this approach is still under discussion.

The picture below shows an example created for the reflection analysis whether to create or not a role class:

Role class diagram

And here the new diagram created for the discussion of the procurement roles:

Procurement roles diagram

Action Points:

  • @everis: Presentation in the F2F meeting about old discussions regarding “Buyer”.

  • @everis: Attention to abstract classes role and agent need to paid when substantiating.

Interesting links shared during the meeting:

Working Group meeting 28/01/2020

Participants: Paloma Arillo, Ana-Maria Babaligea, Cécile Guasch, Giorgia Lodi, Vibeke Engesaeth, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The approach of the meeting on the 28th January was focused on the everis’ presentation regarding the “Planning” mappings and the “Agent” class.

Everis started the meeting explaining its proposal for Planning. Everis explained that the problem discovered doing the mappings to eForms is that some classes cannot be mapped through the PlannedProcurementPart class and therefore the mapping goes through the Procedure in order to arrive to the Lot. A disjoint has been added between the property that links the PIN with the Procedure and the property that links the PIN with the PlannedProcurementPart. Regarding these possible options of the mappings (through the PlannedProcurementPart or Procedure) the WG worked in the following rule in order to know when to go from one or from the other one:

  • In PIN Time-limit the Notice will contain a reference either to PlannedProcurementPart or conversely to Procedure (both are disjoint, see also the diagram Planning). This implies that for PIN Time-limit it is necessary first to discern the existence of one of these classes to know how to get to specific information. For example, some ContractTerms properties like PlaceOfPerformance could be reached either starting from PlannedProcurementPart or through the Lots linked to the Procedure.

Once the Planning mapping proposal was approved by the WG, the second half of the meeting was focused on the everis presentation of the usage of “agent” class instead of the “organization” class. Everis explained that we need to have an “agent” class in ePO which should be an extension of an Agent class of a Core Agent Vocabulary from SEMIC. Everis explained that this Core vocabulary does not exist yet, but as everis is now contractor of SEMIC for the maintenance and evolution of some core vocabularies, they want to propose it. Everis explained that this new vocabulary is needed since the FOAF one does not allow proper reuse for ePO. The FOAF Agent class does not have a very good level of granularity in terms of properties and therefore a new Agent vocabulary would extend the FOAF agent class with more properties.

Everis explained that they are proposing to use the Agent class instead of the organization because in ePO there is the need to represents not only Organizations, also Persons and systems. This proposition was more or less approved by the WG, however, they need that everis shares an example where the class Organization was used in the past and where the Agent class is used now.

Action Points:

Working Group meeting 21/01/2020

Participants: Ana-Maria Babaligea, Cécile Guasch, Giorgia Lodi, Vibeke Engesaeth, Natalie Muric, Roberto Reale, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

During the meeting on the 21st January the following discussions took place:

  • Everis presented its proposals on the Qualification System and how it should be mapped:

    • After a discussion about the QS and how it should be understood, the WG decided to put in on hold and not to go on the mapping of the QS until an explanation on how a QS works is addressed to and answered by DG GROW: Action Point: for OP and everis: forward an email to Isabel da Rosa asking regarding QS:

      • Definition

      • The data flow

  • The WG checked that the approach followed by everis for the mapping of the eForms and ePO on DAP (Direct award pre-notification) seems correct and agreed that everis can go on with the mapping.

    • The WG worked on the definition of the Voluntary Ex-ante Transparency Notice: Voluntary Ex-ante Transparency Notice: A notice informing of the intention to award a contract without prior publication of a contract notice. Additional Information: For European notices above the threshold "A means of advertising the intention to award the contract without opening it up to formal competition. A contracting authority may decide that a contract does not require prior publication through a contract notice in the O.J.E.U. A reason for this decision may be that the contract meets the exceptional conditions described in Article 31 of Directive 2004/18/EC. In a recent V.E.A.T notice the reason was listed as “extreme urgency brought about by events unforeseeable by the contracting entity and in accordance with the strict conditions stated in the Directive” . "Voluntary Ex-Ante Transparency Notice" (VEAT) where a contracting authority deems that a contract does not require prior publication of a contract notice in the European Journal (OJEU). This may apply, for example, if the contract meets the exceptional conditions justifying direct award of contracts.

This definition is still to be worked on.

  • The WG reviewed the definitions provided by everis related to strategic procurement:

  • The WG came up with the definition on Green Procurement, based on the one coming from the COMMUNICATION FROM THE COMMISSION TO THE EUROPEAN PARLIAMENT, THE COUNCIL, THE EUROPEAN ECONOMIC AND SOCIAL COMMITTEE AND THE COMMITTEE OF THE REGIONS (https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:52008DC0400&from=EN): “Approach whereby public authorities seek to procure goods, services and works with a reduced environmental impact throughout their life cycle when compared to goods, services and works with the same primary function that would otherwise be procured.”

Action Point:

Action Point:

  • for WG review the above mentioned issues in preparation for next Tuesday’s 28th meeting.

Working Group meeting 16/01/2020

Participants: Paloma Arillo-Aranda, Ana-Maria Babaligea, Cécile Guasch, Giorgia Lodi, Thor Møller, Natalie Muric, Roberto Reale, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

20200116

Working Group meeting 14/01/2020

Participants: Paloma Arillo-Aranda, Ana-Maria Babaligea, Cécile Guasch, Giorgia Lodi, Natalie Muric, Giampaolo Sellitto, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

20200114

Working Group meeting 09/01/2020

Participants: Paloma Arillo-Aranda, Giorgia Lodi, Vibeke Engesaeth, Thor Møller, Natalie Muric, Roberto Reale, Giampaolo Sellitto, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The meeting on the 09th of January was focused on the mapping of the CAN in the “Result” stage.

The following table shows the BTs mapped as well as how it is represented in the ePO EA file. All the mappings can be consulted in the “Result” diagram:

20200109

Working Group meeting 07/01/2020

Participants: Paloma Arillo-Aranda, Giorgia Lodi, Vibeke Engesaeth, Thor Møller, Natalie Muric, Roberto Reale, Giampaolo Sellitto, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The meeting on the 07th of January was focused on the mapping of the CAN in the “Result” stage.

The following table shows the BTs mapped as well as how it is represented in the ePO EA file. All the mappings can be consulted in the “Result” diagram:

Results

Other comments:

  • NM and ES summarised the work performed until today. NM asks ES which is the status of the Planning. ES explained that it is 90% done, he needs a couple of days to finish.

  • ES also explained that 2 new packages have been created for the representation of the IFLA model in ePO.

  • NM proposed to have the F2F meeting on the 3rd March, the 17th and 18th June, and 25th and 26th November.

Action Points:

  • Everis: check where DAP and QS are unique in eForms for Thursday 9 January.

  • Everis: Come up with a proposal on how to model the DAP and QS for Tuesday 14 January.


Any comments on the documentation?