4 ms·
TLDR: Think of it like Zotero having field names that change depending on the item type. If you select "Journal Article", the CSL `container-title` field is dis
by cormacrelf 5y ago
TLDR: Think of it like Zotero having field names that change depending on the item type. If you select "Journal Article", the CSL `container-title` field is displayed as "Publication", whereas for a book chapter, it's "Book Title". The `software` type in CSL gets a similar treatment in Zotero, and CFF is like that but as a YAML schema for writing by hand. Additionally, you get to give reference data for the dependencies or datasets you built the present one from.
The main page for CFF does not argue for its existence very effectively. You're better off reading the schema (https://github.com/citation-file-format/citation-file-format/blob/main/schema-guide.md https://github.com/citation-file-format/citation-file-format...). Two takeaways:
1. It is is specifically for citing software and datasets. Only those two things. The fields look useful for its intended purpose: You can have multiple dois, for different versions of the software as published. You can include a few more different URLs than most formats, like zipped repo contents for a version or a dataset download link (repository-artifact) etc. If you use the preferred-citation field to point people to a paper instead, then you are warned it is against the principle of citing software and datasets as if they are papers themselves.
2. Unfortunately, though, because the schema only has enough fields for citing those two, if your software is (e.g.) an implementation of an algorithm described in a paper, you cannot express that in CFF. There is a `references` field, but in reality it can only contain other software and datasets because CFF can't describe anything else. It would be better if there were separate fields for CFF software/dataset references and other kinds of reference data, the latter incorporating CSL-JSON by reference. CSL-JSON isn't really written by hand except by a handful of people making CSL tests (me!); the point of such a field would be a space to dump an export from your reference library.
So in sum, what is the advantage of this?
- Anything but JSON. People hate writing it by hand.
- Software-specific field names, whereas if you used CSL-JSON directly `date-released` would be `issued`... who issues software?
- Separates the "main" citation and the "references", whereas other formats are a flat dump of a reference library. It's got structure enough to produce different bibtex/etc for different versions of the code, selectable at conversion time.
(Disclosure: I work for Zotero.)
- sdruskat 5y agoHi, 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).
- cormacrelf 5y agoAh, I missed the fields that would help you define that info on “definition.reference”. https://github.com/citation-file-format/citation-file-format/blob/main/schema-guide.md#definitionsreference https://github.com/citation-file-format/citation-file-format... Clearly I’m not the person who built the connector if I missed that :)