CPA2.3 Access

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

  1. Initial: one or more of the specific objectives and required activities are at an initial maturity level.
  2. 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.
  3. 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.