Practical mapping use case: Ghent University

[wrygiel]

@NicoVanMoortel sent me these questions, and I asked him for permission to forward it here, so that others may possibly learn from experience. I am quoting from his email below.

The biggest question is how to transform the UGent course catalog into the EWP structure when a request is received?

Below a simplified example, but it gives a nice view on how the course catalog is structured in our system (Oasis). Some information to help explain the structure

• The highest level is the faculty. Each faculty administers several degree programs (in the example: “Exchange Programme in Law”)
• Below the degree program a program is defined which is valid for a certain period (in the example there are two programs, each valid during a certain period)
• A program is made up of modules, courses and course sessions.
  • A module has child modules and/or courses
  • A module can be placed in several programs. A module can be placed several times in the same program (in the example all modules are unique)
  • A course can be placed several times in the same program but also in other programs. (in the example Course 001 and 002)
  • A course session is valid for a certain period and linked to a unique course (in the example course 001 and 003 each have 2 unique course sessions)
• In Oasis a degree program, program, module, course and course instance all have a unique UUID

Questions

• What would be best practice? We could flatten the structure and send all unique course/course instances. Or is it better to maintain the structure?
• If we maintain the structure which LOS/LOI should we create:
  • Can our degree program – program be seen as a LOS – LOI? (In the xsd it is mentioned that ‘academic term’ should not be used for degree program…)
  • Do we define the faculty as a course type? Or would it be useful to be able to link a degree program to an organizational unit?
  • Do you agree that for our purposes a module only is a LOS? (and no LOI)
  • Do we send all LOS-id’s through the course application API or only the top level LOS-ID’s?
• For which academic terms do we send the catalog? In the documentation I find that also the programs of the past should be interfaced. For us that is starting 2004

[wrygiel]

We could flatten the structure and send all unique course/course instances. Or is it better to maintain the structure?

I'm not sure what you mean by flattenning in this context, but if you mean "skipping" information on all non-"Course"-type LOSes, then it's okay to do that. The primary purpose of Courses API is exposing information on all possible LA components. If these components are always "Course"s (are they?), then you can choose to implement only a single LOS type: "Course" (because all others are - at this point - not really important in EWP).

Can our degree program – program be seen as a LOS – LOI?

Yes.

(In the xsd it is mentioned that ‘academic term’ should not be used for degree program…)

You probably mean this paragraph. Yes - currently, there can be only one academic term assigned per LOI, and - since programmes usually span over multiple academic terms - we advise implementers to not include academic terms for "Degree Programme" LOIs. But perhaps it's a mistake on our part, and we should allow LOIs to refer to multiple academic terms. We can start an official issue for discussing that (already did that), but until all agree on this, you should simply not include academic terms in your "Degree Programme" LOIs (note there are still start/end dates there, so academic terms might not be all that useful).

Do we define the faculty as a course type? Or would it be useful to be able to link a degree program to an organizational unit?

You mean introducing a new LOS type of "faculty"? I think not, this doesn't sound good - "faculty" is not a "learning opportunity". But the latter suggestion is very reasonable - I will start a separate issue for discussing that (link here).

Do you agree that for our purposes a module only is a LOS? (and no LOI)

It depends - can a module be used as a Learning Agreement component?

• If yes, then we will need a LOI there.
• If no, then it's probably okay to not have a LOI. You could also consider dropping modules completely from your Courses API.

Do we send all LOS-id’s through the course application API or only the top level LOS-ID’s?

I assume you mean "Course Replication API". You should send all your LOS IDs there, not only the top level ones.

The graph of LOSes is acyclic, but - as you already noticed - its subtrees are interconnected in some weird ways sometimes. For example, it is perfectly okay for courses to be included in either 50 or zero different "Degree Programmes". We don't want to force the clients to scan through this graph - we just return all the vertexes.

For which academic terms do we send the catalog? In the documentation I find that also the programs of the past should be interfaced. For us that is starting 2004

Yes - Courses API should be able to describe LOSes used in the past. It's up to the client to notice that a particular LOS doesn't have any recent LOIs. Some clients might simply ignore such LOSes, but others might still find your data very useful (e.g. for statistical purposes).

BTW - "Degree Programmes" also change in time in our model (exactly as it happens in your model, e.g. a different set of courses is assigned after some years). However, our format (based on EMREX ELMO) defines LOSes as specifications that don't change in time. This means that you will always return the "most recent" version of your LOS (unless you implement the optional los_at_date parameter, which allows basic access to this history).

[wrygiel]

@erasmus-without-paper/all-members - if any of you is currently struggling with Courses API - it might be worth reading this.

[huntering]

I don't think statistical purposes is a good motivation to send over the complete catalog because I wouldn't consider that in scope. I don't see any use case within EWP to request the complete course catalog over the years. It could undermine the project because of HEI's not wanting to implement a "heavy" request like this causing disruptions. Are HEI's allowed to state "los_at_date" or "combination before/after" as required in their implementation? Or shouldn't it be allowed for HEI's to have academic year as a parameter and implement it as such that if it is not supplied the HEI considers the current academic year?

[wrygiel]

I don't think statistical purposes is a good motivation to send over the complete catalog because I wouldn't consider that in scope. I don't see any use case within EWP to request the complete course catalog over the years.

You're right. That wasn't a good example. And I can't think of any good example just now. Perhaps this topic (dealing with "old entities" in general) also deserves a separate issue page.

It could undermine the project because of HEI's not wanting to implement a "heavy" request like this causing disruptions.

I'm afraid this will be quite heavy either way. Once a HEI implements Course Replication API it basically announces to everyone "hey, these are all the LOS IDs you need, you can download my entire course catalogue, even one by one if you want, don't worry, I can deal with it". If this might be a problem, then this HEI should not implement Course Replication API. (But it is safe to implement Courses API only.)

Are HEI's allowed to implement los_at_date or combination before/after as required in their implementation?

Currently, implementing los_at_date is optional, but all other parameters MUST be supported.

This however does not mean that you are required to expose all your older LOSes. I think that your EWP partners should be fine if you decide to "hide" the ones older than, say, a year or two. The only thing we require from implementers is to be consistent - for example, if you refer to a local LOS/LOI in any of your Outgoing Mobilities API, then this LOS/LOI MUST be accessible via your Courses API. Note, that this brings us to a related issue - for how long should old mobilities be accessible?

[wrygiel]

Perhaps this topic (dealing with "old entities" in general) also deserves a separate issue page.

Started a separate issue page for this topic here.

[wrygiel]

Closing this issue. Please reopen if you think some questions still need answering.