Closed kaiqu closed 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?
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.
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.
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?
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.
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:
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!
One more thing - should we allow HEI (or unit) to specify more than one abbreviation?
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.
I assumed that one abbreviation is enough. If multiple abbreviations exist, then one of them should be selected.
I agree.
@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 :-)