Formats & representation: 6. Transform to match use cases

This step creates mappings, translations and alternative representations that allow the research object to meet integration and interoperability requirements of the primary use cases.

Different communities, repositories, services, tools and workflows may use other identifier schemes, vocabularies, models or representations. This step connects the canonical representation, developed through the previous steps, to those external requirements through documented mappings and transformations.

An alternative representation may be stored, generated on demand or exposed through a service. Its relationship to the canonical representation and its status as an authoritative, derived, provisional or application-specific representation should be explicit.

This step does not require every transformation to be bidirectional or lossless. A one-way or simplified representation may be appropriate where it meets the intended use, provided that its direction, limitations and information loss are documented.

Use this step during project examination to identify integration requirements, assess available mapping and transformation capabilities and define the required outputs. During an implementation cycle, use it to create, apply and validate the mappings, translations and alternative representations within scope.

Identifier mapping

Establish and maintain documented relationships between identifiers used by different schemes, authorities, repositories or systems.

This capability allows integrations to recognise when identifiers refer to the same subject or to subjects connected through version, component, derivation, replacement or other defined relationships. Since mapping are not always assertions of an exact identity match, the relations should be stated explicitly:

• Exactly the same subject.
• Different records describing the same subject.
• Different versions or releases.
• A collection and one of its components.
• An original and a derived research object.
• A deprecated and replacement identifier.
• Closely related but distinct subjects.

The capability may be provided through authoritative registries, repository cross-references, identifier-resolution services, community mapping resources, lookup services or project-maintained mappings (that themselves can be shared).

Resources

Vocabulary alignment

Establish and maintain documented semantic relationships between concepts from different controlled vocabularies, terminologies, taxonomies or ontologies.

This capability allows the concepts used in the canonical representation to be interpreted or translated for communities and systems that use other semantic resources. Possible alignment relationships include:

• Exact match.
• Close match.
• Broader match.
• Narrower match.
• Related match.
• Context-dependent correspondence.
• Composite or one-to-many correspondence.
• No suitable match.

The capability may be provided through mappings published by vocabulary authorities, community alignment projects, ontology services, mapping registries, specialist tools or project-generated mapping sets.

Resources

Model mapping

Relate entities, properties, relationships, structures and constraints across domain, data, metadata or structural models.

This capability connects the canonical model and representation to the models expected by target communities, repositories, services, tools and workflows. Model mapping may describe conceptual correspondences, structural crosswalks or executable transformation rules.

Mappings are not limited to one-to-one equivalence. A source element may correspond to several target elements, several source elements may be combined, or a target value may need to be derived.

The capability may be provided through standards crosswalks, repository mappings, schemas, transformation specifications, ETL workflows, query languages or project-developed mapping artefacts.

Resources