Support some datacite.yml in addition/instead of CITATION.cff

[yarikoptic]

Your idea

ATM there is an idea to relay more of information for citations to CITATION.cff and not strive to make dataset_description.json to contain all needed information (e.g. affiliations of the authors etc).

BUT, as far as I see, CITATION.cff development stalled, while it is still lacking some rudimentary needed features such as supporting multiple affiliations for authors (citation-file-format/citation-file-format#268) and unclear how to reference funders (citation-file-format/citation-file-format#491).

While that is happening, there is https://schema.datacite.org/ with a working group, continuous progress, and used widely by anyone minting DOIs via datacite (e.g. we do for DANDI and IIRC OpenNeuro also uses datacite).

A well aged example of a datacite record from @mih for a BIDS dataset could be found at
https://github.com/psychoinformatics-de/studyforrest-data-phase2/blob/master/datacite.yml . It lacks affiliations but otherwise a good example .

Ideally there should be a tool to convert from datacite to citation.cff format, but ATM I didn't google up any. may be someone could add some support into https://github.com/con/tributors or alike.

[Remi-Gau]

FYI bids2cite was my attempt to help 'converting' info from dataset_description to citation.cff OR datacite.yml...

https://bids2cite.readthedocs.io/en/latest/usage_notes.html#command-line-arguments

[effigies]

It's not ideal to have three ways of doing things, but I agree that CITATION.cff seems to be stagnating and BIDS is constrained by backwards compatibility to support CITATION.cff.

IMO if datacite.yml has the features needed and now, it's worth supporting, and I would be inclined to adopt it for OpenNeuro-generated metadata instead of CITATION.cff, which is still on our roadmap.

cc @nellh for your thoughts.

[effigies]

Update: OpenNeuro would prefer to work with datacite.yml than CITATION.cff at this point, but we would also prefer to support BIDS-only datasets.

Will bring up with maintainers this week and possibly try to add to steering agenda for next week.

[effigies]

A result of today's maintainer's call was general agreement that supporting multiple citation file formats is reasonable to improve the FAIR-sharing of BIDS datasets that are deposited in public databases. We would prefer that the different formats be mutually exclusive within a dataset, as duplicated metadata would need to be validated or risk becoming contradictory.

[monique2208]

We recently participated in FAIR impact support action where we worked on better exposing dataset metadata in the context of FAIR. Some things might be relevant to this issue.

We currently support the use of the CITATION.cff for the BIDS datasets in our repository. Similarly, we have encountered issues regarding not everything of interest being represented in this format. However, outside of citation-cff, datacite, and even the BIDS dataset description, there are many other ways that this information can be reflected. It is also possible to store it in json-ld format using something like dcat, or schema.org, and this information is also part of RO-crates.

All these efforts have slightly different scopes and most of them have ongoing development. I am not sure if there is one that currently supports all needs for BIDS, or all the needs of a data catalog or repository. For example, we also use datacite to get DOIs, and on our dataset webpages we provide metadata in schema.org and dcat vocabularies. From the perspective of FAIR, the solution here is crosswalks, and this is also partially what we implement in our repository. We convert between citation.cff and datacite, citation.cff and schema.org and dcat, to enable different parts of our repository. Information that is not in citation-cff we pull from somewhere else, but this is possible because we know where it resides. Allowing additional formats in BIDS, means the location of this information will be more flexible and we will have to implement additional crosswalks to deal with these formats.

[yarikoptic]

FWIW, if taking "contributors" aspect in mind, similar idea we implemented in https://github.com/con/tributors to try to sync various locations where contributors could be discovered (e.g. allcontributors.json; git history, as we do in https://github.com/datalad/datalad/blob/maint/.github/workflows/update-contributors.yml, etc ) and then sync them. I also did some conversions for recent JOSS publication between joss header and zenodo.json and citation.cff to only discover that at that point multiple affiliations where not supported at all... uff

What is your solution for crosswalks -- may be it could/should be generalized?

[monique2208]

We currently just code it. We have some python objects that represent BIDS entities, and then we can write them in different formats. I think it could be interesting to see this in something like pyBIDS.

I think just describing them would be a great place to start. For example, like codemeta It would be great to have something like this for BIDS as well.

FAIR-impact has worked on more generic tools, but also just for defining the crosswalks as far as I know. And it a work in progress, and they depend on the vocabularies that are used in the crosswalk to be fully formalized and have persistent identifiers to each term, this is not the case for the BIDS dataset description terms, and the citation.cff terms.

I am not sure what the best solution is right now, as like i said, we ran into the same issues with citation.cff