Closed sim642 closed 1 month ago
the link to the abstract
What link though? The html
field, which al-folio has, isn't standard in Bib(La)Tex. The url
field would be but for whatever reason al-folio has chosen to go its own way.
The doi
field is also standard, but very explicit about what it links to. url
/html
may be anything.
Right now, I have to manually change every entry for al-folio to change its doi
or url
field (which every BibTex exporter outputs) to html
to have any kind of link. Kind of unnecessary to reinvent the wheel here.
And nobody is forced to have two links to the same thing. You can do what you always have done: only use html
. Or you can change those to doi
instead (or have them work out of the box). Even when you import entries with both doi
and url
fields, you still only get a doi
link with this ("thanks" to al-folio ignoring url
).
And nobody is forced to have two links to the same thing. You can do what you always have done: only use
html
. Or you can change those todoi
instead (or have them work out of the box). Even when you import entries with bothdoi
andurl
fields, you still only get adoi
link with this ("thanks" to al-folio ignoringurl
).
There's no need to be passive agressive here. I don't use a BibTex exporter, I copy them straight from the source and adapt as needed, so my use of it is different from yours.
About the keys used, I agree that html
is not a very good choice, url
is better. But just so we don't break what is working for others, can you add to this PR the use of url
also? I mean, check if either url
or html
is defined, use url
as the main one and html
as a fallback.
I don't use a BibTex exporter, I copy them straight from the source and adapt as needed, so my use of it is different from yours.
I don't mean any special BibTex exporter, but even when copied directly from the source of major publishers like ACM the entry will have a doi
field already.
Also, al-folio users could already be usind the doi
field because some publication metric badges already use that.
But just so we don't break what is working for others, can you add to this PR the use of
url
also? I mean, check if eitherurl
orhtml
is defined, useurl
as the main one andhtml
as a fallback.
That would still break existing uses, when someone has defined html
(because it was the only option before), but they also kept url
(which was ignored by al-folio, but shown by the BIB button still) while having html
and url
be different. I can imagine people already using the HTML field and button to link to some HTML page for the paper, which isn't necessarily the publisher's (DOI) page, but their own website for the paper.
al-folio itself even covers the possibility of such pages being part of the same website, it an absolute URL: https://github.com/alshedivat/al-folio/blob/c20074c8cab8df2050350e2367482fdd5328a08e/_layouts/bib.liquid#L201-L207
So what do you suggest? Keep html as the main option, url as fallback?
So what do you suggest? Keep html as the main option, url as fallback?
That's a possibility, although maybe having a button named "HTML" for the url
field is also a bit odd. As in, why isn't the button then "URL", just like how every other button and field name matches up?
Could have them as two completely separate things and everyone can choose in their own bib file which they prefer. Changing to the html
field for al-folio always required manual attention, so it's not that much extra burden.
I will merge this PR. Can you open another issue to rename html
to url
?
Just out of curiosity, what would be the benefits of this? I mean, usually the papers I refer to have both the doi and the link to the abstract, and both take to the same url. Idk how this is for other research areas.