Create Citation.cff

[hauschke]

Thank you for submitting a pull request! Title this pull request with a brief description of what the pull request fixes/improves/changes. Please describe the pull request in detail using the template below.

---

JIRA Issue: (please link to issue)
https://jira.lyrasis.org/browse/VIVO-2006

• Other Relevant Links (Mailing list discussion, related pull requests, etc.)
  https://twitter.com/natfriedman/status/1420122675813441540

What does this pull request do?

This should add a (new) widget by Github which allows easier citing of the VIVO JOSS Paper using Citation File Format (cff), https://github.com/citation-file-format/citation-file-format.

What's new?

Added citation.cff with basic metadata. Could be expanded in future (ORCIDs of contributors etc.). Metadata was generated with https://citation-js.github.io/cff-generator/.

How should this be tested?

1. Does the widget appear?
2. Correct bibliograph data?

Additional Notes:

As soon as this works, the citation recommendation in the readme.md can be removed.

Interested parties

@VIVO-project/vivo-committers, @mconlon17 @vivo-project/vivo-ontologists

[hauschke]

Fixed some issues. Multiple authors and info about publication venue seems not to be supported by the github widget.. Discussion needed if we are going to use the feature.

[chenejac]

My impression is that cff might be used for software citation directly (not via proxy, i.e. via 10.21105/joss.01182). Here is the specification of the CFF - https://zenodo.org/record/5171937#.Ybcg09DMKUk. Do we need anymore the paper directory in the VIVO GitHub repository?

[chenejac]

What is this date? Date of releasing this cff file? Or this document - https://joss.theoj.org/papers/10.21105/joss.01182? Or VIVO last release?

[Zack-83]

It seems to be the date of the article.

[chenejac]

There are also url and repository-code metadata.

[Zack-83]

The article url is redundant with the DOI, so no need to add it.
For the code url we can use either https://vivoweb.org/download/ or https://github.com/vivo-project/VIVO/releases

Suggested change

	doi: 10.21105/joss.01182
	doi: 10.21105/joss.01182
	repository-code: https://vivoweb.org/download/

[chenejac]

I found a couple of examples of using citation.cff file in GitHub repos. I have used "citation.cff site:github.com" google query for this purpose. Here are some examples:

1. https://github.com/citation-file-format/doi2cff/blob/master/CITATION.cff
2. https://github.com/bids-standard/pybv/blob/main/CITATION.cff
3. https://github.com/SCM-NV/qmflows/blob/master/CITATION.cff

[annakasprzik]

We also use it: https://github.com/zbw/stwfsapy https://github.com/zbw/qualle     Gesendet: Freitag, 28. Januar 2022 um 10:14 Uhr Von: "Dragan Ivanovic" ***@***.***> An: "vivo-project/VIVO" ***@***.***> Cc: "annakasprzik" ***@***.***>, "Team mention" ***@***.***> Betreff: Re: [vivo-project/VIVO] Create Citation.cff (#247)   I found a couple of examples of using citation.cff file in GitHub repos. I have used "citation.cff site:github.com" google query for this purpose. Here are some examples: https://github.com/citation-file-format/doi2cff/blob/master/CITATION.cff https://github.com/bids-standard/pybv/blob/main/CITATION.cff https://github.com/SCM-NV/qmflows/blob/master/CITATION.cff — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you are on a team that was mentioned.Message ID: ***@***.***>

[smierz]

just noticed that VIVO uses two different DOIs mentioned in its README:

• https://doi.org/10.21105/joss.01182
• https://doi.org/10.5281/zenodo.2639713

If you use the first one for the Citation file (like this pull request does), then you would fill all fields with values from the article and its metadata. Benefit: you could remove the part from README file and have the Citation button provide the Bibtex reference.

BUT: the second one is a Zenodo DOI used to archive VIVO releases. When using Zenodo for archival, then Zenodo will use the values in the Citation file to fill out this page https://zenodo.org/record/2639714#.YkWTE99CQ2w and here the two publications diverge, for example the first DOI uses different keywords and has no software license (since it is an article) as the second one does, so you would have to rewrite these values manually each time a release is made.
You can see an example of the connection between Citation.cff and Zenodo here https://github.com/Project-TAPIR/pidgraph-notebooks/blob/main/CITATION.cff resulting in https://zenodo.org/record/6373245#.YkWUHd9CQ2w (this is an automated process when doing a release in your software repo, I'm not filling any values manually).
Also keep in mind when using a Citation.cff file, you need to update it after every release + the DOI link in your README.

--> You probably should keep the Bibtex reference in the README and use the values for Zenodo releases in the Citation file.

[hauschke]

Maybe we can ask @sdruskat as a main person behind the citation.cff idea:

Is there something like a good practice to look for regarding the decision to use a JOSS paper or a Zenodo-archived version of a repo in the citation.cff? I'm leaning more towards JOSS, because it's specifically designed at making a software citable in publications, which means it serves the function we (at least I) intended to use the citation.cff for, too.

[sdruskat]

Hi @hauschke, all, 👋

There's no single correct way to do this at the moment, as software citation is gaining traction using some bridge technologies such as software journals, etc. Here's my thinking for your case:

1. Use the Zenodo DOI as the identifier for the software itself in the root document. This way, people can find an archived version of the the citable version of the software itself. (Update this value if you push a new version to Zenodo in the future.)
   e.g.,
2. Use the JOSS paper as a preferred-citation. This way, people will know that they are asked to cite the paper (ideally in addition to citing the software) to give you credit in a more commonly known way (via a paper).

The respective sections could look similar to this:

# This CITATION.cff file was generated with cffinit.
# Visit https://bit.ly/cffinit to generate yours today!

# SNIP
identifiers:
  - type: doi
    value: 10.5281/zenodo.2639713
    description: A long-term archive of version X.X.X
repository-code: 'https://github.com/vivo-project/VIVO'
preferred-citation:
  type: article
  title: "JOSS paper title"
  authors:
    - name: "JOSS paper authors"
  identifiers:
    - type: doi
      value: 10.21105/joss.01182
# SNIP

I hope this helps.

[hauschke]

Thanks a lot, @sdruskat! Can we agree on this? Then I would prepare such a file according to this pattern with the JOSS paper as preferred-citation.

But before we should decide, if we make it a standard to archive a copy of each release on Zenodo.

[chenejac]

@hauschke @sdruskat thanks for this nice discussion. I am wondering whether we really need to archive releases in Zenodo, or it is enough it is already in mvn repository? Can we use

identifiers:
  - type: url
    value: https://mvnrepository.com/artifact/org.vivoweb/vivo-project
    description: A maven repository link
  - type: url
    value: https://github.com/vivo-project/VIVO/releases
    description: A GitHub release link

instead of an identifier of a Zenodo archive?

[sdruskat]

I am wondering whether we really need to archive releases in Zenodo, or it is enough it is already in mvn repository? Can we use

identifiers:
  - type: url
    value: https://mvnrepository.com/artifact/org.vivoweb/vivo-project
    description: A maven repository link
  - type: url
    value: https://github.com/vivo-project/VIVO/releases
    description: A GitHub release link

Sorry for the tardy reply. Of course, it's perfectly valid to use these identifiers. Archiving on Zenodo has the advantage that you get a globally unique ID for the release (a DOI), and the sources are more easily accessible to people who don't use Maven. But it's really up to the project to decide whether that's an option.

[Zack-83]

Do we really require users to cite only the article ainstead of the software?
There is also the solution software-references-article, i.e.

This CITATION.cff file was generated with Zotero.

cff-version: 1.2.0
message: >-
If you use this software, please cite it using the metadata from this file.
title: >-
vivo-project/VIVO
abstract: VIVO is an extensible semantic web application for research discovery and showcasing scholarly work
type: software
license: BSD-3-Clause
url: https://github.com/vivo-project/VIVO
date-released: 2024-08-11

references:

• title: >-
  VIVO: a system for research discovery
  abstract: |
  VIVO [Pronunciation: vee-voh] is member-supported, enterprise open source software and an
  ontology for representing scholarship. VIVO supports recording, editing, searching, browsing
  and visualizing scholarly activity. VIVO encourages research discovery, expert finding, network
  analysis and assessment of research impact. VIVO is easily extended to support additional
  domains of scholarly activity (Börner, Conlon, Corson-Rikert, & Ying Ding, 2012).
  VIVO uses an ontology to represent people, papers, grants, projects, datasets, resources, and
  other elements of research and scholarship as linked open data. The ontology can be used to
  create RDF that can be loaded into VIVO. VIVO RDF data is easily exported for use in other
  applications.
  VIVO includes Vitro (Project, 2019), a domain-free engine for managing linked open data,
  the JFact reasoner (“JFact DL Reasoner,” 2018), SolR (“Apache Solr -,” 2019) for search,
  SPARQL query (“SPARQL Query Language for RDF,” 2008), Jena as a triple store (“Apache
  Jena -,” 2011), supporting both TDB (“Apache Jena - Apache Jena - TDB,” 2019) and
  SDB (“Apache Jena - SDB - persistent triple stores using relational databases,” 2019) on
  MySQL (“MySQL,” 2019), uses D3 (Bostock, 2015) for visualizations, and provides multiple
  APIs, including Triple Pattern Fragments (Verborgh et al., 2016) for rapid remote access to
  specified data.
  Using VIVO, organizations can represent the activities and accomplishments of their scholars
  as linked open data, and share that data with others.
  type: journalArticle
  issn: 2475-9066
  issue: 39
  languages:
  • en
    pages: 1182
    volume: 4
    authors:
  • family-names: Conlon
    given-names: Michael
  • family-names: Woods
    given-names: Andrew
  • family-names: Triggs
    given-names: Graham
  • family-names: O'Flinn
    given-names: Ralph
  • family-names: Javed
    given-names: Muhammad
  • family-names: Blake
    given-names: Jim
  • family-names: Gross
    given-names: Benjamin
  • family-names: Ahmad
    given-names: Qazi Azim Ijaz
  • family-names: Ali
    given-names: Sabih
  • family-names: Barber
    given-names: Martin
  • family-names: Elsborg
    given-names: Don
  • family-names: Fofack
    given-names: Kitio
  • family-names: Hauschke
    given-names: Christian
  • family-names: Ilik
    given-names: Violeta
  • family-names: Khan
    given-names: Huda
  • family-names: Lawless
    given-names: Ted
  • family-names: Levernier
    given-names: Jacob
  • family-names: Lowe
    given-names: Brian
  • family-names: Martin
    given-names: Jose Luis
  • family-names: McKay
    given-names: Steve
  • family-names: Porter
    given-names: Simon
  • family-names: Walther
    given-names: Tatiana
  • family-names: White
    given-names: Marijane
  • family-names: Wolff
    given-names: Stefan
  • family-names: Younes
    given-names: Rebecca
    date-published: 2019-07-26
    doi: 10.21105/joss.01182