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.

BXp+rrzng8vOx8tAhAAGFLZSdnBXvayNgAAAOBD9V9vMzoEIAAAAAAAwMj5Yr9VDwAAAAAAgFEiAAEAAAAAAEaOAAQAAAAAABg5AhAAAAAAAGDkCEAAAAAAAICRIwABAAAAAABGjgAEAAAAAAAYOQIQAAAAAABg5PwPkzFDB3wGM0UAAAAASUVORK5CYII=

While modeling, it was found that the epo-ful:TransportHandlingUnit contains multiple packages, one of which is the epo-ful:GoodsItem. Therefore, the epo-ful:AbstractContainer class was created so that the packages could inherit their common attributes, such as epo-ful:hasPackingTypeDescription, epo-ful:isHazardousRisk, and epo-ful:isReturnableMaterial. The epo-ful:AbstractContainer class also provides the possibility for each of the packages to have an epo:Quantity, such as the epo-ful:hasGrossWeight or the epo-ful:hasNetWeight. It also allows each of them to have an epo-ful:TemperatureSpecification, such as epo-ful:hasTemperatureSpecification.
The epo-ful:TransportHandlingUnit is connected by epo-ful:usesTransportEquipment with epo-ful:TransportEquipment, which in turn can use enumerations to cover attributes such as epo-ful:hasTransportEquipmentType, epo-ful:hasSizeType, and epo-ful:FullnessIndicator. Additionally, the epo-ful:TransportEquipment can have an epo-ful:TransportEquipmentSeal.

Ab0211zbCOhlAAAAAElFTkSuQmCC

The epo-ful:DespatchLine in the epo-ful:DespatchAdvice refers to the OrderLine which comes from the eOrdering module and both these lines have commonalities with the Line used in eCatalogue, work is still ongoing on harmonising all the required attributes. There is already an identifier for the lines, and an epo-cat:Line specifies an epo-cat:Item. The epo-cat:Item is reused from the eCatalogue module, along with its associated classes and enumerations. Additionally, a Batch always contains an Item.

2AYhmEYhmEYhmEYhmEYhmEYhtnXkZyHJED+PyXGY5xX9x93AAAAAElFTkSuQmCC

Plan for 2nd quarter 2023

  • eContract module: to ensure coverage of competency questions for Modification and Contract Completion Notices.

  • eAccess module: which will model the ESPD request and procurement documents

  • Continue on ePO core updates:

  • Rethinking of the Procedure and Lot which will affect the whole epo core module

  • Keep fixing GitHub issues for 2023 Q2 milestone

  • model2owl updates

  • Updates for standard forms mappings TED-RDF-mapping

model2owl updates:

  • Update the UML conventions and the related documents.

  • Remove the generative corrective functionality which adds the “has” or “is” prefix attributes that were not originally in the UML diagram, however the UML has now been updated.

  • Revise data type handling: give up UML data types and use epo compliant data types.

  • Remove the data types such as quantity and use for example directly the class Quantity.in association with another class where appropriate

  • Remove the doubled references (attribute and dependency) to code list

  • Update the transformation scripts based on the updates of the documentation:

  • Conventions checking

  • OWL core generation

  • OWL restrictions generation

  • SHACL generation

  • Fix the bugs and the technical debt:

  • Implement automated testing

  • Refactor code for modular organisation

  • Fix handling of unknown prefixes

  • For example: when a concept has a prefix, that is not listed in the model2owl pipeline, the model2owl pipeline creates a dummy prefix, however this is dangerous as it will be present in the RDF file. Thus, we need to enable the pipeline to crash if the namespace is not recognised. This error should be included in the conventions checking report so that we can ensure that the list of namespaces is up to date.

  • Fix handling of multiple domains and ranges for a property

  • Fix handling relations across modules

  • Migrate from PDF documentation to HTML format, to integrate model2owl into the TED documentation along with ePO documentation, meeting notes, etc.

Procedure and Lot model:

During the mapping, it was discovered that procedures such as Dynamic Purchasing System, Qualification System, Framework Agreement, and other multi-stage procedures need to consider the concept of a mini-competition. This concept has a significant impact on the core of ePO. Therefore, an investigation around most of the procedure types that are present in the procurement procedure type authority table from EU Vocabularies has been initiated to find a way of modeling these mini-competitions.

  • Open and restricted procedures without techniques can be classified into two types:

  • Simple Open procedure without techniques: It begins with a Contract Notice (CN), which opens the procedure and concludes with a Contract Award Notice (CAN), which announces the outcome. In this procedure, the competition and qualification phases occur in parallel.

  • Simple restricted procedure without techniques: Similar to the Simple Open Procedure, but in this case, the qualification phase occurs first, followed by the competition phase.

2Q==

  • A Procedure with Dynamic Purchasing System (DPS) technique is used only for restricted procedures. It starts with a Contract Notice (CN) and ends with a Contract Award Notice (CAN) for the termination of the DPS. The DPS technique has two stages: DPS stage 1, which is the qualification phase, and DPS stage 2, which contains multiple mini-competition stages that can be launched until the DPS is terminated. In the qualification phase (Exclusion Grounds and Selection Criteria), any new economic operator can apply until the termination of the DPS. However, the competition happens only in the next stage of the DPS via mini-competitions for those economic operators that have already passed the qualification phase.

Z

  • A Procedure with Framework Agreement Technique can be used in many types of procedures. It starts with a Contract Notice, followed by the first stage of the Award of the Framework Agreement. This stage includes the qualification and competition phase, the result of which is published in a Contract Award Notice. The next stage of the procedure is to carry out mini-competitions or orders with the awarded economic operators of the first stage. This second stage may or may not result in a Contract Award Notice, depending on the outcome.

Planned releases:

In the future pre-releases will be published and stakeholders will be notified when the pre-release is published giving them time to review and send remarks by email or Github.
v3.2.0 - eFulfilment, updates on eOrdering and ePO (pre-release in April 2023, release in May 2023). After meeting note: There will not be a v3.2.0 release the foreseen changes will be integrated into release 4.0.0
v4.0.0 - ePO core big updates, (Procedure & Lot, terms, purpose and so on), model2owl updates, eContract (pre-release in June 2023, release in August 2023)
v4.1.0 - eAccess, eSubmission, other core + module updates that may arise from GitHub issues (pre-release in November 2023, release in December 2023).

UAqYMvHQ1nAAAAAElFTkSuQmCC

Open Discussion

There was a suggestion to coordinate with the DTLF (Digital Transport and Logistics Forum) whose main area of work is to provide technical assistance for the implementation of Regulation (EU) 202/1056 on Electronic Freight Transport Information. In the near future they will be modelling the waybill which PEPPOL will need to implement.

Closing:

Natalie Muric of the Publications Office presented the next meeting schedule for ePO:

  • Regular ePO Working Group meetings:

  • every Tuesday from 14:30 to 16:30 (EET)

  • meeting link

  • Specific ePO Working Group meetings:

  • every other Thursday from 14:30 to 16:30 (EET)

  • meeting link

  • Quarterly seminars:

  • Tues 13 or Thurs 15 June (afternoons) - After meeting note 27th June

  • Tues 5 or Thurs 7 September (afternoons)

  • Tues 5 or Thurs 7 December (afternoons)

Any comments on the documentation?

Click here to let us know