Property doi is not identified as a basic field.

[samcunliffe]

(I'm really sorry if I'm duplicating an issue: I can't find one.)

The DOI in the example CITATION.cff given on citation-file-format.github.io doesn't get parsed as I expect. It is...

cff-version: 1.2.0
message: "If you use this software, please cite it as below."
authors:
  - family-names: Druskat
    given-names: Stephan
    orcid: https://orcid.org/1234-5678-9101-1121
title: "My Research Software"
version: 2.0.4
doi: 10.5281/zenodo.1234
date-released: 2021-08-11

And I get ...

Property 'doi' was not identified as a basic field, so it was passed as an extra cff field.

---

If I create a CITATION file using the tool GUI, I get something like:

identifiers:
  - type: doi
    value: 10.5281/zenodo.1234

Should doi: be supported?

Debug info

• cff-version: 1.2.0
• App version: 2.2.0
• Using the gh pages site (just in case you're hosted elsewhere).

[abelsiqueira]

Hi @samcunliffe, thanks for reporting your experience with the app.

The doi field is a valid CFF field. Notice that, even though it was passed as an extra CFF field, it should not raise any errors. In other words, we validate the doi field as part of the whole CFF file, but we do not have a dedicated field for it.

We don't have plans to explicitly add a field in the web app for it because the identifiers field gives the same functionality and allows description (https://github.com/citation-file-format/citation-file-format/blob/main/schema-guide.md#doi), and since we parse and validate the doi as an extra CFF field, it doesn't break existing CITATION.CFF files.

Thanks for taking the time to write the issue. Let me know if there is anything else that needs clarifying.

[samcunliffe]

Hello @abelsiqueira,

Thanks for the explanation. I'm not sure I follow (to be clear: my understanding doesn't particularly matter if you're sure the tool is correct).

The spec says that doi: can be used as a shorthand for the identifiers: type: doi. So, I guess I'm expecting the initializer tool to either parse it into one of the identifiers. Or I would expect the example given on the website not to use the shorthand format which causes a warning.

[abelsiqueira]

Hi @samcunliffe, no problem, I can try to explain more.

Sorry for the wall of text below.

One thing to make clear here is that the CFF schema (and its website) are separate from this tool (cffinit), although some people work on both projects.

Our objective is to facilitate the creation of a CITATION.cff with some of what we think are the most important fields, instead of focusing on being a comprehensive tool. A secondary objective is supporting the editing of existing CITATION.cff files. This support should use the CFF schema as a whole for validation to allow the extra fields, so we don't break the user's submitted code but still make sure that it is parsed correctly. This literally came later, since the main goal was to focus on increasing software citation (increase FAIRness of software in general).

So, for future reference, why don't we have a field for doi? It would have similar functionality to identifiers, which would lead to confusion on which one is the right one, which would be bad for the primary objective. It is supported, indirectly, through extra CFF fields, so you can check that the CITATION.cff on the website is correct, so it satisfies the second objective.

In that sense, the tool is correct. It is not expected to parse the doi into identifiers: type: doi, but it is expected to keep the field and correctly verify the final CITATION.cff file under the schema specification.

Regardless of correctness, you gave two suggestions, which we can discuss further:

1. Parse doi into identifiers: type: doi.

The main reason not to implement this is that some users might prefer to have a single doi - or a main doi and other identifiers. I, personally, think that a better practice would be to move to identifiers, but since it could lead to potentially unwanted unnecessary modifications, it could make people angry. Furthermore, changing from doi to identifiers is sufficiently easy, to the benefit/cost ratio is unfavourable.

2. Change the example.

That could be an issue on https://github.com/citation-file-format/citation-file-format/issues.
By the way, I agree, I would prefer if the example did not raise any warning for cffinit.
So if you create the issue, feel free to post a link to this discussion.

Hope this helps.