Cumulative content of Working Group Meetings in 2022

Working Group meeting 13/12/2022

Date: 13/12/2022
Participants: Thor Steinar Møller, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Procedure types and sub-types

Discussion

What is a two-stage procedure (Directive 24)

Article 84: This might in particular be the case in two-stage procedures – restricted procedures, competitive procedures with negotiation, competitive dialogues and innovation partnerships - in which the contracting authorities make use of the possibility to limit the number of candidates invited to submit a tender. Requiring submission of the supporting documents at the moment of selection of the candidates to be invited could be justified to avoid that contracting authorities invite candidates which later prove unable to submit the supporting documents at the award stage, depriving otherwise qualified candidates from participation.

Article 20: Competitive procedures with negotiation may take place in successive stages in order to reduce the number of tenders to be negotiated by applying the award criteria specified in the contract notice, in the invitation to confirm interest or in another procurement document. In the contract notice, the invitation to confirm interest or in another procurement document, the contracting authority shall indicate whether it will use that option.

Article 31 (5): Negotiations during innovation partnership procedures may take place in successive stages in order to reduce the number of tenders to be negotiated by applying the award criteria specified in the contract notice, in the invitation to confirm interest or in the procurement documents. In the contract notice, the invitation to confirm interest or in the procurement documents, the contracting authority shall indicate whether it will use that option.

Article 66 Reduction of the number of tenders and solutions. Where contracting authorities exercise the option of reducing the number of tenders to be negotiated as provided for in Article 29(6) or of solutions to be discussed as provided for in Article 30(4), they shall do so by applying the award criteria stated in the procurement documents. In the final stage, the number arrived at shall make for genuine competition in so far as there are enough tenders, solutions or qualified candidates.

Questions

  • What is the relationship between Lot and Procedure?

    • Is the Technique per procedure or per Lot?

    • What is the definition of a purpose?

    • Are the (process) deadlines/dates, and conditions part of the procedure/lot definitions?

  • When do we talk about “procedure definitions” (like a plan description) and procedure execution recording/accounting (like a travel journal)?

  • What is DPS?

  • Which procedure types can be single-stage and multi-stage?

    • What impact does “single/multi staging” have?

  • What is the difference between procedure stages and technique stages

    • What is a technique stage?

    • What is the procedure stage?

Negotiated procedure without a call

  • no techniques are typically used

  • may lead to a Framework Agreement (FA)

dpeVLaaAAAAAAElFTkSuQmCC

Negotiated procedure with call

  • no techniques are typically used

  • may lead to a Framework Agreement (FA)

wDBf2bW5KL4jwAAAABJRU5ErkJggg==

Competitive procedure with negotiation

  • no techniques are typically used

  • may lead to a Framework Agreement (FA)

EAAAAASUVORK5CYII=

DPS for conference hotels (with no lots)

  • One “part” for Northern hotels (parts of DPS but not Lot)

  • One “part” for Southern hotels (parts of DPS but not Lot)

DPS for cars

  • One “part” for 4x4 SUVs

    • 5 Lots - each Lot per car

  • One “part” for sedans

Ex3:

  • There is a FA on Airline tickets (divided into three “things”)

    • T1: Domestic flights within Norway

    • T2: Scandinavia flights

    • T3: International flights

  • What is T1, T2, T3?

    • Lots

    • Parts

gdJUGbRGVH7CQeUnDLRsDQOVn2RQ+UmBPGRQlZ9wUPkJAy1bw0DlJxlUflIgDxlU5SccVH7CQMvWMFD5SQaVnxTIQwZV+QkHlZ8w0LI1DFR+kkHlJwXykEFVfsJB5ScMtGwNA5WfZFD5SYE8ZFCVn3BQ+QkDLVvDQOUnGVR+UiAPGVTlJxxUfsJAy9YwUPlJBpWfFMhDBlX5CQeVnzDQsjUMVH6SQeUnBfKQQVV+wkHlJwy0bA0DlZ9kUPlJgTxkUJWfcFD5CQMtW8NA5ScZVH5SIA8ZVOUnHFR+wkDL1jBQ+UkGlZ8UyEMGVfkJB5WfMNCyNQxUfpJB5ScF8pBBVX7CQeUnDLRsDQOVn2RQ+UmBPGRQlZ9wUPkJAy1bw0DlJxlUflIgDxlU5SccVH7CQMvWMFD5SQaVnxTIQwZV+QkHlZ8w0LI1DFR+kkHlJwXykEFVfsJB5ScMtGwNA5WfZFD5SYE8ZFCVn3BQ+QkDLVvDQOUnGVR+UiAPGVTlJxxUfsJAy9YwUPlJBpWfFMhDBlX5CQeVnzDQsjUMVH6SQeUnBfKQQVV+wkHlJwy0bA0DlZ9k+P+3irBuixECvgAAAABJRU5ErkJggg==
MggD7FV5UcOodiq8hMhKj9yCBVQCaj8yCAPsVXlRw6h2KryEyEqP3IIFVAJqPzIIA+xVeVHDqHY+v8axLaNGCd0mAAAAABJRU5ErkJggg==

Future agenda

  • Jan 10th 2023 - Discuss Core Business Alignment

Working Group meeting 29/11/2022

Date: 29/11/2022
Participants: Thor Steinar Møller, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Procedure types and sub-types

Discussion

  • Proposing to discuss about Core Business Alignment in a future WGM

Procedure types and sub-types

  • Which procedure types can be single-stage and multi-stage?

    • What impact does “single/multi staging” have?

    • An Open procedure can be single or multi staged?

  • What is the difference between procedure stages and technique stages?

    • What is a procedure?

    • What is a technique?

    • The techniques can be viewed as a kind of procedure.

Procedure can be viewed as a process unfolding from start to the end, which is the conclusion of a contract.

A technique has a starting point as the procedure but it branches out and each branch ends with a separate contract.

By definition, a restricted procedure is already a multi-stage procedure.

Can a DPS be the following types of procedure:

  • Competitive dialogue - No

  • Competitive tendering - no

  • Innovative partnership - No

  • Neg-w-call - No

  • Neg-wo-call - No

  • Open - Yes

  • Restricted - Yes

  • Oth-mult - ?

  • Oth-single - ?

In theory, a DPS can be used in an Open procedure, but not in a restricted procedure.
Restricted means anyone can apply, but not anyone can participate. It is open all the time for qualifications, and restricted for competition.

The difference between a DPS and a FA is that under the FA a Contract Award Notice (CAN) is not published. In Italy CANs might be published.

Definitions:

  • Phase - a distinct period or stage in a series of events or a process of change or development

  • Stage - a period or step in a process, activity, or development

DvxpFbBHwT8E2kNts0Ad8EfBPwMwHfLnSfgH83jtwi4JuAbyK12aYJ+Cbgm4CfCfh2ofs+sU+GM25qVBgAAAAASUVORK5CYII=
QsFwA15zJej+wAAAABJRU5ErkJggg==
8PnJppm4RWlDsAAAAASUVORK5CYII=

Working Group meeting 22/11/2022

Date: 22/11/2022
Participants: Natalie Muric, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

ePO next release planning

  • Implement DPS/FA, procedures and sub-procedures

  • Re-examine the procedures and sub-procedures concepts, and their relations to Lot and Purpose

  • In DPS we have MiniCompetition AwardOutcome and NOT the LotAwardOutcome

  • The submission statistical information is at the Lot level, in the DPS/FA this information is at the MiniCompetition Level

  • Consider the split of the process information

  • CPV code pairing (re-model purpose)

  • Modifications modelling

  • Contract

  • Perhaps also touch on the Winner Role, which may be played by people and organizations, and sometimes even multiple ones, that don’t necessarily for an epo:OrganizationGroup.

Roles classification

Group leader role removal

  • The GroupLeader class was removed since we already have epo:leadBy predicate between epo:OrganisationGroup and org:Organization.

  • But not all groups have legal name so the cardinality for epo:hasLegalName is changed to 0..1

xlc97fE+3QAAAAASUVORK5CYII=

  • Closing GitHub issue 386.

  • The lead buyer in Contract Notice can differ in the Contract Notice and Contract Award Notice corresponding to the mini-competition.

  • Presenting examples of an instance diagram for lead buyer.

  • In a joint procurement, all the Buyers are responsible and one of them might be the lead for awarding.

  • This doesn’t mean we have an OrganizationGroup.

  • Created a new concept epo:LeadBuyer as a subclass of epo:Buyer defined as: “A role of an agent who is a Buyer and takes the administrative lead of the procedure.
    WG approval 22-11-2022”

  • We need to model DPS and Framework agreement in order to be able to map correctly.

  • Discussing an example of award.

  • Buyers can be specified for the Procedure for the pre-award phase and for the Contract (Purchase and Framework Agreement) for the post-award phase.

  • However, already in the pre-award it is possible to know who will be the buyers in the Contract (post-award).

  • A Buyer can be responsible either for the procedure or for the purchase contract.

  • Responsible is not the same as the leader.

  • A lead can sign the contract.

  • Joint procurement means that a procedure is the responsibility of more than one buyer. One of the responsible buyers has to be the lead or they can use a ProcurementServiceProvider to delegate the ancillary activities to, meaning there is no lead.

Working Group meeting 15/11/2022

Date: 15/11/2022
Participants: Thor Steinar Møller, Natalie Muric, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Dynamic Purchasing System

Discussion

Open procedure with framework agreement

Single-stage and multi-stage procedure -
Tenderers may be limited or pre-set -
Buyer can the same (as in FA) or different (for using the FA to establish a contract) -

Stages

  • In a single stage procedure there is

    • a single process start-to-end

    • Only one tender deadline

    • Allowed procedure types

      • Open

      • Restricted

      • Other single stage procedure

    • Disallowed

      • Negotiated

      • Competitive dialogues

      • Competitive tendering (perhaps)

      • Innovation partnership

      • Negotiated with prior publication of a call for competition / competitive with negotiation

      • Negotiated without prior call for competition

      • Other multiple stage procedure

  • In a multi stage procedure there is

    • Multiple tender deadlines

      • ONLY One call for competition that is published

        • Possibly everyone is invited or possibly a restricted set

      • When the competition is reopened (the subsequent stage, not the first one), it is “limited” (no notice published)

        • Always a restricted set of participants

        • Reopen always only with “award” criteria and no “exclusion” or “selection” criteria.

    • DPS - introduces ONE subsequent stage

      • New economic operators may join based on “requests to join” , but no new publication of CN. The requests to join are based on the initial CN.

      • DPS can be open or closed (in Italy).

    • Negotiated procedure can have “infinite” number of stages

    • Allowed procedure types

      • Negotiated

      • Competitive dialogues

      • Competitive tendering (perhaps)

      • Innovation partnership

      • Negotiated with prior publication of a call for competition / competitive with negotiation

      • Negotiated without prior call for competition

      • Other multiple stage procedure

    • Disallowed procedure types

      • Open

      • Restricted

      • Other single stage procedure

Dynamic Purchasing System (DPS)

Procedure types allowed with DPS

  • Restricted Procedure types Disallowed

  • All the rest

A DPS never really completes. One can keep adding participants.

DPS flow

    • Purpose:

      • Announce the call for competition

      • Attract requests for participation

      • Choose candidates

  • Can publish a Prior Information Notice (PIN) if you want

  • Publish a Call for Competition (CN)

    • Optionally including Award Criteria

  • ESPD Request has to be published at the same time as CN (elsewhere)

  • Specifications can be published (elsewhere)

  • The request to participate is submitted by the Tenderer

    • Including the ESPD Response

    • (optionally) Including the evidence for selection criteria and exclusion grounds

  • Request to participate is evaluated

    • Not sooner than 30 days after the CN publication

    • Not later (for each request to participate) than 10 days after the submission

  • Tenders that pass the Exclusion grounds and Selection criteria are admitted to the DPS

    • Purpose:

      • Conduct competition based on award criteria

  • The Buyer triggers the (RE-)opening of the competition, when needed,

    • There may be multiple openings of “competition” among the chosen candidates

    • _Also known as _

      • (in Italy) mini-competition

      • sub-procedure

    • The Buyer is (sometimes) a different organisation in this stage

    • The Buyer triggers the (re-)opening of competition, when needed, by sending an invitation to tender including the specifications and award criteria to the Candidates.

  • Tenderers submit tenders

  • The Evaluation Committee (set-up by the Awarding-Buyer) evaluates and creates an evaluation report

  • Based on the evaluation report, an Award Decision (based on award criteria only) is created (by the Awarding-Buyer)

  • Selecting-Buyer requests to the (nearly) awarded Tenderers (wanna-be Winners) the evidence for selection criteria and exclusion grounds

  • Tenderers provide the evidence to the Selecting-Buyer

  • Selecting-Buyer evaluates the provided evidence and

    • If it is conformant(good) the contract is awarded to the Tenderer, making them Winners

    • Otherwise the Tenderer is not awarded

  • All Tenderers are then told of the Award Decision (who was awarded and not + reasons on why and why not)

  • The contract is signed by the Awarding-Buyer and the Winners

  • Contract Award Notice (CAN) is published

    • for each award decision (within 1 month) OR

    • Collect all award decisions (once every 1 month or 6 months for example) and a bulk is published (usually for the contracts below the threshold)

Critical note:

  • In the case of DPS, the CAN is an Award Notice for the Contract, while in the case of normal (non-DPS) procedures the CAN is an Award Notice for Lots. [THIS IS DEBATABLE]

Critical note:

  • The opening of the competition under the DPS may be opened as a sub-procedure having its OWL Identified, yet linked to the “parent-DPS-procedure”. [THIS IS DEBATABLE]

  • In the DPS CAN, most likely, the contract number will be provided rather than a reference to the Lot number (in the Procedure).

Note

  • DPS is open during the whole duration of the procedure. If a DPS is a setup to last for 2 years, then eC can register and apply under this DPS. DPS is a kind of FA where the procedure is open for a long period.

  • And when needed, a CA can launch a mini-competition, like the FA, whereas the EC that has the capability to submit a tender can submit its tender in that specific sub-competition.

Note

  • In Italy, DPS is like a digital market internal to public institutions.

  • There is always a system that supports the DPS.

  • Is the procedure ID of the CAN the same as the one for CN?

  • The discussion on DPS should continue on Thursday, 24th Nov.

  • In a CAN for DPS it will be a Contract Number, not a Lot Number.

Working Group meeting 08/11/2022

Date: 08/11/2022
Participants: Natalie Muric, Giovanni Paolo Sellito, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

Standard Form F20

The problem of identity is discussed in the beginning of the meeting. Probably it is easier to have two organisations when we change any property.
The proposed approach is the following:

pyiKIqiKIqiKIqiKIrSrUYfI4rbGoEw4aVmAAAAAACAiCNGhOyIEQEAAAAAACKOGBGyI0YEAAAAAACIOGJEyI4YEQAAAAAAIOKIESE7YkQAAAAAAICII0aE7IgRAQAAAAAAIo4YEbIjRgQAAAAAAIg4YkTIjhgRAAAAAAAg4p7GiP8PdozrLf0JoP8AAAAASUVORK5CYII=

We have an instance, Procedure2 (in the Contract Modification Notice), which is the same as Procedure1 (in the Contract Notice).

But the modification is at the level of Contract, not the Procedure or Lot. A contract has its own CPV codes. These are modifications during the execution of a Contract.
When we have a Contract, the Procedure is over.
This is not modelled in ePO yet. The current model is not correct and we should take another look at it.
Based on the definition of the Procedure class, it seems that the model presents an instance of a process.
After a discussion in the WG, it was concluded that the modifications are on the epo:Contract, not any other ProcurementObject. The Contract module of EPO is not yet completely modelled, and therefore modifications implementation should be addressed as part of the modelling Contract module.

Github issue 386 - group leader

The definition for Group Leader in ePO 3.0.1 is “A role of an agent that is the primary contact for a group of organisations.”
The proposal was to remove the epo:GroupLeader since this role is already encoded in the relations between epo:OrganisationGroup and org:Organization:

xTPLNHghEUAAAAAElFTkSuQmCC

espd:eo-role-type

This is an new authority table in EU vocabularies:

+5TGAoUOwWJAAAAAElFTkSuQmCC

A new ticket has been added on github: https://github.com/OP-TED/ePO/issues/409

Concession contract

The concession contract should be discussed. There are 2 URIs: one from CPSV and ePO and both definitions should be discussed.
Since the 3.0.0 release of ePO, it introduced the concept of ConcessionContract, which is already present in CPSV-AP.
Definition in ePO:
“A contract between one or more buyers and one or more economic operators giving the right to the economic operators to exploit the rights foreseen in the contract which may include the receipt of payments.”
Definition in CPSV-AP:
“Concessions are contracts for pecuniary interest by means of which one or more contracting authorities or contracting entities entrusts the execution of works, of the provision and the management of services, to one or more economic operators.” From Directive 2014/23/EU (paragraph 11)
In CPSV-AP, a cv:Contract is a subclass of epo:Contract.

89OzfwH5bBokykVpeQAAAABJRU5ErkJggg==

We should decide on a single definition in order to use only epo:ConcessionContract in both CPSV-AP and ePO.
But the PublicOrganization and economic operator are also at the level of epo:Contract, not only ConcessionContract.
A concession contract is not related only to Directive 2014/23/EU.

It is proposed to use epo:Contract class instead of epo:ConcessionContract in CPSV-AP.

The relation between cv:ConcessionContract to eli:LegalResource, establishedUnder, is not yet represented in ePO, since we did not model the Contract yet.
But in ePO we use only European law, an ePO can not maintain an eli:LegalResource.
Another proposal is to create a ServiceConcessionContract in CPSV-AP that is a subclass of epo:ConcessionContract.

imgAAAABJRU5ErkJggg==

Roles

Changed the definition of epo:Contractor to:
“The role of an agent that has signed a contract with a Buyer.
WG approval 08/11/2022”

w8kMKeSMWvIMQAAAABJRU5ErkJggg==

Working Group meeting 25/10/2022

Date: 25/10/2022
Participants: David Chaves, Maria Navas Loro, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

Github issue 381

  • Usually define domain for properties that have a skos:Concept in range.

  • At the moment when generating the artefacts from UML model:

    • OWL core (lightweight)

    • SHACL shapes

    • Restrictions (lightweight)

  • In model2owl transformation scripts should we add subclasses in the OWL core file or should these be in the restrictions?

    • rdfs:domain

    • Rdfs:range

  • In the uml2owl transformation document (https://github.com/OP-TED/model2owl/blob/master/doc/uml2owl-transformation/uml2owl-transformation.pdf) are presented all the transformation rules and in which layer they belong: core ontology, data shape (SHACL shape) and reasoning (restrictions) layer.

  • Below is a snippet from that document where we can see that the domain and range of associations are in the reasoning layer and the range is also in SHACL shapes layer.

D5pWwXyi1Zp1AAAAAElFTkSuQmCC

  • But there seems to be a bug because the domain for properties derived from the "dependency connectors" are missing.

  • This bug should be fixed.

Github issue 383

  • In the latest release version, ePO 3.0.1, a Result Notice belongs to the Notice module.

  • Only the epo:Notice class is now in the ePO core module.

r5YSwJrAPywokNaYA1KBf6+WEsCa1Aq8PfFWhJYQxACf2usJYE1KBL4m2ItCaxBqcDfF2tJYA2Anx9d0QEAAAAAgKZY0QEAAAAA0AVWdAAAAAAAdIEVHQAAAAAAXWBFBwAAAABAF1jRAQAAAADQBVZ0AAAAAAB0gRUdAAAAAABd+P8BCvWg3UjhECgAAAAASUVORK5CYII=

Github issues 382

  • There is a list of more specific comments regarding this issue.

  • In OCDS, the term Tender refers to something else than in ePO. We have a class from Procedure, which is the process, and we also have a term of the actual Tender as a noun. In OCDS, Tender refers to the entire process of tendering.

  • ePO 3.0.1 was used to get the following comments:

    1. A Contract includes one or more Lots. Why not use LotGroup for this case? A LotGroup is actually a combination of several lots to conduct comparative assessment of the tenders. Is used in cases when the total value of the offers for lots in particular is higher than the value of the offer per a group of the same lots.
      For example, assuming we have two lots, the LotGroup is used when the value of the offer for Lot 1 plus the value of the offer per Lot 2 is higher than the value of the offer for LotGroup containing Lot 1 and Lot 2.

    2. To revise the definition for epo:Procedure. Explicitly mention that a Procedure should have at least one Lot, even though this is derived from the cardinality.

    3. Do we consider epo:Procedure as the central part of the ontology? Essentially, a Notice will always be linked to one and only one Procedure. We do not model processes, but we have modelled objects over time.

    4. What do Terms represent? What is the relation to the Documents? The terms may be published in the notice mainly in the competition phase (some of them may be in planning as well). There are three types of terms: lot specific, procedure specific and contract specific (post-award related terms).
      Terms are not actual documents. They are the rules of the game. And they have attributes that link to different documents.

    5. The specification documents for each Lot are not yet modelled.

    6. In the epo:ProcurementCriterion we might need to add an URL attribute in case we need to add a reference to a procurement document (PDFs) specifying the award or selection criteria.

    7. The class Winner depends on the class Tenderer. We can not instantiate a Winner before having an insurance of Tenderer. The term “depends” doesn’t represent a logical dependency.

    8. epo:Contract epo:includesTender epo:Tender has a cardinality of 0..* because of standard form mappings. To be checked if it is still needed in the mappings.

    9. Description of the class Contract is very abstract. Suggestion to add some general information in the definition: include the main parts and refer to the procurement process.

Dynamic Purchasing System Technique

  • What is a Dynamic Purchasing System (DPS)? DPS is open during the whole duration of the procedure. If a DPS is a setup to last for 2 years, then eC can register and apply under this DPS. DPS is a kind of FA where the procedure is open for a long period.
    And when needed, a CA can launch a mini-competition, like the FA, whereas the EC that has the capability to submit a tender can submit its tender in that specific sub-competition.
    QUESTION: Is there a specific notice to set up a DPS? To be checked in D24?

  • Set up a meeting with who is the coordinator of the DPS subgroup.

eAuction Technique

  • What is an eAuction Technique? Contracting authority can be set up on a digital platform (exclusively). Very similar to eBay, but the offer is not increasing, but decreasing.
    Sometimes they organise the auction in rounds.

  • This technique influences ONLY the submission stage.

  • Procedure types that can have eAuction:

    • Competitive Dialogue (NOT)

    • Competitive tendering (Yes)

    • Innovation partnership (don t know)

    • Negotiated - both types can have eAuction

Working Group meeting 18/10/2022

Date: 18/10/2022
Participants: Mauro, Natalie Muric, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Present and Discuss the Procurement Object

Discussion

  • Proposal to discuss the alignment of Core Business vocabulary with ePO.

Procurement Objects

  • Presenting the proposal that was implemented in a previous WGM (2022-10-04).

  • epo:ReviewObject might need a revision in the future. Decided to leave it as it is for the time being..

  • The award decision is between a tender and a contract so its position is good.

  • Revise definition from epo:ProcurementObject. The proposed definition “The whole or a division of goods, services or works to be procured” is more of a description of the concept and not a definition for it.

  • Answering the question “what are the attributes of the epo:ProcurementObject describing?” might give us a better definition.

  • In the epo:ProcurementObject there is nothing about the subject matter, but only in epo:ProcurementElement.

  • Discussed the case where we have a Direct Award Procedure which is followed by a contract signing.

    • In this case we will also have a Lot for that type of Procedure.

  • The relation epo:hasOverallPurpose between epo:Procedure and epo:Purpose is deleted since it is no longer needed. Instead of this one, we will use epo:hasPurpose between epo:ProcurementObject and epo:Purpose.

H2ejO26K4JZPAAAAAElFTkSuQmCC

  • Trying to decide whether a Lot is recurrent or only the procedure can be recurrent. For the moment it was decided to keep the attributes epo:isRecurrent and epo:hasRecurrenceDescription at the epo:ProcurementObject level.

  • Decided to move at-voc:contract-nature at the level of epo:ContractTerm level from epo:Purpose, as in the diagram below:

xtMQa3b0Q5AIQAAAABJRU5ErkJggg==

  • In eForms, the title and description of Lot and Procedure were in the Purpose Business Group, BG-2.

  • Also, recurrence and recurrence description are on the Purpose level, but they do not seem to belong there.

  • Should the contract nature be moved back?

    • We should have incremental changes on the model, even if they might impact the standard form mappings.

  • The definitions for epo:Lot, epo:Procedure and epo:PlannedProcurementPart are about different nature of things so they need to be aligned to cover all three aspects:

    • The procedural/process/game rules

    • The object/scope/purpose of procurement

    • The description of influences or additional information related to the procurement (isSMESuitable, isUsingEUFunds etc.)

Discussing github issues 382

Working Group meeting 11/10/2022

Date:*c
*Participants: Peter Borresen, Mauro, Natalie Muric, Csongor Nyulas, Pietro Palermo, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Discuss eFulfilment and eOrdering roles.

References:

Despatcher role

  • Can the despatcher be a different organisation than the seller?

    • It is not necessarily the seller.

    • There are 3 options: the seller, the buyer or another organisation.

    • We need to indicate another organisation besides the seller.

  • In case of a service, the supplier of the service is the same as the despatcher.

  • We can not use the verb provide because it means supply.

  • Added definition:

    • The role of an agent who sends the goods or notifies of the service or works execution.

Additional Information:
The role is carried out by the supplier or on behalf of the supplier.
Despatcher is also known as Despatch Party, Consignor, deliverer.

  • Prefix is epo-ful.

Invoicer role

  • It would be useful to model which “party” can play this role: buyer side, seller side or third party (acting on behalf of the seller or acting on behalf of the buyer).

  • Added definition:

    • The role of an agent who claims the payment and is responsible for resolving billing issues and payment arrangements. Additional information:
      Most of the time the invoicer is the seller.
      Rhw invoicer may or may not be the owner of the credit owed by the Buyer.
      Also known in other contexts as invoice issuer, accounts receivable or creditor.

Roles discussion

  • Primary Roles:

    • sending and receiving Public Procurement information (documents, data packages, etc.)

  • Secondary Roles:

    • Involved in the process described in information exchange (documents, data packages, etc.), so they are "referred to" or "mentioned".

  • Primary:

    • actors in the process (Seller, Buyer)

  • Secondary:

    • actors acting on behalf of (Seller, Buyer)

  • Tertiary:

    • (third parties)/actors just participating in the process and only mentioned

Predicate discussion

  • Discussing relations from epo-ord:Order:

H3jFE2Z5z27JAAAAAElFTkSuQmCC

  • These relations seem to be mixed.

  • Changed epo-ord:isDeliveredByDespatcher to epo-ord:isSentByDespatcher.

  • Changed epo-ord:isDeliveredToDeliveree to epo-ord:isDeliveredToConsignee.

bW978AAAAABJRU5ErkJggg==

Deliverer/Carrier role

  • Deliverer and carrier are synonyms, but the definitions that we provided in ePO for these two roles make them not synonyms.

  • epo-ord:Deliverer seems to be copied over from ePO 2.0.2 from Order Reification diagram.

  • Decided to merge Deliverer and Carrier into the same role.

  • Added definition for Carrier:

    • The role of an agent who handles the physical delivery/transportation of the despatched shipment.

Additional information:
The role is also known as Deliverer.

WG approval: 11/10/2022

  • The prefix for this role is epo-ful: since the Carrier is not known in the ordering phase.

Github issues

  • Some new GH issues (381, 382, 383) were discussed and need to be approached.

  • We need to try and react soon to these new issues.

Working Group meeting 04/10/2022

Date: 04/10/2022
Participants: Csongor Nyulas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Proposing new model for procurement objects

Discussion

  • Since epo:Lot, epo:Procedure and epo:PlannedProcurementPart are all procurement objects with more properties in common, it was decided to make epo:ProcurementObject a gathering class only for these three objects.

  • A temporary definition that needs to be revised within the following WGM has been added to epo:ProcurementObject:

The whole or a division of goods, services or works to be procured.

Additional Information:
Anything that can specify the procurement content (i.e. goods, services, work) is a Procurement Object. _
_In a sense, such an "object" can constitute the "object of a contract".
To test whether something is a Procedure Object check if it can have a Purpose and/or CPV classification (The CPV establishes a single classification system for public procurement aimed at standardising the references used by contracting authorities and entities to describe the subject of procurement contracts.).

Note:
Procedure, seems to be an exception from this rule. Because it is a conflated term: it carries process properties and "purpose" properties.

  • Created epo:ProcurementElement as a gathering class for all procurement elements that are involved in the procurement process, including epo:ProcurementObject.

  • A temporary definition that needs to be revised within the following WGM has been added to epo:ProcurementElement:

Gathering class for critical/central elements in the procurement process.

TODO: add definition
Additional information:
Alias: ProcurementComponent

  • The following relations epo:isSubjectToProcedureTerm, epo:isSubjectToLotTerm are now sub-properies of epo:isSubjectToTerm predicate between epo:ProcurementObject and epo:Term.

  • Deleted epo:isSubjectToPlanningTerm predicate between epo:PlannedProcurementPart and epo:ProcessPlanningTerm.

  • The source class for epo:hasEstimatedValue was changed from epo:Lot and epo:Procedure to epo:ProcurementObject.

  • Both predicates, epo:refersToPlannedPart and epo:usesTechnique, were moved from epo:Lot and epo:Procedure to epo:ProcurementObject.

AAAAAAElFTkSuQmCC

Working Group meeting 27/09/2022

Date: 27/09/2022
Participants: Natalie Muric, Csongor Nyulas, Garcia Merino, Mauro
Model editor: Andreea Pasăre
Note editor: Andreea Pasăre

Agenda

  • Discuss GH issues for F03 standard form mappings

    • 187

Discuss

Github 187

  • We need a consistent way of mapping for section 5 whether we have the lot number or the contract number.

  • It was agreed that if the lot was not mentioned and there was only one lot, the lot was taken from section II.

  • How to approach the mappings if we have multiple lots, but without the lot numbers specified.

  • if there is no award there is no contract and therefore there is no instantiation

  • If the contract is awarded you can infer from the ontology that the contract exists.

  • I’m not sure therefore that we have to create a link that can be inferred.

  • The title could be for the lot if it is a non-award.

  • If awarded then the title will be the contract title.

  • If non-award then the title will be the lot title.

  • If we have a contract number, the RDF should have one as well.

  • If we have a lot number, the RDF should have one as well.

Github 126

  • The excel maps correctly to the authority table economic-operator-size however the rdf shows a boolean see 348503-2021

  • The authority table is not listed in the resources

  • This needs to be documented in the mappings: although in xml we say it does not exist we need to explain that.

Working Group meeting 13/09/2022

Date: 13/09/2022
Participants: Cecile Guasch, Natalie Muric, Csongor Nyulas, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discuss

  • Summary of what has been done in the ePO group in the last couple of months.

Github 152

  • If the SME checkbox is checked we will "reuse" the Organization instance, and we will add epo:Business as an additional type.

Github 156

  • If an Organization is not an SME does not mean it should be a large SME.

  • This issue can be closed as we agreed that the current representation is the best that we can do.

Github 149

  • epo:refersToProcedure between epo:ResultNotice and epo:Procedure should be renamed since it’s too general.

    • epo:announcesAwardOfProcedure is not ok since the award is at lot level

    • epo:finalizeProcedure is not ok since we have completion phase for this

  • Decided to change the source class for epo-not:refersToProcedure to make it a super-property from epo:ResultNotice to epo:Notice

    • Prefix was changed to epo:

    • Making epo-not:announcesProcedure (from both epo-not:CompetitionNotice and epo-not:DirectAwardPrenotification) sub-properties of epo:refersToProcedure

wCwfMcCPSW73gAAAABJRU5ErkJggg==

  • Decided to have the prefix epo: for all relations going from epo:Notice.

RaPiaEUL+hP8P3sAOCuyS770AAAAASUVORK5CYII=

Github 138

  • Propose to add a new code in the at-voc:non-award-justification to cover this specific subsection: "No tenders or requests to participate were received or all were rejected".

Github 127

  • Decided to use a different predicate, epo:hasAwardedValue that goes from epo:LotAwardOutcome to epo:MonetaryValue.

zqQ0ZAAAAAElFTkSuQmCC

New Github issues

  • Added a new GH issue 161.

Working Group meeting 06/09/2022

Date: 06/09/2022
Participants: Cecile Guasch, Natalie Muric, Csongor Nyulas, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Notice metadata overview

Discuss notice metadata

  • Plan to generate a new version with notice metadate included.

  • Publish the normalisation scheme for standard form mappings.

  • Diagram containing notice metadata:

D1fI1ydocJ9pAAAAAElFTkSuQmCC
FsKXApoX9yHAI0WU2KICOfokCNmDgXb+sg0SFk4YnsMUZwjOEbajWdMGmNhMSUGOncbBuZEP5DSCRAGCL5k2F+RqaAlEiSNxG8BediyLswiZIqpd87dKWTIf8PPQQysCbo4MIAAAAASUVORK5CYII=

At-voc:implementation-regulation

  • This needs to be changed.

  • The relation for regulation implementation should go from epo:Notice to at-voc:legal-basis.

  • If we include the regulations, we have to change the name “legal-basis” of the controlled vocabulary.

  • Changed epo:hasImplementationRegulation to epo:isBasedOnImplementationRegulation wit the following definition: “Indicates under which regulation a notice is created.
    WG Acceptance 06/09/2022”

  • How to signal the difference between SF notices and eForms notices?

    • The implementation regulation should help in this, but might not be enough.

Notice predicates

  • epo:Notice is part of ePO core.

  • Keeping all predicates that go from epo:Notice in the Notice module with the prefix epo-not.

  • The RDF for PPDS should contain all these predicates from the notice module.

Working Group meeting 23/08/2022

Date: 23/08/2022
Participants: Cecile Guasch, Natalie Muric, Giovanni Paolo Sellito
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Standard forms mappings F21 & F22

    • F21

      • II.1.6.1 II.1.6.1.1 II.1.6.1.2 II.1.6.1.3

      • II.1.6.2

      • II.1.6.3

      • V.2.4.1 (It is the same as II.2.6)

Discussion

  • II.1.6) Information about lots

    • epo:ProcedureSubmissionTerm is created:

      • Subclass of epo:ProcedureSpecificTerm

ReUAAAAASUVORK5CYII=

  • Renaming epo:SubmissionTerm to epo:LotSubmissionTerm and the definition modified appropriately

  • Adding new attribute epo:isSubmissionForAllLotsAllowed in class epo:ProcedureSubmissionTerm for subsection “Tenders may be submitted for all lots” with the following definition: “Indicates whether tenders may be submitted for all Lots.

Additional information:
This field is used to complement the SubmissionTerms (which are at the Lot level) for the Procedure level which is covered by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms)

WG approval 23/08/2022“

  • Renaming attribute epo:hasLotSubmissionLimit to epo:hasMaximumLotSubmissionAllowed

  • Adding boolean attribute epo:isOneLotOnlyAllowed with the following definition: “Indicates whether tenders may be submitted for only one Lot.

Additional information:
This field is used to complement the SubmissionTerms (which are at the Lot level) for the Procedure level which is covered by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).

WG approval 23/08/2022”

  • Moved epo:hasMaximumNumberOfLotsToBeAwarded attribute in epo:ProcedureTerm

  • Decided to delete class epo:ProcedureSubmissionTerm and moved attributes to epo:ProcedureTerm

ImfoXHZM3MryFXAdcC090Pk+JiLI3+m5lQLBALkKgAAANwKcIwnzfziGjaGfv6fkEvHgF6X13QVlrYgz7ch5fZTIrIGIHOQbDJTIwqmhQi7gAVja4Aek0BMCcUDxwA8NsQiUf6nppgUxsYmeNDzLYBp74cLny8g06vw1DIul4dcBQAAANcAx3jSFHxuLqvpPH993TEWl9Yh9xAJhchLFHLRGB1NH+Wfdyo60yI+z4vsBQNe4m0tb5ysVMWmAccAPCp43BNiVkUqpfToiItcBdgBpr0fNJBOZxc2JKQVgVvdAACApwDHeLpwubyQyKyNzZ3zL687hkwmjU0tHJ2YRV6lkPN6iNhijtDmEoLhzOCc8fPXDpCuAscAPCp2dg+gvEVj1AkFDg0cYA+Y9n7oSKWSTxVtUcn5oGsHAAA84v8DdUaxVwRA+FUAAAAASUVORK5CYII=

  • For the subsection “The contracting authority reserves the right to award contracts combining the following lots or groups of lots:” a new string attribute should be created on the epo:ProcedureTerm, epo:hasLotAwardCombination, with the following definition: “The contracting authority reserves the right to award contracts combining lots or groups of lots.

Additional Information:
This property contains information about the Lots concerned.
This property is required by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).

WG approval 23/08/2022”

  • V.2.4.1 (It is the same as II.2.6)

    • The value in section II is used only when we have a call for competition.

    • The value in section V is used in all other cases.

    • They do not appear at the same time

    • In case we have different values between contract notice and contract award notice we need to provide another predicate.

    • Created the predicate epo:hasRestatedEstimatedValue. “A forecast of the value of the procurement before competition, which is repeated in the contract award notice.

Additional Information:
This property should be equivalent to the epo:hasEstimatedValue. It is created, however because the existent data model two different fields (with the same conceptual meaning) and therefore the values may differ.

This property is required by the regulation (EU)-2015-1986 (modeled in the TED Standard Forms).

WG Approval 23/08/2022”

  • In all Contract Awarded Notices, in section V, we should use epo:hasRestatedEstimatedValue and in section II, we should use epo:hasEstimatedValue

B5aRIH9tIpN9AAAAAElFTkSuQmCC

  • In the next meeting should be discussed which metadata should be included as part of the content.

Working Group meeting 16/08/2022

Date: 16/08/2022
Participants: Peter Borresen, Cecile Guasch, Natalie Muric
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • eOrdering development.

eOrdering discussion

  • Present the proposed eOrdering model.

gfhzyujPsbHGAAAAABJRU5ErkJggg==

  • Between epo:Order and epo:Item should be a reification. There are properties that are dependent on the item. (e.g. delivery conditions).

  • Introducing epo:OrderLine. In version 2.0.2 OrderLine existed.

zwAAAABJRU5ErkJggg==

  • The constraint on epo-ord:containsOrderLine should be kept open in order to not lose valid use cases.

  • There is a framework contract with a set of items that have been agreed upon. This contract can be used to create a system. The buyer starts a process asking the supplier to provide an optimal configuration.

  • The request might be a vague order line which gets refined in the process.

  • For an order line to be correct it must either provide an item description or specify an item.

Ace+tx89PG34AAAAAElFTkSuQmCC

  • There are things that are described but they do not exist in a catalogue.

  • Some attributes from epo-cat:CatalogueItem are common and they are moved to epo:Item.

wc1krr2UApAkgAAAABJRU5ErkJggg==

  • To be discussed in a future eCatalogue meeting.

eFulfilment discussion

  • A proposed UML model for despatch advice logistics is presented.

xPn0WPMxcEvAAAAAElFTkSuQmCC

  • Providing use cases as github issues are preferred.

  • There are no requirements for primary and secondary parties.

  • The definitions of the entities should be provided as well.

  • The proposed UML diagrams should be used. === Roles in Despatch advice

  • The scope is to align the concepts from PEPPOL ordering and despatch advice with what there is already in ePO. ==== epo:Deliveree

8CvB2TDmXC0UwAAAAASUVORK5CYII=

  • Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.

  • Renaming epo-ord:Deliveree to epo-ord:Consignee and keep the definition from Deliveree because the term Consignee is a more used term in PEPPOL. (inform Pieter as well)

epo:Originator

  • Comparing all definitions from PEPPOL Ordering, PEPPOL Despatch and from ePO.

  • The name Beneficiary gives more information.

  • Need → Initiation of Need fulfilment request → Provision of the need fulfilment means.

  • Changing the definition for epo-ord:Originator

fShAAAAAElFTkSuQmCC

  • When the Buyer creates a framework contract, it does not catch the real Originator.

  • Creating epo:Beneficiary with the following definition: “The role of an agent that consumes the goods and on whose behalf makes the purchase.

Additional Information:
The Beneficiary is the end-user and is often the Consignee and the Originator.
”

  • Adding as a requirement that the Buyer can also originate the order.

  • epo-ord:Originator should be moved to epo:Originator in the core module. To be discussed in the future meeting.

Working Group meeting 09/08/2022

Date: 09/08/2022
Participants: Natalie Muric, Csongor Nyulas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Discuss Concession concept in the context of standard form mappings. === Discussion

  • Added new class epo:ConcessionEstimate with the following particularities:

    • The attribute epo:hasCalculationMethod was moved to epo:ConcessionEstimate.

    • The predicate epo:foreseesConcession has target class epo:Tender and source class epo:ConcessionEstimate.

    • The predicates epo:hasEstimatedUserConcessionRevenue and epo:hasEstimatedBuyerConcessionRevenue have target class epo:ConcessionEstimate and source class epo:MonetaryValue.

n9YHwgU+4QZuAAAAABJRU5ErkJggg==

  • Added predicate epo:definesConcessionDuration between epo:ContractTerm and epo:Duration.

  • Added predicate epo:definesConcessionPeriod between epo:ContractTerm and epo:Duration.

xPqwAAAAAElFTkSuQmCC

Working Group meeting 02/08/2022

Date: 02/08/2022
Participants: Natalie Muric, Csongor Nyulas
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • eNotice development

Discussion

eNotice

  • Separate the Notice systematisation (Notice module) from the Notice content (NoticeContent module)

  • In the Notice module we have instances created from the values of CV like in the example below:

G9PAQS464orgAAAAAElFTkSuQmCC

  • We are constraining a class to a specific value of a property (Directive 23 in the image above)

  • There is a controlled list for all notice subtypes in eForms.

F8XjPjj8G9ynwAAAABJRU5ErkJggg==

  • Restricting cardinalities for epo:hasNoticeType

e5Ll7vPwf32F5ULAmvPsAAAAASUVORK5CYII=

  • The namespace prefix to be used should be epo-not:

  • The notice package from ePO core should be moved to the Notice module.

  • Check all attributes from epo:Document and decide what namespace should be used (epo:hasPublicationDate) and if they should be moved at the Notice level.

  • For the moment what is in the Document class should stay there and decide what can be moved in the future.

  • The package notice classes seem ok. Check and validate this package.

  • Creating pmc:at-voc:notice-type with a comment that this value is not part of the notice type controlled vocabulary yet.

sE9jxUktsDMAAAAASUVORK5CYII=

  • If it is a D24, then it is a Prior Information Notice.

  • If it is a D25, then it is a Periodic Indicative Notice.

Working Group meeting 26/07/2022

Date: 26/07/2022
Participants: Paloma Arillo, Cecile Guasch, Giorgia Lodi
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Add missing definitions for eCatalogue

Discussion

eCatalogue missing definitions

Added new definitions for the following:

  • epo-cat:Certifier “A role of an agent that assesses the conformance of an Item to a set of requirements and grants the certificate as a proof of conformance.

WG approval 26/07/2022”

  • epo-cat:CertificationLabel “Concept that stands for a set of norms, expectations, standards and policies.

Additional Information:
Such standards may relate to social, ethical and quality etc.

WG approval 26/07/2022”

  • epo-cat:ItemDescription “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.

WG approval 26/07/2022”

  • epo-cat:ItemCertificate “”

  • epo-cat:hasPricePercentage “The factor relative to the price charged in addition.

WG approval 26/07/2022”

  • epo-cat:hasCertificationNumber “The unique identifier of the certificate.

WG approval 26/07/2022”

  • epo-cat:hasAttributeType “Construct meant to represent the association between an attribute defined in an external classification scheme and the value ascribed to it.

WG approval 26/07/2022”

  • epo-cat:hasFixedAmount “The predetermined monetary value charged in addition to the price.

WG approval 26/07/2022”

  • Added epo-cat:hasReferenceURI attribute on the class epo-cat:CertificationLabel with the following definition: “A reference to where the label specification (norms, expectations, standards and policies) can be found.

WG approval 26/07/2022”

  • epo:hasValidityPeriod “The property indicating when the ItemCertificate is in force.

WG approval 26/07/2022”

  • epo-cat:issuedByCertifier “Relation indicating the Certifier responsible for providing the ItemCertificate.

Additional Information:
Certifier is a role played by an organisation.

WG approval 26/07/2022”

  • epo-cat:attestedByLabel “Relation indicating the conformance subject represented by a CertificationLabel.

WG approval 26/07/2022”

  • epo-cat:hasCertification “The property providing the proof of conformance.

WG approval 26/07/2022”

  • epo-cat:hasBaseQuantity should be mandatory, so the cardinality was set to 1.

  • epo-cat: hasLeadTime changed to epo-cat:hasExpectedDeliveryTime with the following definition: _“The expected amount of time between the order and delivery of an item. _

WG approval 26/07/2022”

Working Group meeting 19/07/2022

Date: 19/07/2022
Participants: Paloma Arillo, Cecile Guasch
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Close eCatalogue GH issue 343

  • Start discussing eOrdering

Discussion

Environmental/Social labels for items

  • There is a collection of requirements and there are several labels. Each of these associations provide certification schemes.

  • It is not good to look at that only from the label perspective.

  • There is a connection between the requirement set and the procurement criteria, and some of the labels can serve as a fulfilment as a procurement criteria.

  • CCCEV might be used in these circumstances. Might complement these labels.

  • Some subtypes of criteria can constitute a requirement for a particular label.

  • Directive 2014/24 mentions the following:

    • (75) Contracting authorities that wish to purchase works, supplies or services with specific environmental, social or other characteristics should be able to refer to particular labels, such as the European Eco-label, (multi-)national eco-labels or any other label provided that the requirements for the label are linked to the subject-matter of the contract, such as the description of the product and its presentation, including packaging requirements. It is furthermore essential that those requirements are drawn up and adopted on the basis of objectively verifiable criteria, using a procedure in which stakeholders, such as government bodies, consumers, manufacturers, distributors and environmental organisations, can participate, and that the label is accessible and available to all interested parties. It should be clarified that stakeholders could be public or private bodies, businesses or any sort of non-governmental organisation[…​].

    • (23) ‘label’ means any document, certificate or attestation confirming that the works, products, services, processes or procedures in question meet certain requirements;

    • (24) ‘label requirements’ means the requirements to be met by the works, products, services, processes or procedures in question in order to obtain the label concerned.

  • CCCEV should be revised and compared with the actual modelling of Environmental/Social labels.

  • Information Concept (CCCEV) seems to be a Label concept, based on the definition.