Working Group meeting

Date: 05/11/2024  
Participants: Ioannis Fountoukidis, Natalie Muric
Model editor: Andreea Pasăre
Note editor: Grzegorz Kostkowski

Agenda

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

Discussions

It was explained that a Tender Clarification is not a Procurement Document. Modelling it as such is incorrect due to its limited visibility (availability) compared to the public nature of Procurement Documents.

The WG agreed to introduce the following changes:

  • 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.

ge0j+7LtosR8wAAAABJRU5ErkJggg==
  • Proposal

AzaY8sXZgAAAABJRU5ErkJggg==
  • 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:

5rYmqo167eLAAAAAElFTkSuQmCC

It was also observed that it is possible to provide a file and reference it in a cac:Attachment entity:

wE7eLeCkZWSSwAAAABJRU5ErkJggg==

The accepted version of the diagram:

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

Vk+bQRPAAAAAElFTkSuQmCC

The motivation behind the proposal was discussed. It was explained that it was inspired by the CCCEV model.

kseKkGK8f8DKDsFrQ1v4rUAAAAASUVORK5CYII=

The WG decided to model that in another way. It was decided to store a response value as a new optional attribute. The dct:description was chosen for that purpose and a new attribute for epo-sub:Response was added:

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

The WG worked on the mapping issues with aux:mapping label:

#599
The ticket was closed with the following comment:

kvtHoW4UWWOUUAAAAASUVORK5CYII=

#364
The ticket was closed with the following comment:

oMAADAXf4GnQgIgA8hk5sAAAAASUVORK5CYII=

#640
The ticket was moved to a new column "eForms alignment discussion". The purpose of this column is to hold issues to be discussed during an alignment project meeting.
#663
A few verification steps, as detailed in the action points, are required before continuing work on this ticket.

Action Points

X5AAAAABJRU5ErkJggg==
  • Discuss in pre-award meeting about the modifications (model and mappings) we’ve made taking into account the following:

    • What cac:ParentDocumentReference is? It may be a Call for Tender – to verify

a+D8oNYxixycDc0eb+sSQfwQ6RCc6VxsDRxajzQXN6hco4l9kjO6dF4Dl3GKj+UWabpHWbYHjil0msuli92BA5uFZtUejJa6wwvdIMCGRrQUh5glSyaTTCOzv5lMxh2AvipMPI8rC1tJuGf8POdY1NjEvtJ7NCuFzCfXDP8F1WrHborlLt8AAAAASUVORK5CYII=
  • Model roles and user stories as defined in the eEvaluation ORSD document for the next WG meeting (12/11/2024).