Consortium of European Social Science Data Archives

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.