Working Group meeting 02/09/2021

Date: 02/09/2021
Participants: Paloma Arillo Aranda (OP), Eugeniu COSTETZKI (Meaningfy), Cécile Guasch (ISA2 - DIGIT), Hilde Kjolset (dfø), Giorgia Lodi (ISTC-CNR), Natalie Muric (OP), Andrea PASARE (xx) and Giampaolo Sellitto (ANAC)
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Norway’s Database for public procurement (DOFFIN by its Norwegian acronym)

Issues

  1. (4)The JSON file: The description is split into several lines in the JSON file because it is easier to read the HTML file. Same as in the EPO RDF we have several elements <P>. In the construction of the Jason file it is assumed that there is one line per information and it is the result of transforming the file. Giorgia has to check a way to merge all the information in one file.

  2. (1)Zip of all data that are distributes using folders that contain years and month and there is a subfolder per day and then inside each there are atomic files per notice. If we think on DICAT AP a data set that focuses in only ones notice would be weird to be considered as a data set so it was decided to add information. The way that Italy does is a good one so it was decided to do monthly distribution and per notice type. We can share the analysis done by BDTI??? Aligned to Italy, which is also easier to access for humans so that there is a homogeneous set of information. We used the TED mapping to analyse the presentation of the Norwegian data: they stored more information about the notices. In xml file in TED we could not find the information about the notice ID

  3. (2)Main CPV per lot – it seems that in the Norwegian model the ‘additional cpv’ it is mapped to the lot and the the main cpv is mapped at procedure level. In the mapping current forms to eForms the additional is part of the current forms. In the new forms, we should use ‘main cpv’ for both, procedure and lot in the future. Maybe the Norwegian data does not correspond to the current mapping with the ’additional’ classification although this is not used when there is only one lot. In the Norwegian model if there are several lots both, main and additional are used.

Discussion

The JSON file: procedure has main cpv, the procedure has one lot and the additional code is the same as the main but with an additional zero at the end. It seems to be the same hierarchy.

The current form has main cpv as repeateable in the additional cpv section together with supplementary cpv. In the ePO the predicate is ‘main classiffication’. TED current forms: lot = additional cpv. Supplementary is about an additional information about that cpv code in the sense of main additional code.

The solution would be to speak about cpv without ‘main’ and ‘additional’.

In Norway the additional is not a mandatory field, so in some cases te cpv is not there, the same as in the TED data. In the Norwegian dataset the main cpv is mandatory.

In the ePO the main classification is mandatory and additional classification o to several. It is wrong because the situation changed with eFORMS. In the current forms the information is not good enough. In the eForms you can use main and additional in both procedure and lot but for lot is optional. We cannot change the model for the BDTI project so we stick to additional and this will be revised in the new version of model taking into consideration the eFORMS point of view and the current forms.

  1. (6)NUTS codes – it seems that no always the NUTS code is provided in the Norwegian model. It is there but not in the same granularity. In the Jason file there is nothing similar to a nuts attribute. Hilde will investigate and call a short meeting about this issue.

  2. (3)Notice uuid – the Nowegian case there isnno ID but ‘form section uuid’. Norway does not have an Official Journal so there are troubles mapping to the TED dataset. If we have the procedure, we can find it in the TED data and in the Norway notice. The question is whether there is a need to map the contract notice and the contract award notice. The ID is not unique in the Norwegian notices. The DOFFIN number is added because there is one sole place where notices are archived and it is an internal reference number. The hope is that the model and the new EFORMS will bring data quality and that the information will be done almost automatically.