search

visdesignlab / visdesignlab.github.io

https://vdl.sci.utah.edu/
BSD 3-Clause "New" or "Revised" License
6 stars 22 forks source link

Display bibtex on paper pages instead of downloadable link #36

Closed alexsb closed 7 years ago

alexsb commented 7 years ago

We can generate bibtex from our YAML files instead of uploading bibtex files. This will be more robust, practical and cleaner.

Problems:

mckennapsean commented 7 years ago

An alternative would be https://github.com/davidagraf/doi2bib but this would not work for newer articles, so I won't go down this route.

With YAML, we may have to watch out for bibtex specific issues. CSL standard names might be worth using: http://blog.martinfenner.org/2013/07/30/citeproc-yaml-for-bibliographies/

Another option would be Google Scholar bib files since they are a static link, it looks like. We could have this bib URL link as a backup / alternative rather than generating automatically, which allows for full customization. I think focusing on the issue above first is a priority, though, and this would be a simple feature to add on.

alexsb commented 7 years ago

I'm happy with any solution that works, but looking at these links I still believe that custom code using the existing information in the YAML headers is probably the easiest.

mckennapsean commented 7 years ago

Kay! Got a working ish version. It just displays whatever bib-aspects you specify. At minimum, a publication must have a title, authors, and a year.

Simple, and works. Right now I just have it rendered on the page with Liquid, and we can have a button that expands/hides it.

I haven't looked into unpublished, since we have no examples of that yet. I will add fields that the others need. The only thing of note is that proceedings tend to have a booktitle rather than a journal, so I may have to mess with the template a bit to use one or the other.

mckennapsean commented 7 years ago

I had another idea, the bibtex file will just grab whatever is in a YAML block with the variable bib. It is then easily adaptable to multiple types of entries and fields, just add them in your YAML and done! Order is also determined by the order you place them. Here is an example of some fields I have for my EuroVis paper:

bibentry: article
bib:
  journal: Computer Graphics Forum
  booktitle: 
  editor: 
  publisher: 
  address: 
  doi: 
  url: 
  volume: 36
  number: 3
  pages: 
  month: 
  year: 2017

The title & authors are elsewhere in the file, and I think that is fine, as every publication requires those. Everything else is optional. Empty fields won't show up in the bibtex. I will upload a branch soon-ish.

mckennapsean commented 7 years ago

Feel free to try it out! Publications from 2016 onward should work. I just need to implement toggling, clean up the styling, and update all the publications.

https://github.com/visdesignlab/visdesignlab.github.io/tree/bibtex-generation

alexsb commented 7 years ago

This would duplicate a lot of information and make it more burdensome to create new entries.

I'd rather just add new volume / number tags to the top-level yaml, the rest (of the relevant entries) is already there, right?

mckennapsean commented 7 years ago

Only adding volume/number tags manually to YAML entries is less robust. This would mean we have to manually adapt new fields or entry types (such as inproceedings which use booktitle or supporting page numbers, publishers, editors, etc.). The end goal of this new format would be to not have any duplication, apart from short names for journals.

The only duplication I have now is the journal name, since they are not always journals (some are proceedings). I plan to just replace this with a Liquid tag that uses bib.journal, otherwise bib.booktitle. I would take a template for the bib fields and place it in the README somewhere, so each publication would only have the fields it uses (or will use).

The reason behind these changes is making it sustainable with Liquid. It is really easy to add all the fields inside bib manually, but this requires changes to the Liquid source when you want to add a new field. Additionally, <pre> tags are whitespace-sensitive, so optionally including a new field results in having those 5+ optional fields all on the same line in the source. This left the Liquid template in a very unmaintainable state. This is why I made the bib field to store all the fields, then it can be easily traversed in a for loop.

This would leave 4 required fields outside of the bib YAML key:

Yes, this does require going through each publication. And it requires changing some of the Liquid source. Both are trivial, and I am happy to do so in that branch. It has to be done anyways if we want to add in volume/number entries, and I was going to go through each bib file to see if there are any additional fields we need.

If you are on board with the changes, I can make sure the README is updated accordingly, but I wanted to check in before making massive changes like this. And @pgoffin , if you are going to add your pubs, you may wish to wait till we have this sorted out. :)

mckennapsean commented 7 years ago

Alrighty! I have all bibtex stored on pages from their YAML, as we discussed.

https://github.com/visdesignlab/visdesignlab.github.io/tree/bibtex-generation

Besides removing bibtex files & adding the bibtex on the page, this branch also currently changes how we display the "citation" that shows up on both the "Publications" page and on each publication's page. The change is that the volume, numbers, and pages are not currently being rendered. This could be added, but not all publications have these (so a bit messier to write in Liquid). I can do so... but do we need it? The bibtex citation has all of that information available right on the page, and on the publication list, just where it was published (journal or booktitle/proceedings) and the year seems fairly sufficient. Let me know what you think though.

What I have left to do is style the bibtex output, update the readme with details and a template, and possibly have a button for hiding or copying the bibtex.

mckennapsean commented 7 years ago

@alexsb - feel free to remove any *.bib files on the SCI server as well!