Contract conclusion date mapping F20 (Sec V.2.1)

[costezki]

Should we use this mapping, from F03. F06, F21 and F22, or the one from F25? Wouldn't in fact both happen automatically (also for all the other forms), since both mappings are available in the technical mapping and for this given XPAth both mapping will fire? If this is a problem, haw can we deal with it?

[costezki]

In F20 I think if it is a change to the contract it will be contract hasConclusionDate but as I said I will have to look more carefully

[csnyulas]

The concnlusion of our discussion with @muricna was that we should decide based on the Directive. If the Directive 23 is chosen it should be hasAwardDecisionDate, all the others should be to hasContractConclusionDate

[csnyulas]

Looking at the practical implementation of the proposed solution, it seemed like we can decide how to map the value of the AWARD_CONTRACT/AWARDED_CONTRACT/DATE_CONCLUSION_CONTRACT XPATH, based on the VALUE attribute of the LEGAL_BASIS element, as following:

• LEGAL_BASIS VALUE="32014L0024", which appears for F03, F21, and some of F20 -> hasContractConclusionDate
• LEGAL_BASIS VALUE="32014L0025", which appears for F06, F22, and some of F20 -> hasContractConclusionDate
• LEGAL_BASIS VALUE="32014L0023", which appears for F25, F23, and some of F20 -> hasAwardDecisionDate and
• for F13, for both LEGAL_BASIS VALUE="32014L0024" or LEGAL_BASIS VALUE="32014L0025" we would map the value of the RESULTS/AWARDED_PRIZE/DATE_DECISION_JURY XPATH to hasContractConclusionDate.

However, by looking at the rest of all available sample data, we observed that sometimes the <LEGAL_BASIS VALUE> tag has different values than 32014L0023, 32014L0024 or 32014L0025, and sometimes it might even be missing. In such cases, in our (linited) sample data, we found so far:

• <LEGAL_BASIS VALUE="32018R1046"/> for F03 (e.g. see notices 607499-2021, 438840-2022)
• <LEGAL_BASIS_OTHER><P>Direttiva 2014/24/UE</P></LEGAL_BASIS_OTHER> for F03 (e.g. notice 274649-2022)
• <LEGAL_BASIS_OTHER><P>Richtlinie 2014/24/EU</P></LEGAL_BASIS_OTHER> for F03 (e.g. notice 631687-2020)
• <LEGAL_BASIS_OTHER><P>Οδηγία 2014/24/ΕΕ</P></LEGAL_BASIS_OTHER> for F03 (e.g. notice 006737-2021)
• <LEGAL_BASIS_OTHER><P>Reglamento (UE) n.<FT TYPE="SUP">o</FT> 236/2014 del Parlamento Europeo y del Consejo, de 11 de marzo de 2014, por el que se establecen normas y procedimientos de ejecución comunes de los instrumentos de la Unión para la financiación de la acción exterior y el ICD.</P></LEGAL_BASIS_OTHER> for F03 (e.g. notice 135100-2021)
• <LEGAL_BASIS_OTHER><P>Richtlinie 2014/24/EU</P></LEGAL_BASIS_OTHER> for F20 (e.g. notice 251593-2022, 078194-2021)
• <LEGAL_BASIS VALUE="32018R1046"/> for F20 (e.g. notice 309583-2022, 431009-2022)

The examples above show that the actual technical mapping needs to be smarter, and more complex, then just checking for the directive value in the <LEGAL_BASIS VALUE> tag, and we might still not have full certainty that we cover all possible edge cases, and the question remains: "How should our mapping err on such cases?"

[csnyulas]

This is marked as Fixed, as we dealt with the overwhelming majority of the cases (including backwards compatibility with previous versions f the XSD), however before we close it, we would should look at what is the correct way to map the notices that have <LEGAL_BASIS VALUE="32018R1046"/> or LEGAL_BASIS_OTHER that don't refer to D23, D24 or D25.