Recognition of virtual, blended and short-term doctoral components

[jiripetrzelka]

From the specification of the GET endpoint, it is not clear to me how to deal with recognition of virtual, blended and short-term doctoral components in case that:

• the component is recognized for a component with a different number of ECTS credits, or
• the component is recognized for multiple components at the sending institution, or
• multiple components of these types are recognized for just one component at the sending institution, or
• if this multiple recognition even intermingles with regular courses (i.e. one virtual and one physical component from abroad is recognized for just one component at the sending institution).

The EWP specification and the new LA seem to assume that non-semestral components are always recognized as one component for one component with the same number of ECTS credits, because the table B seems to reflect only recognized components from table A, not from table C and subsequent tables (without letter).

If my assumption above is correct, how should we proceed? Two scenarios come to my mind: a) In table B, send only components recognized for physical components from table A, or: b) In table B, also include all components recognized at the sending institution for virtual, blended and short-term doctoral components (not only in case they are not recognized as one to one with the same number credits, but all of them).

However, neither solution seems perfect. The first one gives misleading and potentially incomplete information on recognition to the receiving partner, while the second seems to violate the design of the endpoint.

Or is there something in the design of the endpoint that I'm missing?

[kamil-olszewski-uw]

Please note that blended and short-term doctoral components apply to other LA types and always stand alone, so they will never be in the same LA together with Tables A, B and C. This is clearly stated in the specification of the get endpoint. In the case of the classic type LA - "Semester(s)" - the specification also clearly indicates which elements are Tables A, B or C.

Your questions are more of a business than technical nature. Perhaps these guidelines will be helpful for you:

https://wiki.uni-foundation.eu/display/EWP/New+LA+template

They say: "The total number of ECTS credits (or equivalent) in Table B should correspond to the total number of ECTS credits (or equivalent) contained in Table A."

Table C is something extra, of the nature of which I am not quite sure yet. In any case, it is not that every lecture that takes place virtually automatically lands in Table C. There can be online courses that will be entered in Table A. How to use Table C and what to enter into it - this question is to the Erasmus national agencies and DG EAC.

[jiripetrzelka]

Thank you for clarification. There are, however, several questions that are still not clear to me:

In case of the short-term doctoral mobility, there does not seem to be a clear way to distinguish whether the component is physical or virtual. The short-description attribute might help if there was an equivalence between this attribute being non-empty and the component being virtual. But I guess that is not the case because the GET API specification says only: "This field MAY be provided for components in short-term-doctoral-components". So how is one supposed to tell physical and virtual components apart with certainty?

Since Table B cannot be used for short-term doctoral and blended mobility and since no instruction explicitly forbids us to recognize these components for a) a component with another number of credits, b) multiple components in a one-to-many fashion, c) one component in a many-to-one way, I assume that there has been an implicit design decision not to inform the receiving partner about the way these components are recognized in case they are not recognized as one-to-one for the same number of credits and from that I infer that any change that would limit itself only to the way these components are recognized does not require the student to create a new LA. Is that true?

As to the Table C, my question is not which components should be put in it and which should go into Table A, because that is a decision that students can make on their own after consulting their coordinator, who may consult anybody else who has the authority to decide it. My question is what to do once the component has landed in Table C and the coordinator decides to recognize it in one of the four ways illustrated above (i.e. not as one-to-one for the same number of credits). If this scenario is not forbidden, then it may occur. And if it may, then it probably will. And in that case I need to know whether the components-recognized element in the GET API endpoint should contain components recognized for components stated in Table C or not. Who can give me the answer?

[kamil-olszewski-uw]

In case of the short-term doctoral mobility, there does not seem to be a clear way to distinguish whether the component is physical or virtual. The short-description attribute might help if there was an equivalence between this attribute being non-empty and the component being virtual. But I guess that is not the case because the GET API specification says only: "This field MAY be provided for components in short-term-doctoral-components". So how is one supposed to tell physical and virtual components apart with certainty?

Please note that in LA there are no physical and virtual components present at the same level. However, each component (from tables other than A and B) may have its own virtual component, i.e. some fragment of itself that is virtual. For example, the "diploma thesis" component may have its virtual "online presentation" component. A non-empty "short-description" element clearly signifies that a particular component has its virtual component. It is not written in the API specification because it is the business information that is presented in the published new LA template.

Since Table B cannot be used for short-term doctoral and blended mobility and since no instruction explicitly forbids us to recognize these components for a) a component with another number of credits, b) multiple components in a one-to-many fashion, c) one component in a many-to-one way, I assume that there has been an implicit design decision not to inform the receiving partner about the way these components are recognized in case they are not recognized as one-to-one for the same number of credits and from that I infer that any change that would limit itself only to the way these components are recognized does not require the student to create a new LA. Is that true?

Since this type of LA does not contain the B table, changes of exemptions from recognizing components at the home university do not require the creation of a new LA. But first of all, it should be clarified with DG EAC or Erasmus national agencies whether short-term mobility (doctoral or blended) and components from Table C should involve ANY exemptions from recognizing components that we would like to enter in Table B.

Regarding the content of Table B and relationships such as one-to-one, one-to-many or many-to-one: LA template never contained an exact mapping of which components from table A replace specific components from table B. As far as I know (this is a possible question for Erasmus national agencies) this case is much more flexible. It is primarily about the fields of education, which the components from different tables cover.

As to the Table C, my question is not which components should be put in it and which should go into Table A, because that is a decision that students can make on their own after consulting their coordinator, who may consult anybody else who has the authority to decide it. My question is what to do once the component has landed in Table C and the coordinator decides to recognize it in one of the four ways illustrated above (i.e. not as one-to-one for the same number of credits). If this scenario is not forbidden, then it may occur. And if it may, then it probably will. And in that case I need to know whether the components-recognized element in the GET API endpoint should contain components recognized for components stated in Table C or not. Who can give me the answer?

As I mentioned, this is a business question for the relevant authorities and does not affect the API specification. I think I understand the problem. We do not know, for example, whether the student will enter everything into Table A, or half to Table A and half to Table C, and we wonder how to interpret it in the context of exemptions in Table B. In my opinion, the sending HEI's system should be as flexible as possible in this respect and allow for much, as there may be various exceptional situations for which both HEIs agree. And if the division of components into Tables A and C proposed by the student (and approved by his coordinator) is not appropriate according to the coordinator of receiving HEI, then he or she may just reject LA proposal with appropriate comment.

[georgschermann]

Please note that blended and short-term doctoral components apply to other LA types and always stand alone, so they will never be in the same LA together with Tables A, B and C. This is clearly stated in the specification of the get endpoint. In the case of the classic type LA - "Semester(s)" - the specification also clearly indicates which elements are Tables A, B or C.

@kamil-olszewski-uw could you please point me toward the specification where this is clearly stated? for blended-mobility-components it is clearly stated that "This element is present only for blended mobilities with short-term physical mobility" but I can't find anywhere that it has to stand without components-recognized or components-studied and these elements also don't state that they are only present for semester type mobilities, they are required (=MUST) for those but not only present in those?

After checking the template I see where this comes from, but this isn't reflected in the specification, amongst our clients it seems to be a common practice that there are regular courses studied and recognized for blended mobilities.

[kamil-olszewski-uw]

The specification shows for each set of components its template table. Official template uniquely assigns specific tables to specific LA types. For example, there are no A, B and C tables in both short-term LA types - so regular courses should appear in the only table for a given short-term type of LA.