search

erasmus-without-paper / ewp-specs-api-iias

Specifications of EWP's Interinstitutional Agreements API.
MIT License
4 stars 13 forks source link

Invalid ISCED codes #85

Open tsiakmaki opened 2 years ago

tsiakmaki commented 2 years ago

Since ISCED-F subject area codes must comply with the: http://uis.unesco.org/sites/default/files/documents/isced-fields-of-education-and-training-2013-en.pdf partners should not use codes that are not implied in the document.

But, during iia exchanges, we noticed codes that do not comply with the document. What is expected by the receiving partner to do in such case?

kamil-olszewski-uw commented 2 years ago

In my opinion, we don't have to force client systems to automatically validate it. I think we can leave it to the users. If a user downloading IIA doesn't like the incorrect ISCED code (even because it will not be in their dictionary), they will not approve IIA in such form.

umesh-qs commented 2 years ago

Receiving partner should not approve the IIA if they don't like it, and ask the sending partner to make the changes accordingly.

tsiakmaki commented 2 years ago

One suggestion might be to include the ISCED code in the IIA Validation.

janinamincer-daszkiewicz commented 2 years ago

What do you mean by that?

tsiakmaki commented 2 years ago

to restrict this element under a predefined list of allowed codes (enumeration)

jiripetrzelka commented 1 year ago

In the Mandatory Business Requirements it says:

Invalid ISCED codes: the EWP Spec requires the use of ISCED codes implied at: http://uis.unesco.org/sites/default/files/documents/isced-fields-of-educationand-training-2013-en.pdf

Do I interpret it correctly that suplementary codes ending with 0, 8 and 9 are not invalid?

And do I interpret it correctly that implemeters are therefore required to provide these codes to their users and allow them to enter them into IIAs?

image

janinamincer-daszkiewicz commented 1 year ago

@kamil-olszewski-uw please, have a look here.

jiripetrzelka commented 1 year ago

I will add a sub-question to my first question so that we can arrive at the most exact list of valid/required codes:

Are there any codes at http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf that are considered invalid by the Mandatory Business Requirements?

janinamincer-daszkiewicz commented 1 year ago

As you mention Mandatory Business Requirements, I also ping @pleys :)

demilatof commented 1 year ago

I will add a sub-question to my first question so that we can arrive at the most exact list of valid/required codes:

Are there any codes at http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf that are considered invalid by the Mandatory Business Requirements?

@jiripetrzelka I think that any list of ISCED codes should be compliant with the codes accepted by the Beneficiary Modules, because we cannot accept an ISCED for an IIA if the same ISCED is refused when we try to insert a mobility in the Beneficiary Module. Or the Beneficiary Module should become more permissive. For example, the data dictionary (KA131-HED) in the sheet "education fields" doesn't consider the codes ending in 00, such as 0300, 0400, 0700 but even 1040, 1038, 1048, 9999 and others whilst they are listed in the PDF you have linked: List_of_the_ISCED_Codes_used_by_Egracons.pdf

jiripetrzelka commented 1 year ago

I see four points in which the BM Data Dictionary differs from the Egracons list:

These findings help to formulate the question for the authors of the Mandatory Business Requirements more precisely:

kamil-olszewski-uw commented 1 year ago

Keep in mind that Beneficiary Module tends to make frequent changes in the structure of collected data, sometimes even without announcements. I would be careful with relying on the (current) BM requirements too much.

To a certain version of BM Data Dictionary, there were no leading zeros in the ISCED education fields for the call year 2021. Then they were added. We have 2-digit and 3-digit codes (broad and narrow fields) in Data Dictionary, which in BM itself are grayed and impossible to choose. In general, accepting the 4-digit ISCED codes is probably the only constant (so far) BM principle in this area, inherited from MT+ (and for this reason 4-digit codes are recommended by the API).

In other words, we cannot be sure that there will be no other changes in the future. And even though the requirements may remain unchanged for one call year, there is a possibility they will be changed for the following call year, which will result in having simultaneously different requirements for different call years.

I'm not sure if we should introduce any restrictions on the data set and the form of this data to the API specification. The first one (data set) could be left for users to decide whereas the second (data form) can be eventually adapted in our systems (more precisely, in our export files to BM) to the potentially variable BM requirements.

Moreover, it should be noted that the introduction of such restrictions in the API will be backwards incompatible. This incompatibility will concern the set of previously accepted data, which can complicate the situation in the case of mutually approved IIAs.

jiripetrzelka commented 1 year ago

So in other words, users MUST be able to put inside an IIA any of the codes listed http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf except those that end with '00'?

In other words, software providers MUST NOT decide for their users that codes such as 0011, 0118, 0188, 0540 and 9999 will be unavailable?

demilatof commented 1 year ago

Keep in mind that Beneficiary Module tends to make frequent changes in the structure of collected data, sometimes even without announcements. I would be careful with relying on the (current) BM requirements too much.

I know, I have had to change the Excel file more than 3 times and always without notice. I'm not saying that we should rely on the BM requirements, but that if we put some kind of limit, they should be compliant with BM. Or, in other words, two programs of the UE should be compatible each other. By the way, in this moment the BM is a nightmare for importing mobilities by means of a file.

kamil-olszewski-uw commented 1 year ago

So in other words, users MUST be able to put inside an IIA any of the codes listed http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf except those that end with '00'?

Yes.

Codes that end with '00' are not recommended, but they are not forbidden.

In other words, software providers MUST NOT decide for their users that codes such as 0011, 0118, 0188, 0540 and 9999 will be unavailable?

Software providers may decide it for their users locally (if that's what their customers want). But they must not technically reject a partner IIA with "controversial" ISCED codes sent via EWP as not compliant with specification.

jiripetrzelka commented 1 year ago

@kamil-olszewski-uw Thanks for the clarification. I would suggest to incorporate your conclusions into the specification and/or the Mandatory Business Requirements so that future implementers can easily find them. I would also like to suggest to omit the word "Invalid ISCED codes" in the Mandatory Business requirements because the linked document does not operate with the notion of "validity" at all. It just lists which ISCEDs exist and when to use which. So the only sensible interpretation would be that invalid codes are those that are not listed in the document, i.e. codes that do not exist, which is self-evident. I would rather suggest to stick to the terminology of "recommended" / "not recommended".

kkaraogl commented 1 year ago

My suggestion would be that the list of ISCED Codes is treated as a vocabulary maintained centrally, in some way, and utilized by the partners' implementations.

Each end every one of us maintaining local ISCED Code lists, according to our understanding of what is valid or not valid, is not effective.

janinamincer-daszkiewicz commented 1 year ago

How would it look like from the point of view of the local system when the set of values changes - new positions show up or some old disappear? For example we have mutually approved IIAs with some ISCED codes, and some of them disappear? Or when we are in the middle of negotiations? Or we have used them for courses in our course catalog and these courses are listed in the LAs?

kkaraogl commented 1 year ago

How would it look like from the point of view of the local system when the set of values changes - new positions show up or some old disappear? For example we have mutually approved IIAs with some ISCED codes, and some of them disappear? Or when we are in the middle of negotiations? Or we have used them for courses in our course catalog and these courses are listed in the LAs?

Whatevever has been stored in the local implementations will remain as-is, it wouldn't be correct to recursively change those. But for the future, everyone would be utilizing this shared vocabulary.

jiripetrzelka commented 1 year ago

This "shared vocabulary" could be a new Type defined in https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd with enumeration values taken from http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf

I wouldn't worry about changes so much because http://uis.unesco.org/sites/default/files/documents/isced-fields-of-education-and-training-2013-en.pdf states in point 12 that there have been only 3 revisions so far - in 1976, 1997 and 2011.

umesh-qs commented 1 year ago

This "shared vocabulary" could be a new Type defined in https://github.com/erasmus-without-paper/ewp-specs-architecture/blob/stable-v1/common-types.xsd with enumeration values taken from http://egracons.eu/sites/default/files/List_of_the_ISCED_Codes_used_by_Egracons.pdf

I wouldn't worry about changes so much because http://uis.unesco.org/sites/default/files/documents/isced-fields-of-education-and-training-2013-en.pdf states in point 12 that there have been only 3 revisions so far - in 1976, 1997 and 2011.

@jiripetrzelka if there is a change lets say in 2022, can you please describe the process to handle this technically for existing IIAs?

jiripetrzelka commented 1 year ago

@jiripetrzelka if there is a change lets say in 2022, can you please describe the process to handle this technically for existing IIAs?

Two lists would be defined in the specification - ISCED-2013 and ISCED-2022. For IIAs in the period 2021/22 - 2028/29 the second list would be recommended. The first list would still be an option for backward compatibility of IIAs already signed/approved. IROs would not be required to re-approve IIAs with new ISCEDs. But it would be recommended in case of amendments. Other option for period 2021/22 - 2028/29 - the new list would not be introduced and the old list would be used until the end of this programme period. For IIAs from 2029/30, only ISCED-2022 would be allowed by the specification.

umesh-qs commented 1 year ago

@jiripetrzelka if there is a change lets say in 2022, can you please describe the process to handle this technically for existing IIAs?

Two lists would be defined in the specification - ISCED-2013 and ISCED-2022. For IIAs in the period 2021/22 - 2028/29 the second list would be recommended. The first list would still be an option for backward compatibility of IIAs already signed/approved. IROs would not be required to re-approve IIAs with new ISCEDs. But it would be recommended in case of amendments. Other option for period 2021/22 - 2028/29 - the new list would not be introduced and the old list would be used until the end of this programme period. For IIAs from 2029/30, only ISCED-2022 would be allowed by the specification.

@jiripetrzelka so you are suggesting that the application will maintain multiple lists and at the time of making changes to the IIA, provide ISCED selection based on the academic year range. And when an IIA is received do ISCED check based on the academic year range and associated list?

jiripetrzelka commented 1 year ago

@jiripetrzelka so you are suggesting that the application will maintain multiple lists and at the time of making changes to the IIA, provide ISCED selection based on the academic year range. And when an IIA is received do ISCED check based on the academic year range and associated list?

Yes but these details would vary in each implementation. For example, we wouldn't check it based on range of academic years but based on programme period (each IIA is internally linked to a specific programme period in our system and the range of possible academic years is also inferred from the programme period).

serkanUH commented 1 year ago

Hi

For the sake of simplicity , I agree with @kkaraogl proposal to have central maintained vocabulary (isced-list).

You could keep just one list by making a complex type "isced" and adding a start and end dates to each isced code. If a code changes in description (detailed field ), the end date of the "old" description can be set and a new entry with the same iscod code and modified description can be made

<isced>
    <code>0311</code>
    <detailed_field>Economics</detailed_field>
    <start_date>01-06-2019</start_date>
    <end_date>19-04-2023</end_date>
</isced>

<isced>
    <code>0311</code>
    <detailed_field>Changed Economics</detailed_field>
    <start_date>20-04-2023</start_date>
    <end_date></end_date>
</isced>
bvalero-umh commented 1 year ago

We must have a catalogue with all the valid codes and their descriptions in English, in an trusted external link included in the specification, if it is something parseable like a CSV, then better than an official PDF hard to read. I don't think codes that may become obsolete in the future are an issue, this will be rare and we can just indicate in the description that it is obsolete.

I am not sure if having this catalogue as a type enumerate can be useful. But at least the field should be restrained to exactly 4 numbers, to force all clients to fill with zeros at the left.

demilatof commented 1 year ago

We must have a catalogue with all the valid codes and their descriptions in English, in an trusted external link

https://wikis.ec.europa.eu/download/attachments/39355216/BM%20KA131%20Higher%20Education%20call%202021%20-%20Data%20Dictionary_v.7.xlsx?version=1&modificationDate=1677235050264&api=v2

The sheet "education fields" list all the ISCEDs accepted by the Beneficiary Module, even if different from the official ISCED list (little difference, anyway).

I am not sure if having this catalogue as a type enumerate can be useful. But at least the field should be restrained to exactly 4 numbers, to force all clients to fill with zeros at the left.

I don't think anybody has to fill with zeros anything; we should just use valid ISCEDs already declared with 4 digits. As a matter of fact, ISCEDs have this structure:

2 digits: Broad field 3 digits: Narrow field 4 digits: Detailed field

We are interested in detailed fields

serkanUH commented 1 year ago

I believe that what isced codes should be used is NOT a technical question. The list of the Benificiary Module ? The list that is used for egracons ? Or the "official" list of unesco ?

These 3 lists are all 3 different. Keep in mind that according the unesco description 05 is not the same as 0500 . Those trailing zero's are not just filling up the gap in order to get to 4 digits ( when u want to use the Broad field. These zero's have meaning by saying this field is "not further defined" . So we should not use the trailing zero's to fill the gaps in order to have 4 digits. The List of the benificiary mode does not have these "0 - Not further defined" codes on Broad or Narrow fields. ONly on the detailed fields. While The list of egracons does have these codes and is imo closer to the source document of unesco.

Simular with codes ending with 8 (interdisciplinary programmes ) or 9 ( not elsewhere classified ).

Again, this is however not a Technical discussion but rather on Business Level . From a technical point of vue it does not matter much what list will be chosen .

From my experience and also regarding the discussion here , I really have this feeling to implement this field as a free text field and advice my IRO just to follow whatever our partners puts here. We will be saving months of discussion.

So to conclude : we need first ( if there is no one yet ) a decission on what isced codes to use. After that we can discuss how to implement technically

demilatof commented 1 year ago

So to conclude : we need first ( if there is no one yet ) a decission on what isced codes to use. After that we can discuss how to implement technically

I agree. From a technical point of view, we can stress that it would be better if the list of ISCED coded is unique for all services: EWP, Learning Agreement, Beneficiary module and so on. Otherwise, we'll have some issues that we cannot easily resolve e.g.: we agree to use an ISCED code in EWP, we accept it for Learning Agreement but at the end it is refused by beneficiary module platform. And then? This should not happen.