search

erasmus-without-paper / ewp-specs-api-institutions

Specifications of EWP's Institutions API.
MIT License
0 stars 0 forks source link

Abbreviation #10

Closed kaiqu closed 7 years ago

kaiqu commented 7 years ago

@wrygiel : We concluded here that you would add abbreviation to the Institutions and possibly the OUnits API, but it's not there yet. Just a reminder - my apologies if you remember, but just haven't got around to it yet :-)

wrygiel commented 7 years ago

No, I forgot about it.

I think we need to clearly specify the scope of this abbreviation. Otherwise I fear we will get some junk data there. For example, should we say that "this abbreviation should be unique within a country"? I don't think we may require it to be "unique on the world's scale", but the country seems reasonable. Clients would then display this abbreviation with a country-code prefix to get a somewhat world-unique value.

What do you think?

kaiqu commented 7 years ago

For example, should we say that "this abbreviation should be unique within a country"? I don't think we may require it to be "unique on the world's scale", but the country seems reasonable. Clients would then display this abbreviation with a country-code prefix to get a somewhat world-unique value.

I would agree for the Institutions API, but on second thought, I believe "other-id" can serve this purpose here? In that case, this leaves the OUnits API - with only a "HEI-wide" uniqueness.

wrygiel commented 7 years ago

I feel that "other-id" should be used for unique identifiers (assigned by an external party), while this abbreviation seems to be a code/label (assigned by the HEI itself). This label may "struggle" to be unique, but often won't be.

wrygiel commented 7 years ago

Of course, if you have unique abbreviations in Norway (assigned centrally, with no possible conflicts), then you could use "other-id" for that (e.g. with a type of "norwegian-abbreviation-code"). Perhaps this is what you really want to achieve?

wrygiel commented 7 years ago

you could use "other-id" for that (e.g. with a type of "norwegian-abbreviation-code")

But then nobody would display those in their client software. So there's not much point in this solution, I think.

kaiqu commented 7 years ago

you could use "other-id" for that (e.g. with a type of "norwegian-abbreviation-code")

But then nobody would display those in their client software. So there's not much point in this solution, I think.

Ah - if "other-id" isn't supposed to be displayed, there is no point, I agree.

So, the "abbreviation" suggestion remains for both APIs, with the following (attempted) uniqueness:

wrygiel commented 7 years ago

Ah - if "other-id" isn't supposed to be displayed, there is no point, I agree.

Depends on the implementer, but I would display only the "known" other-id types, the ones my users would find useful (as opposed to displaying all of them).

So, the "abbreviation" suggestion remains for both APIs, with the following (attempted) uniqueness

Ok!

wrygiel commented 7 years ago

One more thing - should we allow HEI (or unit) to specify more than one abbreviation?

wrygiel commented 7 years ago

should we allow HEI (or unit) to specify more than one abbreviation?

I assumed that one abbreviation is enough. If multiple abbreviations exist, then one of them should be selected.

kaiqu commented 7 years ago

I assumed that one abbreviation is enough. If multiple abbreviations exist, then one of them should be selected.

I agree.