Working Group Meeting

Date: 20/03/2025  
Participants: Victorio Bentivogli Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

It was discussed that a new alignment with PEPPOL for eORdering effort has started, regarding Order change, Order response and Order Agreement.

Issue #641 was discussed

Issue #643 was discussed:

Issue #575 was discussed:

Properties epo-ful:hasOnCarriageShipmentStage and epo-ful:hasPreCarriageShipmentStage were deleted.

Property epo-ful:hasMainCarriageShipmentStage was renamed to epo-ful:hasCarriageShipmentStage.
Definition of epo-ful:hasCarriageShipmentStage was modified to: "The Shipment Stage for the last mile covered in a transport chain."

Issue #765 was discussed:

The main question is, if from a Business point of view, the Financing and Payer party should be at the level of epo:LotResult or at the level of the Result Notice.
They were put on the epo:LotResult Level because not all Lots mentioned in a Result Notice are always awarded.
It was discussed that this issue could be treated in ePO 5.1.0.
Finally, it was agreed that epo:BudgetProvider and epo:PaymentExecutor should be mapped using epo:AgentInRole epo:conceptualisedBy epo:Lot. It can also be used for a epo:PlannedProcurementPart and epo:Procedure since they all are subclasses of epo:ProcurementElement.

The following eForms fields were discussed in the context of their mappings to ePO:

Field OPT-093-Review: An Identifier for a Review. It was not defined well, and no one has used this as of now (no data).
Fields OPA-36-Lot-Number, OPA-98-Lot-Number, OPA-36-Part-Number: These are Attributes of other fields currently not in use in eForms. They were designed to hold a number, but were discarded because eForms typically uses 2 fields to do this: One field has the measure and is coupled with another field that has the unit value.

Issue #549 was discussed:

Another option is to rename epo:hasScopeDividedIntoLot to epo:aggregatesLot.
The issue was left open to be discussed in a future WGM.

Issue #763 was reviewed.

There was a second request in the ticket:
- "Also, the epo:definesTenderProcessor, epo:definesTenderReceiver, epo:definesProcurementProcedureInformationProvider and epo:definesOfflineAccessProvider and some new epo:definesXXX properties could be added to link all the above roles to epo:PlannedProcurementPart, without the need to instantiate the epo:AccessTerm and epo:SubmissionTerm classes."
- The following answer was given to the above question: "Regarding the second request, since those roles are defined at the level of epo:AccessTerm and epo:SubmissionTerm in the case of a epo:Lot, we will keep the same implementation for a epo:PlannedProcurementPart."

Issue #764 was briefly discussed.

A a number of attributes and Predicates were moved from the level of epo:ProcurementObject and epo:Lot, to the level of epo:ProcurementElement, in order to them usable by epo:PlannedProcurementPart.
A more detailed explanation on the changes will be given as a comment of Issue #764.

Diagram showing the Ontology before the modification

Diagram showing the Ontology after the modification

To discuss #765 with the eForms team.
- The main question is, if from a Business point of view, the Financing and Payer party should be at the level of LotResult or at the level of the Result Notice:
- Edit: It was agreed that the epo:BudgetProvider and the epo:PaymentExecutor should be mapped using epo:AgentInRole epo:conceptualisedBy epo:Lot. It can also be used for a epo:PlannedProcurementPart and epo:Procedure since they all are subclasses of epo:ProcurementElement.