sdruskat

The agenda release and docs update came a few days later, yes. I think it might have been in the Gem already, albeit experimentally.

This is because CFF is mainly built to support the software citation principles [1], where it is argued (rightly so, if you ask me) that software is important enough to be cited in its own right.

Also, there will likely be no new paper for each version of software, so if you want to cite the version you have used in your work (e.g. towards reproducibility), the paper may be useless.

[1] https://doi.org/10.7717/peerj-cs.86

The guarantee is that you have citation information for a specific research output type: software (or dataset, as defined), and that it is the output you have found the CFF file with. Unless people want to break the principle on purpose, against which no format/mechanism can do anything ;).

@software is simply an alias for the fallback @misc, i.e., semantics are lost, no fields like different URLs for different software media (code, build artifacts, etc.), no software identifier support, etc.

Also, you can have people cite your paper on GitHub by giving them it as a preferred citation in CFF, and GitHub will render that instead of the source code. Which is, btw, against the software citation principles [1], but caters to people who need time adapting and want traditional credit now.

[1] https://doi.org/10.7717/peerj-cs.86

Not for providing citation metadata for software, where BibTeX misses important fields.

This is indeed something that needs to be solved. I think the current path in the schol comms community leans towards having contributors (with different roles) as well as authors.

Also, summary authors ("the <project> contributors") is one way to relatively elegantly circumvent this, and something you could do in a CFF file for example (these are being picked up by Zenodo).

This is something that you can do by providing a `preferred-citation` in a CITATION.cff file. This will be rendered on GitHub as the thing to cite. See the schema guide section about this here: https://github.com/citation-file-format/citation-file-format....

We're trying to bring CFF to other platforms as well, so everything just becomes stickier ;). E.g. https://gitlab.com/gitlab-org/gitlab/-/issues/337368.

I guess the answer is semantics: who will guarantee (e.g. to downstream services) a CITATION.bib file will contain the metadata for the software in the repo? CFF is single-purpose and made for just that.

Hi, and thanks for supporting CFF through the Zotero connector (for GitHub repos) now :).

FYI, we're in the process of improving the website atm, including a Rationale section, etc. which will hopefully make it clearer why we think the format is a good idea, at least for the time being.

As for your takeaway 2.:

`references` can take all kinds of references, not just software and references, including articles, so a paper describing the algorithm implemented in the software that the CFF file describes is exactly in scope for that (the paper being, e.g., a prior work).

Now including GitHub, that gives you BibTeX generated from CFF files :).

Hi, co-lead of the CFF project here.

One advantage I see is semantics, and that it's single-purpose. Downstream clients (archives, indexers, GitHub citation feature, etc.) know exactly what they're dealing with (citation information for software or datasets). Also has better support for software-related fields than BibTeX for example (@software being an alias for @misc).

Clutch predicted this in 2004: "Everybody move to Canada, smoke lots of pot, everybody move to Canada right now!" (Clutch, "The Mob Goes Wild", Blast Tyrant. DRT: 2004) https://youtu.be/XDCNJtK6XkE

And seriously, there is obviously a massive commercial interest in legalized marijuana, hence we'll see more and more moves in that direction. The correlation with de-demonization (and de-criminalization!) of 'organic' drugs and widening of personal liberties is a side-effect, albeit a welcome one.

I've confronted my PhD supervisor (Professor of Library and Information Science) with this statement once, and she almost went berserk. Her take is that free text search is approaching the solved problem stage, but almost all other search isn't.

Software Heritage is doing great things, and will be central to current efforts in research software sustainability, software citation, and most of all reproducible research!

- Burnistoun (sample here: https://www.youtube.com/watch?v=sAz_UvnUeuU, https://en.wikipedia.org/wiki/Burnistoun): I have regularly thrown laughing fits over this.

- Hardy Bucks (https://youtu.be/qq-G2ugAG44, https://en.wikipedia.org/wiki/Hardy_Bucks)

Tech-wise, Silicon Valley I think is funny esp. the earlier series.

Aims to be, yes. Early stages still, but it's well-supported by a number of institutions, funders, governments even.

Aaaand it's back.

It exist! Not a whitepaper, but at least a Medium article: https://medium.com/@alexberegszaszi/mango-git-completely-dec.... Ethereum + IPFS/Swarm as backend for Git.

Source code is currently unavailable as it is hosted on ... drum roll ... GitHub: https://github.com/axic/mango.

If all goes belly up there is always Software Heritage (https://www.softwareheritage.org/).

Has been done now. https://status.github.com/messages.

Great concept promising potentially more in-depth experiences than the cpomtetition. I think that the single point of failure of the site would be failure to build a large enough community of reviewers.