Abbreviation

[kaiqu]

@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]

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]

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]

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]

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]

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]

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:

• Institutions API: Country-wide
• OUnits API: HEI-wide

[wrygiel]

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]

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

[wrygiel]

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]

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

I agree.