Joint Workshop on

FAIR Digital Objects and the Cross-Domain Interoperability Framework (CDIF)

Time: 26.11.2024 from 15.00–16.30 CET (14:00–15:30 UTC)

Location: https://us02web.zoom.us/meeting/register/tZAsc-2sqDkuEtHV1oQPBfLGL7sS8ci0UzBd#/registration

Agenda

15.00	Sven Bingert	Welcome and FDOs
15.10	Simon Hudson	CDIF Introduction	A brief description of WorldFAIR and WorldFAIR+, and the process for developing and extending the CDIF recommendations.
15.20	Arofan Gregory	CDIF Overview	A description of the existing and planned features of CDIF, identifying the functions, standards, and technologies which are being recommended, and being considered for future recommendation.
15.40	Arofan Gregory	CDIF and FDOs	A consideration of how FDOs will be employed in future iterations of the CDIF guidelines, and the approaches likely to be used. The emphasis here is on the practical requirements for packaging within FAIR exchange.
16.00	Stian Soilant-Reyes/ Peter Wittenburg	Will it fit together?	Comments from the point of view of FDOF
16.10	Simon Hodson	Q&A	An open discussion of developments in the FDO space and how they can be best used to meet the requirements of CDIF moving forward.
16.30	end

 

Background

CDIF

The Cross-Domain Interoperability Framework (CDIF) is a set of guidelines for using existing domain-neutral standards and technologies for the exchange of FAIR data and related resources. CDIF, currently in its first version, was a product of the EC-funded WorldFAIR project which looked at FAIR implementations across 11 domains.

WorldFAIR+ activities are continuing through a set of aligned projects, and further work to implement, refine and extend CDIF is underway. The focus is on establishing a core set of metadata fields, implemented in a common, predictable fashion, to enable the exchange of data and metadata across domain and infrastructure boundaries. It relies on common web architectures/technologies, and recommends the use of web standards (such as Schema.org, DCAT, SKOS, etc.) in a coordinated fashion, expressed as JSON-LD. The goal is to establish a practical approach to FAIR implementation which is feasible today, using common technologies, standards, and approaches.

A set of common functions required for FAIR implementation has been identified, including discovery and cataloguing, provision of integration-ready data described at a granular level, automated negotiation of access, and the dissemination of controlled vocabularies. This set of functions will be expanded in the next CDIF iteration to cover provenance and context around data resources, support for common binary formats, and preparing data for use in LLM training sets. The work will also extend to semantic mapping and the role of disseminating repositories.

FAIR Digital Objects (FDOs) are a necessary part of FAIR exchange, reflecting the packaging needed for dissemination and archiving functions. The approach to FDOs within CDIF will emphasize the “webby” implementation of FDOs. While no final decisions have yet been made, the use of RO Crate is one option which has been identified. Further, Signposting is already one of the recommended implementation options for navigation of FAIR resources. The employment of “webby” FDOs is driven by the need for a solution based on common existing architectures and implementations, without dictating to users the granularity of what is exchanged.

CDIF is not a standard or technology platform itself: it recommends the use of other standards and technologies. It is a practical exercise, with the expectation that the CDIF recommendations will be adjusted as practice evolves and new options gain traction in the marketplace.

References:

What is the Cross Domain Interoperability Framework (CDIF)?

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.

FAIR Digital Objects

The FDOs are simple units of information: A PID points to a persistent structure that contains a set of attribute value pairs. When a client submits such a PID to a resolver, the attribute-value pairs are returned. These attribute-value pairs should include all relevant properties of a Digital Object stored in some repositories. Of course, the attribute set should include references to the various copies of the bit-sequence encoding some content, to all kinds of metadata including rights and if necessary, even to smart contracts, and should include a set of properties of the bit-sequence such as its Type, its Checksum, its Size, etc. To make this unit of information FAIR the FDO specifications request the following for machine actionability: (1) The set of attributes being included in the structure needs to be defined by an FDO Profile. (2) All attributes being used need to be defined and registered in recognized open registries.

There are two mandatory attributes to be included: (1) the reference to the FDO Profile and (2) the Type of the FDO. In the case of Data FDOs[1] there must be references to the data and metadata. All other attributes are optional, and it is known that repositories would like to add various properties to facilitate their work. Optional attribute names and definitions must be defined and registered in open registries. The Type information allows owners to establish relationships with operations which would be the opening to enhanced machine actionability and a way to encapsulation which is a powerful concept known from object-oriented programming.

Using these specifications, we can state that FDOs (1) are simple, machine actionable and generic units of information based on an established core data model,(2) can be connected via adaptors to all well-organized repositories to let their internally managed bit-sequences appear as FDOs to the outside world, (3) are independent of any technology and specific data organization and modelling as may be used by the connected repositories, (4) are creating a unified integrated domain which does not require central institutions and therefore is not restricted by any border, (5) are an excellent step to agree on a unified interface protocol.

References:

FDO Overview: https://zenodo.org/records/7824714

FDO Requirement Specifications: https://zenodo.org/records/7782262

Data FDOs: https://drive.google.com/file/d/1ySd4HB89nXYopUe0HK0bzCdbf8Zx5_Jl/view?usp=sharing

[1] There are different configuration types of FDOs. Some indeed contain data, others may, for example, simply contain references to other FDOs that then refer to data.