Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Freetext elements vs codelists #2

Closed
JoseLuisCueva opened this issue Jul 8, 2016 · 4 comments
Closed

Freetext elements vs codelists #2

JoseLuisCueva opened this issue Jul 8, 2016 · 4 comments

Comments

@JoseLuisCueva
Copy link

Several elements in the Response are treated as unconstrained text (obviously in the language of the E.O.). This raises interoperability (and perhaps legal certainty) issues, in particular for en electronic document meant for electronic procurement in a multilingual realm.
It might be solved (at least in many important cases) by using codelists properly maintained.
In some cases there are already well-known classifications, taxonomies or codelists, defined and maintained by the EC itself (eg CPV for defining the "business area covered by the contract"), by international organizations such as the International Labour Organization (eg ISCO for classification of occupations) or the UN (eg UN/SPSC), or by Standards Bodies. These might be supplemented by properly maintained and referenced public lists, even provided by the country of the Contracting Authority.
I believe the ESPD EDM and the ESPD service should provide the capability for using and referencing codelists like these, so both the E.O. and the C.A. (and eventually their IT systems) can make sure both parties understand unambiguously (in the common language provided by the codelist or taxonomy) the same thing in the ESPD Request (or Contract notice) and in the ESPD Response.

@JoseLuisCueva
Copy link
Author

Example 1: yearly/average yearly turnover "in the business area covered by the contract andspecified in the relevant notice or the procurement documents..."
The "standard form" does not provide a place for the E.O. to state the business area his turnover is computed for. But even with a place for a description in natural language there is a problem for matching what the C.A. meant in his Request or CN or CD´s (in the C.A. language) and what the E.O. is expressing in his ESPD Response (in his own language).
Taxonomies such as the CPV (EC Resolution) or UN/SPSC could serve as a way for solving this issue.

@JoseLuisCueva
Copy link
Author

Example 2: Part IV-C "TECHNICAL AND PROFESSIONAL ABILITY", several items for employees and staff qualifications.
In this case, the use of taxonomies such as the International Standard Classification of Occupations (ISCO-08) from the International Labour Organization (ILO) could seve as an interoperable, neutral and unambiguous way of expressing the professional qualifications of employees, staff, etc.

virgiliu-ratoi-ec-ext added a commit that referenced this issue Sep 19, 2016
* commit '0ade3e5bec87a273d8553c3a5b2fab1983db68f4':
  release 08-2016
  #20 phrase with parameters was splitted
  ESPD-26 added separated finish page to have same code for printing
  ESPD-124 #16 added list legal representatives
  #16 add more economic operator representatives to the XML
  ESPD-126 #17 Added links for EO's
  #34 change the id of the G1.1 requirement group of criminal convictions exclusion criteria because it was duplicated
  #32 add schemeID for VAT number and national number at the economic operator party identification level
  branch for hotifx #42
  #35 added characterFilter for WebLogic server only
  fix for WL12.1.3
  revert back my fix commits
  hotfix for WL, country changed to String
  temporary FIX for WL migration
  temporary FIX for WL migration
  temporary FIX for WL migration
  fix for Wl migration
  fix for wl migration
@paulakeen
Copy link

paulakeen commented Oct 3, 2016

I would recommend to assess the use of ESCO, the European Skills, Competences, Qualifications and Occupations taxonomy defined and maintained by COM (DG EMPL).

@ec-mcs
Copy link
Collaborator

ec-mcs commented Nov 14, 2016

This will be part of the new model. So I will close it here.

@ec-mcs ec-mcs closed this as completed Nov 14, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants