For instance 10.6084/m9.figshare.979190 reported by Michael Crusoe. JavaScript parser didn't like @data entries produced by figshare and when requesting the entry dx.doi.org returns a 403 response for type accept type text/bibliography, also allowing application/x-bibtex fixes this. Interestingly dx.doi.org throws 500 exceptions if application/x-bibtex is the only acceptable type or appears first for some other DOIs.
Was displaying warning message about history citations being potentially incomplete for tools - which if they have annotated citations we should assume they are complete.
... per @martenson's suggestion and with @erasche2 permission.
Wonder if we want to double down on these buttons and convert tool shed link and citations handling to use this mechanism or perhaps add a drop down "gear" menu with these options ala the history panel.
This fixes a bug where web UI short circuits rendering of history panel if history only contains dataset collections and no datasets.
The most obvious alternative to this would be to 1) add collection information to the per-content state ids dict - which may not make a lot of sense since we haven't nailed down exactly what collection states should look like and if they will be drawn from the same possible set of states as dataset states or 2) build a separate set of state summaries for dataset collections. In addition to these two approaches being more work, they also lock the API into more expensive queries by default.
Allow tool authors to specify citations using a DOI or BibTeX. BibTeX can be specified either by pointing at a BibTeX file in the tool directory or by embedding bibtex entries right in tool citation blocks. If referencing a file parallel to the tool, the file should contain only a single BibTeX entry, this restriction can be easily lifted by adding a BibTeX parser as a Python dependency for Galaxy - but I do not have permission to do this.
These citations will appear at the bottom of the tool form in a formatted way but the user will have to option to select RAW BibTeX for copying and pasting. Likewise, the history menu now has an option allowing users to aggregatesuch citations across an analysis a comparable list of citations.
UI interactions are implemented using a Backbone model and view and data is fetched from the Galaxy server as BibTeX using the API. Two API entry points have been added - one to fetch the BibTeX entries for a tool and another for a history.
BibTeX entries for citations annotated with DOIs will be fetched from http://dx.doi.org/ and cached using Beaker.
Additional Limitations:
- I am not super happy with a few different GUI elements of this. It is ugly and I didn't write the BibTeX parser but I did write the code that takes parsed BibTeX and converts it to a formatted entry. If merged, I will outline a Trello card to follow up and improve the UI and find some more standard way to build a formatted HTML citation from a parsed BibTeX entry.
- BibTeX Limitations: LaTeX embedded in the BibTeX entries doesn't render properly when producing a "pretty" citation in the GUI (should still be exported to citation managers properly though). Cross references aren't supported at this time.
Alternative Implementations:
BibTex/DOI vs. PROV:
There was some discussion of PROV encoding citation information on the development mailing list. The citation tags on tools are typed so this could certainly be added - but it was discussed at the BOSC 2014 codefest and there was some conensus that tool authors are more likely to already have BibTeX or DOIs available for the tool's references and the major reference managers end users will likely plug these citations into while writing papers are more likely to be able to consume BibTeX than anything else.
The bench biologist using Galaxy is the consumer of this work I most concerned with - if we need to convert citations into other formats such as EndNote or Word's bibliography support there is a suite of tools we could optionally plug into Galaxy (http://sourceforge.net/p/bibutils/home/Bibutils/) to enable this down the road. PROV seems to have such an ecosystem to leverage - I could not even find a tool to convert it BibTeX.
Parse BibTeX Client vs Server:
As mentioned above it would be nice in some ways to be able to parse and reason about BibTeX on the backend - but it would require adding a new dependency to Python. Since we have to ship BibTeX to the browser anyway to allow users to copy and paste it - I decided it was easier to start with parsing and formatting BibTeX on the client side. I therefore added the following library BSD JavaScript dependency https://github.com/mayanklahiri/bib2json to enable this. I would be happy to revisit this decision and produce formatted entries server side - there seem to be more Python options for doing this than JavaScript.
Martin Cech