REPORT ON THE 13TH WORKING GROUP MEETING OF THE EPROCUREMENT ONTOLOGY

Q1 meeting

Online meeting: 9/03/2023

Agenda

  • Welcome

  • Release 3.1.0 (December 2022)

  • Work carried out in 1st quarter 2023

  • eOrdering

  • eFulfilment

  • ePO core updates

  • Plan for 2nd quarter 2023

  • eAccess

  • eContract

  • ePO core updates

  • Planned releases

  • Open discussion

  • Closing

Welcome:

Natalie Muric explained the aim of the meeting is to present the work carried out since the last meeting in December and to present the short-term plan for the first half of 2023. Stakeholders’ attention was drawn to the next modules to be evolved, namely eAccess and eContract.
The following sections provide a summary of what was presented and discussed.

Release 3.1.0 (17 December 2022)

Andrea Pasare from Meaningfy presented links covering release 3.1.0:

She then provided a description of release 3.1.0. The release contains:

  • The first publication of an eOrdering module, containing use cases and alignment to PEPPOL.

  • Updates to the eCatalogue module following requests posted on github.

  • Notice systematisation in the eNotice module for standard forms and eForms.

  • Updates to the core:

  • The grouping of epo:Procedure, epo:PlannedProcurementPart and epo:Lot under epo:ProcurementObject which itself is a subclass of epo;ProcurementElement.

  • The roles hierarchy was restructured into 3 types of roles: epo:AcquiringParty, epo:SellerParty and epo:AuxiliaryParty.

  • Updates carried out via the complementary model2owl which transforms the UML diagrams into machine-readable format

  • A combined glossary of all the modules along with the individual glossaries already provided with each module.

  • Turtle output

  • Implementation of a metadata management mechanism.

  • Fixes to issues posted on github for example requirements brought about by the TED-RDF-mapping project which maps the standard forms to the ontology.

Work carried out in 1st quarter 2023

ePO core updates:

The main modifications to the ePO core were highlighted:

  • Differentiating between Procedure and Lot with regard to Criterion.

  • Rethinking the Channel concept.

  • Addition of the Candidate role.

  • A new methodology for treating GitHub issues:

  • Labelling for associated projects such as standard form mappings

  • Labelling for the different modules.

  • Planning of fixes per quarter ie Q1 2023 milestone

Procurement criteria summary

https://github.com/OP-TED/ePO/issues/420
epo:ProcurementCriterion was up-until now modelled at lot level; however in order to map to standard forms the epo:ProcurementCriterion needed to be linked to the epo:Procedure in an aggregated way, therefore the epo:ProcurementCriteriaSummary concept has been added to the model:

f8BhM5iUUbedyAAAAAASUVORK5CYII=

Channel concept

https://github.com/OP-TED/ePO/issues/435 :
The Channel concept was removed from a previous release however when modelling the eOrdering module it was realised that the original modelling made sense. It was noted that further work will probably be necessary on this concept.

vbFfe8H3QIQAAAABJRU5ErkJggg==

Candidate role:

Candidate role was introduced in version 2.0.2. Although it was later removed and was indirectly represented in the attribute epo:hasMaximumNumberOfCandidates within the epo:MultipleStageProcedureTerm concept. Following a request Candidate has been added as a role see: https://github.com/OP-TED/ePO/issues/174 and https://github.com/OP-TED/ePO/issues/436

k6Y6+LXp0uUqcKdSGqTlZZJ4LVLet4ZHUf3E3IUAeEDAAAAAAAAMiExw8emA1GiqKyXYcPHCBkqCFCBgAAAAAAAGSGDhr0GQ1e6Xc0UxSVnfIHDIQMtUHIAAAAAAAAgMzybzZSFJW9QvUIGQAAAAAAAJBZcsORoqhsFapHyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACpCyAAAAAAAAAAAACoSCBkoiqIoiqIoiqIoiqIoiqIoiqLKqf8P5e80rQG36+IAAAAASUVORK5CYII=

eOrdering updates:

epo-ord:eOrdering was published in 3.1.0 release, in the first quarter of 2023 we have been working on the OrderResponse and checking the completeness of the eOrdering modelling against the UBL syntax bindings provided in PEPPOL.
It was noted by a participant that the work goes further than PEPPOL taking into consideration the wider UBL message and expert knowledge coming from CII (Cross Industry Invoice) or elsewhere.

Order

Order comprises multiple orderlines.

OrderResponse

An OrderResponse is submitted for specific order and comprises of Order Response Lines and the diagram below was presented.
It was noted that the OrderResponseInformation is an information hub which was addressed in the previous release making the epo-ord: OrderResponseInformation available either at the header level or the line level.

FLHZH4e2Y0AAAAABJRU5ErkJggg==

eFulfilment:

The development of the eFulfilment model, using the PEPPOL model as the basis started already last year, during the first quarter we have been developing further this model. To have a clear vision of the roles involved in despatch one should look at three main concepts and see how the roles are distributed:

  • epo-ful:Consignment is a transport agreement specifies a Notifier, a FreightForwarder and a Carrier. These three roles have the superclass AuxiliaryParty.

  • epo-ful:DespatchAdvice specifies epo-ful:Consignee, epo-ful:Despatcher and the epo-ful: Originator.

  • epo-ful:ShipmentAgreement is the Commercial Agreement between the Commercial Parties (epo:Buyer and epo-ord:Seller). It was noted by a participant that the roles in general belong to the epo core and are reused across the models, one exception here can be seen in the Carrier which is used for the first time in eFulfilment.
    To ease the visualization and explanation the eFulfilment diagram was broken down for the presentation into smaller diagrams so they are not available as such in the documentation of the ontology.

Ayp+JeHYd4hYAAAAAElFTkSuQmCC

It was explained that epo-ful:DespatchAdvice comprises the epo-ful:DespatchLine and may refer to a epo-ful:Consignment which is a transportation agreement and/or a epo-ful:ShipmentAgreement which is the commercial agreement between the epo:Buyer and epo-ord:Seller..

wF2C6yILlxfswAAAABJRU5ErkJggg==

The epo-ful:Consignment is the main concept in the diagram below and was presented in the meeting. It can be seen that the eCatalogue concept epo-Cat has been reused.:
There are three enumerations associated with the charge information:

  • at-voc-new:allowance-charge-reason

  • at-voc-new:charge-category

  • at-vocnew: charge-modifier The epo-ful:Consignment can have multiple epo-ful:ShipmentStages:

  • epo-ful:hasMainCarriageShipmentStage

  • epo-ful:has OnCarriageShipmentStage

  • epo-ful:has PreCarriageShipmentStage The epo-ful:ShipmentStage is linked to epo-ful:ShipmentInformation through two relations: epo:hasArrivalShipmentInformation and epo:hasDepartureShipmentInformation. epo-ful:ShipmentInformation includes details about the despatchDate and description. Additionally, the epo-ful:ShipmentStage is connected to the epo-ful:TransportMeans, which has a corresponding epo-ful:TransportMode enumeration. The role of epo-ful:TransportMeansOperator is played by a person since there is a need to indicate, for example, the driver’s license. for example the driver’s license.