Cumulative content of Working Group Meetings in 2025

Date: 15/04/2025  
Participants: Natalie Muric, Pietro Palermo
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

eForms Requirements:
Discuss eOrdering requirements.
- Implement Item property code for ePO #773
- To address dct:issued and any other date/time concepts.
- Present diagrams for OrderChange, OrderCancellation, OrderResponse, and OrderAgreement.
Discuss eFulfilment requirements
- Model Fuel Consumption business group from the Despatch Advice data model #660 *

Discussion

The eOrdering requirements were discussed:
- All the new diagrams were reviewed.
- OrderCancellation CM diagram: To delete generalizations to OrderCancellation so it is harmonized with the OrderChange CM diagram.
- dct:Issued attribute representing both date and time was discussed. Thw WG concluded that It is ok to just use dct:Issued in the Ontology to represent both date and time.
- It was decided that the Implement Item property code for ePO #773 ticket can be moved to ePO 5.1.0.

eFulfilment requirements:
- Model Fuel Consumption business group from the Despatch Advice data model #660:
  - It was decided that this ticket will be moved to ePO 5.1.
  - To investigate whether this is related to the EED concept from the eForms Annex.

The following github issues for ePO 6.0.0 were discussed.
- epo-sub:ESPD should be a specialization of epo:QualificationResponse #699
  - It seems that there is a problem between PEPPOL pre-award data model terms and UBL. Perhaps the problem is that they are using an older UBL specification.
  - It was mentioned that qualification response is the UBL equivalent to the ESPD and not its specialization.
- epo-acc:ESPDRequest should be a specialization of epo:TendererQualificationSubmission #700
  - It was mentioned that UBL’s Qualification Application Request is the UBL equivalent to the ESPDRequest.
- Remove Predicate epo-sub:relatesToESPDRequest #701
  - The https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=CELEX:32016R0007 regulation was discussed. After consulting the regulation the WG concluded that an ESPD does not necessarily require an ESPD Request. This is due to the fact that in many cases someone creating an ESPD will often use premade ESPD templates and will not need to create an ESPD Request.
- epo:indefiniteDuration to be deprecated #587 was discussed.
  - it was agreed to remove epo:IndefiniteDuration while aligning with Time Ontology for ePO 5.0.0.
  - It was decided that there is a need to represent indefinite durations for standard forms for epo 5.2.0. Thus, a relevant ticket will be created.

Review related issues:
- How is the relationship between epo:ReviewDecision and epo:ReviewRequest represented in eForms? #777
  - From a business point of view, the review decision should answer a review request and that’s why we are keeping the cardinality 1 for this release, and redescuss this in the context of alignment with eForms in a future release.
  - The ticket was moved to ePO 5.1.0.

It was decided that the following issues will be moved to 5.1.0:

It was decided that Problem with associations from Tender to Lot and LotGroup #683 will be moved to 6.0.0 as further discussions are needed as to whether a change is required in the Ontology.

Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726 : Although all the changes to the Ontology needed to accommodate the unmappable fields were implemented, they need to be reviewed.

Announces vs. RefersTo #781 discussion: The WG decided to create a spreadsheet that indicates what predicate should be used for each Notice – Entity pair.

Action Points

Update the Mappings to the eOrdering data models.
- Update OrderCancellationConfirmation and OrderCancellationChange mappings.
- Update the concepts related to the Time Ontology.
Create a Github Issue: The ESPD should become independent of the ESPD request. link it to #701 Remove Predicate epo-sub:relatesToESPDRequest
To follow up with the open Github issues on eCatalogue.
create a Github Issue: We need a way to represent indefinite durations for standard forms for 5.2.0.
Create a spreadsheet for Announces vs. RefersTo #781
Create a Github issue to model E1 (premarket consultation) notice.
To review Unmappable eForms fields in PIN, CEI and T02 notice subtypes #726.

Working Group Meeting

Date: 08/04/2025
Participants: Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

OrderResponse field BT-ORL-5 Maximum backorder quantity was discussed:
- Predicate epo-ord:hasBackOrderQuantity [0..1] was added from epo-ord:OrderResponseLine to epo:quantity.
OrderResponse field BT-ROL-2 Referenced Order line status code was discussed.
OrderCancelation
- OrderCancelation became a postAwardDocument.
- Predicate Linking epo-ord:OrderCancellation with Order was changed from epo:isSubmittedFor to epo-ord:isSubmittedForOrder.
- It appears that we do not need the predicates pointed out below. This needs to be discussed further in a future WGM.

OrderChange
- OrderChangeRejection and OrderChangeConfirmation became PostAwardDocuments.
- To compare the implementations ofOrderChange and OrderResponse in a future WGM and decide what is the better one.

It was agreed that the OrderResponseConfirmation, OrderResponseRejection and OrderResponseSimple data-models can be modelled using epo-ord:OrderResponse.
For attribute epo-ord:hasDownloadURL, the following definition was added: "Location where the resource can be downloaded".
ePO tickets 743 and 611 were described, answered and closed.

Working Group Meeting

Date: 03/04/2025  
Participants: Natalie Muric, Thomas Peterson, Kok Wim
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss the mappings between fields from the TC440 Order Data model to ePO concepts.

Discussions

Field BT-OHI-6 : The field represents a reference of the Order. We are going to delete the existing epo-ord:hasCustomerReference attribute, and turn it into a predicate connecting epo:PostAwardDocument to adms:Identifier.
- Definition: "A supplementary reference used to identify the Buyer’s internal process."

Field BG-ADR: Question: Is this a Document, or a PostAwardDocument?
- Answer: It should be placed at the level of the Document.
Field BG-IPSP: What role should we use for that? We should create the epo-ord:Invoicee role and not just use buyer as mentioned in https://docs.ted.europa.eu/epo-wgm/notes/2023-02-21-eord.html#_agenda.
- Class epo-ord:Invoicee was created as a subclass of the Acquiring Party.
  - Definition: "The Role of an Agent who receives and processes the Invoices."

Predicate epo:specifiesInvoicee was added.

caCADlQAAAAAAAXUAA9IGZ2UVCAB43tWqvAPsACADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOVAAAAAAABdQAD0AQjAfgYCQDkQAAAAAEAXEAB9AAKwn4EAUA4EAAAAANAFBEAfgADsZyAAlAMBAAAAAHQBAdAHIAD7GQgA5UAAAAAAAF1AAPQBCMB+BgJAORAAAAAAQBcQAH0AArCfgQBQDgQAAAAA0AUEQB+AAOxnIACUAwEAAAAAdAEB0AcgAPsZCADlQAAAAAAAXUAA9AEIwH4GAkA5EAAAAABAFxAAfQACsJ+BAFAOBAAAAADQBQRAH4AA7GcgAJQDAQAAAAB0AQHQByAA+xkIAOX8H1mYLgD6ti2QAAAAAElFTkSuQmCC

Predicates epo:exposesInvoiceeChannel, and IndicatesInvoiceeContactPoint from epo:Buyer were removed.

Field BT-ODI-1-4-8
- At the level of epo-ord:DeliveryInformation, attribute epo-ord:hasDeliveryEmail was created.
  - Definition: "The electronic address to which the products or services are to be delivered."
Field BG-ODT: the solution provided in the ePO Github issue #623 was explained.
- Attribute epo:GeneralDeliveryTerm was renamed to epo:hasGeneralDeliveryTerm
- locn:geographicName should be used for BT-ORDT-3 instead of an identifier.
- Field BT-ORDT-4 was discussed.
  - epo-ord:hasRequestedShippingPriority was removed from epo-ord:DeliveryInformation, and was put under epo-ord:DeliveryAgreement
ePO Github issue #767 was discussed and marked as completed for the fields:
- BT-OAI-6-4 "Order allowance Exemption reason text"
- BT-OAI-6-5 "Order allowance VAT exemption reason and specification code".
- BT-OCI-6-4 "Order charge Exemption reason text"
- BT-OCI-6-5 "Order charge VAT exemption reason and specification code".
Field BT-OTO-5 in Github Issue #696 was discussed, updated and closed.
Field BT-OL-6-5 should only be used in the Order Change. Was removed.
Field BT-OL-10 implemented as discussed in Github issue #766, and the solution provided was acknowledged by the Working Group.
Field BT-OL-11: It was decided to re-use attribute epo-ordhasAccountingCost at the level of the OrderLine.
Field BT-II-10-3: To create a GitHub issue to ask about the ItemNameCode. (Code for the item property according to a property code system)
Fields: BT-OAHI-10, BT-OCAREHI-10, BT-OCACOHI-10, etc. :It was agreed that we shall use attribute epo:hasAdditionalInformation at the level of epo:Document for these fields.
The diagrams for the OrderChange, OrderCancellation and OrderAgreement were presented:

Order Change diagram

Order Cancellation diagram

Order Agreement diagram.

Regarding Order Response:
- Proposal to change epo-ord:hasAcceptanceStatus predicate from OrderResponseInformation to epo-ord:hasStatus
- Predicate ImplementsContract from OrderResponse was deleted as it was not in use.

Action Points

To Reply to #695
Add a github issue for Item Property code.

Working Group Meeting

Date: 27/03/2025  
Participants: Victorio Bentivogli, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss the eOrdering module extensions:

Discussions

The Order Response, Change, Agreement and Cancelation data models were discussed and their respective ePO diagrams were presented.

The Order Cancelation diagram was developed, containing the new Classes epo-ord:Cancellation, epo-ord:OrderCancellationRejection and epo-ord:CancellationConfirmation as seen on the diagram below:

OrderAgreement: The Working Group struggled to understand this concept, and what is the difference with Order. After consulting PEPPOL’s OrderAgreement data model, the Working Group concluded that Order Agreement is an alternative Order.The diagram for the Order Agreement is displayed below:

Predicate epo-ord:comprisesOrderLine, linking epo-ord:Order to epo-ord:OrderLine became epo-ord:comprises in order to be used by all subclasses of epo-ord:Order and epo-ord:OrderLine.
epo-ord:hasStatus was added at the level of epo-ord:OrderLine so it can be referenced by the epo-ord:OrderChangeLine if needed.
Classes epo-ord:OrderChangeRejection and epo-ord:OrderChangeConfirmation were added as seen in the diagram below:

Working Group Meeting

Date: 25/03/2025  
Participants: Victorio Bentivogli,Veit Jahns, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss the Following Github Issues:
- #744 (eCatalogue)
- #730 (eCatalogue)
- #722 (eCatalogue)
- #549
- #764
- #605
- #662
- #610
- #743
- #443
- #611
- #623

Discussions

Issue #744 was discussed: Attribute epo:hasCalculationMethod was added to the class epo-cat:EnvironmentalEmissionInformation.

Issue #730 was discussed:
- We use the same Attribute for eOrdering and eCatalogue, both at the level of the OrderResponse, Catalogue Response, CatalogueResponseLine thus a more general definition is required.
- Definition of epo-ord:hasResponseDescription was modified to: "Explanation of the response".
Issue #722 was discussed: The expert for the Catalogue concepts was pointed to the issue for review.
Issue #549 was discussed: epo:hasProcurementScopeDividedIntoLot Definition was updated to: “Defines Lot”.
Issue #605 was discussed: it was agreed to remove attribute epo:hasOJSType and change the datatype for epo:hasOJSIssueNumber from xsd:integer to rdf:PlainLiteral
Issue #662 was discussed: Since in eForms, the Subcontractors are referenced at the level of the Organization, as of ePO 5.0.0 the following implementation is adopted:
- Removing epo:foreseesSubcontractor and epo:specifiesSubcontractors predicates between epo:Tender and epo:Subcontractor and use org:Organization epo:foreseesSubcontractor epo:Subcontractor.
- Keeping epo:Contractor epo:foreseesSubcontractor epo:Subcontractor and epo:Contractor epo:hasSubcontractor epo:Subcontractor since they might be used in a future use-case.

Issue #610 was discussed: The name of the concept epo:VehicleInformation was changed to epo:CleanVehicleDirectiveInformation as depicted below:

$wNa0YAQsC4bRQAAAABJRU5ErkJggg==$

Issues #743 and #443 were discussed: epo-ord:hasAcceptanceStatus was renamed to epo-ord:hasResponseStatus.

Issue #623 was discussed:
- The ePO team prefers not to have the at-voc-new:document-type code list on the level of epo:Document, but a new Class for each of the concepts mentioned in the code-lists.
- It was argued that currently there is no need to change this as this code list is used to reference a number of additional documents.
- Maybe that code list could be trimmed so we can only have relevant values.
- There should be examples of that codelist.
- Predicate epo:documentUsedInPublicProcurement was renamed to epo:hasDocumentType.

Action Points

Create a ticket to get all the values that are relevant to procurement that the at-voc-new:document-type code list contains.
Fix Issue #623 and create another issue about Document status if needed.

Working Group Meeting

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

Agenda

Discuss epo 5.0.0 github issues.

Discussion

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

epo:hasCurrency cardinality was changed from [0..1] to 1.

0SEAAAAAOAvoEAAAAOBLoEMAAACAL4EOAQAAAL4EOgQAAAD4EugQAAAA4EugQwAAAIAvgQ4BAAAAvgQ6BAAAAPgS6BAAAADgS6BDAAAAgC+BDgEAAAC+BDoEAAAA+BLoEAAAAOBLoEMAAACAL4EOAQAAAL4EOgQAAAD4EugQAAAA4EugQwAAAIAvgQ4BAAAAvgQ6BAAAAPgS6BAAAADgS6BDAAAAgC+BDgEAAAC+BDoEAAAA+BLoEAAAAOBLoEMAAACAL4EOAQAAAL7kP+Krerdl9SmeAAAAAElFTkSuQmCC

Issue #643 was discussed:

epo-cat:hasTaxScheme cardinality was changed from [0..1] to 1.

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

Action Points

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.

Working Group Meeting

Date: 18/03/2025  
Participants: Victorio Bentivogli, Natalie Muric, Giovanni-Paolo Sellito
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss new Github Issues related to eForms.

Discussions

Issue #757 was discussed

After checking eForms fields BT-808 and BT-807, predicate epo:specifiesReviewRequester was added on the level of epo:ReviewDecision.
Maybe in the future we can replace predicates epo:specifiesReviewer and epo:specifiesReviewRequester with just an epo:specifiesRole predicate.

Ue6HYh50Qz9jKIgDgHcMwWv7oeTbFHwE3mI4BkErnrt96uLG5LR8AQONwG1BoigCAd7gNqCJ0DACrUsnmCia32gCgEgIAmvohn816vEIuV7G4L6wfEQCK0DEAAEBBBEBV4lUmHI3vBqO83CvrP2y9PojmltZCAAAAAElFTkSuQmCC

Issue #756 was discussed.

Class epo:ReviewInformation was created.
Predicate epo:relatestoEFormsSectionIdentifier was added with domain epo:ReviewInformation and range adms:Identifier.
Attribute epo:hasElementReference was removed from epo:Document and added to epo:ReviewInformation.
Predicate epo:resolvesReviewRequest was renamed to epo:answersReviewRequest.

S3AwCAfggARREAkggAAACACAJAUQSAJAIAAAAgggBQFAEgiQAAAACIIAAURQBIIgAAAAAiCABFEQCSCAAAAIAIAkBRBICkX1C8nmEmaczjAAAAAElFTkSuQmCC

Issue #761 was discussed.

Indeed code list at-voc:received-submission-type seems to be redundant.
All the values of the code list were analysed and it was made sure that for each value of the code list there is an attribute on class epo:SubmissionStatisticalInformation that represents it.
The codelist at-voc:received-submission-type was removed.

Issue #762 was discussed.

epo:ProcedureSpecificTerm, epo:ContractSpecificTerm and epo:LotSpecificTerm classes were deleted and all terms that were specialisations of these classes are now specializations of epo:Term.

PyMmJiM2lrHvazHs6y49Jjo7Ib7h2TMCgAAAAKxv7snJkcHBYYtFWodOV1NVxRhjHldfV7fw6p8AAADgOzE0NLT0f3cA+AgCAACA7wEBAGCNCAAAAL4Hb968mQOANVj9nw+REAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgEAIAAAAAEAgBAAAAAAgEAIAAAAAEAgBAAAAAAiEAAAAAAAEQgAAAAAAAiEAAAAAAIEQAAAAAIBACAAAAABAIAQAAAAAIBACAAAAABAIAQAAAAAIhAAAAAAABEIAAAAAAAIhAAAAAACBEAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgEAIAAAAAEAgBAAAAAAgEAIAAAAAEAgBAAAAAAiEAAAAAAAEQgAAAAAAAiEAAAAAAIEQAAAAAIBACAAAAABAIAQAAAAAIBACAAAAABAIAQAAAAAIhAAAAAAABEIAAAAAAAIhAAAAAACBEAAAAACAQAgAAAAAQCAEAAAAACAQAgAAAAAQCAEAAAAACIQAAAAAAARCAAAAAAACIQAAAAAAgRAAAAAAgED+B9iSzjYA55BBAAAAAElFTkSuQmCC

However, there are diagrams that show different points of view of specific terms. Eg, all the terms that were under epo:ProcedureSpecificTerm appear on a specific diagram as seen below. To discuss the business value for these diagrams in the future.

nz50nzPQLwJwDc8G1F9BuBAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACvCAgAAAAAAAAAAPCKgAAAAAAAAAAAAK8ICAAAAAAAAAAA8IqAAAAAAAAAAAAArwgIAAAAAAAAAADwioAAAAAAAAAAAACviP8CeNn0EpPhcDMAAAAASUVORK5CYII=

Terms related to Procedure

Terms related to Lot

Terms related to Contract

Action Points

To create a diagram with all the relationships of epo:LotGroup

Working Group Meeting

Date: 11/03/2025  
Participants: Victorio Bentivogli, Paul Donohoe, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Achilles Dougalis

Agenda

Discuss new Github Issues related to eForms.

Discussions

Issue #754 was discussed:

The problem with the ticket is that apparently the ND-ModificationSection is repeatable.
The Modification Justification Vocabulary was consulted.

A possible solution would be to extend the cardinality for the predicate (referring to Modified Notice Part Reference).
A use case was given: When the publications office changed name to OP, all the contracts had to be amended.
- Based on that, each contract will have a single epo-not:ContractModificationNotice.
Predicate’s epo:relatesToEFormSectionIdentifier linking epo-con:ContractModificationInformation to adms:Identifier. cardinality was changed from [0..1] to [0..*].

Issue #758 was discussed:
- A Contract always mentions Lots not LotGroups.
- Are there actual notices with Groups of Lots? just a few but most were not done correctly.
- It makes sense to have a Tender for a group of lots.
- A predicate epo:concernsLotGroup connecting epo:ContractLotCompletionInformation with epo:LotGroup was added.
- Predicate epo:describesLotCompletion was renamed epo:concernsLot.