Number of digits in the ISCED code

[kamil-olszewski-uw]

We tested the exchange of IIAs via EWP with one of the partner universities. When we downloaded the agreement, it turned out that the partner assigned the three-digit ISCED code to cooperation conditions. We couldn't save it in our system because we only have more detailed four-digit codes in our dictionary.

The IIAs pattern published by the EC says nothing about the detail of the ISCED code, but I have never come across a three-digit ISCED code from our partners. Which does not change the fact that perhaps they should be allowed.

Do you think we should allow only four-digit ISCED codes, or should we allow codes with a different number of digits - three-digit and/or two-digit?

Should the decision we make here also apply to all other places in the EWP where an ISCED code appears?

[umesh-qs]

I don't think we should restrict that. You can always go back to your partner and ask them to send 4 digit code before approving the agreement. Why would your partner pass 3 digit code for Erasmus agreement, if it is not allowed?

[EvelienRenders]

I agree with @umesh-qs , our faculties like using the broader ISCED codes with their partners.

The only place where 4 digit ISCED is obligatory is when reporting to the mobility tool +. But that is on student level, and there we always take the ISCED that corresponds to the study programme of the student, not the agreement.

[pleys]

Not sure if I agree with @umesh-qs and @EvelienRenders. There is a direct connection between the agreement and the mobility (e.g. for nominations) so in my view ISCED should be the same for both and we shouldn't change the ISCED at the level of the student. I have no problem with 1, 2 or 3 digit ISCEDs but than this should also be changed at the level of MT+.

[umesh-qs]

Even if it is done at MT+ level, what happens when in the future number of digits are changed. I think it is over the years codes have changed and might change in future. So restricting a particular length will be a rework at API level whenever the number of digits is changed. For individual systems that do not support all the codes should either have it in their system or should ask the partner to send the appropriate code.

[kamil-olszewski-uw]

Not sure if I agree with @umesh-qs and @EvelienRenders. There is a direct connection between the agreement and the mobility (e.g. for nominations) so in my view ISCED should be the same for both and we shouldn't change the ISCED at the level of the student. I have no problem with 1, 2 or 3 digit ISCEDs but than this should also be changed at the level of MT+.

In our case, over 99% of mobilities share the same ISCED code with agreements. The only differences arise when there is "unused" mobility, and some student from another faculty wants to go to a specific receiving HEI, and receiving HEI exceptionally agrees to it. In such cases, ISCED codes differ, but for mobility its "parent" cooperation conditions must be remembered.

[EvelienRenders]

I agree @pleys that in an ideal world you would like to have only nominations and Mobilities for students in programmes that correspond to the 4 digit ISCED on the agreement. At least for reporting purposes it would help.

However... I feel like that is too big of a deviation from how agreements have been for 30 years now.

I think that bestowing the technical ideal upon the users is not a smart from an adoption point of view. They already have to get used to so much.

Does anybody know who we can ask what EUFs reason was for implementing all codes in the dashboard?

What is the added benefit for the end users when the ISCED is restricted to 4 digits?

[kamil-olszewski-uw]

I don't think we should restrict that. You can always go back to your partner and ask them to send 4 digit code before approving the agreement. Why would your partner pass 3 digit code for Erasmus agreement, if it is not allowed?

Even if it is done at MT+ level, what happens when in the future number of digits are changed. I think it is over the years codes have changed and might change in future. So restricting a particular length will be a rework at API level whenever the number of digits is changed. For individual systems that do not support all the codes should either have it in their system or should ask the partner to send the appropriate code.

Very accurate comments.

Indeed, if we impose the number of digits, the new EC guidelines in this regard will entail the need to create a new version of the API.

Moreover, the agreement is established by two partners. They can always agree on a mutually acceptable ISCED code.

[kamil-olszewski-uw]

SUMMARY: We will NOT force a specific number of digits in the isced-f-code, but in the commentary to this element we will strongly recommend that the ISCED code should be four-digit, because this way it will be compliant with the requirements of Mobility Tool+ apllication, which only accepts four-digit codes for mobilities.

[sascoms]

Sorry for the late reply but need to state this:

Our opinion is:

• Standards are good.
• APIs always should have standards in all aspects (params, requests, codes used, content type etc.).
• Changes are inevitable. APIs and systems should adapt themselves to the changes.

And regarding the isced codes, it does not matter for us whether it is 1/2/3/4 digits, but we definitely want and would like to see and have a standard in all the API specs so all parties adheres to these standards and thus no confusion or conflicts occur.

Best,

[kamil-olszewski-uw]

If we receive official guidelines on standards, then one way or another we will try to adapt the standards to it. Yes, changes are inevitable, but we must try to avoid possible changes that are backwards incompatible as such changes create chaos until all partners implement the latest version of the API.