Cumulative content of Working Group Meetings in 2019

Working Group meeting 19/12/2019

Participants: Paloma Arillo Arranda, Ana-Maria Babaligea, Cécile Guasch, Thor Møller, Natalie Muric, Roberto Reale, Giampaolo Sellitto, Juan Carlos Segura and Enric Staromiejski.

The meeting from 19th of December 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:

Result

Working Group meeting 17/12/2019

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

The meeting from the 17th of December was focused on the mapping of the CAN in the “Result” stage.

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

Result

Other comments:

  • The diagrams are partial views of the ontology.

  • The evaluation report is the class that links the award decision and the tender. Instead of using to use the Evaluation Report, the WG decided to create a relationship that links the AwardDecision and the Tender Lot (see the new diagram)

Action Points:

  • Everis: Some attributes of the class “statistical information” have to be split. We need to make a break-down task.

  • Everis: According to the Naming and Design Rules, the object “properties” should be in past. The WG decided to leave it in present and not in past. However, this has to be reflected in the document of the rules.

  • Everis: Create an issue in eForms asking if they are talking about any tender or only the winning tender.

Working Group meeting 12/12/2019

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

The meeting of the 12th December was focused on the mapping of the CAN in the “Result” stage. Natalie Muric explained that this morning Juan Carlos and herself were working on all the BTs with data type value in order to see how they should be mapped.

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:

Result

Action points:

  • Everis: Disjoint between hasAwardedValue and hasAwardedMaximumValue, as well as, a disjoint between hasAwardedValue and hasAwardedEstimatedValue is needed.

  • Everis: Suggest solutions for the division of inadmissible tenders, abnormally low tenders and the SMEs as there are some incoherencies.

Working Group meeting 10/12/2019

Participants: Paloma Arillo Aranda, Ana-Maria Babaligea, Thor Møller, Natalie Muric, Juan Carlos Segura and Enric Staromiejski.

The meeting of the 10th December was focused on the mapping of the CAN in the “Result” stage. Natalie Muric explained that this morning Juan Carlos, Thor, Giorgia and herself were working on all the BTs with data type value in order to see how they should be mapped. Natalie showed and explained the mappings came up from that analysis session. Natalie remarked as the main output of this session the fact that we created sub-properties of properties. The properties created are sub-properties of the properties Document “relates To” Procedure. These sub-properties are different in each phase:

  • In the case of a Planning form, this sub-property notifies is used.

  • In the case of Competition form, this sub-property announces is used.

  • In the case of Result form, this sub-property summarises is used.

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:

Result

Other comments:

  • The WG decided to remove the property “hasCeilValue” that linked Procedure and Procurement Value because it is not used anymore in eForms.

Meeting from 05/12/2019:

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

The meeting of the 5th December was focused on the mapping of the CAN in the “Result” stage. Everis presented an analysis performed regarding the Procurement Values. The purpose of this analysis was to identify whether the properties that link different classes to the class “Procurement Value” are used or not, and in which phase there are used. This analysis was required due to the same properties are used to link different classes to the class “Procurement Value”. The results of the everis’ analysis are the following ones:

  • Lot hasAwardedValue ProcurementValue

  • BT eForms: Not used

  • Stage: Not used

  • Lot hasFrameworkMaximumValue ProcurementValue

  • BT eForms: Not used

  • Stage: Not used

  • Lot hasEstimatedUserConcessionRevenue ProcurementValue

  • BT eForms: BT-162 (Pending)

  • Stage: Result

  • Lot hasEstimatedBuyerConcessionRevenue ProcurementValue

  • BT eForms: BT-160 (Pending)

  • Stage: Result

  • Lot hasEstimatedValue ProcurementValue

  • BT eForms: BT-27

  • Stage: Competition

  • FrameworkAgreement hasAwardedValue ProcurementValue

  • BT eForms: Not used

  • Stage: Not used

  • Procedure hasCeilValue ProcurementValue

  • BT eForms: Not used

  • Stage: Not used

  • Procedure hasGlobalEstimatedValue ProcurementValue

  • BT eForms: BT-27

  • Stage: Competition

  • GroupLot hasEstimatedValue ProcurementValue

  • BT eForms:

  • BT-27

  • BT-157

  • Stage: Competition

  • GroupLot hasFrameworkMaximumValue ProcurementValue

  • BT eForms: Not used

  • Stage: Not used

  • ProcurementValue hasOverallAmount Value

  • BT eForms: Not used

  • Stage: Not used

  • ProcurementValue hasMinimumAmount Value

  • BT eForms: Not used

  • Stage: Not used

  • ProcurementValue hasMaximumAmount Value

  • BT eForms: BT-157

  • Stage: Competition

  • ContractAwardNotice hasTotalFrameworkValue ProcurementValue

  • BT eForms: BT-118

  • Stage: Result

  • ContractAwardNotice hasTotalValue ProcurementValue

  • BT eForms: BT-161

  • Stage: Result

During the meeting, the WG discussed the difference between Maximum Value and Estimated Value and whether the Maximum Value was needed or not. This discussion came up because according to the new eForms regulation, the maximum and estimated value are used as equals. Before, eForms used the two terms differently. After the discussion, the WG decided to remove the properties “hasFrameworkMaximumValue” and a new definition for the property “hasEstimatedValue” was created:

A forecast of the value of the procurement before competition.

Additional Information Different cases of estimated values may refer to a lot, the global value of the procedure, or of a combinatorial value of a group of lots. The forecast is calculated by the buyer and covers all revenues whether coming from the buyer or third parties. See for example recital (19), Article 5 of Directive 2014/24/EU and other articles from the rest of Directives about procurement.

In the case of framework agreements and dynamic purchasing systems, this refers to the maximum estimated value.

Action point:

  • Everis to add references to other Articles.

Finally, the WG decided to have 2 extra-sessions (09th and 10th December) in order to check all the BTs that are data type value and see how they should be mapped.

Meeting: 03/12/2019

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

The meeting of the 3rd December was focused on the mapping on 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:

Result

Discussions continued on the other value data types in the result forms. There was some confusion about the eForms business terms BT-660 Framework estimated value, BT-27 Estimated value and BT-660 Framework Estimated Value. To this end it was decided to create a github issue: https://github.com/eForms/eForms/issues/329 and Everis was asked to check the different properties associated with the procurement value for the next meeting.

Meeting: 28/11/2019

Participants: Paloma Arillo Aranda, Ana-Maria Babaligea, Cécile Guasch, Natalie Muric, Roberto Reale, Giampaolo Sellito, Juan Carlos Segura and Enric Staromiejski.

The meeting of the 28th November was focused on the mapping on 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 consult in the “Result” diagram:

Result

Meeting: 26/11/2019

Participants: Ana-Maria Babaligea, Giorgia Lodi, Natalie Muric, Giampaolo Sellitto, Roberto Reale, Juan Carlos Segura and Enric Staromiejski.

The meeting of the 22nd November was focused on the mapping on the CAN in the “Result” stage. Work commenced on mapping BT-161 and BT-118 and how to treat the aggregation of the different lots per notice, the work will continue in the next meeting. The following table shows the BTs mapped as well as how it is represented in the ePO EA file. All the mappings can be consult in the “Result” diagram:

Result

Meeting: 22/11/2019

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

The meeting of the 22nd November was focused on the mapping on 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 consult in the “Result” diagram:

Result

Meeting: 21/11/2019

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

The meeting of the 21st November was focused on the mapping on the CAN in the “Result” stage. OP explained that the mappings are only related to those BTs that only apply to the “Result” stage and therefore were not covered during the mappings on the “Competition” 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 consult in the “Result” diagram:

Result

Other actions:

  • Codelist legal-regime, the code "none" has changed into "standard". The definition too has changed to adapt it to the concept "standard" legal-regime.

Meeting: 12/11/2019

Participants: Paloma Arillo Aranda, Cécile Guasch, Thor Moller, Natalie Muric, Giampaolo Sellitto, Juan Carlos Segura and Enric Staromiejski.

The meeting of the 12th November was focused on two topics: Mapping of the Planning stage and IFLA presentation related to the versioning.

Everis started the meeting with the mappings performed internally. Everis explained that those cases where the Lot and Procedure are needed for the mapping, they have been indicated in the mappings file. Enric also explained that he talked with Marc Christopher Schmidt from DG GROW regarding the use of Procedure in the Planning Stage. As a conclusion of the call, Marc Christopher proposed to create an issue. Everis agreed with the WG, proposed to create an issue in the eForms GitHub platform in order to clarify the situation detected. The WG agreed that it is also needed to understand whether the purpose foresee, or not, planned procurement as well as procurement and lots.

After the mapping status explanation, Enric continued the meeting with the IFLA presentation related to the versioning. Enric indicated that regarding the versioning, LEX has 2 types of versions: (1) Multi-version and (2) Single version. However, Enric indicated that in ePO the idea is to have only 1 version, a single version which means a new distinct object per version. This new object contains classes explicitly designed to indicate which parts of the documents have change, how, the reason, etc.

Enric continued the presentation explaining the kind of versioning used in LEX and the proposal for ePO:

  • LEX

    • Current: in-force version

    • Self: this version

    • Next: next version

    • Previous: previous version

    • First: Original version

  • ePO

    • Current: in-force

    • Previous

Enric proposed the following identification of the version in ePO:

  • CEN/BII (CEN TC440) versioning policy → MajorVersionID.MinorVersionID.BugFixingID

After the versioning explanation, the meeting was focused on how to represent the attributes and properties in the ontology. This discussion came from the need of to have naming and design rules. Everis will work on the definition of the naming and design rules for ePO.

Meeting 11/11/2019

Participants: Vibeke Engesaeth, Cécile Guasch, Thor Moeller, Natalie Muric, Giampaolo Sellitto, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The meeting of 11th November was focused on the mapping of the PINs in the Planning phase.

Everis explained to the WG the situation detected during the mapping performed. During the mapping, Everis detected that the new regulation says that the “Procedure” in some cases is optional and mandatory, and therefore this creates confusion since in the Planning phase the Planned Procurement Part should be used instead the Procedure. The same situation happens with the Lot which force us to make the mapping through Lot class.

According to the situation explained by Everis, the WG decided to work in some BTs in order to find a solution. The WG took the BG-2 Purpose. The definition says: “the Information about the purpose. This information must be given for the whole procurement procedure and, if they exist, also per lot. In case of a prior information notice used only for in¬formation, this information may differ per part of the notice that may later become a lot or a self-standing procedure”. The WG said that this definition should also make reference to the Planned Procurement Part and not only to the Procedure and lot.

Meeting 07/11/2019

Participants: Paloma Arillo Aranda, Ana-Maria Babaligea, Vibeke Engesaeth, Cécile Guasch, Thor Moeller, Natalie Muric, Juan Carlos Segura, Jalini Srisgantharajah and Enric Staromiejski.

The meeting of 7th November was focused on the second part of the presentation about how to reuse the FRBR model. The first presentation took place on 22nd October. Both presentations were made by Enric Staromiejski.

The presentation started highlighting the importance of understanding what is meant by the elements “Resource” and “Asset”. Enric came to the WG with two possible definitions for both terms. However, as they were not clear enough the WG worked on a new ones:

  • Resource:

  • Enric’s proposal: a thing, possibly resulting from a work, that is available for its use

  • WG definition: a well identified thing available for use Are you sure the word "thing was in the final definition? What is more I see nothing on resource and asset in the slides Enric sent after the meeting. I know he was writing on the screen do you have a copy of this?

  • Asset:

  • Enric’s proposal: a valuable resource resulting from a work

  • WG definition: a resource resulting from a work possibly bringing value

After the decision of the definitions for Resource and Asset, Enric explained that during the analysis reusing the IFLA LRM specifications 2 challenges were encountered:

  1. How the ePO concept of “Document” can be implemented as an “information resource” in contrast to the “bibliographic resource”; and

  2. How to implement “a volume resource” that aggregates or collects different “Documents”, e.g. a VCD (Virtual Company Dossier) containing different types of evidences.

Enric explained that in order to reuse the IFLA model new concepts have to be introduced or re-define some of the existing ones. The concepts detected were “Resource”, “Asset”, “Information”, “Document”. The definitions of them have been discussed and new definitions have been created. Note that this concepts have to be represented in the ePO models accordingly:

  • Resource: a well identified thing available for use.

  • Asset: A resource resulting from a work possibly bringing value.

  • Information resource: data, in a context of use. Additional information: in the case of electronic information resources they are accessible via a unique identifier. Why are there 2 IRs there should be only one –

  • Information resource (IR): a set of interrelated data, in a context of use, that is accessible via a unique identifier. Additional Information:

    • The context refers to (source 2009 DAMA International©,

    • The Business meaning of data elements and related terms,

    • The format in which the data is presented,

    • The time-frame represented by the data,

    • The relevance of the data to a given usage,

    • The content retrieved from an information resource is to be considered an “Assset”. Thus, metadata on the provenance, authoring, versioning, etc., is also retrievable/accesible through the information resource.

    • Examples of IRs are “a VCD exchanged via an electronic system”; “a de-referenceable URI returning an electronic certificate on the financial standing of an economic operator”;

  • Document: an information resource conveying a set of interrelated business information. Additional Information: examples of Documents within public procurement are: A Contract Notice, an ESPD Request, an electronic certificate such as a certification about the Qualification of an Economic Operator, an eInvoice, etc.

After the creation of the new definitions, and due to not enough remaining time available, Enric explained briefly the rest of the presentation. Enric showed to the WG how the ePO “Information Resource” is implemented:

Information Resource

The WG said that this way to represent the concepts is difficult to understand and representing the same concepts and model using our methodology would be better. Everis agreed to do so.

Enric indicated very briefly the “aggregate” element which has to be understood as “a manifestation embodying multiple expressions”, and exist three types of aggregates:

  1. Aggregate Collection of Expressions,

  2. Aggregates Resulting from Augmentation, and

  3. Aggregates of Parallel Expresions.

Enric explained that the modelling of aggregates as a manifestation embodying multiple expressions is simple and straightforward; works and expressions are treated identically regardless of their form of publication or the physical manifestation in which they are embodied. An expression may be published alone or it may be embodied in a manifestation with other expressions.

The next concept explained by Enric are the “serials” modeled by the IFLA LRM. Serials, according to IFLA, are complex constructs that combine whole/part relationships and aggregation relationships.

To finalize the meeting, Enric showed two couples of examples on how to implement collection and how to implement aggregate manifestations in OP’s CDM.

Meeting 05/11/2019

Participants: Paloma Arillo Aranda, Ana-Maria Babaligea, Vibeke Engesaeth, Cécile Guasch, Thor Moeller, Natalie Muric, Juan Carlos Segura, Enric Staromiejski.

The meeting on 5th November was focused on to work on the pending definitions of some concepts(classes and attributes).

The concepts worked were the following ones:

Concepts

Meeting 31/10/2019

Participants: Paloma Arillo Aranda, Vibeke Engesaeth, Cécile Guasch, Natalie Muric, Roberto Reale, Juan Carlos Segura, and Enric Staromiejski

The meeting of 31th October focused on two topics: the updated solution presented in the last WGM 29th October about the mapping of the competition phase for PINs and CNs, and on how to model the “notice-type”.

During the first part of the meeting, everis presented a solution on how to model the “notice-type”. The first everis proposal for to model the “notice-type” is to rename the code list as “notification-phases-content-types” implying that depending on the phase of notification, the content type of the document would be different.

The second proposal was about how to determine the exact content provided by the information resource (epir, explained in the IFLA presentation last 22nd October) for Competition. For this, 4 steps were detected:

  1. Determine the notification phase, either (or both consistency rule):

  2. Determine the “root element” in the Notification, either (or both  consistency rule):

  3. Determine the exact type of content (RULES and QUERIES), e.g., to test the content is from a PIN CFC Social → all the steps above, plus:

    • PIN isA Notice,

    • PIN notifies Procedure,

    • Procedure hasID Identifier=XXXXXX,

    • Procedure isAbout LegalRegime=light-regime

  4. Test the existence of a specific element, e.g. “BT-740 Buyer Contracting Entity”

    • PIN isA Notice,

    • PIN notifies Procedure,

    • Procedure has Buyer,

    • Buyer hasContractingEntity Indicator,

    • Procedure hasLegalBasisID URI=DIR23_URL

After the proposal on how to model the “notice-type”, Everis presented to the WG the updated solution presented in the last WGM. (29th October) of an updated mapping of the competition phase for PINs and CNs. An example of the mapping:

Mapping example

The WG accepted the proposal and Everis will continue working in the Planning phase.

NM is to update the eForms side of the table to include any changes brought about by the Commission Implementing Regulation EU 2019/1780 by creating a new file to which Everis will add the existing mappings.

To end the meeting, OP proposed to move some scheduled meetings. The meeting for the 14th November was moved to the 11th November (14:30-16:30) due to the Commission EXEP meeting and the meeting of the 19th November was moved to 22nd November (13:00-15:00).

Meeting 29/10/2019

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

The meeting of 29th October was focused on an Everis solution about how to map the Competition phase for PINs and CNs.

The Everis proposal was based on the PIN CFC general and CN general and check that every term was mapped within the CN diagram. Only PIN CFC general CN general were mapped in order to show to the WG an example of how to do the mapping.

It was proposed to rename the Contract Notice diagram as Competition since the mapping is for the CNs and PINs of the Competition phase. Likewise, per each phase a diagram is needed.

Everis explained that during the mapping 3 different cases were detected: (1) There are not too many differences between the CNs mapped previously and the PINs, at least in the Competition phase; (2) Some business rules are needed. For instance, when the terms are only used in CN and not in PIN; (3) Some cases where the term is used in the PIN and not in the CN, it needs to be mapped within the diagram (Everis made a proposal on how to map the detected ones).

After some comments from the WG attendees some action points were defined:

  1. Everis: Update our solution to the latest version of the NM excel file (new eForms regulation);

  2. Everis: Mapping of the rest of PINs and CNs for Thursday;

  3. Everis: Proposal on how to model the notice type.

Meeting 24/10/2019

Participants: Ana-Maria Babaligea, Enrico Francesconi, Cécile Guash, Natalie Muric, Juan Carlos Segura and Enric Staromiejski.

The meeting of 24th October was focused on the analysis of the Legal Resource class which is being used in the ePO Ontology. The meeting started discussing the problems that could have using the class Legal Resource which is reused from the European Legislation Identifier (ELI). According to the participants, there is not a legal obligation for the creation ELI in Member States and therefore there is no obligation to use it. The working group was advised against using the ELI ontology class as it is outside the domain of eProcurement and therefore not the responsibility of the eProcurement ontology, however using an URI that could contain the ELI identifier was considered a good option. The WG decided to remove the class and add an attribute Legal Resource URI in the classes Procedure and Planned Procurement Part. This attribute will cater for triples like:

  • epo:Procedure epo:hasLegalBasis xsd:URI

  • epo:PlannedProcurementPart epo:hasLegalBasis xsd:URI

OR

  • Procedure eli:local_id URI (which can be AnyURI or a String, ELI Strongly recommended when existing in the MS)

  • PlannedProcurementPart eli:local_id URI

Meeting 22/10/2019

Participants: Ana-Maria Babaligea, Cécile Guasch, Thor Moeller, Natalie Muric, Juan Carlos Segura and Enric Staromiejski.

The meeting on 22/10/2019 was focused on the analysis of the IFLA’s FRBR model and how it can be reused in the ePO Ontology. This analysis and presentation was carried out by Enric Staromiejski based on the Enrico Francesconi’s presentation that took place in the last F2F meeting in Luxembourg with all Working Group Members.

The FRBR defines 4 levels of abstraction:

  1. Work

  2. Expression

  3. Manifestation

  4. Item.

These 4 levels are aspects of the Bibliographic Resource element defined in the IFLA model.

Taking into account the IFLA’s model, Enric proposed to have different classes/entities that can be mapped to FRBR. These ones are:

  • eProcurement Information Resource (ePIR)

  • eProcurement Document

The ePIR could be described by Metadata organized into FRBR model. However, a distinction between the taxonomy of ePIRs and the relation of each ePIR to classes of the FRBR model is needed.

In ePO, the ePIR would represent the Bibliographic Resource element that is used in the FRBR model. Therefore in ePO we will have ePIR= Work+Expression+Manifestation+Item. We keep the 4 levels of abstraction and there are also aspects of the ePIR. The reutilization of the FRBR in ePO could be as follows:

20191022

Any comments on the documentation?

Click here to let us know