Purpose
The objective is to provide access to research data in an effective and secure way, ensuring that data can be discovered, accessed, understood, used and re-used in the long-term perspective.
CC2.3: Capability completeness of Access
- Initial: one or more of the specific objectives and required activities are at an initial maturity level.
- Partial: only some of the specific objectives or required activities are met at a defined maturity level, or all specific objectives are met at a repeatable maturity level.
- Complete: all specific objectives and required activities are met at a defined maturity level or better.
SO2.3.1: Discoverability and accessibility
To enable users to discover, access and download data and metadata.
RA2.3.1.1: Access interfaces
The repository provides one or more interfaces to the information holdings of the repository (note: “...interfaces will normally be via computer network or […] links to an online service, but might also be implemented in the form of a walk-in facility, printed catalogue ordering service, or fax-back type service” [Source: OAIS].
(0) Not defined: |
No interfaces or contact points (repository is in the establishing phase). |
(1) Initial: |
The repository may have an office or a walk-in facility that provides irregular and ad hoc assistance getting access to its information holdings; formalised access procedures and processes are lacking; few or none online interfaces are available, or they are ‘hostile’ to users. |
(2) Repeated/partial: |
Access is being provided repeatedly (e.g. through office hours, personal contact or online correspondence); some of the information holdings are available through online interfaces; awareness of accessibility and usability of interfaces is growing; part(s) of interface(s) are satisfactory, others parts are inadequate; lacks systematic approach and dedicated resources (staff, funding). |
(3) Defined: |
Online interfaces are in place; there is a systematic approach to the development of interfaces; focus on users and usability; sufficient resources and qualified personnel are in place; processes and procedures are formalised and documented. |
(4) Managed: |
Interfaces are regularly reviewed and updated; usage and access is measured and monitored. |
(5) Optimised: |
Surveys, review processes or other feedback mechanisms are in place; outputs of monitoring are formally reported; reporting are aligned to technology watch and are and integrated into higher level preservation strategies and policies. |
RA2.3.1.2: Searchable and indexed content
The data and metadata holdings of the repository are searchable through indexed content (variables, abstracts, etc.). [maps to Annex 2, section 5]
(0) Not defined: |
No search facilities; content is not indexed |
(1) Initial: |
Some awareness of the need to index information; some content is indexed on an ad hoc basis, on the individual level; no formalised procedures or standards for indexing are implemented. |
(2) Repeated/partial: |
Much of the repository content is searchable, but information is unstructured; no formalised procedures or standards for indexing are implemented; single (local) language thesauruses may be in use. |
(3) Defined: |
All content is structured through standards and thesauruses (e.g. HASSET and/or ELSST) are used to index and search data and metadata holdings; processes and procedures are formalised and documented; usage of standards and thesauruses are explicitly defined; multi-lingual thesauruses in use; mechanisms in place to ensure that their local language(s) are maintained within the multi-lingual thesauruses. |
(4) Managed: |
Search and indexing procedures are regularly measured, reviewed and updated. |
(5) Optimised: |
Outputs of monitoring are formally reported; reporting are aligned to technology watch and communication with Designated Community; processes and procedures are integrated into higher level preservation strategies and policies. |
RA2.3.1.3: Downloadable data holdings
The repository makes their data holdings downloadable through data gateways / interfaces. [maps to: Annex 2, section 4] [Annex 2, section 12] [Annex 2, section 13] [CESSDA Statutes, section 7]
(0) Not defined: |
No data is downloadable. |
(1) Initial: |
Repository is in the phase of selecting and acquiring data; limited availability of content, only parts of collection is made available for download. |
(2) Repeated/partial: |
Most data are downloadable through interfaces/gateways; downloads are un-administered and lacks reporting mechanisms. |
(3) Defined: |
All data holdings are downloadable through stable interfaces; any restrictions and condition on (re-)use of data formalised and documented; default position regarding downloadable publicly/government funded data is that it shall be openly accessible and free; all data are accessible for free for authenticated members from public research and education. |
(4) Managed: |
Downloads and download routines are regularly measured and assessed; procedures and processes are updated and reviewed. |
(5) Optimised: |
The usage and success of download framework are continuously assessed and monitored; regular and formalised contact with relevant stakeholders; framework for downloads are regularly reviewed and updated based on technology watch and technology monitoring. |
RA2.3.1.4: Metadata harvesting
The repository enables the harvesting of all their resource discovery metadata and relevant preservation metadata. [maps to: Annex 2, section 3] [Annex 2, section 12]
(0) Not defined: |
No metadata harvesting enabled |
(1) Initial: |
Repository is in the phase of selecting and acquiring data; metadata is unstructured and has limited accessibility. |
(2) Repeated/partial: |
Most metadata can be harvested, but protocols are not implemented (or are only partly implemented). |
(3) Defined: |
All metadata are harvestable; OAI-PMH / Dublin Core are implemented; metadata from publicly funded data are openly accessible and free; all metadata free for authenticated members from public research and education. |
(4) Managed: |
Metadata harvesting is measured and monitored; regular reviews of metadata protocols. |
(5) Optimised: |
Outputs of monitoring are formally reported; reporting are aligned to technology watch and communication with users / Designated Community; metadata accessibility is integrated into higher level preservation strategies and policies. |
RA2.3.1.5: Data formats
The repository has an explicit data format strategy and provides data in formats that are used and understood by the Designated Community.
(0) Not defined: |
No strategy for formats and standards. |
(1) Initial: |
There is some awareness of the formats and standards that are used by Designated Community; the repository provides data in user-specified formats on an ad hoc basis, when enquired. |
(2) Repeated/partial: |
Some standards and formats are repeatedly in use; lacks a defined and explicit strategy; there are no lists of available formats. |
(3) Defined: |
A data format strategy is explicitly defined and formalised and communicated to users; data are provided in formats that are commonly in use and understood by users. |
(4) Managed: |
Data format usage and enquiries are measured and assessed; data format strategy is regularly reviewed and updated. |
(5) Optimised: |
Data format strategy is regularly reviewed and updated based on technology watch and formalised communication with users / Designated Community; data format strategy is integrated into higher level data policies. |
RA2.3.1.6: Metadata standards
The repository provides metadata in accordance with standards that are used and understood by the Designated Community [maps to Annex 2, section 1].
(0) Not defined: |
No awareness; no strategy for metadata standards. |
(1) Initial: |
Some awareness of metadata standards; most of repository holdings lack a coherent metadata strategy. |
(2) Repeated/partial: |
Some metadata standards are repeatedly in use; lacks an explicit and formalised strategy. |
(3) Defined: |
Metadata are provided in accordance with standards that are used and understood by the Designated Community (e.g. DDI); metadata strategy is explicitly formalised and defined and communicated to the Designated Community. |
(4) Managed: |
Usage and enquiries concerning metadata are measured and assessed; metadata strategy is regularly reviewed and updated. |
(5) Optimised: |
Metadata strategy is regularly reviewed and updated based on technology watch and formalised communication with users / Designated Community; metadata strategy is integrated into higher level data policies (open data policies). |
RA2.3.1.7: Access policy
The repository uses an access policy to address and guide data and metadata access. [maps to Annex 2, section 13] [CESSDA Statutes, section 7]
(0) Not defined: |
Not applicable; no awareness |
(1) Initial: |
There is some awareness of the need for an access policy; data access processes are performed on an ad hoc basis. The repository deals with access issues on a case-by-case basis. |
(2) Repeated/partial: |
The access policy is not formally defined, but there are some repeatable procedures in place; data access processes follow a regular pattern - they have developed to the stage where similar procedures are followed by different people undertaking the same task. |
(3) Defined: |
An access policy is defined and is connected to specific processes and procedures; the policy is in conformance with the OECD recommendations and guidelines on data access (OECD Principles and Guidelines for Access to Research Data from Public Funding, OECD 2007). |
(4) Managed: |
The access policy is monitored and measured for compliance with processes and procedures; actions are taken where processes appear not to be working effectively or not to be in accordance with the policy. |
(5) Optimised: |
Access policy is regularly reviewed and updated based on technology watch and formalised communication with users / Designated Community. |
SO2.3.2: Access control and handling of anomalies
To provide controlled access to repository holdings by identifying users and to handle any technical errors and anomalies in a secure way.
RA2.3.2.1: Failures, anomalies, system failures
The repository logs and reviews all errors, access management failures and anomalies (in order to identify security threats and access management system failures).
(0) Not defined: |
No logs or reviews of failures. |
(1) Initial: |
Some awareness of the need to handle and review access failures and anomalies; issues are solved and recorded on an ad hoc, case-by-case basis; no formalised procedures or logs/protocols are in place. |
(2) Repeated/partial: |
Failures and anomalies are repeatedly solved and recorded in specific ways, but there are no written procedures or process descriptions in place; logs may exists but they are incomplete and lacks a common, formalised framework. |
(3) Defined: |
All access management failures and anomalies are logged, recorded and reviewed in a systematic way; processes and procedures for error handling are formalised and documented. |
(4) Managed: |
All logs, processes, procedures and handling of anomalies and errors are regularly reviewed and updated. |
(5) Optimised: |
All systems are regularly reviewed and updated; system checks and reviews should be able to identify possible security threats before they occur (predictive). |
RA2.3.2.2: Persistent identifiers (PIDs) / locators
The repository uses externally visible, standardised persistent identifiers to ensure reliable tracing of data and metadata.
(0) Not defined: |
No system or policy for persistent identification |
(1) Initial: |
There is some awareness of the need for persistent identifiers and locators, but actions are sporadic and ad hoc; there are no formalised systems, processes or procedures in place. |
(2) Repeated/partial: |
Mechanisms and systems for identification and location are partly in place, but does not comply with formalised DOI systems; mechanisms are being repeatedly used, but there is lack of formalisation and written procedures. |
(3) Defined: |
There are mechanisms and systems in place for persistently identify and locate data and metadata (either by following external systems like DOI, or by internal PID systems); all processes and procedures are documented and formalised. |
(4) Managed: |
PID systems and locators are regularly reviewed and updated; mechanisms are aligned to higher level preservation goals and plans. |
(5) Optimised: |
All mechanisms and functions are monitored and measured; there are systemised reviews and updates of PID systems based on technology watch and formal, regular communication with Designated Community. |
RA2.3.2.3: Authentication and authorisation
The repository uses AAI (Authentication and Authorisation Infrastructure) or other direct or federated user authentication approaches to control access to data.
(0) Not defined: |
No authentication approach in place. |
(1) Initial: |
There is some awareness of the need to implement authentication approaches; access control is performed on an ad hoc, case-by-case basis. |
(2) Repeated/partial: |
An authentication infrastructure emerges by repeated use of authentication approaches; lacks standardisation and formalisation. |
(3) Defined: |
The repository uses digital identities, identity management, authentication, authorisation to control access to data; AAI is formalised, systematised and documented. |
(4) Managed: |
All AAI mechanisms and functions are measured, assessed and regularly reviewed and updated. |
(5) Optimised: |
All AAI mechanisms and functions are monitored and measured; there are systemised reviews and updates of PID systems based on technology watch and formal, regular communication with Designated Community and other relevant stakeholders. |