Finish the Evaluation conceptual model

The Evaluation instance diagram (depicted below) was presented. The Evaluation instance diagram explains how the evaluation of 3 Tenders for a single Lot will be represented as a graph.

The Evaluation Diagram (seen below) was further discussed: Previously the epo-eva:TenderReceiver role was connected with the Tender. After the discussion it was decided that all roles should only be connected with Procurement Objects via the epo:contextualizedBy predicate. The epo-eva:TenderReceiver was subsequently removed for the Evaluation Diagram.

It was discussed how to connect the tender classification request diagram (shown below) with the evaluation diagram (above). The proposed solution (already depicted in the diagram above) was accepted.

Issue #712 was discussed. Specifically, the attribute” epo:maskedProperty” should be renamed as “epo:MaskableProperty”, and the predicate “epo:concernsNonPublishedFieldValue” should be renamed as “epo:concernsMaskedObject”.

Create a Github Issue: Are the predicates for the roles needed ? The roles should be self-explainable. To re-evaluate how roles are connected with other objects in the ontology. The role should be linked with a procurement Object. (epo:contextualized by) and not by an action that the role will be doing.

#591

#710

Discuss whether this should go into the alignment section #714

Discuss #711

Take a decision for #715

Take a decision for #680

Discuss #713

#679

Discuss updates #712

#726 was discussed.

#591 was implemented.

#710 : OrganizationalUnit was added to the Ontology.

#728 was discussed, and each participant gave their view on the subject.

#680 was discussed. The cardinality of epo:isSubjectToProcedureSpecificTerm was relaxed to [0..*].

#679 was discussed: The cardinality of epo:hasAwardCriteriaStatedInProcurementDocuments was relaxed to [0..1]

Regarding #715:

#711 was discussed and the issue was updated. It still needs to be discussed with the eForms team.

#713 was discussed.

Present Evaluation Diagram

Regarding the "evaluation roles" diagram:

The "evaluation criteria" diagram was created, in order to represent the criteria of the evaluation document.

Create github issue: Review all the roles of the ontology to see which module they belong to. (for epo 5.00).

To investigate the advantages of the different epo prefixes that exist for each module, and if there is value in keeping them, rather than only having the epo: prefix.

To update the ORSD based on how the diagram was changed.

Create an instance diagram for MEAT (most economically advantageous), at least 3 tenders , at least 4 criterion in the technical offer. Each technical criterion has 25% , 1 value in the financial offer.

To discuss definitions for epo:resultsFromMiniCompetitionAwardOutcome and epo:FurtherStageAwardOutcome in a future WGM.

re-discuss #592

#678 - find definitions for both predicates (epo:definesEstimatedContractDuration and epo:definesContractDuration) in the next WGM

Issuehttps://github.com/OP-TED/ePO/issues/712[ #712] was discussed again. Predicates were modified,

It was noted thatIn eForms, under specific circumstances such as the re-publication of a Notice , a newly published notice may use the same Unique identifier of an older Notice (for Example, case with unpublished fields). However, the field OPP-010-notice changes (mapped in epo as epo:Notice / rdf:PlainLiteral |?this epo:hasNoticePublicationNumber ?value ) will have a different value, and could be used to differentiate between the two notices.

https://github.com/OP-TED/ePO/issues/678[#]678 was discussed. The following definitions were added:

#592 was updated: "epo:hasEstimatedDuration" definition:
"Relation indicating a Dynamic Purchase system has an estimated duration".

The following predicates definitions were changed:

#708 was updated

Ask the eforms team to create rdf data examples of BT-195( 106) using the model described in Issue #712

Investigate why a Tender is supported by only one ESPD response

It was mentioned that the epo-eva:EvaluationReport is very similar to the epo:TenderAwardOutcome. To be decided in the future if we need to keep both of these concepts.

Could the evaluation and the award criteria be different ? To be discussed in the next meeting.

It was discussed that indeed, 1 ESPD can be used for one or more Tenders. Consequently, epo:Tender epo-eva:isSupportedBy epo-sub:ESPD cardinality was changed from [1] to [1..*] .

It was mentioned that sometimes the Evaluation committee could be a system rather than a group of people. It was decided that it is going to be implemented only as a group of people for now.

As seen in the pictures below, further changes were made to the diagrams presented in the 20241119 WGM.

Ticket https://github.com/OP-TED/ePO/issues/686 was updated:
Implement predicate epo:foreseesSubcontractor [0..*] having the following definition:

Clarify unpublished fields ticket (#712) and discuss the potential solutions.

It was explained that the problem is that currently unpublished fields cannot be mapped. To resolve that, the unpublished information needs to be properly modelled in the ontology.

It was clarified that the unpublished information is described using the following four business terms described here:

It is required to provide a way to describe different procurement concepts (like LotAwardCriteria) with these dedicated fields.

SDK explorer was used to identify fields that the unpublished information applies to. Relevant term identifiers contain the hidden field identifier in the parenthesis (for example "BT-195(BT-5422)-Lot").

The eForms expert explained that in XML representation the relevant fields can have special value to indicate that the information it’s not published (for example "-1" for monetary value).

It was concluded that it is required to map concepts as well as values.

The approach was further discussed. It was clarified that suitable object properties are required to link an ontology concept to unpublished information (epo:NonPublishedInformation class).

It was clarified that concepts that are in the scope of interest need to be treated independently (not associated with the Notice). NonPublishedInformation can be described for various concepts and it is not specific to the Notice. However, for the purpose of mapping it is required to make unpublished information reachable via notice.

The eForms expert estimated that there are about 120 unpublished fields as for now.

When discussing the possible approach, it was confirmed that it is sufficient to use a relative path to a value starting from the considered class (mappings).

Discuss about the Evaluation Conceptual Model

It was agreed that the epo:LeadBuyer is a different concept than the epo-eva:UniqueResponsibleOfTheProcurement. The former is a Legal person (Organization), while the latter is a natural Person.

The epo-eva:Evaluator and epo:JuryMember are also natural Persons, so together with eva:UniqueResponsibleOfTheProcurement are played by a person:Person.

It was discussed whether we need to create epo:SelectedCandidate and epo:ExcludedCandidate.

It was argued whether we need an epo:ExcludedCandidateList in the eEvaluation module. If so, it needs to be removed from the eEvaluation ORSD. To be further discussed in a future meeting.

It was discussed whether we need to model each different member of the epo-eva:EvaluationCommittee as mentioned in the eEvaluation ORSD. To be further discussed in a future meeting.

Regarding epo:RelliedUponEntity and epo:NonReliedUponEntities, it was discussed that epo:NonReliedUponEntities should be a specialization of epo-eva:ForeseenSubcontractor

It was agreed that the epo-eva:EvaluationCommittee is appointed by epo-eva:UniqueResponsibleOfTheProcurement.

It was discussed if an epo:Tender has to be connected to an epo-eva:TechnicalOffer. The answer is that this is not mandatory, so the predicate epo:isSupportedBy should have a cardinality of 0..1

It was discussed whether an epo:Tender should be supported by more than one epo-sub:Espd responses, because currently this is modelled as a relation with cardinality of 1.

epo-eva:EvaluationFormula rdf:PlainLiteral attribute was added to the epo-eva:EvaluationReport. It was argued that maybe a controlled vocabulary could be used. See here . A formula should also be a criterion.

It was mentioned that the epo-eva:EvaluationReport is very similar to the epo:TenderAwardOutcome.

It was discussed whether the evaluation and the award criteria should be different concepts.

After the meeting the Activity description diagram looked like this.

Investigate why a Tender is supported by only one ESPD response.

It was mentioned that the epo-eva:EvaluationReport is very similar to the epo:TenderAwardOutcome. To be decided in the future if we need to keep both of these concepts.

Investigate if a controlled vocabulary could be used for representing the formula. See here .

Could the evaluation and the award criteria be different ? To be discussed in the next meeting.

Work on eForms mapping issues. Discussions
The WG worked on the following GitHub tickets:

Update the Guide to the ePO Conceptual Model to include information that class instances are not exported in model2owl artefacts. The instances are represented in EA UML diagram as blue boxes:

Presentation of proposed changes for Tender Clarification Request (T0009) and Tender Clarification (T010) in the CM diagrams and collecting the feedback.

epo:TenderClarification and epo:TenderClarificationRequest were changed to both inherit from epo:Document.

The new epo:specifiesTenderer association was introduced between epo:TenderClarificationRequest and epo:Tenderer.

The decision to replace epo:EconomicOperator with epo:Tenderer was made.

Proposal

Analysis of cac:AdditionalDocumentReference in PEPPOL docs. The WG analysed a relevant example RDF in PEPPOL documentation and found that there is one tender clarification and each answer is an attachment. It was further identified that each response needs to be an annex to a tender clarification:

The WG discussed representation of the epo-sub:Response value.
The proposal was to store it in a dedicated instance of cccev:SupportedValue:

The WG reviewed the eEvaluation ORSD document. It was confirmed that all identified roles described in the document need to be modelled.