Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for collection-doi in APA and BibTeX formatter #41

Open
lnielsen opened this issue Jul 16, 2021 · 10 comments
Open

Support for collection-doi in APA and BibTeX formatter #41

lnielsen opened this issue Jul 16, 2021 · 10 comments
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@lnielsen
Copy link

Just a suggestion for improvement

If you add the collection-doi field it's not used by the APA and BibTex formatters. It would be great if there was some resolution mechanism implemented that would

  • Use 'doi' if it exists.
  • Use 'collection-doi' if 'doi' not present.
  • Use 'url' or some other identifier if neither of the above exist.

This is to ensure that at least one identifier makes it into a citation string as this greatly helps with later citation tracking.

cc @arfon

@hainesr
Copy link
Member

hainesr commented Jul 16, 2021

Hi @lnielsen, many thanks for this note; this is really useful insight!

I will look at using collection-doi if we don't have a doi as you suggest.

Looking at the current code it looks like we insert a URI if it's there - even if we also have a DOI. And for the URI we prefer the repository_code over url if provided. Does this seem reasonable?

And if there is no URI at all, is there anything else we could usefully provide as an identifier do you think?

Thanks.

@hainesr hainesr self-assigned this Jul 16, 2021
@hainesr hainesr added the enhancement New feature or request label Jul 16, 2021
@hainesr hainesr added this to the 1.0 milestone Jul 16, 2021
@arfon
Copy link
Collaborator

arfon commented Jul 21, 2021

And if there is no URI at all, is there anything else we could usefully provide as an identifier do you think?

We presumably want to use a Software Heritage identifier too if there is one? e.g., https://github.com/citation-file-format/citation-file-format/blob/main/README.md#exemplary-uses-3

@lnielsen
Copy link
Author

Looking at the current code it looks like we insert a URI if it's there - even if we also have a DOI.

I've tried to check what the Citation Style Language does for the APA style. As far as I can decode it only includes the DOI and not both DOI/URL. See the APA style file

From a citation tracking point of view one identifier is preferable (i.e. no ambiguity). From a user point of view, I'm not sure - I think there's a certain value in having the URL there as well.

And for the URI we prefer the repository_code over url if provided. Does this seem reasonable?

Yes, fully agree.

We presumably want to use a Software Heritage identifier too if there is one? e.g., https://github.com/citation-file-format/citation-file-format/blob/main/README.md#exemplary-uses-3

Yep agree, an SWH identifier can be used as well - probably via a resolver link:

# https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html#software-heritage-resolver
https://archive.softwareheritage.org/<identifier>

@hainesr
Copy link
Member

hainesr commented Jul 21, 2021

I just realised last night (#43) that the ruby library doesn't have the identifiers type yet - it was added to the CFF spec recently. I'll add that this week. Then where would we use a resolver link for a SWH identifier in APA/BibTeX?

Also, I was looking at the collection-doi field, and it isn't present at the top level for the software object itself. It's only potentially present in a reference. So I don't know if it makes sense to pull that to the top level, unless I've missed something.

@lnielsen
Copy link
Author

Also, I was looking at the collection-doi field, and it isn't present at the top level for the software object itself. It's only potentially present in a reference. So I don't know if it makes sense to pull that to the top level unless I've missed something.

You're completely right - I completely missed that it was related to a reference and not top-level key. So, yes it doesn't make sense to use it.

@hainesr
Copy link
Member

hainesr commented Jul 22, 2021

Thanks @lnielsen, @arfon.

So I think then the workflow for choosing a doi would be:

  1. Use a top-level doi if provided, else
  2. Use a doi from the top-level identities field (subject to Missing identifiers type. #43)

And for choosing a URI:

  1. Use repository_code if present, else
  2. Use url if present, else
  3. Use a resolvable SWH URI from the top-level identities field if present

Or would we swap 2 and 3 for the URI? Or would we bump SWH to 1?

@lnielsen
Copy link
Author

I would go with moving the SWH to the doi just because it's a more stable identifier than the URL and users have to manually add it to the CFF file thus making an active choice to promote the SWH identifier.

@hainesr
Copy link
Member

hainesr commented Jul 23, 2021

Is it acceptable to use an SWH ID as a DOI? As in, can anything that is considered archival be used as a DOI, or should they be of the 10.5281/zenodo.1003150 form?

@hainesr
Copy link
Member

hainesr commented Jul 28, 2021

Ah, an SWH ID won't pass validation as a DOI.

@mfenner
Copy link

mfenner commented Aug 3, 2021

SWH ID is not a DOI, but another kind of persistent identifier. It would be desirable to have both if possible as they address different use cases. Most DOIs (about 85%) for software are from Zenodo, but it is not a requirement.

@hainesr hainesr modified the milestones: 1.0, Future Oct 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

4 participants