European Higher Education Institution Identifiers

Living Standard,

This version:
https://heidirepo.github.io/EHEII
Issue Tracking:
GitHub
Inline In Spec
Editors:
(Knowledge Innovation Centre)
(European Quality Assurance Register)

CC0 To the extent possible under law, the editors have waived all copyright and related or neighboring rights to this work. In addition, as of 17 December 2020, the editors have made this specification available under the Open Web Foundation Agreement Version 1.0, which is available at http://www.openwebfoundation.org/legal/the-owf-1-0-agreements/owfa-1-0. Parts of this work may be from another specification document. If so, those parts are instead covered by the license of that specification document.

Abstract

A proposal for an enhanced, interoperable approach to identifying higher education institutions in Europe

1. Background

1.1. Relevance

Higher education institutions (HEIs) are a pivotal entity for many different systems and applications. Institutional identifiers are thus a matter of priority.

With less than 10000 HEIs in Europe the numbers are relatively managable, but yet large enough to warrant some standardisation to allow for data exchange without manual intervention or mapping.

1.2. Existing systems

Various approaches already exist to identify higher education institutions in Europe:

Identifier Maintained by Used in Link Comment
PIC EU EU programmes, European Student Card EU portal
Erasmus Institution Code EU Erasmus+ EU page
eIDAS identifier EU Europass Digital Credentials EU page General organisational identifier, not HE specific
SCHAC Géant ELMO, Emrex, EWP SCHAC
ETER ID EU-funded consortium ETER, OrgReg, DEQAR ETER page
DEQARINST ID EQAR DEQAR DEQAR data
Global WHED ID IAU WHED WHED page World-wide coverage

The EWP Registry Service provides an accessible mapping between SCHAC, PIC and Erasmus codes for a number, but not all HEIs in Europe. The EU provides a spreadsheet of Erasmus Institution Codes, including the related PIC code.

Given that each organisation has their own approach how to deal with demographic changes (e.g. mergers), there is not necessarily a one-to-one relationship between different identifiers.

In conclusion, existing identifiers for HEIs in Europe are currently not fully articulated to each other.

2. Use Cases

The following use cases should be made possible/be facilitated by an enhanced approach to HEI identifiers.

**NB: This is an initial collection of use cases. We aim to supplement those with contributions from stakeholders during the discussion. Use cases should be defined in line with this template.**

2.1. Cross-check Institution Data

Actor: HEI, recognition officer, student, employer

Submitter: Colin Tück

User Story: The users receives data from or about a HEI, and wishes to automatically search another database for additional data about the HEI concerned.

For example, the user might recieve student mobility data, such as a transcript of records, via EMREX or EWP, or a qualification from a student applying for recognition. The user wants to acquire information on the sending institution’s quality assurance status from DEQAR.

Restrictions: none

2.2. Populate EDCI Accreditation Database

Actor: Europass National Offices

Submitter: Anthony F. Camilleri

User Story: The user wishes to collect national data on courses, qualifications and institutional/programme accreditations, and upload these to Europass to power the 'course search', as well as the 'accreditation check' for digitially signed credentials. The identifiers used for data collection at national level should ensure no duplication of data, while the identifiers sent to Europass should resolve back to the institutions, and also not be duplicated with identififiers from other Member States/data suppliers.

Restrictions: All institutions in the database must be represented by a URI due to requirements arising from the W3C Verifiable Credentials standard.

2.3. Correlate Datasets

Actor: researcher, policy maker, statistics office

Submitter: Colin Tück

User Story: The user has data on a number of HEIs in Europe and wishes to correlate this with other data or statistics on the same HEIs, e.g. from ETER.

Restrictions: none

2.4. List Higher Education Institutions

Actor: HEI, student, university staff

Submitter: Jeroen van Lent

User Story: The user wishes to access a list of current Higher Education Institutions in Europe, and preferably also globally. This include names in English as well as in local language and also distinguish the business/brand name, should that be different from the legal name + official abbreviation. This list should be made available to a directory of HEIs as well as made available to various student information systems and student data exchange applications.

Restrictions: none

2.5. Geographic Clustering

Actor: HEI, student, university staff

Submitter: European University Foundation

User Story: The user wishes to cluster HEIs by geographical location, preferably based on coordinates. (NUTS2 regions are not universally available beyond the EU.)

Actor: HEI, recognition officer, researcher

Submitter: Colin Tück

User Story: The user wishes to identify HEIs by former names (including former institutions) and to follow (past or present) links between HEIs (e.g. consortia, merged institutions, spin offs, etc.).

Restrictions: none

3. Requirements

3.1. Basic Requirements

3.1.1. Identifier is a URI

Identifiers must be Uniform Resource Identifiers (URIs).

3.1.2. Identifier is permanent

An identifier must be permanently assigned to an institution; it must remain assigned (for historical reference) after that institution has closed and must never be re-assigned to a different institution.

3.1.3. Identifier is resolvable to a validated Record

Each identifier must be resolvable/dereferencable to a Record with a minimum dataset containing:

to check if all HEIs necessarily have a legal entity ID <https://github.com/HEIDIrepo/EHEII/issues/1>

need to distinguish between geographic location and HE system to which the institution belongs <https://github.com/HEIDIrepo/EHEII/issues/2>

The minimum dataset must be validated, e.g. by verifying against XSD/JSON Context/equivalent before publication.

3.2. Management Requirements

3.2.1. Identifiers are only issued to officially recognised higher education institutions

Identifiers must be assigned only to entities that are officially recognised as higher education institutions/providers according to their national legislation. Identifiers should thus be generated by trusted issuer organisations in a federated network; trusted issuers could include national authorities and select European bodies to issue identifiers for countries where no national authorities issues identifiers.

3.2.2. Each Identifier and minimum dataset associated record are owned by one issuer

The trusted issuer owns and is responsible for the minimum dataset and must keep it up-to-date. Ownership of identifiers (and the associated records) must be transferable between issuers.

3.2.3. Governed by agreed policies

All aspects of operations must be governed by agreed policies, including on:

3.2.4. Public challenge mechanism

Any public user must be able to open issues against identifiers (see the GLEIF Challenge mechanism for an example). Such issues will be linked to the respective identifier, and must be resolved by the issuer. Issues can be opened in respect to incorrect legal form, wrong parent/child , institution no longer operating etc.

3.3. Interoperatbility Requirements

3.3.1. Central hub to aggregate/store all Identifiers and Records

A central hub must provide access to all Identifiers and Records. It must offer at least a REST API and a public front-end, both allowing search by various parameters.

3.3.2. Catalogue of interoperable operators

All operators using Identifiers should publish their use in a central, open catalogue, together with method to search/connect/resolve by Identifier.

3.3.3. Ability for institutions to self-publish data

Higher education institutions should be able to self-publish (additional) data without the need to register or manually contact another body.

This could be accomplished by creating a namespace that defines an agreed URL under their own domain where institutions may self-publish data.

4. Options

To be elaborated and discussed after first meeting.

Conformance

Conformance requirements are expressed with a combination of descriptive assertions and RFC 2119 terminology. The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in the normative parts of this document are to be interpreted as described in RFC 2119. However, for readability, these words do not appear in all uppercase letters in this specification.

All of the text of this specification is normative except sections explicitly marked as non-normative, examples, and notes. [RFC2119]

Examples in this specification are introduced with the words “for example” or are set apart from the normative text with class="example", like this:

This is an example of an informative example.

Informative notes begin with the word “Note” and are set apart from the normative text with class="note", like this:

Note, this is an informative note.

References

Normative References

[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Best Current Practice. URL: https://tools.ietf.org/html/rfc2119

Issues Index

to check if all HEIs necessarily have a legal entity ID <https://github.com/HEIDIrepo/EHEII/issues/1> ↵
need to distinguish between geographic location and HE system to which the institution belongs <https://github.com/HEIDIrepo/EHEII/issues/2> ↵