galaxy-hub icon indicating copy to clipboard operation
galaxy-hub copied to clipboard

Provide Zotero/bibliography/citation system

Open NickSto opened this issue 2 years ago • 3 comments

The EU Hub currently uses jekyll-scholar to provide a system for citing papers. It provides the {% cite %} and {% bibliography %} tags. These depend on a separately-maintained .bib file (or files?) in the _bibliography/ directory.

EU's .bib files

update_citations-eu.py queries Zotero and dumps the result into _bibliography/citations-eu.bib.

There are also a number of other .bib files in that directory, and I'm not sure exactly how all of them are used:

citations.md

This produces the full list of Galaxy publications. It references both citations-eu.bib and citations-eu-manual.bib: {% bibliography --file citations-eu --file citations-eu-manual %}

*/publications.md

Each subsite seems to have its own .bib file, which is referenced in the {% bibliography %} in the corresponding */publications.md file to generate the subsite's publications page.

index-*.md

But there's also a {% bibliography %} in four middle pane Markdown files (e.g. index-metagenomics.md), and they don't name any of the .bib files. Yet somehow they generate a bibliography which includes the papers cited. In index-metagenomics.md, all examples are papers which only exist in _bibliography/references.bib. But the config file doesn't reference that or any other .bib file, so I'm not sure where the connection is made.

Reimplementing it

Building the bibliography

We could query Zotero on build and add the papers to GraphQL using the Data Store API. We could also keep the manually curated lists in a YAML or JSON file or something.

Inserting citations

The pages which just produce a full bibliography list should be relatively easy. Worst-case, we could just make them dynamic pages and query GraphQL.

But the pages which use the {% cite %} tag would be trickier. There's no functionality I'm aware of that would let components communicate with each other to discover, say, which papers were cited earlier in the same page. Instead, we'd have to duplicate the id of each paper cited in at least two places: where it's cited, and in the bibliography at the end.

Another issue with {% cite %} pages is that components can't do dynamic GraphQL queries. A workaround would be to store the citation data in a JSON and import it in the component like we do config.json. A catch with that workaround is that the Zotero data would be stored in the GraphQL layer, not the JSON, and would be inaccessible. To address that we'd have to tell authors that they need to manually add anything they cite to the JSON. Or we abandon the GraphQL/Data Store API fanciness and just use a script to write the Zotero data to the JSON, much like .eu currently does.

NickSto avatar Jun 01 '22 19:06 NickSto

{% bibliography %} I've written a (rubbish) jeklly-scholar replacement in use at GTN. What happens here is that {% cite %} is used on a page. scholar keeps track of every page that uses cite, and then when bibliography is called, builds it from that list.

naming bib files is strictly only for "display this and only this bib". Otherwise, all bibs are discovered, for referencing with e.g. cite

hexylena avatar Sep 12 '22 10:09 hexylena

@hexylena Thanks for the info! I guess it auto-discovers all .bib files in the repo somehow, so it doesn't have to explicitly reference them in the config file?

NickSto avatar Sep 12 '22 20:09 NickSto

Yep, exactly. You can set a search path in the config.yml for the plugin, or I think there's some default value otherwise.

It should be very fast to discover all bib files, that's the solution we've taken in the GTN, rather than making it configurable since that's not really useful.

hexylena avatar Sep 13 '22 10:09 hexylena