search

OP-TED / ePO

The eProcurement Ontology provides the formal, semantic foundation for the creation and reuse of linked open data in the domain of public procurement in the EU.
European Union Public License 1.2
58 stars 18 forks source link

Codelist; MULTIPLE; Make authority codes human-readable #165

Closed jpmckinney closed 1 year ago

jpmckinney commented 5 years ago

While human-readable codes aren't required for interoperability, my experience has been that human-readable codes lead to fewer implementation errors.

Presently, the codes in question are 'barely' human readable; for example, I can guess 'no suitable responses' from 'no-suit-resp' – but many others are harder to guess. I assume it's uncontroversial to make these more readable, given that they are somewhat readable with effort presently.

This issue only pertains to the codelists that have codes like 'no-suit-resp', i.e. not the legal basis codelist, which uses an interoperable CELEX number for the authority code.

jpmckinney commented 5 years ago

See https://github.com/eForms/eForms/issues/295 for discussion of direct-award-justification.

muricna commented 5 years ago

I agree, however to avoid having too long codes some business knowledge will be necessary to interpret the codes as per your example above.

JachymHercher commented 5 years ago

When will we have an opportunity to comment on the draft codes?

muricna commented 5 years ago

The codes that form part of the ontology are available in the model you are free to comment.

JachymHercher commented 5 years ago

@muricna thank you for pointing me to the glossary. If I understand correctly, the relevant part is the second sheet, column "Authority Code". Can you please confirm that this is still the latest one? Certain elements seem duplicate (e.g. publ-law-body appears 2-3 times), others incomplete (e.g. there are just some countries), for others I'm not sure they reflect the latest version of the ontology.

Before giving individual comments, I realized that it would be better to understand what were the rules that you followed when drafting the current codes (e.g. are there any restrictions that the codes need to respect; which codes can't we touch; etc.) Broadly speaking, the goal of these design rules should be that, as far as possible, codes should be understandable without knowing the CodeName. When this is not possible, they should at least follow a regular pattern.

For example: 1) Is there a harmonized approach on whether each word of the CodeName should be abbreviated or not? (For example, "soc-pro" is used for "Social Protection", but "econ" for "Economic Affairs". 2) Is there a harmonized approach to the abbreviations' structure? (For example, "rcr" is used for "Recreation, culture and religion"; but in most other cases, only the first letters are used.) 2) Is there a harmonized approach to the lengths of abbreviations? (For example, "hc-am" for "Housing and community amenities" has two characters per abbreviation; while "rcr" for "Recreation, culture and religion" has three; "heal" for "health" has four; etc.) 2) Is there a harmonized to approach to when we use acronyms? (e.g. "pub-os" for "Public order and safety" has an element of an acronym, but most other codes do not.)

Here are some examples of design rules that we could follow: I. If there is an "intuitive code" or a need to avoid an "obvious misunderstanding", we just follow that. (E.g. "edu" is intuitive for "education"; while when shortening "economic", "econ" is clearer than "eco"). II. If the CodeName is one word, keep the Code same as the CodeName.

JachymHercher commented 5 years ago

(May I ask you to reopen the issue, please? Just not to forget about it.)

muricna commented 3 years ago

The codes for eForms have been published on EU Vocabularies see also the correspondance of eForms codes and controlled vocabularies on EU Vocabularies.

It still needs to be decided how the remaining epo code lists that are not in EU Vocabularies will be dealt with.