search

eForms / eForms

The 2nd consultation on eForms, the update to the EU's procurement standard forms. Scroll down for more information.
20 stars 8 forks source link

Systematic and authorative mapping between eForms and the ontology conceptual model #262

Closed VibekeE closed 5 years ago

VibekeE commented 5 years ago

There are differences in the approach between eForms and Ontology, Due to the complexity these differences, the mapping gets complex. Difi propose that the Publication Office takes the responsibility to develop a systematic and authoritative mapping. An examples of differences is "Lots". In the conceptual model Lot is as a sub class of Procurement Project belonging to a procedure. The specific information element for each Lot is connected directly to the Lot. In the eForms on the other hand, the different information classes contain the Lot ID. Another example is "Classification". In the Ontology CPV code is a specific information element, whilst in the eForms the combination of classification type and classification code provides similar information. This represent different approach of structure.

JachymHercher commented 5 years ago

@muricna, @paulakeen

(This issue builds on #201)

paulakeen commented 5 years ago

I agree that the ones responsible for the development of the ontology make sure that the mapping between eForms and the Ontology is possible. But that is currently the situation, is it not?

As a matter of fact, the data elements in eForms should be viewed as a subset of the ontology, independently of the "approaches" followed by each one: adopting different approaches when modelling is inevitable (and even normal/convient) when the goals (but not the context of use are different), as well explained by @JachymHercher in #201.

In the case of the eFroms "Classification" and ePO "CPV" there should not be any problem, as the eForms elements "Classification Type" (BT-26), and "Main Classification Code" (BT-262) can be perfectly mapped to the corresponding ePO data element of type Code and its corresponding attributes (listID, listName, listAgencyID, listAgencyName, listVersionID, and any other attribute that may be added as an extension if needed -> in ePO codes are expressed as SKOS-XL, which allows to add any necessary metadata about the list and about any concept coded in the list).

And yet we need to persevere in the effort for total alignment, namely to solve business situations so what needs to be applied to lots and what not are agreed between both initiatives, e.g. #287.

muricna commented 5 years ago

The ontology is the reference for eProcurment concepts and to that end the eForms should apply the ontology.

guascce commented 5 years ago

I believe that this issue is not only about technical implementation. The ontology is at the heart of the semantics for procurement.