feat: bib -> acceptance, acceptance_rate, location, cve_score

[CheariX]

I added further filds to bib.liquid.

A common field is location, which is now printed.

I added fields for acceptance and acceptance_rate. These fields might be usefull for external people to better determine a vanue's quality.
acceptance is used for the accepted vs submitted papers.
acceptance_rate is a percent-value.

The existence of two distinct variables stems from the fact that the 'acceptance_rate' is represented using the venue color. On my website, I employ venue colors correlated with computer science conference rankings, which naturally leads to associating the acceptance rate with the same color scheme for coherence and better understanding.

You can find more examples on my website.

Also, I added a CVE Score, which is mainly usefull for IT-Security researchers, see this example.

---

Let me know what you think about this proposal.

[george-gca]

This CVE Score is what is shown as CVSS: 4.4 (Medium). 2022? I believe maybe we could add a field for extra information, and render as markdown. What do you think? This way this would be more general for different kinds of scores. As for the other information, it is ok for me. What do you think @alshedivat?

[alshedivat]

instead of creating all these new fields, I'm wondering if we could pass all these additional fields as a "dictionary" with extra information? something like this: additional_info={acceptance: "9/123", acceptance_rate: "7%", CVSS: "4.4 (Medium)"}. then we can make the template iterate over all key-value pairs and render them. I'm not sure if jekyll-scholar would natively support this though.

[george-gca]

I believe it does, and I agree with your idea. Can you implement it this way @CheariX?

[CheariX]

I can have at look at this. My first thoughts are:

1. Do these dictionaries work with Zotero? Currently, I use Zotero for enrching my bib files with such additional information. I could imagine that many other people do so as well, so I will have to find out how to put data there that betterbibtext exports the as a dictionary.
2. I want to use colors from my _venues.yml. Using this dictionary approach, it would not be possible. All I could do is manually add them into my bibtex file.
3. I'm not sure why we need a dictionary at all? The same behavior couldbe achived using a simple string additional_info that uses HTML to seperate different data. My main use case was to put such data at different positions in the bib.liquid

What do you think about:

a. We add a additional_info as a simple string so that most people can use it for multiple purposes.
b. We add some kind of inclusion hook:

• We could include a specific file, such as bib.hook.liquid only if it exist.
• This file wont be provided by the al-folio template so that people won't get into trouble when updating.
• If the filebib.hook.liquid does not exist, this step is simply skipped
• I'm not sure if it is possible to implement this, i.e. I don't know if a function checking the existance of a file exists in Jekyll.

[george-gca]

I implemented a plugin to allow checking if a file exists. You can see it being used here. But why would you implement a hook?

Actually when I thought about a dictionary, I thought about it like, iterate through all other key/value pairs and use them that way, this I believe it is possible. So in your case, instead of having additional_info={acceptance: "9/123", acceptance_rate: "7%", CVSS: "4.4 (Medium)"} you would have:

acceptance: "9/123"
acceptance_rate: "7%"
CVSS: "4.4 (Medium)"

as other key/value pairs in your bib entry, and these values would be retrieved in order and rendered just below the regular ones. Of course this way it wouldn't work for using the same color as the conference, but I believe the color part is some specific solution for your case, so maybe it is not fit for the template code.

Now, I agree that another good solution is to add additional_info as a field in the bib entry with support for markdown/html inside, and just render it with markdownify. Which solution do you think is best @alshedivat?

[CheariX]

I experimented with various options and made several observations:

1. Jekyll-Scholar interprets additional_info={acceptance: "9/123", acceptance_rate: "7%", CVSS: "4.4 (Medium)"} as a plain string, not JSON. Or perhaps I have made an error? In this case, we would need to implement additional steps to parse the key/value pairs.
2. Even if the key/value pairs were accessible, there must be some "hardcoded" assumptions:
   • For example, what is the separator between the previous entry and the first additional_info entry (dot, comma)?
   • What character do we use to separate key and value? Maybe there are cases where people want something else?
   • If we want it more flexible, more complex code would be needed.
3. Due to these reasons, I opted to treat additional_info as a string. Users can add data in any format they like, using markdown.
4. For more sophisticated scenarios, I introduced a hook file. This file is only created if it exists. For instance, this file could be used to handle other BibTeX fields, such as acceptance_rate. Additionally, it allows the use of CSS styles, as shown in my example with the venue styles.
   • The primary advantage of this hook approach is that future updates of al-folio would not result in any merge conflicts, since this hook file does not exist in the template repository. Users must create them individually.

Example:

I'd be happy to hear your feedback.

[alshedivat]

thanks for the discussion and updates. I support the overall approach of using markdownify instead of trying to parse a string into a key-value pairs and then custom-handle that.

[CheariX]

I apprecieate that you like it, @alshedivat
So I assume that this is ready to go?