Working Group meeting
Date: 01/08/2023
Participants: Natalie Muric, Arillo Aranda Paloma, Pascaline Laure Tchienehom,
Model editor: Andreea Pasăre
Note editor: Alexandros Vassiliades
Discussion:
Question:
Can the ESPD Business Handbook (ESPD Request part only) be considered as requirements for eAccessalong with the documentation of ○%09https:/wiki.ds.unipi.gr/display/ESPDInt/BIS+41+-+ESPD+V2.1.0#BIS41ESPDV2.1.0-tbr070-007[ESPDint]?
Conclusion:
Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.
Reuse in the previous sentence implies partial reuse of the content in the xml file. Paloma will ensure the ESPD documentation reflect the meaning of the re-use more accurately.
Requirements of ESPD and eAccess should not be considered the same. We should consider the ESPD Request as part of eAccess. The ESPD Response should be considered part of eSubmission.
Question
Is it necessary for Buyers and Economic Operators to create a new ESPD document for each procedure? Instead, is it possible to re-use an ESPD in different procurement procedures, facilitating the tasks of users.
Conclusion
The Lot is defined at the ESPDResponse level as depicted in the image below:
It would appear that each ESPDRequest has a different identifier for each Procedure concerned which implies that the ESPDRequest as a whole cannot be reused across procedures.
Decision on the first draft of eAcess which was based on the ESPD-EDM
-
A new property from ESPDResponse to ESPDRequest was created (epo-sub:relatesToESPDRequest):
-
ReferenceNumber does not need to be covered in ePO
-
DocumentVersionIdentifier exists as epo:hasVersion at the Document level in ePO
-
The epo:hasPublicationDate at the Document level, but the data type does not permit the time, which is required by the ESPD Request. How to treat dates and times needs to be further looked into.
-
CopyIndicator is not necessary and is not to be implemented in the ePO.
-
The relation between epo:ESPDRequest and epo:Buyer seems an overkill as they are related through the epo:Procedure, therefor this relation was removed.
-
The ESPD requires an identifer for the criteria, which implies cccev:Requirement should be connected through a relation with adms:Identifier. However, CCCEV provides identifiers as a literal therefore it needs to be discussed if CCCEV and ADMS concepts can be implemented in this way.
-
The legislation part for Criterion is implemented as depicted in the image below. However it is necessary to see if there is a better way of modelling for example through ELI (European Legislation Identifier) or as a Document.
Action point:
-
Discuss how to treat dates when we have have differing requirements ie epo:hasPublicationDate with the date data type for the notices, however the ESPD requires datetime data type. No dummy dates can be used in the notices as this could have legal consequences.
-
Check if the cccev:InformationConcept and adms:Identifier can be connected. Can 2 external concepts be connected within another ontology. See below:
-
(cccev:InformationConcept) and (adms:Identifier
-
cccev:Requirement and adms:identifier
-
-
Review modelling of the Legislation