Questions raised about initial draft

[kaiqu]

@wrygiel raised some questions about an initial schema draft. We had a discussion as code comments, but I am now pulling the conversation out of the comments into this issue, to (hopefully) make it more accessible. (Sorry about having a bunch of questions in a single issue, but I couldn'r take the time to split it up)

Wojtek's comment: Data on facts sheets is missing. Initially in Oslo we have discussed many other elements to be included here, like housing information and IRO contacts. I have made some notes back then, they include on all the stuff everyone proposed, some of these seemed important: https://github.com/erasmus-without-paper/ewp-specs-api-institutions/commit/47b878d33e143da8501f7ba0d515b336837e16d5#diff-5bfd1cf6e5fb6f8e73184c993ebaf72bR30

Kai's comment: Yes - after generating the XML example, I only checked for completeness wrp. the data model, which is not a complete description. (Also, the check was a bit superficial, as I didn't follow all the relationships in the model). I include the missing elements below, but first some questions/comments on the proposed elements (NOTE: the iro section is almost empty at the moment, since most of it's elements have unanswered questions):

• website (0..*): Called "url" here.
  • I am not sure whether the "title" should be an attribute or a sub-element (if the latter, the contents must be a separate sub-element, which seems a bit cumbersome)
• phone/fax numbers/emails (0..*, generic, non-IRO related):
  • By "generic, non-IRO related", do you mean just a list - or should they have a type attribute? If the latter, types could be the same as for URLs? Also, "fax" could be a phone type, or possibly another attribute...
• IRO section
  • First, I didn't know this was supposed to be a separate section. Maybe some of the URLs above belong here?
  • links to PDF documents (0..*, recommended):
  • If these are meant to be instead of websites, we could use the URL elements above (ending in filename.pdf)? Otherwise, we need some type coding scheme, I guess (I would need some input for modeling this).
  • Lots of various text fields from fact sheets
  • Some examples of titles/sections taken from some PDF fact sheet:
    • nominations and applications for incoming erasmus students:
    • Isn't this handled by the Mobilities API? (Nominations and applications are special cases of Mobility in the data model)
    • courses:
    • Isn't this handled in the Courses/Course Search APIs?
    • credit system (it's always ECTS?):
    • This is now implemented by the Boolean use-ects element above. Is it necessary to exchange data about other systems?
    • housing/insurance:
    • Covered by URLs of the appropriate type.
    • study programme descriptions:
    • I haven't seen any input on the modeling of this. In FS, Study Programmes belong to a Subject Area, but that may not be the case elsewhere?
    • language of instruction:
    • I think this belongs in the Courses API?
    • language requirement (general):
    • This has been moved to the cooperation-condition element in the IIAs API.
    • grading [table]:
    • What is the difference between grading and grading table? Anyway, this is missing from the data model. Judging from the history of UiO, it could belong on the Subject Area or Study Programme level, or maybe even on the Course level(!) In FS, grading rules are coded numerically (even if the actual grades are alphabetical like A-F), and the structure is something like this:
    • code (id)
    • code (best)
    • code (worst)
    • code (pass limit)
    • granularity (can only be != 1 for actual numeric grades)
    • description
    • exams:
    • I can't see what this would mean on the Institution level?
    • expected arrival date:
    • It seems this would belong in Academic Term?
    • living expenses, academic expenses, other expenses:
    • I have modeled these as text fields with a type attribute.
    • health insurance/facilities/student services/orientation/internships/career services/info dissemination:
    • Are these supposed to be text/description fields? In that case, I would suggest the usual type attribute.

[wrygiel]

During the Warsaw workshop, we have initially agreed that most of these will be represented as title-content pairs. I am working on XSDs for Institutions API just now, so I'll try to handle this one.

[wrygiel]

1. Do we really need the <use-ects> element? Can its value affect our use cases in any useful way? I believe that this information will be inherently transferred in different places, e.g. the <credits> elements in Courses API or Mobilities API.
2. Could you explain what <euc-no> is?

[wrygiel]

Could you explain what <euc-no> is?

I think I found it. "Erasmus University Charter number". Can we put this inside <other-id type='euc-no'>?

[kaiqu]

Do we really need the <use-ects> element? Can its value affect our use cases in any useful way? I believe that this information will be inherently transferred in different places, e.g. the <credits> elements in Courses API or Mobilities API.

I don't remember the reason I put this in there, but I do ask (in a comment in the example) whether an Institution/Org Unit can participate in EWP without using ECTS. I'm happy to remove it if you don't think it serves any purpose.

Could you explain what <euc-no> is?

I think I found it. "Erasmus University Charter number".

Yes.

Can we put this inside <other-id type='euc-no'>?

Does it uniquely identify HEI (or possibly an Org Unit)? In that case, that would be the obvious solution, yes.

[wrygiel]

but I do ask (in a comment in the example) whether an Institution/Org Unit can participate in EWP without using ECTS

Perhaps they won't be able to implement mobility-related APIs without using ECTS, but this won't necessarily prevent them from joining the network (there are some other APIs besides the mobility-related ones, and none of the APIs are required). Even non-HEIs can join and serve some third-party APIs for other members.

[kaiqu]

Do we really need the "use-ects" element? [...]

[...] whether an Institution/Org Unit can participate in EWP without using ECTS [...]

Perhaps they won't be able to implement mobility-related APIs without using ECTS, but this won't necessarily prevent them from joining the network [...]

If I understand you correctly, a participant that implements mobility-related APIs must by definition use ECTS? But in that case, no grade conversion would be necessary?

[janinamincer-daszkiewicz]

ECTS is used in Europe, EWP would like to exchange data woth countries from other continents. I think it should be able to use mobility-related APIs without using ECTS. Let's ask Stefan for confirmation.

[kaiqu]

This seems to be the last remaining unanswered question in this issue:

Do we really need the "use-ects" element? [...]

[...] whether an Institution/Org Unit can participate in EWP without using ECTS [...]

Perhaps they won't be able to implement mobility-related APIs without using ECTS, but this won't necessarily prevent them from joining the network [...]

If I understand you correctly, a participant that implements mobility-related APIs must by definition use ECTS? But in that case, no grade conversion would be necessary?

ECTS is used in Europe, EWP would like to exchange data woth countries from other continents. I think it should be able to use mobility-related APIs without using ECTS. Let's ask Stefan for confirmation.

@StefanJahnke, can you confirm this?

[wrygiel]

@StefanJahnke, can you confirm this?

Closing this due to lack of feedback.