OpenAIRE compatibility checklist
Use this checklist to review whether dataset metadata and the repository interface are prepared for aggregation, discovery and linking through OpenAIRE. The checklist covers both individual metadata records and the technical provision of repository metadata. It is intended as a practical pre-check before formal validation and registration of a data source.
Resource information
Resource type
Metadata and repository interoperability checklist
Intended users
Repository managers, metadata specialists, developers, curators and data stewards
Recommended use
Metadata mapping, repository onboarding, harvesting preparation and validation
Status
Practical pre-check based on the OpenAIRE Guidelines
Download the checklist
Use the XLSX version to review metadata records and repository interfaces separately. Record evidence, validation results,responsible persons and required corrective actions.
Available formats
What does OpenAIRE compatibility mean?
OpenAIRE compatibility means that a research data source can expose sufficiently complete, structured and consistently encoded metadata for aggregation, validation, discovery and linking with other research entities.
Compatibility therefore depends on both the quality of individual dataset records and the technical interface through which the repository provides those records.
Compatibility is a repository-level capability
A researcher can improve an individual metadata record, but the repository manager is responsible for metadata mapping, export, harvesting interfaces, validation and data-source registration.
Two levels of compatibility
Complete both parts of the checklist when preparing a repository for OpenAIRE validation or aggregation.
1. Dataset metadata record
Reviews identifiers, creators, title, publisher, dates, resource type, description, access rights, licence, funding and relationships to other research outputs.
2. Repository and harvesting interface
Reviews metadata mapping, OAI-PMH exposure, metadata format, sets, record identifiers, update handling, validation and registration readiness.
Dataset metadata record checklist
Review whether each dataset record contains complete and consistently encoded information before testing repository-level compatibility.
| Area | Compatibility criterion | Expected evidence |
|---|---|---|
| Identification | The dataset has a globally unique and persistent identifier. | DOI, Handle, URN or another supported identifier |
| The identifier resolves to the correct public landing page. | Successful identifier resolution test | |
| The dataset title is present and understandable. | Title metadata element | |
| The publisher or repository responsible for publication is identified. | Publisher metadata element | |
| The publication year is present and correctly encoded. | Publication year value | |
| A relevant date and date type are provided. | Issued, Available, Updated or another appropriate date | |
| The resource is identified as a dataset or another correct research-output type. | Resource type and general resource category | |
| Creators and organisations | At least one creator is present. | Creator name |
| Creator names follow one consistent form. | Consistent family-name and given-name representation | |
| Creators are listed in the intended attribution order. | Ordered creator list | |
| ORCID or another person identifier is included where available. | Name identifier and identifier scheme | |
| Creator affiliations are present where available. | Affiliation metadata | |
| Institution names are represented consistently. | Normalised organisation names | |
| Contributors are distinguished from principal creators. | Contributor name and contributor type | |
| Description and discovery | A description or abstract explains the dataset content and purpose. | Description with an appropriate description type |
| Subject terms or keywords are provided. | Subject metadata | |
| Controlled subject schemes are identified where used. | Subject scheme and scheme URI | |
| The language of the resource is provided where applicable. | Language code | |
| File formats are recorded where available. | Format or media-type values | |
| Dataset version information is included where versioning applies. | Version metadata | |
| Access and rights | The access status is stated explicitly. | Open, restricted, embargoed or closed access |
| The access value uses the expected controlled representation. | Recognised rights URI or vocabulary term | |
| A licence is provided where one applies. | Licence name and URI | |
| Access status and licence are not confused. | Separate access and licence statements | |
| An embargo end date is provided when the dataset is embargoed. | Available date | |
| Restricted-access procedures are described on the landing page. | Access-request information | |
| Public metadata do not disclose restricted information. | Metadata sensitivity review | |
| Funding and relationships | Funding information is included when applicable. | Funder, funding programme and award identifier |
| Funding identifiers are represented consistently. | Persistent or authoritative award information | |
| Related publications are linked when known. | Publication DOI or another persistent identifier | |
| Related datasets are linked when known. | Related dataset identifier | |
| Related software or workflows are linked when relevant. | Software DOI, URL or other identifier | |
| Every related identifier has an identifier type. | DOI, URL, Handle or another type | |
| Every relationship has an appropriate relation type. | IsSupplementTo, IsDerivedFrom, IsVersionOf or another relation | |
| Record consistency | Required metadata elements are not empty. | Validated metadata record |
| Dates, identifiers and URIs use valid syntax. | Syntax-validation result | |
| Values are represented in the appropriate XML or metadata structures. | Exported metadata record | |
| The exported record corresponds to the repository landing page. | Export–landing-page comparison | |
| No placeholder or test values remain in the production record. | Final metadata review |
Repository and harvesting interface checklist
This part should be completed by the repository manager or technical operator responsible for metadata export and data-source provision.
| Area | Compatibility criterion | Expected evidence |
|---|---|---|
| Repository identity | The repository has a stable public name and landing page. | Repository information page |
| The responsible organisation and operator are identified. | Provider and operator information | |
| A technical contact is available. | Repository contact information | |
| The repository scope and supported research outputs are described. | Repository policy or description | |
| Repository terms of use and metadata-use conditions are available. | Published terms or policy | |
| The repository uses stable public dataset landing pages. | Sample public records | |
| Production and test interfaces are clearly distinguished. | Documented production endpoint | |
| OAI-PMH interface | A publicly accessible OAI-PMH base URL is available. | Production OAI-PMH endpoint |
The interface responds correctly to Identify. |
Valid Identify response | |
The interface responds correctly to ListMetadataFormats. |
Available metadata-prefix list | |
| The expected DataCite metadata format is exposed. | metadataPrefix="oai_datacite" |
|
The interface responds correctly to ListSets where sets are used. |
Valid set list | |
The interface responds correctly to ListRecords. |
Harvestable records | |
| Pagination and resumption tokens operate correctly. | Successful multi-page harvesting test | |
| Repository record identifiers are stable and unique. | Persistent OAI identifiers | |
| Dates used for incremental harvesting are updated correctly. | Datestamp and update test | |
| OpenAIRE set | An OpenAIRE-specific OAI set has been considered. | Documented set decision |
| The set uses the expected lowercase set specification where implemented. | openaire_data |
|
| The set contains the intended dataset records. | ListRecords query using the set | |
| Test, withdrawn and unintended records are excluded where appropriate. | Set-content review | |
| The rule for inclusion in the set is documented. | Local harvesting policy | |
| Metadata mapping | Local fields are mapped to the expected DataCite/OpenAIRE elements. | Metadata crosswalk |
| Mandatory elements are always exported. | Sample-record validation | |
| Mandatory-if-applicable elements are exported when values exist. | Rights, descriptions and related identifiers | |
| Repeatable local fields remain repeatable in the export. | Multiple creators, subjects and relations | |
| Controlled values are mapped to the required vocabulary terms or URIs. | Mapping table | |
| Identifiers retain their scheme information. | Identifier type and scheme | |
| Related identifiers retain relation types. | RelatedIdentifier export | |
| The export does not flatten structured fields into ambiguous free text. | XML structure review | |
| Record lifecycle | Newly published records become available for harvesting. | Publication-to-export test |
| Metadata updates are reflected in the exported record. | Update test | |
| Version changes are represented consistently. | Versioned record comparison | |
| Withdrawn or deleted records are handled according to repository policy. | Deleted-record behaviour | |
| Restricted datasets retain publicly harvestable metadata where appropriate. | Restricted-record test | |
| Landing-page URLs in the export remain valid. | URL resolution test | |
| Metadata exports remain available after software updates. | Regression test | |
| Validation and registration | Representative records have been tested before full validation. | Sample validation report |
| Mandatory-field and encoding errors have been corrected. | Resolved validation issues | |
| Warnings have been reviewed rather than ignored automatically. | Warning-resolution log | |
| The production interface has been tested with the applicable validator. | OpenAIRE validation result | |
| The registered base URL and compatibility profile correspond to production. | Registration information | |
| A contact has been assigned for future validation failures. | Named responsible person | |
| Compatibility is rechecked after metadata-schema or repository upgrades. | Periodic validation procedure |
Minimum compatibility record
At minimum, a dataset record should contain a valid identifier, creator, title, publisher, publication year and relevant date. Rights and description information should be supplied whenever applicable.
At repository level, the production metadata interface should expose valid and harvestable records using the supported metadata format, preserve structured values and pass the applicable compatibility checks.
How to record the result
Record the result separately for the metadata-record and repository-interface levels.
Yes
The criterion is satisfied and technical evidence is available.
Partly
The criterion is implemented but requires correction or completion.
No
The criterion is not currently satisfied.
Not applicable
The criterion does not apply to the repository or record type.
Needs clarification
Metadata or technical guidance is required before assessment.
How to use the checklist
1. Sample
Select representative open, restricted, funded and related-output dataset records.
2. Inspect
Compare repository metadata with the actual exported records.
3. Test
Test the production harvesting interface, formats, sets and record lifecycle.
4. Correct
Correct field mappings, vocabularies, missing values and interface errors.
5. Validate
Run formal validation and document the production configuration.
Issues that should block validation or registration
Do not proceed until the following critical problems have been resolved.
Unavailable interface
The production harvesting endpoint is inaccessible, unstable or returns invalid protocol responses.
Missing mandatory metadata
Required identifiers, creators, titles, publisher or date values are absent from exported records.
Incorrect metadata mapping
Structured local information is lost, misclassified or exported using invalid elements or values.
Unresolved record links
Dataset identifiers or landing-page URLs do not resolve to the correct public records.
Record the validation configuration
Record the repository name, production base URL, metadata prefix, selected OAI set, guideline profile, validation date, validator result, unresolved warnings, responsible technical contact and software version.
Repeat validation after changes to metadata mappings, OAI-PMH configuration, repository software or publication workflows.
Important notes
- Treat this checklist as a preparation aid rather than as a substitute for the current official OpenAIRE Guidelines and validation service.
- Assess exported metadata rather than relying only on the values visible in the repository user interface.
- Test several record types, including records with funding, embargoes, restrictions and related research outputs.
- Do not assume that a DataCite DOI automatically makes the complete repository record OpenAIRE-compatible.
- Keep access status, licence and embargo information as distinct metadata concepts.
- Preserve identifier schemes and relationship types in the exported metadata.
- Use the production endpoint during final validation rather than a temporary development interface.
- Revalidate after repository upgrades or changes to metadata crosswalks.
- Document local decisions for mapping repository fields to the OpenAIRE application profile.