Working Group meeting

Date: 15/02/2022
Participants: Cecile Guasch, Giorgia Lodi, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Natalie Muric


  • Discuss current issues and old decisions related to Amount and Value classes

Approved implemented changes

  • Rename epo:Value class to epo:MonetaryValue class.

  • Maximum and Minimum attributes were proposed to be used as predicates: epo:hasMinimumAmount and epo:hasMaximumAmount; and epo:hasOverallAmount.

  • Delete epo:Amount class and use epo:MonetaryValue class instead which has amount number and currency attributes.

  • The source of the relations epo:hasEstimatedUserConcessionRevenue and epo:hasEstimatedBuyerConcessionRevenue have been moved from epo:Lot to epo:TenderLot. This is in accordance with eForms Regulation (BT-160 and BT-162).

  • Attributes from epo:StatisticalInformation, epo:hasLowestReceivedTenderLotValues and epo:hasHighestReceivedTenderLotValues, become relations to epo:MonetaryValue. (BT-710 & BT-711)

  • Contract class has no value(s). This is in line with the eForms regulations. Note: It is the ContractTerm and Framework Agreement Term classes that may have specified monetary values. (BG-310 does not require value) Note: The contracts have values in some datasets (to be investigated which ones and to be decided at a later stage: e.g. tender lot awarded value becomes the contract awarded value).

  • Subcontract class is deleted because current forms and eForms do not require it.

Old model:


New model:



Introduction of discussions last June on Monetary value and previous discussions on subcontract
Presenting how the sandbox implements Monetary value.
It is agreed with the WG the RevenueConcession concepts are transformed into predicates

Statistical information is looked at and the plurals are to be made into singular.
It is agreed to have a predicate hasHighestReceivedTenderlotValue from StatisiticalInformation to MonetaryValue (the same for LowestReceived….)
This was agreed as the Tender is specifically mentioned in the Notice.

It seems that Contract is not specifically mentioned in the eForms. It should be checked with DG GROW if this is because it can be implied from the TenderValue.

Discussion whether the aggregate of contract values in the notice should be considered in the ontology

It should be noted that the consumption of the Contract will need to be shown in future versions of the ontology.

In Italy:
HasEstimatedValue is in planning
HasMaximumValue is in the tendering
HasAwardedValue is in Awarding
Has MaximumEstimatedValue in Contract (not sure if correct)

This shows we should pay attention to situations, without meaning that process modelling is needed.

This is represented in the SubcontractingEstimate class that the WG accepts along with the removal of the subcontract class that can be reintroduced if a use case is provided at a later stage.
It is noted furthermore that the subcontract is not mentioned in the contract (though this should be confirmed by other MS).