Working Group meeting 01/02/2022

Date: 01/02/2022
Participants: Cecile Guasch, Hilde Kjølset, Giorgia Lodi, Natalie Muric, Giovanni Paolo Sellitto
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Update HTML version of model-refactoring branch with new diagrams of documents and present them to the WGM.

Discussion

  • Do we have abstract classes or not? Because abstract classes are not instantiated, it is ok to have them since they won’t generate new URIs. Do we really need all these classes for the requirements (standard forms)?

  • Requirement:

    • It should cover eForms, and current forms if possible

    • It should cover notices, eOrdering and eCatalogue.

  • Nothing regarding the payment or submission in the data. Only regarding the result of these actions.

  • A request for providing some more information regarding the new proposed model was made.

  • Besides eForms and standard forms, there is some BDTI data from the Italian and Norwegian side.

  • We concentrate on stabilising this for eForms and Notices and then challenge the model to include some use cases that are not there.

  • There are some use cases where the roles are not defined that well.

  • We should find a small set of data that fit most of the use cases.

  • We don’t know yet if every info from the current forms can be mapped to eForms.

Notice core module

wGPc4JF5ncdBwAAAABJRU5ErkJggg==

  • epo:hasLegalBasis is for the Procedure or for the Notice?

  • It is the content of the document that matters, so the Procedure should have a legal basis.

  • If we have this at the PRocedure level we could assure a robust approach.

  • There is an exception if we have only a PIN and not a Procedure, so we will talk about a project.

  • The fact that notice types belong to a legal basis is something that is part of the internal system that has to choose the notice type.

  • It is good to analyse which notice type is needed where but it is not needed to express the public procurement information.

  • Presenting the eForms mappings.

  • The mappings to the Notice content should not be part of the ePO. We are doing this low-level exercise to discover if the current model can express everything.

Questions:

  • If we have a project and it changes the legal basis in between what can we do?

  • What happens to fields that are not mandatory based on the country?

    • We should provide the best cardinalities in order to avoid this.

Documents hierarchy

  • It appears that the way Notices are currently defined are not directly mappable to the eForms or Standard Forms.

  • We advise to revise the level of granularity at which these concepts are defined.

  • For example, in eForms and Standard forms there are two types of ContractAwardNotice whereas in EPO only one.

  • More notice types are missing.

Discussion on PIN subclasses:

  • In the NoticeType PIN the acronym is used with two meanings:

    • Prior Information Notice

    • Periodic Indicative Notice

  • We shall be careful when each is used and modelled accordingly in Ontology.

  • In notice-type controlled vocabulary, the BuyerProfile is considered a PIN:

ROMSSxbBytEAAAAASUVORK5CYII=

Discussion on CallForCompetition class:

  • In the current model this is a procurement document, but in notices it is a notice type.

  • epo:CompetitionNotice class is an epo:ProcurementDocument as well, and not epo:ClassForCompetition. === Questions:

  • Should epo:Notice be a subclass of epo:ProcurementDocument?

    • From the directive:

QVuG9PuucJAAAAABJRU5ErkJggg==

Call for competition is a procurement document.

  • Shouldn’t BuyerProfile be a subclass of PIN?