Switch bibtex type from misc to software?

[tmorrell]

There is now support in biblatex for a software item type https://www.softwareheritage.org/2020/05/26/citing-software-with-style/, and this type works well in Zotero. Having a more accurate type would highlight that we're dealing with software, but I don't know the impact this would have in other reference managers.

[arfon]

I discussed this with @npch a few weeks ago and he pointed out that this could potentially have some very negative consequences. Specifically I think the concern was that the most common BibTeX packages (I don't recall which sorry) would skip any entries that they don't recognise (e.g., @software) which would mean these items wouldn't be cited, therefore undermining the whole point.

Hopefully @npch will notice this GitHub ping and provide a little more information here on his thinking but I think it's currently unclear to me whether this would be good change right now.

[hainesr]

We could have this as a configurable option as it could be useful for some users. @misc could remain the default with @software available with a switch.

Are @misc and @software otherwise interchangeable - at least to the extent we use them here?

[arfon]

Some kind of flag sounds reasonable.

Are @misc and @software otherwise interchangeable - at least to the extent we use them here?

I think @software has some additional software-specific fields but I'm not an expert on this: https://hal.archives-ouvertes.fr/hal-02977711/document

[npch]

There’s a big difference between BibTeX and BibLaTeX - the two should be considered as distinct. Some implementations of BibLaTeX support @software, BibTeX doesn’t at all and isn’t ever likely to, as I understand it. Maybe the switch is between whether you’re outputting to BibTeX or BiBLaTeX?

…

-- Neil Chue Hong Director, Software Sustainability Institute *** Note new address *** Room 2.43, EPCC, University of Edinburgh, The Bayes Centre, 47 Potterrow, Edinburgh, EH8 9BT, UK Tel: +44 (0)131 650 5957 http://www.software.ac.uk/ LinkedIn: http://uk.linkedin.com/in/neilchuehong Twitter: http://twitter.com/npch ORCID: http://orcid.org/0000-0002-8876-7606

________________________________ From: Arfon Smith ***@***.***> Sent: Sunday, July 18, 2021 5:04:03 PM To: citation-file-format/ruby-cff ***@***.***> Cc: NEIL CHUE HONG SSI Director ***@***.***>; Mention ***@***.***> Subject: Re: [citation-file-format/ruby-cff] Switch bibtex type from misc to software? (#40) This email was sent to you by someone outside the University. You should only click on links or attachments if you are certain that the email is genuine and the content is safe. Some kind of flag sounds reasonable. Are @misc and @software otherwise interchangeable - at least to the extent we use them here? I think @software has some additional software-specific fields but I'm not an expert on this: https://hal.archives-ouvertes.fr/hal-02977711/document — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#40 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AALP6T3AYS3Z7ZUNUMGJEZ3TYL3PHANCNFSM5AKG5GRQ>. The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. Is e buidheann carthannais a th’ ann an Oilthigh Dhùn Èideann, clàraichte an Alba, àireamh clàraidh SC005336.

[hainesr]

Thanks @arfon and @npch.

I think my conclusion is that if we're going to support this then it would be through a separate formatter specifically targeting BibLaTeX, and leaving the BibTeX formatter well alone.

Also, the set of @software, @softwareversion, @softwaremodule and @codefragment are complex enough we probably don't want to delay version 1.0 for this (do we?) even if it would be great to have them in there eventually.

[sdruskat]

Agree that having two separate formatters would be the best option here.

[hainesr]

Thanks all. I'm going to close this and note the outcome in a new issue: #48

[rdicosmo]

Noticing only now this thread, and it is pretty sad to see @misc used to describe software projects instead of the more appropriate entries now available, mentioned by @tmorrell : I would like the discussion to be continued.

It appears that the rationale for this decision is the fear to see the @software, @softwareversion, @softwaremodule or @codefragment entries ignored or skipped in the articles that use BibTeX bibliographies.

Now, my experience as an old time user of BibTeX (and even developer of BibTeX styles) is that all BibTeX styles handle unknown entry types exactly as @misc : this is because BibTeX was conceived from the very beginning as an extensible format (before XML :-)). You can see this by yourself looking at the special instruction that is placed in the .bst files to this end

FUNCTION {default.type} { misc }

Hence, for old BibTeX styles, using @software or @softwareversion produces exactly the same (lame) output as using @misc, while a BibLaTeX user that includes the biblatex-software style extension will benefit from the advanced software citation features.

This is a strong argument to avoid @misc and go for @software or @softwareversion in the GitHub export (depending on whether you want to cite a project, or a specific version).

An example of what an existing journals does can be seen here: http://www.ipol.im/pub/art/2020/300/
If you click on the SWHID info box for the source code, you will get

@softwareversion{sw-ipol.2020.300,
title = {{Local Contrast Enhancement based on Adaptive Logarithmic Mappings}},
author = {Jose-Luis Lisani},
date = {2018-01-01},
license = {AGPL-3.0-or-later},
version = {2.0},
swhid = {swh:1:dir:03d81d9e8d583aa52bfe5a696c875a406571684c;origin=https://doi.org/10.5201/ipol.2020.300;visit=swh:1:snp:e3c3904624230050561a3c5a615b3852fda6a22c;anchor=swh:1:rev:2bda715d58c19bfc04bac7028a5c67780f177cd3},
related = {ipol.2020.300},
relatedtype = "Reference article: https://doi.org/10.5201/ipol.2020.300"
}
% the biblatex-software style extension is recommended for software bibitems

P.S.: in full transparency, I am the author of the biblatex-software style extension for BibLaTeX

[rdicosmo]

There’s a big difference between BibTeX and BibLaTeX - the two should be considered as distinct. Some implementations of BibLaTeX support @software, BibTeX doesn’t at all and isn’t ever likely to, as I understand it. Maybe the switch is between whether you’re outputting to BibTeX or BiBLaTeX?
…

Hi Neil, as a very long time user and former BibTeX style developer, I can shed some light here.

The BibTeX format was designed as an extensible format, and to the best of my knowledge, all BibTex styles handle unknown entries exactly like @misc (look for the instruction FUNCTION {default.type} {misc}). I just checked the 152 styles that come with the standard TeXLive distribution I use, as well as various popular conference and journal styles, and they all behave this way (the only exception are a few special purpose styles that are not used for articles).

This means that using @software, @softwareversion or @codefragment instead of @misc makes absolutely no difference for BibTeX users, while it makes a world of difference for BibLaTeX users, and allows to signal that software is on par with other artifacts, instead of downgrading it to miscellanea.

If you see any other reason to continue using @misc instead of the appropriate entry types among @software, @softwareversion or @codefragment, it would be helpful to share it.

[npch]

The main reason was that existing guidance out in the wild around BibTeX e.g. https://www.bibtex.com/e/entry-types/ and guidance from libraries was to use @misc. But this is something that we do need to get changed as part of the wider software citation work.

If the rendering of unknown types defaults to @misc (I did not know that this was the case - thanks for pointing me to the relevant instruction) in all common TeX distributions then I would be happy to endorse the generation of @software instead. I had been under the impression talking to others that this was dependent on the tool processing the BibTeX file.

[rdicosmo]

Great, it seems we have now a clear green light to switch the export to @software!
@arfon @sdruskat : floor is yours to move forward :-)
Please do not hesitate to ask if you need a hand about the various fields that are supported: the current list is in section 3 of the biblatex-style guide (you can find it for example at https://ctan.gutenberg.eu.org/macros/latex/contrib/biblatex-contrib/biblatex-software/software-biblatex.pdf)

[hainesr]

I've done some testing of @software and @softwareversion in Overleaf (3.14159265-2.6-1.40.21 (TeX Live 2020); BibTeX unknown) and on my local machine (pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian); BibTeX 0.99d (TeX Live 2019/Debian)). I tested apacite, chicago and IEEEtran styles.

It seems like @software does work as expected.

In the IEEEtran style the crossref isn't followed from @softwareversion back to @software so the author details are missing.

I suppose, given that at present we are only looking at switching out @misc for @software, we'd be OK but I'd like @arfon, @sdruskat and @jspaaks (and others) thoughts before doing this. Having a separate BibLaTeX formatter is also still an option if it could be fit into the GitHub interface.

[arfon]

I suppose, given that at present we are only looking at switching out @misc for @software, we'd be OK but I'd like @arfon, @sdruskat and @jspaaks (and others) thoughts before doing this. Having a separate BibLaTeX formatter is also still an option if it could be fit into the GitHub interface.

Thanks for testing this @hainesr – based on @rdicosmo's input and your testing too, I'd support moving to @software as the default output here.

I'd rather not have a separate formatter for BibTeX and BibLaTeX at this stage, and would rather keep the UI free for additional potential outputs.

[rdicosmo]

Dear Robert, thanks for experimenting with all this. Would you mind sharing the test example that shows the crossref issue in IEEEtran? I'd be interested in looking at it (you can send me this directly).

…

-- Roberto P.S.: the decomposition in @software and @softwareversion using the crossref field is not mandatory: one can very well produce a @softwareversion entry with every field included. The idea of using the crossref field is to enable compact citations when several versions of the same software are cited, and to avoid duplications in a bibtex file: these are nice to have features, but one can live without them :-)

-- Roberto

On Sun, 26 Sept 2021 at 13:55, Robert Haines ***@***.***> wrote: I've done some testing of @software and @softwareversion in Overleaf (3.14159265-2.6-1.40.21 (TeX Live 2020); BibTeX unknown) and on my local machine (pdfTeX 3.14159265-2.6-1.40.20 (TeX Live 2019/Debian); BibTeX 0.99d (TeX Live 2019/Debian)). I tested apacite, chicago and IEEEtran styles. It seems like @software does work as expected. In the IEEEtran style the crossref isn't followed from @softwareversion back to @software so the author details are missing. I suppose, given that at present we are only looking at switching out @misc for @software, we'd be OK but I'd like @arfon <https://github.com/arfon>, @sdruskat <https://github.com/sdruskat> and @jspaaks <https://github.com/jspaaks> (and others) thoughts before doing this. Having a separate BibLaTeX formatter is also still an option if it could be fit into the GitHub interface. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#40 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFH5PZDW36R4XYSYU527YTUD4C3RANCNFSM5AKG5GRQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[hainesr]

I have merged these changes to main.

@rdicosmo, I have emailed you an invite to the Overleaf project.