3 of 59

Acknowledgement of Country

We acknowledge and celebrate the First Australians on whose traditional lands we meet, and we pay our respect to their elders past and present.

4 of 59

Welcome to new RDA members!

OPENNESS

COMMUNITY-�DRIVEN

CONSENSUS

NON-PROFIT AND TECHNOLOGY-�NEUTRAL

HARMONISATION

INCLUSIVITY

6 Guiding Principles are at the heart of the RDA community.

JOIN THE RDA�www.rd-alliance.org/register/

All RDA members are expected to adhere by the RDA Code of Conduct to foster a welcoming and inclusive environment.

5 of 59

Metadata IG

Established May 2013 — First met Jan 2014 (P2, Munich) — New co-chairs 2024
Activities:

Provide forum for cross-domain discussions about metadata for research data
Identify and promote metadata solutions to data management challenges
Recommend how to improve quality and interoperability of metadata (better FAIRness)

Outputs:

RDA Metadata Principles and Their Use

Recommended Metadata Element Set
RDA Metadata Standards Catalog (via MSC WG)

6 of 59

Goal

How to extend basic metadata to more fully support FAIR data

access policies and procedures,
provenance, quality,
data structure
domain-specific semantics.

7 of 59

Agenda

Overview of Cross Domain Interoperability Framework (CDIF)
Documentation of datasets for data integration
DISCUSSION: Examples of metadata documenting complex datasets; where are there gaps?
Case study: Application of ODRL/DUO/DP to automate data access for sensitive data
Case study: machine-actionable descriptions of data access protocols for distributed genomic data and biobank
DISCUSSION: metadata conventions for extensions to enable automated data access and integration
Wrap-up. 3 Take aways, call for input on notes, examples, challenges…

8 of 59

Part 1: CROSS Domain Interoperability Framework

Simon Hodson

9 of 59

Identifies a set of functional requirements for interoperability, particular for steps in data combination, and identifies good practices for each of these requirements.
Draws on work with the WorldFAIR case studies and with a number of international initiatives (ODIS, Science on Schema.org, UN Stats KG work, GBIF…)
Good web practices: Significant proportion of CDIF rests on good web practice, domain neutral standards and good practice: disciplines can adopt or map.
Use cases: domain or cross-domain projects or data services that need to combine data for analysis, modelling etc.
Directed at implementers: describes use cases, identifies standards, gives guidance and on how to implement them.
Categorically not a new standard. Rather it is a framework of existing and emerging standards.
A framework of standards/specifications to provide a lingua franca.

What is the CDIF (Cross-Domain Interoperability Framework)?

10 of 59

What is CDIF?

The Cross Domain Interoperability Framework (CDIF) is a set of practical, implementation-level principles designed to improve data management practices within any community and lower the barriers to cross-domain data reuse. CDIF offers standards and methodologies for achieving different levels of interoperability necessary for reusing data across diverse domains. It is built around five core profiles that address the essential functions for implementing cross-domain FAIR principles.
CDIF was first released in May 2024 as an output of the WorldFAIR project: https://doi.org/10.5281/zenodo.11236871
The point of reference for CDIF and its component profiles is now the CDIF Book: https://cdif.codata.org
CDIF has attracted a lot of interest and has led directly to a set of additional projects and collaborations.

11 of 59

Discovery Profile

Discovery profile: https://bit.ly/cdif-discovery

A Content model that specifies the information expected to be included in any metadata record, with required, recommended and optional content items.
A JSON-LD serialization for that content using the Schema.org vocabulary to define the fields in a metadata record, and an implementation using the DCAT rdf vocabulary
Workflows to publish CDIF metadata so that is can be found and indexed by search providers using standard web technology

Variable description in the discovery metadata

Name of the variable as it appears in the dataset.

Uses schema.org variableMeasured.

Text description.
propertyID with URI for the represented concept.

12 of 59

Description Profile: DDI CDI for Data Structure, Variable Cascade, Provenance…

Important to think about how we combine data for cross-domain research.
Data Documentation Initiative (DDI) Cross-Domain Integration (CDI) specification contains three modules to assist with this:

Structural Description: assists processing of data structure transformations across four data structures.
Data Description / Variable Cascade describes data at an atomic level, describes relationships between concepts, representations and instances (assists with combining data and documenting information loss).
Provenance and Processing: module uses PROV-O and SDTL to provide and relay provenance and processing information.
Now officially released: https://ddialliance.org/ddi-cdi

13 of 59

CDIF, Next Steps

14 of 59

CDIF-4-XAS: Overview and Next Steps

Overview of standards, vocabularies (and ontologies), data formats and practices within the XAS area (landscape analysis): https://doi.org/10.5281/zenodo.14920226

Survey of XAS database schemas and software dependent XAS schemas.
Survey of XAS community standardisation effort: observe an alignment around NXxas for multi-spectra raw and processed data and XDI for single spectra data (reinforced by an IUCr recommendation).

Next Steps

D2: ‘Semantic description of at least two XAS community standards using a CDIF profile (XAS-CDIF)’: i.e. mapping and description of NXxas and XDI data using CDIF.

description using the CDIF Discovery profile for metadata;
description using DDI-CDI data description for variables, struccture;
characterisation of the XDI (table) and Nxxas (HDF5) data structures using DDI-CDI;
mappings for key concepts;
will be published next week… !

Use cases: CDIF-4-XAS contends that increased standardisation of metadata and by following CDIF recommendations will increase the reuse potential of XAS data outside the original experiment. Concrete use cases need to be identified to demonstrate that this is indeed the case.

15 of 59

Cluster of EC-funded projects, including Climate-Adapt4EOSC, looking at various case studies, including urban heat, coastal management and shrink-swell of soils.

CDIF for semantic and technical interoperability.
Incorporation and mapping of key semantics.
RO-Crates for packaging and orchestration.

Exploring how to maximise and automate solutions for Legal and Organisational Interoperability.

Identify commonly encountered LOI obstacles.
Identify corresponding LOI enablers (agreements/contracts, licences, conditions) and test them with case studies.
Express them in code (building on DPV, ODRL, DUO standards).
Report on landscape and proposed solutions, Dec 2025.
Legal and Organisational IFs, late 2027.

CDIF in Climate-Adapt4EOSC

16 of 59

“FAIR Principles implementation for DDE”: Implementation of FAIR principles, alignment of IUGS CGI standards with CDIF, for cross-domain research topics and data reuse in geology. Three years. From August 2025. Global. Funding from IUGS.

Enabling the alignment of IUGS CGI and other geology standards with CDIF.
Envisage a similar methodology to the OSCARS project with XAS data.
Map and implement CDIF discovery profile.
Implement CDIF data description profile.
Highlight importance of authoritative and FAIR concept schemes.

CDIF in DDE

17 of 59

Re-initiate the CDIF WG (break over summer, project proposals and deliverables…)
Continue exploring project and collaboration opportunities.
Upcoming Dagstuhl workshop will look at:

Provenance and context (and quality)…
Access (implementation of ODRL, DPV, DUO to manage responsibilities)
Metadata mapping and data integration
CDIF for XAS

CDIF: Next Steps

18 of 59

Part 2: DDI-CDI documentation for Data Integration

Stephen Richard

19 of 59

Data Integration

Use multiple datasets to produce a single unified data set that can be used in analysis
Issues:

what are the variables represented by the data
are the variables comparable
how to include domain-specific information
how is the information serialized

20 of 59

What are the variables

CDIF Discovery profile

schema.org variableMeasured: name, alternateName, description, propertyID, unitText

21 of 59

Are the variables comparable

This gets domain specific

measurement technique
context

iAdopt addresses the kinds of information require

This in general will require extension profile

22 of 59

Domain-specific information

Profiles:

set of conventions for representing some information
vocabulary
serialization scheme (compatible with base scheme)
requirements

Has to be documented and identified
Open world-- anyone can define a new profile....

need registry for others to find existing profiles (Metadata IG?)
interoperability agreements in communities

23 of 59

How to serialize

Need open-world serialization

RDF, JSON, YAML....

Metadata needs to self describe extensions included

"schema:about": {"@id": "xas:485749"},� "schema:description": "metadata about documentation for se_na2so4",� "dcterms:conformsTo": [� {"@id": "cdif:profile_basic_1.0"},� {"@id": "cdif:profile_xasCDIF"}�]

24 of 59

Discussion

EXAMPLE complex datasets with metadata

Data Cubes, Time series, vector or tensor fields,

Add examples in notes,

25 of 59

Part 3: automate data access for sensitive data

Steven D McEachern

26 of 59

Use case: automation of data access for sensitive data

A standalone repository holding sensitive personal data wishes to provide ‘secondary access’ to other research groups.

A metadata aggregator wants to provide search clients with filters based on access policies

A central clearing house mediating access to data in federated repositories

Federated analytics over multiple sensitive data providers

27 of 59

Proposed approach

Recommendation: Open Digital Rights Language (ODRL - W3C) to describe data asset access policies. https://www.w3.org/TR/odrl-model/

With

Data Use Ontology (DUO - GA4GH) to describe terms of use

Data Privacy Vocabulary (DPV - W3C) to describe and integrate legal and risk concepts

28 of 59

Object Digital Rights Language (ODRL)

A policy expression language that provides a flexible and interoperable information model, vocabulary, and encoding mechanisms for representing statements about the usage of content and services. (https://www.w3.org/TR/odrl-model/ )

Core classes:

Parties - actors or agents who exercise ->
Rules - ODRL Permissions (can do), ODRL Duties (must do), ODRL Prohibitions (must not do) encompassing ->
Actions - operations performed on ->
Assets - digital objects in a CDIF context.

Policies are then structured artefacts that document the above information.

29 of 59

Basic operation of ODRL

30 of 59

DUO

The Data Use Ontology was developed by the Global Alliance for Genomic Health (GA4GH) to allow “data stewards to tag datasets with permitted use terms that facilitate data discovery and access”

Source: https://www.ga4gh.org/product/data-use-ontology-duo/

31 of 59

DUO and

automation

Restrictions and requirements specified in licenses and DUO codes

Access requests specified in DUO-aligned request systems

Source: https://github.com/EBISPOT/DUO

32 of 59

Data Privacy Vocabulary (DPV)

“The motivation of DPV is to provide a 'data model' or an 'ontology' of concepts for interoperable representation and exchange of information about processing of (personal) data and the use of technologies.” Source: https://w3id.org/dpv/

Core conceptual model
With specific Risk and Impact Assessment (https://w3c.github.io/dpv/2.2/dpv/modules/risk.html )

“For risk and impact assessment, DPV's provides a 'lightweight risk ontology' based on commonly utilised concepts of Risk, RiskMitigationMeasure, Consequence, and Impact along with risk assessment concepts of RiskLevel, Severity, and Likelihood.”

33 of 59

The core DPV model

34 of 59

Combining

the three

Dataset policies as odrl:Offer

Data use requests as odrl:Request

Data use decisions as odrl:Agreement

Source: Pandit and Esteves (2024) Table 1

35 of 59

Proof of concept (Pandit and Esteves, 2024)

Work to be developed at Dagstuhl CDIF workshop, November 2025

Pilot implementation expected in 2026 at UKDS and ODISSEI

36 of 59

Part 4. data access protocols for distributed genomic data

Milan Ojsteršek

University of Maribor, Slovenia

milan.ojstersek@um.si

37 of 59

The main problems in biomedical data interoperability

The primary challenges in biomedical data interoperability stem from the absence of a uniform language and consistent context across the highly fragmented healthcare and research ecosystem. Solving these issues is crucial for enabling large-scale analysis, machine learning, and personalized medicine.

Semantic Interoperability (diverse terminologies and coding, contextual ambiguity).
Structural Interoperability (format heterogeneity, lack of standardisation in APIs, closed data models in vendors‘ applications).
Organizational and Legal Interoperability (privacy and consent, trust and governance models).

The main problems in biomedical data interoperability revolve around the lack of a uniform language and consistent context across the highly fragmented healthcare and research ecosystem. Solving these issues is crucial for enabling large-scale analysis, machine learning, and personalized medicine.�

Semantic Interoperability (The Language Barrier). This is the most significant challenge. It refers to the ability of computer systems to exchange data with unambiguous, shared meaning.

Diverse Terminologies and Coding: Different institutions use different standards, or even local, proprietary codes, to record the same clinical concept. For example, one clinic might use ICD-10 for a diagnosis, while a lab uses LOINC for a test, and a researcher might prefer SNOMED CT. Without a robust mapping layer (like the one provided by OMOP's vocabularies), these concepts are not automatically comparable.
Contextual Ambiguity: Data might be recorded without the necessary context. For example, a blood pressure reading lacks meaning if the record doesn't specify whether the patient was standing, sitting, or post-exercise. The meaning of the data is lost during the transfer.

Structural Interoperability (The Format Barrier) This relates to the technical format and organization of the data being exchanged.
Format Heterogeneity: Data resides in wildly different systems: electronic health records (EHRs), claims databases, imaging systems (DICOM), genomic sequencers, and simple spreadsheets. Each has a unique internal structure, making direct exchange difficult.
Lack of Standardisation in APIs: While standards like HL7 FHIR aim to solve this by providing modern APIs, adoption is not universal. Legacy systems still rely on older, less flexible standards (like HL7 v2), leading to integration challenges.
Data Silos: Data is often locked into proprietary vendor systems, intentionally making it difficult to extract and share. This requires complex custom interfaces for every data exchang

3. Organisational and Legal Interoperability (The Governance Barrier) Even when the technical standards are met, policy and consent issues can block data sharing.

Privacy and Consent: Strict regulations (like GDPR in Europe or HIPAA in the US) govern how patient data can be shared and used. Ensuring that consent forms are properly digitized and honored across different systems is a massive administrative and technical hurdle.
Trust and Governance Models: Organizations are hesitant to share data unless there is a clear legal framework and a trusted governance model that specifies who is responsible for data quality, security, and integrity throughout the entire lifecycle.

Solutions like the OMOP Common Data Model (which provides semantic standardization for research) and HL7 FHIR (which provides a standard structural API for exchange) address these problems, but full interoperability requires widespread adoption across all three layers.

38 of 59

The landscape of metadata standards in clinical and biomedical research is highly diverse, as different standards are optimized for different phases of the data lifecycle (e.g., real-time exchange vs. long-term analysis).

The main metadata and data models used across clinical and research areas are:

1. Interoperability and Exchange Standards

These standards focus on enabling the seamless transfer of data between clinical systems, apps, and registries.

HL7 FHIR (Fast Healthcare Interoperability Resources): The modern, dominant standard for data exchange in real-time. FHIR defines a set of modular "Resources" (e.g., Patient, Observation, MedicationRequest) that serve as metadata containers for both the clinical information and the technical information needed for transfer (e.g., timestamps, status).
DICOM (Digital Imaging and Communications in Medicine): The global standard for handling, storing, printing, and transmitting information in medical imaging. DICOM specifies both the image format and the extensive metadata (patient ID, study date, machine settings) that must accompany it.
CDA (Clinical Document Architecture): A standard from HL7 for the structure of clinical documents (e.g., discharge summaries, progress notes). CDA specifies the metadata for the document itself (type, author, date) and provides a structure for the content.

2. Research and Analytical Standards

These standards focus on transforming complex, real-world data into a uniform structure suitable for large-scale, reproducible research.

OMOP CDM (Common Data Model): This is the leading standard for observational research. OMOP provides a uniform structural standard (a set of tables like PERSON and CONDITION_OCCURRENCE) and, crucially, mandates the use of standardized terminologies (SNOMED CT, RxNorm, etc.) for all clinical concepts. This standardization of both structure and content enables global network studies.
CDISC (Clinical Data Interchange Standards Consortium): A suite of standards used globally for organizing data from controlled clinical trials. Its key models include:
SDTM (Study Data Tabulation Model): Defines the standard structure for submitting study data to regulatory agencies (like the FDA).
ADaM (Analysis Data Model): Defines the structure of datasets used for statistical analysis.

�

3. Terminologies and Content Metadata

These are not data models themselves, but their rules and concepts are embedded as metadata within all the above standards.

SNOMED CT (Systematized Nomenclature of Medicine—Clinical Terms): The world's most comprehensive clinical terminology. It is used to code diagnoses, symptoms, and procedures with high granularity, providing the semantic metadata.
RxNorm: The standardized nomenclature used for coding all medications by active ingredient, strength, and dose form.
LOINC (Logical Observation Identifiers Names and Codes): The standard used for coding laboratory tests and clinical observations, ensuring that a "sodium test" has the same identifier across all systems.

39 of 59

The Global Alliance for Genomics and Health (GA4GH) unites an international community dedicated to advancing human health through genomic data. They build technical standards, and policy frameworks, and tools that will expand responsible, voluntary, and secure use of genomic and other related health data.

GA4GH: International policies and standards for data sharing across genomic research and healthcare

Rehm, Heidi L. et al.

Cell Genomics, Volume 1, Issue 2, 100029, 2021, DOI: 10.1016/j.xgen.2021.100029

40 of 59

BBMRI-ERIC

BBMRI-ERIC is a European research infrastructure for biobanking. It brings together all the main players from the biobanking field – researchers, biobankers, industry, and patients – to boost biomedical research. To that end, they offer quality management services, support with ethical, legal and societal issues, and a number of online tools and software solutions for biobankers and researchers. BBMRI-ERIC currently includes 23 countries and one international organisation, making it one of the largest European research infrastructures.

41 of 59

MIABIS (Minimum Information About BIobank data Sharing)

MIABIS is dedicated to standardising data elements used to describe biobanks, research on samples, and associated data. All BBMRI-ERIC‘s biobanks use MIABIS metadata standard for interoperability inside their federated platform.

BBMRI-ERIC utilises this metadata in the directory (the catalogue of sample collections), the locator (a real-time search on donor and sample levels), and the finder (a data analysis tool focused on clinical, phenotypic, and genomic data).

MIABIS, the Minimum Information About Biobank data Sharing initiative! MIABIS is dedicated to standardising data elements used to describe biobanks, research on samples, and associated data.

The MIABIS Core, crucial for initiating collaboration and enabling sample and data exchange, comprises four main entities: Biobank, Collection, Research Resource, and Network. MIABIS Core 3.0 (Eklund et al., 2024) further refines these attributes, providing a modular structure for easy adherence and extension.

Two additional aggregate level components have been prepared for Imaging (DICOM-MIABIS) and for Standard Operating Prodecures (SOPs). Ongoing developments include additional components describing dataset types and biobank capabilities, contributing to the continuous evolution of the MIABIS data standard.

Data describing Dataset Types - under active development -a basic model for any dataset, and entities tailored for Omics and Imaging data found in biobanks. Omics and Imaging are chosen as proof-of-concept components due to their significance in biobank data provision. The Omics entity includes features for describing genomics, metabolomics, proteomics, and transcriptomics data, while the Imaging entity encompasses various imaging data types such as radiological, macro-imaging (body/organ), micro-imaging (tissue), and process-imaging (e.g., ECG, EEG).
Data describing Biobank Services - under active development

In response to the need for more detailed information, MIABIS has extended its terminology to include individual- evel components, describing samples, sample donors, and events. These entities enhance the ability to perform sophisticated queries. Ongoing developments include an additional component describing molecular pathology.

Data describing Sample, Sample Donor, and Event v1.0 (Eklund et al., 2020):

42 of 59

European Health Data Space

The European Health Data Space is a health specific ecosystem comprised of rules, common standards and practices, infrastructures and a governance framework.

Regulation (EU) 2025/327 of the European Parliament and of the Council of 11 February 2025 on the European Health Data Space and amending Directive 2011/24/EU and Regulation (EU) 2024/2847

The European Health Data Space is a health specific ecosystem comprised of rules, common standards and practices, infrastructures and a governance framework that aims at:

Empowering individuals through increased digital access to and control of their electronic personal health data, at the national level and EU-wide.
Fostering a single market for electronic health record systems, relevant medical devices and high-risk AI systems.
Providing a trustworthy and efficient set-up for the use of health data for research, innovation, policy-making and regulatory activities (secondary use of data).

Regulation (EU) 2025/327 was adopted on 11 February 2025, and published in the Official Journal on 5 March 2025

The aim of this Regulation is to establish the European Health Data Space (EHDS) in order to improve natural persons’ access to and control over their personal electronic health data in the context of healthcare, as well as to better achieve other purposes involving the use of electronic health data in the healthcare and care sectors that would benefit society, such as research, innovation, policymaking, health threats preparedness and response, including preventing and addressing future pandemics, patient safety, personalised medicine, official statistics or regulatory activities.
In addition, this Regulation’s goal is to improve the functioning of the internal market by laying down a uniform legal and technical framework in particular for the development, marketing and use of electronic health record systems (‘EHR systems’) in conformity with Union values. The EHDS will be a key element in the creation of a strong and resilient European Health Union.

43 of 59

HEALTHDCAT-AP

The HealthDCAT Application Profile (HealthDCAT-AP) is a domain-specific metadata model designed to support the implementation of the secondary use framework under the European Health Data Space (EHDS).

HealthDCAT-AP introduces new properties that enable semantically consistent dataset descriptions, structured for automated exchange and federation across catalogues. This ensures that metadata can be processed and integrated into local, regional, national and EU-level catalogues, including the one operated by the central platform of the HealthData@EU infrastructure.

A distinctive feature of HealthDCAT-AP is its explicit classification of dataset access rights into three categories: non-public, restricted, and public. Each category is defined with specific technical requirements.

In addition, new controlled vocabularies have been developed to harmonise property values, thereby ensuring comparability and interoperability of dataset descriptions across Member States.

44 of 59

1+MG Schema

The 1+ Million Genomes (1+MG) initiative aims to enable secure access to genomics and the corresponding clinical data across Europe for better research, personalised healthcare and health policy making. Since the Digital Day 2018, 25 EU countries plus the United Kingdom and Norway signed the Member States’ Declaration ‘Towards access to at least 1 million sequenced genomes in the EU by 2022. This plan consists of stepping up efforts towards creating a European data infrastructure for genomic data and implementing common national rules enabling federated data access. The initiative forms part of the EU’s agenda for the Digital Transformation of Health and Care and is aligned with the goals of the European Health Data Space (EHDS). The updated 1+MG Roadmap, published in Q3, 2023, sets out the priorities for the period 2023-2027.

The Genomic Data Infrastructure (GDI) project (2022-26), is enabling access to genomic and related phenotypic and clinical data across Europe. It is deploying a federated, sustainable and secure infrastructure to access the data, based on the guidelines and recommendations in the 1+MG Framework. GDI builds on the outputs of the B1MG, B1MGplus and the Genome of Europe projects to realise the ambition of the 1+Million Genomes (1+MG) initiative.

The Genome of Europe (GoE) project (2024-28) is building a collective reference genome cohort of European citizens, selected to mirror the genetic composition of the European population. This will generate a solid basis for the development of personalised medicine and health approaches in Europe.

The Beyond 1 Million Genomes (B1MG) project (2020-2023), provided coordination and support to the 1+ Million Genomes Initiative (1+MG). Working closely with stakeholders, it defined the legal, organisational and technical requirements for cross-border access to genomics and personalised medicine data, and translated these into practical technical specifications and implementation guidelines. The Beyond 1 Million Genomes plus (B1MGplus) project (2025-28), a follow-up to the B1MG project, is facilitating the adoption of shared standards and best practices, encouraging stakeholder engagement and ensuring alignment with the objectives of the European Health Data Space. The project is providing support to help countries move from pilot phase to operational services that are embedded in national healthcare and research systems.

1+MG framework contains the set of agreed outputs and guidance on:

Legal, ethics and governance

Governance documentation including consent models, privacy safeguards and legal frameworks

Technical infrastructure

Information on the standards, APIs and reference implementations to build a 1+MG Node

Data and metadata

Resources on data models, minimal metadata, quality and inclusion standards

Healthcare integration and sustainability

Guidance for preparing health systems to adopt genomics, including a maturity model and long-term sustainability planning

Use cases

The use cases and analysis driving the development of the 1+MG infrastructure

45 of 59

European Genomic Data Infrastructure

46 of 59

1+MG data models, standards and ontologies

48 of 59

GDI Infrastructure

Centralised Discovery and Access Management

User Portal (DCAT - AP)
Passport and AAI
REMS

European level interconnectivity

Beacon Network (Beacon v2.2 data model and API)
Passport and AAI
REMS

National node level

Secure storage, secure computing and analysis, federated execution, federated learning. Common framework of standards and APIs.
Manage your own data and metadata.

Institutional level

Secure storage, execution of institutional processes, secure computing and analysis,

49 of 59

Partial decentralised data access

GDI project receives funding from the European Union’s Digital Europe Programme under grant agreement number 101081813.

50 of 59

Slovenian GDI architecture diagram

51 of 59

DISCUSSION: conventions for modular metadata

Options:

dcTerms:conformsTo
http headers
Profiles Vocabulary https://www.w3.org/TR/dx-prof/
SHACL, JSON-schema, html....
Mapping classes and class values between different ontologies metadata schemas, data models and vocabularies in biomedical research
Is it possible to achieve complete machine actionability for genomic and biobank data? What would need to be done to enable these processes to be carried out without human intervention?

52 of 59

Links

See Poster P45 'Implementation of metadata components for Cross Domain Interoperability (CDIF)'

CDIF GitHUB https://github.com/Cross-Domain-Interoperability-Framework

RDA Metadata Interest group:

RDA Metadata Principles and Their Use

session notes: https://docs.google.com/document/d/1v1yZM6Lj3spxpJIkRkhR9URUGbfcQ19b

54 of 59

Addendum on Data Integration and DDI-CDI

55 of 59

Towards practical interoperability for data integration

Data Integration: ability to combine, link, relate and different in various ways for data production, analysis, understanding complex phenomena, etc.
Large number of use cases in multiple domains (and across domains)

UN Statistical Division SDGs SDMX data -> Google Data Commons via DDI-CDI
NADA data catalogs (IHSN) with 1000’s of studies in DDI-Codebook -> SDMX via DDI-CDI
A growing number of WorldFAIR+ and CDIF projects

56 of 59

Mapping approach

DDI-CDI comes in handy as a Rosetta stone for mappings and integration

Focuses on multidisciplinary (and interoperable) data sharing and integration
Provides multiple syntax representations for machine-actionability
Complements (and integrates with) other DDI products

Prerequisites for effective data integration

Include reference and structural metadata to describe data well enough to make it integration-ready (including structure, semantics and codesets)

Define mappings between concepts, variables and codesets as necessary (expressed in SKOS/SSSOM)
Harmonize concepts/variables/formats (whenever possible) or document the caveats (if not 100% possible)

Preserve process metadata for provenance (description of operations performed on the data)

57 of 59

Interoperability between SDMX and DDI

Benefits

International standard suites with large adoption base
Include DDI Codebook, DDI Lifecycle, DDI CDI, SDMX 2.1 and 3.x, XKOS, VTL and others.
Open and collaborative development
Growing ecosystem of tools and libraries readily available (key for efficient development)
Support for structural and semantic harmonization and alignment

Issues

Developed independently by difference communities with little intentional alignment
Impedance mismatch: varying emphasis on semantics, structures and granularity
Different strengths (and weaknesses)

Results

Developed guidelines on how to make both standards interoperate with each other and with VTL to enable data production pipelines for statistical production
Developed foundation for further work to include SDTL, XKOS, and other open implementation standards

58 of 59

Mappings need to be “contextual”

•Mappings are many-to-one and many-to-many

•The usage of a class depends on the related classes (context)

•The same class can be mapped differently in different contexts (and for different use cases)

59 of 59

Expected outcomes

• No prescriptive framework given the potential number of scenarios: we cannot know how exactly a user will work with the data for integration purposes

• Data description elements (from DDI and SDMX) required to make the data integration-ready

• Machine-actionable mappings based on standards (SKOS/SSSOM, others)

• Clarification of potentially confusing terminology

• DDI and SDMX tend to use similar terms for notions that are not exactly the same, e.g. Concepts, Categories, Codes, Components, etc. whereas some other notions are explicitly defined in one standards but not in the other, e.g. Variable.

• Recommendations on how to define the integration process based on mappings and data structures

• Identification of potential interoperability with other standards (DCAT, schema.org, etc.)