How to adapt international metadata standards
International metadata standards provide common properties, definitions, identifiers and controlled values for describing research objects across repositories, catalogues and information systems.
This guideline explains how to create a local application profile based on an international standard without changing its original semantics. It covers standard selection, field mapping, local obligations, multilingual labels, controlled vocabularies, extensions, validation and profile governance.
Resource information
Resource type
Metadata application profile development guideline
Intended users
Metadata specialists, repository managers, data stewards, curators and developers
Recommended use
Metadata-profile design, repository configuration, cataloguing and interoperability projects
Related output
A documented, versioned and technically implementable local application profile
What does adaptation mean?
Adaptation means selecting and constraining elements from an existing metadata standard for a defined community, repository, discipline or information system.
The resulting application profile specifies which properties are used, which are mandatory, which may be repeated, which controlled values are accepted, how local fields are mapped and how records are validated.
Adaptation does not mean changing the standard
A local profile may provide Ukrainian labels, examples, additional obligations and domain-specific extensions. It should not redefine the meaning of an international property or replace its canonical identifier with an unrelated local field.
Standard, vocabulary and application profile
Metadata schema
Defines properties, structures, cardinalities, value types and technical representations for metadata records.
Metadata vocabulary
Defines properties or concepts with stable names, identifiers and semantic definitions.
Application profile
Selects and constrains terms from one or more standards for a specific implementation or community.
Crosswalk
Documents relationships between fields in two schemas or between a local profile and an external standard.
Selecting the appropriate standard
Select the base standard according to the type of resource, destination system and required interoperability.
| Standard or profile | Recommended purpose | Typical use |
|---|---|---|
| DataCite Metadata Schema | Identification, citation and linking of datasets and other research outputs | DOI registration, repository metadata and research-object relationships |
| DCMI Metadata Terms | General semantic description of digital and physical resources | Institutional systems, linked data and lightweight cross-domain descriptions |
| DCAT | Description of catalogues, datasets, data services and distributions | Open-data portals, institutional catalogues and federated data catalogues |
| OpenAIRE Guidelines | Metadata exposure for aggregation into OpenAIRE | Repository harvesting, validation and OpenAIRE data-source registration |
| Disciplinary standard | Domain-specific scientific variables, methods and objects | Materials science, genomics, geosciences, social sciences and other domains |
Core principles of adaptation
Preserve semantics
Keep the original meaning and identifier of every reused property.
Document constraints
Define local obligations, cardinalities, value types and validation rules explicitly.
Reuse identifiers
Use canonical property URIs, persistent identifiers and recognised vocabulary terms wherever possible.
Extend transparently
Add local or disciplinary fields only when no suitable existing property can represent the requirement.
Metadata-profile development workflow
Develop the application profile through a documented sequence from use-case definition to validation and governance.
1. Define
Define the resources, users, systems and interoperability goals.
2. Select
Select the base standard, target profile and exact versions.
3. Map
Map local information requirements to canonical properties.
4. Constrain
Define obligations, cardinalities, value rules and extensions.
5. Validate
Test example records, approve the profile and manage its versions.
Step 1 — Define the use case
A metadata profile should be designed for a defined set of resources, systems and users rather than for every possible research object.
Questions to resolve
- Which resource types will the profile describe?
- Who creates, reviews and uses the metadata?
- Which repository, catalogue or CRIS will store the records?
- Which external systems must receive or harvest the metadata?
- Which scientific disciplines are covered?
- Which search, reporting and reuse tasks must be supported?
- Which Ukrainian legal or organisational requirements apply?
Step 2 — Select and version the base standards
Record the exact schema or vocabulary version on which the local profile is based. Do not define the implementation only as using the “latest” version.
Version record
Profile name: Ukrainian Research Dataset Metadata Profile
Profile version: 1.0
Base schema: DataCite Metadata Schema
Base schema version: 4.7
Additional vocabulary: DCMI Metadata Terms
Target interoperability profile: OpenAIRE Guidelines for Data Archives
Profile status: Draft
Approval date: YYYY-MM-DDStep 3 — Collect local information requirements
Create an inventory of the information currently collected by researchers, repositories, institutions and national information systems.
| Requirement | Source | Purpose |
|---|---|---|
| Dataset title and description | Repository and researchers | Discovery and interpretation |
| Creators, contributors and affiliations | Repository, CRIS and institutional reporting | Attribution and responsibility |
| Funding programme and project number | Grant and institutional requirements | Reporting and research-output linking |
| Scientific field and classification | Repository and national classifications | Search, statistics and aggregation |
| Access and legal restrictions | Authors, ethics and legal review | Access management |
| Disciplinary methods and variables | Research communities | Scientific interpretation and reuse |
Step 4 — Create a metadata crosswalk
Map every local requirement to the closest semantically equivalent international property. Record uncertain, partial and unsupported mappings explicitly.
| Local requirement | DataCite representation | DCMI representation | Mapping note |
|---|---|---|---|
| Dataset title | Titles.title |
dcterms:title |
Direct mapping |
| Dataset creator | Creators.creator |
dcterms:creator |
Preserve person structure and identifier |
| Description | Descriptions.description |
dcterms:description |
Select an appropriate description type where required |
| Dataset identifier | Identifier |
dcterms:identifier |
Preserve the identifier scheme |
| Subject or keyword | Subjects.subject |
dcterms:subject |
Preserve vocabulary and concept URI |
| Licence | Rights |
dcterms:license |
Keep licence separate from access status |
| Related publication | RelatedIdentifier |
dcterms:relation or a more specific relation |
Preserve identifier type and relation type |
| Publication date | PublicationYear and, where appropriate, Dates |
dcterms:issued |
Not always a one-to-one mapping |
Do not assume that similar field names are equivalent
Compare definitions and usage rules rather than only labels. Properties with similar names may represent different roles, events or levels of description.
Mapping relationship types
Each crosswalk relationship should indicate how closely the source and target properties correspond.
Exact
The source and target properties represent the same concept and level of description.
Broader or narrower
One property is more general or more specific than the other.
Conditional
The mapping is valid only for particular values, resource types or implementation conditions.
No equivalent
The local requirement requires an extension or cannot be exported to the target schema.
Step 5 — Define obligation and cardinality
The local profile may make an optional international property mandatory for a specific use case. This is a constraint on the local profile, not a change to the original standard.
| Profile rule | Meaning |
|---|---|
| Mandatory | The property must be present in every applicable record |
| Mandatory when applicable | The property must be present when the corresponding information exists or condition applies |
| Recommended | The property should be supplied whenever possible |
| Optional | The property may be supplied |
| Not used | The property is not included in this profile |
| Cardinality | Defines minimum and maximum occurrences, for example 1, 0–1, 1–n or 0–n |
Recommended field specification
Local label:
Canonical property:
Definition:
Purpose:
Obligation:
Cardinality:
Value type:
Controlled vocabulary:
Identifier scheme:
Language support:
Validation rule:
Example:
Mapping note:
Source standard:
Source version:Step 6 — Select controlled vocabularies
Use controlled values for fields that require consistent classification, validation or machine processing.
| Field type | Recommended value control |
|---|---|
| Resource type | Controlled resource-type list defined by the base standard or profile |
| Contributor role | Standard contributor or role vocabulary |
| Relationship type | Controlled relation-type vocabulary |
| Access status | Defined access-rights vocabulary and URI where required |
| Licence | Authoritative licence title and URI |
| Language | Standard language code |
| File format | Media type or documented format registry value |
| Scientific subject | Appropriate general or disciplinary vocabulary |
Step 7 — Support persistent identifiers
Research outputs
DOI, Handle, accession number or another authoritative identifier.
People
ORCID or another supported person identifier.
Organisations
ROR or another authoritative organisation identifier.
Projects and funding
Persistent or authoritative grant, award and project identifiers.
Preserve both the identifier value and its scheme. Do not transform different identifier types into undifferentiated text or local numeric codes.
Step 8 — Localise labels without changing machine values
The user interface and completion guidance may be provided in Ukrainian and English. Canonical property identifiers, vocabulary codes and technical values should remain unchanged.
Human-readable layer
- Ukrainian field label;
- English field label;
- completion instruction;
- local examples;
- explanation of institutional practice.
Machine-readable layer
- canonical property identifier;
- controlled vocabulary code or URI;
- standard identifier scheme;
- language tag;
- defined datatype and syntax.
| Layer | Example |
|---|---|
| Ukrainian label | Назва набору даних |
| English label | Dataset title |
| Canonical property | DataCite: Titles.title |
| Local instruction | Provide a specific title identifying the research object, method and scope where relevant. |
Step 9 — Add local and disciplinary extensions
Add a local property only after confirming that the requirement cannot be represented by an existing property, sub-property, controlled vocabulary or related object.
Document every extension
- local property identifier;
- human-readable labels;
- definition and purpose;
- expected value type;
- obligation and cardinality;
- controlled vocabulary where applicable;
- relationship to external properties;
- export and loss-of-information behaviour.
Prefer linked extensions to isolated fields
A domain-specific metadata block should be explicitly connected to the core dataset record so that general discovery metadata remains interoperable while disciplinary detail is preserved.
Step 10 — Define technical representations
The application profile should distinguish its conceptual model from the formats in which records are exchanged or stored.
Repository form
User-interface fields used for metadata entry and review
JSON
Structured metadata for APIs, local packages and automated processing
XML
Schema-based exchange, validation and repository harvesting
RDF or JSON-LD
Linked-data representation using persistent property and concept URIs
Step 11 — Develop validation rules
| Validation level | Example check |
|---|---|
| Presence | Mandatory property is present |
| Cardinality | Property occurs within the permitted minimum and maximum |
| Datatype | Date, URI, identifier, number or language tag has valid syntax |
| Controlled value | Value belongs to the permitted vocabulary |
| Conditional rule | Embargo end date is present when access status is embargoed |
| Relationship rule | Related identifier has both an identifier type and relation type |
| Cross-field consistency | Licence, access status and rights information do not contradict one another |
| Resolution | Persistent identifier resolves to the intended object |
Step 12 — Test the profile
Test the profile using representative records rather than one simple example.
Recommended test records
- an openly accessible dataset;
- a restricted or embargoed dataset;
- a dataset with several creators and affiliations;
- a funded dataset with a related publication;
- a versioned dataset;
- a dataset with disciplinary metadata;
- a multilingual dataset record;
- a record containing local extensions.
Profile governance and versioning
A metadata profile requires documented responsibility for approval, implementation, support and future updates.
| Governance element | Required decision |
|---|---|
| Profile owner | Organisation or group responsible for the profile |
| Technical maintainer | Person or team maintaining schemas and validators |
| Approval process | Procedure for approving new fields and profile versions |
| Change log | Documented additions, removals and changed constraints |
| Compatibility policy | Rules for backward compatibility and migrations |
| Review cycle | Regular review after changes to external standards or systems |
| Deprecation policy | Procedure for retiring fields without losing existing metadata |
Required profile documentation
Profile specification
Properties, definitions, obligations, cardinalities and value rules
Crosswalk
Mappings between local, base-standard and target-profile fields
Implementation guide
Repository, API, XML, JSON or RDF representation instructions
Validation package
Rules, examples, test records and expected validation results
Common adaptation problems
Translation instead of mapping
Field labels are translated, but canonical properties and their semantics are not documented.
One field for several concepts
Creators, contributors, contacts and institutions are combined in one unstructured text field.
Changed semantics
An international property is reused for a local value that does not match its definition.
Uncontrolled local values
Standard codes and URIs are replaced by inconsistent free-text variants.
Missing version information
The profile does not identify which version of the source standard it implements.
Overextension
Numerous local fields are added although existing international properties could represent the information.
Lossy export
Repeated values, identifiers or relationships are flattened into one text string during export.
No governance
Changes are introduced without approval, documentation or migration rules.
Recommended working method
Maintain the application profile, crosswalk, controlled-value lists, validation rules and examples as separate but versioned components of one profile package.
Test every change against existing repository records and all target export formats before approving a new profile version.
Important notes
- Record the exact version of every source standard and target interoperability profile.
- Preserve canonical property identifiers and standard definitions.
- Treat Ukrainian and English labels as interface and guidance elements rather than new metadata properties.
- Keep access status, licence, rights holder and access procedure as distinct concepts.
- Preserve repeated fields, nested structures, identifiers and relationship types during export.
- Add local fields only when an existing property cannot represent the requirement.
- Document data loss when a rich local profile is mapped to a simpler target format.
- Validate both individual records and repository exports.
- Review the profile after changes to DataCite, DCMI, DCAT, OpenAIRE or the repository software.
- Do not call a local profile an official DataCite, Dublin Core or OpenAIRE standard.