figure out relation to codemeta about cffconvert

[sdruskat]

Great to see that you are working on implementing a reader for CFF!

I plan to write something coherent about the relation between CFF and CodeMeta soon as this is something that I think is important for users of both to understand. Some points I hope can clear things up a bit:

• IMHO, CodeMeta aims to, generally, provide a minimal schema for metadata for research software. It isn't necessarily tailored for citation metadata but can be used to provide metadata that can be used for citation. The metadata can be provided as schematized JSON. The schema adds its own keys to a subset of schema.org, but there is a discussion (codemeta/codemeta#161) whether this can be transformed to CodeMeta extending schema.org.
• CFF aims to provide a format for the explicit and exclusive provision of citation metadata for research software. Things like transformability to BibTeX and RIS have been taken into account. As such, CFF is both less comprehensive in terms of general metadata (although I will extend it to cover the whole key set of CodeMeta at some point), and more "detailed" in terms of citation metadata. It is also potentially a source format for codemeta.json files (via the crosswalk table you have already linked to).

[jspaaks]

Hi Stephan,

thanks for these explanations. I never really looked into linked data or schemas and whathaveyou so it's a bit of a learning experience for me. But anyway, I do think it's a useful and necessary endeavor so I'm glad you and the other guys (and girls?) have taken the initiative for CFF. We're following any developments with interest. BTW the reason that we have adopted the cff format is that we have a bunch of GitHub repos (github.com/NLeSC and others) that we would like people to start citing (when they use parts of it). We are working on improved dissemination of our software through a website we're building (which we refer to as a Research Software Directory). That website lives here (https://research-software.nl) and is being developed here (https://github.com/research-software-directory, all Apache 2). Anyway, the product pages include a section "Cite this software" which we generate from the CITATION.cff from the respective repos. We use citeas.org as a fallback (see the flow diagram at https://github.com/research-software-directory/frontend/issues/42).

Perhaps also of interest to you is the citeme tool that @bpmweel has developed, basically a way of annotation your python functions and classes such that at a later time, it's just one command to generate exactly the minimum set of citations depending on what you actually use from a software package. According to the author, it's not very mature yet but I think such a package is a good idea if nothing else.

[sdruskat]

Well, thanks for the interest! I'm obviously happy to discuss/present at any time. I've proposed a mini-workshop on CFF for the SSI Collaborations Workshop and will be there anyway, so in case you or someone from the NLeSC is able to be there we can have a chat.

I'd already had a look at the RSD when I found out about this repo here, and in fact was hoping that you would use CFF files for the "Cite this software" section in the frontend, as this is exactly what I had in mind for CFF from the onset.

citeme looks like a great idea. In the original lightning talk at WSSSPE5.1 which led to CFF (abstract here) I had also suggested that CFF files can be used to present citation metadata to the user during runtime (or as part of the output), so perhaps citeme together with a generic Python CFF reader (which could re-use some parts of citationcff) would be a nice synergy?

Generic CFF readers for different languages as well as a plugin-based conversion framework for CFF data are on my todo list as well (citation-file-format/citation-file-format#36, citation-file-format/citation-file-format#44), so perhaps we can integrate at some point.