Inconsistency between how cffconvert renders url and the GitHub widget

[alexlancaster]

If we use the CITATION.cff: https://github.com/citation-file-format/cffconvert/blob/main/tests/lib/cff_1_3_0/urls/IRACU/CITATION.cff

authors: 
  - name: "Test author"
cff-version: "1.3.0"
identifiers:
  - description: "The URL"
    type: url
    value: "https://github.com/the-url-from-identifiers"
message: "Test message"
repository: "https://github.com/the-url-from-repository"
repository-artifact: "https://github.com/the-url-from-repository-artifact"
repository-code: "https://github.com/the-url-from-repository-code"
title: "Test title"
url: "https://github.com/the-url-from-url"

The expected output from cffconvert prioritizes the url in identifiers, e.g. the apalike test output (https://github.com/citation-file-format/cffconvert/blob/main/tests/lib/cff_1_3_0/urls/IRACU/apalike.txt) is:

Test author Test title URL: https://github.com/the-url-from-identifiers

However if I put that same .cff file on a repo, e.g.: https://github.com/alexlancaster/cffconvert_test_cffs

and click the "Cite this repository" the output is:

Test author. Test title [Computer software]. https://github.com/the-url-from-repository-code

This seems inconsistent to me. I'm aware that the GitHub widget uses the ruby backend, but I would expect that used in the default way that they would be the same, and has implications for what end-users should use for the default url, because cffconvert is often used internally to generate citations that would be different from GitHub.

My sense about what should be prioritized is actually the basic url field, because it's a "top-level" field, and I had assumed that would take precedence since you can have multiple url in identifers that have different relations to the the thing being documented.

E.g. I use it in my own repo: https://github.com/alexlancaster/pypop/blob/citation-cff-zenodo/CITATION.cff to note identifiers like GitHub tags and PyPI repo:

- description: GitHub tag for repository
    type: url
    value: https://github.com/alexlancaster/pypop/tree/v0.9.167
    relation: IsSupplementTo
  - description: PyPI package
    type: url
    value: https://pypi.org/project/pypop-genomics/0.9.167
    relation: IsSourceOf

and I also use cffconvert to convert this to .zenodo.json which are recognized during the upload. What ends up happening is a skew what is shown as the URL.

In contrast, the top-level url is more unambigously about the current entity.

Not sure what the right solution here is, but this inconsistency should be addressed.

[alexlancaster]

In addition there is an inconsistency with handling of doi.

The GitHub widget will the DOI and display it in the widget if it is at the top-level. But if it's in identifiers it will ignore it completely. Whereas cffconvert will ignore the top-level doi and only use the first doi it finds in identifiers

[jspaaks]

Hi Alex, thanks for reporting this issue.

I agree that it would be helpful for users to have consistency across tooling. In fact I've advocated for it, and proposed a mechanism for how to implement it, here: citation-file-format/citation-file-format#330 (comment)

Unfortunately, I expect it might be a while before CFF can achieve consistency across its ecosystem of tools. I feel this is ultimately a funding issue.

Best,
Jurriaan

PS ping @sdruskat @hainesr

[sdruskat]

Thanks for bringing this up, Alex!

I agree with Jurriaan in that consistency would be nice, but also that it might take a while and is due to funding. I prefer the way this is done in cffconvert, with the identifiers url taking precedence over the root one, but ruby-cff is a currently unfunded project and so I'm not sure if and when such a change might happen.

[hainesr]

I'm happy to make changes to ruby-cff to make sure things are consistent. I think we should document what the precedences are though, as I'm sure there are loads of places where we have conflicting data.