FDO Compliance Profiles

As indicated, the term FDO should only be used by those who are compliant with the specifications, since this is the only way to guarantee interoperability amongst the increasing number of implementations and applications. We therefore kindly ask all projects claiming to have implemented FDOs to fill in the simple Compliance Profile template. Each submitted form will be evaluated by a team of experts from the FDOF and GOFAIR and a short note about their evaluation result will be added.

Here we are listing the copies of the forms that have been filled in by the corresponding developers.

The University of Manchester – WorkflowHub

Name	Stian Soiland-Reyes
Affiliation	The University of Manchester

Application/project	WorkflowHub
Documentation References	https://about.workflowhub.eu/
Bundled Information	Workflows, license, attributions, software citations, workflow runs
Configuration types	Configuration Type 10 with Signposting
PID system	Yes
Which PID system	DOIs via Datacite e.g. https://doi.org/10.48546/workflowhub.workflow.29.3 with fallback URL identifiers for entries with incomplete kernel metadata
Resolved structure	A DOI like https://doi.org/10.48546/workflowhub.workflow.29.3 resolves to HTML landing page https://workflowhub.eu/workflows/29?version=3 with FAIR Signposting and content negotiation, leading to RO-Crate https://workflowhub.eu/workflows/29/ro_crate?version=3, JSON-LD https://workflowhub.eu/workflows/29.jsonld and DataCite XML.
Profiles	Workflow RO-Crate profile https://w3id.org/workflowhub/workflow-ro-crate/ with example https://about.workflowhub.eu/Workflow-RO-Crate/example/ (JSON-LD and HTML)
Mandatory kernel attributes	Kernel attributes according to DataCite Metadata Schema https://schema.datacite.org/meta/kernel-4.6/ and RO-Crate requirements https://www.researchobject.org/ro-crate/quick-reference
Bit-sequences	Each WorkflowHub entry links to an RO-Crate ZIP as bit-sequence using Signposting, as well as signposting to metadata as JSON-LD. The linked RO-Crate bit-sequenced contains the identifier of the WorkflowHub landing page, which has Signposting back to the DOI. Not all entries are assigned PIDs (requested by users when metadata is complete), but all bit-sequences have the identifier. See project deliverable https://doi.org/10.5281/zenodo.15094824 for details on FDO implementation in WorkflowHub using Signposting.
Other kernel attributes	BioSchemas ComputationalWorkflow https://bioschemas.org/profiles/ComputationalWorkflow/1.0-RELEASE annotations on the landing page e.g. https://workflowhub.eu/workflows/29 to describe the workflow. DataCite metadata is propagated to OpenAIRE e.g. https://explore.openaire.eu/search/software?pid=10.48546%2Fworkflowhub.workflow.29.3 Collections e.g. https://workflowhub.eu/collections/33 are also exposed as JSON-LD markup using schema.org, planned to be assigned DOI as a Datacite Collection type.

Naturalis Biodiversity Center – DiSSCo Digital Specimen Architecture

Name	Wouter Addink
Affiliation	Naturalis Biodiversity Center

Application/project	DiSSCo Digital Specimen Architecture
Documentation References	https://github.com/DiSSCo/dissco-developers-documentation/wiki
Bundled Information	data and metadata
Configuration types	type 6, although we do not (currently) define operations. The FDO profile only describes the structure of the digital object that the pid record redirects to.
PID system	Yes
Which PID system	Handles and DOIs (which are also Handles)
Resolved structure	PID record (Handle record), that has multiple redirects, e.g. to a HTML landing page and to a JSON representation, sometimes also to other HTML pages or a bit sequence of a media object (depending on the DO type)
Profiles	yes, these are stored in DTR Test provided by ePIC, for example https://dtr-test.pidconsortium.net/#objects/21.T11148/d8de0819e144e4096645 and https://dtr-test.pidconsortium.net/#objects/21.T11148/306452d0867adb910803 which link to a further description (json schema) in https://schemas.dissco.tech/schemas/ objects are created, documented and validated based on these schemas so they are always compliant. In the near future we aim to migrate either to EOSC DTR (https://typeregistry.pidconsortium.net) or stop using a DTR and only rely on our schema repository (DTR does not seem to get momentum and there is no progress in migrating our current profiles). Our schema repository fits our needs and a DTR is only beneficial with an active community managing and aligning the definitions.
Mandatory kernel attributes	Yes. These are specified in https://dtr-test.pidconsortium.net/#objects/21.T11148/d8de0819e144e4096645 and in https://schemas.dissco.tech/schemas/fdo-profile/handle-kernel/1.0.0/handle-kernel.json
Bit-sequences	yes, through 10320/loc. See for an example https://doi.org/10.3535/492-QSL-9GZ?noredirect
Other kernel attributes	These depend on the DO Type and are also defined in https://dtr-test.pidconsortium.net/ and in https://schemas.dissco.tech/schemas/

Karlsruhe Institute of Technology – Helmholtz Metadata Collaboration Platform

Name	Andreas Pfeil
Affiliation	Karlsruhe Institute of Technology

Application/project	Helmholtz Metadata Collaboration Platform (HMC)
Documentation References	https://doi.org/10.3289/HMC_publ_03
Bundled Information	Profile reference, data and metadata locations, descriptive and rights metadata, refences to related FAIR DOs, depending on use-case more or less extensive scientific descriptive metadata
Configuration types	Type 3, with the difference that the backlink to PID1 is in the kernel information record of PID2, and may not be in the metadata itself (as its schema is usually fixed and doesn’t support it).
PID system	Yes
Which PID system	Handle System
Resolved structure	Handle record. For human interaction, we also allow setting the URL field value of the handle system to any information which is also within a typed attribute (e.g. a digitalObjectLocation or a landing page). This avoids untyped additional information, while still supporting human interactions with PIDs as known from DOIs. Machines will just read the record.
Profiles	Yes. Implementation is here: https://dtr-test.pidconsortium.net/#objects/21.T11148/b9b76f887845e32d29f7. The profile schema of dtr-test is here: https://dtr-test.pidconsortium.net/#objects/21.T11148/532ce6796e2828dd2be6 We use the Typed PID Maker for validation and prefix access (create, update, resolve, implicit validation, explicit validation). The Typed PID Maker takes one of currently two supported JSON representations of a PID record as input. Attribute validation is currently being done with either the type-api (https://typeapi.lab.pidconsortium.net/) or legacy schemas in dtr-test (one of them has to work out for the validation to succeed). Profile validation (obligation, cardinality, etc) is implemented locally on an internal representation.
Mandatory kernel attributes	Yes. Our current version is fully defined in dtr-test (https://dtr-test.pidconsortium.net/#objects/21.T11148/b9b76f887845e32d29f7). It uses the Kernel Information Profile attribute (https://dtr-test.pidconsortium.net/#objects/21.T11148/076759916209e5d62bd5) and the digitalObjectType (https://dtr-test.pidconsortium.net/#objects/21.T11148/1c699a5d1b4ad3ba4956). We currently use custom types in the DTR as values for the DOtype and await further experiences from applications or even some consensus on how to improve on them.
Bit-sequences	Yes (configuration type 3). There is the digitalObjectLocation and the relation fields, one of them is „hasMetadata“, pointing to the PID of the metadata. Both attributes are repeatable.
Other kernel attributes	They are defined and registered the same as all other attributes (see other questions). The full list can be found in the profile: https://dtr-test.pidconsortium.net/#objects/21.T11148/b9b76f887845e32d29f7

ZB MED SemTec

Name	Leyla Jael Castro
Affiliation	ZB MED

Application/project	SemTec Team pages (available). MLentory (not released yet but same approach described here)).
Documentation References	No documentation available only the actual pages at https://zbmed-semtec.github.io/ Right now only projects and theses implement Signposting and RO-crate
Bundled Information	Descriptive metadata, rights metadata, optional data and software (via links, not the bit-sequence yet)
Configuration types	Configuration type 9 and 10. We use W3id as PID but there is no PID record in that case. The bit-sequence is pointed to via a detached RO-Crate record.
PID system	Yes
Which PID system	W3ID.org (httaccess redirection, kind of handle)
Resolved structure	HTML landing page.
Profiles	We use RO-crate and some Bioschemas profiles. Profiles are accessible on the project pages (https://www.researchobject.org/ro-crate/specification and https://bioschemas.org/profiles). Both rely on schema.org. Example RO-crate profile: https://www.researchobject.org/ro-crate/specification/1.1/root-data-entity#direct-properties-of-the-root-data-entity Example of Bioschemas profile: https://bioschemas.org/profiles/ComputationalTool
Mandatory kernel attributes	We use Signposting for the type and the RO-crate profile. Example at https://zbmed-semtec.github.io/theses/2023_Protein_function_embeddings/
Bit-sequences	The metadata is exposed with JSON-LD, not a a binary file. The metadata includes links to the downloadable files, we do not include yet the actual binary files. We plan to do it in the following way: the Signposting in the landing page will point to an RO-crate package that will include the binary files that will be referenced in the metadata about the RO-crate itself.
Other kernel attributes	Creation and latest modification dates, and the version are commonly included, using schema.org attributes in either the RO-crate package or the metadata describing the actual research artifact.

GWDG FDO One

Name	Jana Böhm
Affiliation	GWDG

Application/project	FDO One
Documentation References	https://gitlab.com/fairdo, https://fdo-one.org/
Bundled Information	FDOs data/metadata resources: data, descriptive metadata. Other FDOs: operation-FDOs, service-FDOs, attribute-FDOs, profile-FDOs. Planned/still under discussion: FDOs for the FDO type, FDO genre, rights specifications
Configuration types	configuration type 4 (Actually, our configuration type also allows entering multiple data and metadata bit-sequences. However, each bit-sequence is identified by an own PID same as in configuration type 4.)
PID system	Yes
Which PID system	Handle
Resolved structure	Handle record
Profiles	Yes, we use the DTR to store FDO profiles in JSON format and use the TypeAPI (https://typeapi.lab.pidconsortium.net/) to retrieve the schemas. Profiles are stored at https://typeregistry.lab.pidconsortium.net/#objects/?query=type:“Profile“ (profile registry). However, this registry also stores other profiles not used in the FDO context. We are currently building up a registry solely for FDO profiles at typeregistry.testbed.pid.gwdg.de (also, other registries such as for attributes, FDO types, FDO genres, FDO operations will be built here).
Mandatory kernel attributes	Yes, the profile includes two fields called “FDO_Type_Ref” (https://typeregistry.lab.pidconsortium.net/#objects/21.T11969/2bb5fec05c00bb89793e )and “FDO_Profile_Ref” (https://typeregistry.lab.pidconsortium.net/#objects/21.T11969/bcc54a2a9ab5bf2a8f2c). Those attributes are instanciated by PIDs referencing an FDO type respectively FDO profile. However, currently, it is still under discussion how the FDO type actually looks like. Probably it would be helpful to discuss in the context of the FDO forum what the FDO type actually is meant to be.
Bit-sequences	Yes, the resolved PID structure has the fields “FDO_Data_Refs” and “FDO_MD_Refs” which contain arrays of PIDs which identify data respectively metadata bit-sequences.
Other kernel attributes	The profile (https://typeregistry.lab.pidconsortium.net/#objects/21.T11969/141bf451b18a79d0fe66) contains the following kernel attributes: FDO_Type_Ref: PID referencing a FDO type FDO_Profile_Ref: PID referencing a FDO profile FDO_Data_Refs: Array of PIDs where each references a data bit-sequence FDO_MD_Refs: Array of PIDs where each references a metadata bit-sequence FDO_Genre_Ref: PID referencing a FDO genre FDO_Rights_Ref: reference to a rights specification FDO_Status: status of the FDO, string: created, deleted, embargoed, moved, … They are registered in the DTR (see question 10).

Please, take a few minutes to describe the FDO compliance with the help of answering the questions below:

1. What is your name?

2. What is your affiliation?

3. What is your email address

4. What is the name of your application or project?
(give a short name as reference)

5. Please, include references to the main project documentation?

6. Which information is bundled by your FDO?
(data, software, descriptive metadata, rights metadata, configurations, etc.)

7. Which FDO configuration type(s) are you using?
(for questions about configuration types look here, if you use a different one as mentioned in the document, briefly describe the type)

8. Do you use a PID system to identify your FDOs?
(Handles, DOIs, URL/URIs, etc.)
NoYes
And if so, which?

9. To what kind of structure is the PID resolved?
(HTML landing page, PID record, etc.?)

10. Do you use FDO profiles to describe the resulting structure?
If so, where are they stored and according to which schema are they defined? Where can one find an example?

11. Do you include the mandatory kernel attributes in the resulting structure which the PID resolves to (FDO profile reference and type)?
How and where are they specified?

12. If the FDO includes data and/or metadata bit-sequences, does the structure which the PID resolves to include references to them?
(could be several different data and/or metadata bit-sequences)

13. Which other kernel attributes do you include in the structure which the PID resolves to?
Where are they defined and registered?

14. Do you want to upload a short explanatory document?

Bitte lasse dieses Feld leer.

Please, check your answers and when ready, please, press submit. Your submission will get an ID. Please save the ID such that you will be able to later update your information by a new answer version, if required. You can also find the ID in the list on the website.

Please prove you are human by selecting the heart .