Outgoing Mobility IDs

[wrygiel]

I believe that Outgoing Mobility identifiers should be unique within the entire EWP Network (as opposed to being unique within a single sending institution). This approach seems safer in regard to possible changes in the network topology (e.g. when HEIs are merged).

This can be achieved by:

Solution 1. Using a central, sequential ID generator. For example, if Mobility Tool had a web service which would allow us to "reserve" a particular ID, we could make us of that.

Solution 2. Use UUIDs.

Solution 3. Prefix mobility identifiers with sending institution's SCHAC IDs (e.g. uw.edu.pl:49220).

[wrygiel]

It's worth noting that in solution 3, if changes in network topology occur, the merged institution would still need to support previous prefixes for entities which were created prior to the merge. This might be a little confusing to some developers (and may result in bad implementation).

Solution 2 can also be implemented badly (when not enough entropy is used). However, we can remedy that if we require that the institution's SCHAC ID will be included in this entropy.

Solution 1 would be very nice, but it's unlikely that Mobility Tool provides such a service. It would also make our nomination process dependent on the Mobility Tool's availability.

To sum up, solution 2 is my current favorite.

[georgschermann]

the impact of merges on solution 3 is not so severe i think, and would be my favourite because of simplicity, but we would also be good with solution 2
solution 1 is not feasible for a number of reasons i think

[wrygiel]

the impact of merges on solution 3 is not so severe i think

Some similar scenarios could also turn out to be problematic in solution 2 solution 3, e.g.

• switching domains, without the merging part (after HEIs are renamed),
• when HEI would like to reuse some primary keys which have been previously deleted,
• some badly designed systems may even allow the users to edit primary keys (especially non-integer primary keys).

But you're right - all of these cases are not very probable.

[wrygiel]

I have used UUIDs in v0.2.0 of the https://github.com/erasmus-without-paper/ewp-specs-mobility-flowcharts document, but this issue is still open for discussion.

[mikesteez]

We also suggest solution 2 with UUIDs. It is simple and globally unique. As we are in the process of implementing the specs, we would be happy if we could come to a conclusion.

[wrygiel]

We hope we will confirm this in Warsaw, when @kaiqu and @geirmv will discuss example API responses.

BTW, Outgoing Mobility API specs are still drafts. It might be safer to wait with the implementation until stable versions (stable-* branches) are released.

[wrygiel]

Currently this is the only ID which the specs require to be globally unique - in all other places we require them to be unique within a single HEI.

Also, it turned out that in all contexts where mobility_id is provided, its parent hei_id is provided too (because some implementations need it).

Perhaps we should reconsider and loosen the requirements here? I no longer believe global uniqueness is required here - a local ewp:AsciiPrintableIdentifier seems to be equally sufficient.

[wrygiel]

Of course, we will still "recommend" using UUIDs, but I don't see much reason for actually "requiring" them. After codes were introduced, this ID is similar to all other IDs in other APIs, so I just propose to handle it in a similar fashion.

[kaiqu]

Currently this is the only ID which the specs require to be globally unique - in all other places we require them to be unique within a single HEI.

That would be the sending HEI in this context.

Perhaps we should reconsider and loosen the requirements here? I no longer believe global uniqueness is required here - a local ewp:AsciiPrintableIdentifier seems to be equally sufficient.

Of course, we will still "recommend" using UUIDs, but I don't see much reason for actually "requiring" them.

So, you are proposing two alternative ID structures, where the HEIs can choose which one to use? Maybe call the UUID id and the HEI+local id code, to follow the pattern in the rest of the APIs?

[wrygiel]

That would be the sending HEI in this context.

Yes.

So, you are proposing two alternative ID structures, where the HEIs can choose which one to use?

No. I'm just proposing not to force mobility_id to be an UUID. Currently this is enforced by the schema; the schema also enforces these UUIDs to be formatted in the canonical format (with dashes). I propose to change <mobility-id>'s type to ewp:AsciiPrintableIdentifier, so that HEIs would be able to choose other kind of IDs here (but we would still recommend that they choose UUIDs, or something similarly unique).

Maybe call the UUID id and the HEI+local id code, to follow the pattern in the rest of the APIs?

Note, that id fields in other APIs are not required to be globally unique - they need to be unique within the single HEI only.

As to adding the code - it would make sense if we had natural keys for mobilities. Poland doesn't have such natural keys in this particular table. Do you have them?

[kaiqu]

I'm just proposing not to force mobility_id to be an UUID. [...] I propose to change mobility-id's type to ewp:AsciiPrintableIdentifier, so that HEIs would be able to choose other kind of IDs here (but we would still recommend that they choose UUIDs, or something similarly unique).

Ah, ok.

As to adding the code - it would make sense if we had natural keys for mobilities. Poland doesn't have such natural keys in this particular table. Do you have them?

No, you're right - I agree with your proposal.