Improve bst style file considering author input

[augustfly]

For now here is a list (otherwise forked into our repository).

• [x] Review @pkgw Yet Another "H" ApJ

[augustfly]

I've seen this a couple times in the wild recently. An advantage is that yahapj pulls elements of the BibTeX to build live links in the reference section of the PDF.

Adding this feature (reference section live linking) would bring our author PDF copy closer to the final production PDF, which:

• links the journal abbreviation to the DOI link
• links the Volume/Page to the ADS link

yahapj live links the Journal/Volume/Page to:

• the DOI link built from the doi page
• to a link built from archivePrefix:eprint fields

There are other ways to do this, including:

• http://cosmologist.info/utils/apj_hyperref.bst (trying to use ADS's bibtex features like the adsurl)
• http://ctan.org/tex-archive/macros/latex/contrib/doi (doi linking)
• http://ads.harvard.edu/pubs/bibtex/astroads.bst (adding [ADS] links at end of references using adsurl

Lastly we would need to look into styling options for this in hyperref, which we already support natively in AASTeX6.

[augustfly]

FFR: YAHAPJ does not format most @MISC bibtex types according to our preferred style. It also incorrectly resolves ASCL eprint ids to arXiv.

[augustfly]

This is a summary of version 6.1 (beta) discussions regarding YAHAPJ like functionality and production quality PDF reference linking.

1. This entire discussion is about bibtex based references, which are becoming a real fundamental unit in getting data, software and other eprint type object references correct. The presumed sources for bibtex includes: ADS (predominately), Zenodo, the CrossRef/DataCite APIs, etc.
2. Our approach is to overload @MISC bibtex types terribly, which is the source of all this trouble. Creating our own @DATA and/or @SOFTWARE types might be better, but then we head off into a world where these types are not well established (they are not supported in bibtex at all, but are in biblatex). No one I know mints bibtex with either @DATA or @SOFTWARE types, which means requiring these types is the same as requiring authors to hand edit their bibtex 100% of the time to use these objects in their paper. I don't think we want that. So lets try overloading @MISC until it breaks.
3. It may already have broken.
4. To recap, we
   • strongly prefer explicit publisher keys in either data or software bibtex and references (f1). This is to follow the Force11 software citation guidelines;
   • request explicit version keys for software even if that means disentangling the software title as encoded by the GitHub=> Zenodo workflow (f2). This is to follow the Force11 software citation guidelines;
   • prefer prefix style URIs (e.g., doi:10.555/55.55lol55) for eprint identifiers since it gives a more uniform appearance given there are many types of eprint identifiers other than DOIs (why are they special anyway?)
   • given the above req, these URIs should be anchor linked to the actual digital object resolution, which leads to everything that comes after this.
5. There are empty commas in @MISC formatted entries because most @MISC entries lack version and publisher keys. Since these are in fact optional (since we are overloading @MISC), we have to check that either version or publisher keys exist and if they do not then they should be excluded along with their comma. This is level 0 of the complexity we are adding to @MISC;
6. YAHAPJ is missing fields because it is doesn't understand what we want it to do with @MISC entries. yahapj has the nice advantage of making anchored links in the bibliography but it is currently tied to the doi key, or only understands archivePrefix=arXiv. For instance the ASCL anchored link is incorrect. This is because YAHAPJ uses the wrong URL resolution, assuming that all archivePrefix should be arXiv prefixes, when for archivePrefix=ascl the resolution URL should be http://ascl.net/ instead.
7. In all cases ADSNOTE keys should be ignored in bibtex. We could do something fancy with ADSURL but I think that is too domain specific.

8. What we do with URLs in bibtex, e.g.s, ADSURL or URL or DOI or etc, depends upon what we want from the style. Do we want to provide links in the bibliography? What do we want to do with multiple URLs? I propose first that we build a URL string for every entry that could have one. That URL string would be one of the following in cascading preference:

   case a) a DOI URL string, built from https://doi.org/{DOI_VALUE} case b) archivePrefix URL string, built from a resolution root and the {EPRINT_VALUE} (see logic below) case c) a URL string build from whatever is {URL_VALUE} but only if the above two options fail. case d) for now we should ignore ADSURLs.

9. These are two possible archivePrefix values and resolution URLs to include (but see future proofing below):

   case b.1) archivePrefix="arXiv" then resolution URL = http://arxiv.org/abs/ and the URL string = http://arxiv.org/abs/{EPRINT_VALUE} case b.2) archivePrefix="ascl" then resolution URL = http://ascl.net/ and the URL string = http://ascl.net/{EPRINT_VALUE}

10. The next question is if we anchor the resulting URL string or just append it to the current bibliographic entry. Anchoring the link could help clean up the appearance of duplicated material in the bibliography. If we anchor then the logic should be:

    case a) the text anchor should be either the "Journal, Volume, Page" text or the "doi:{DOI_VALUE}" text already in the bibliographic string; case b) the text anchor should be the {archivePrefix_VALUE}:{EPRINT_VALUE} string we already build for these entries; case c) if the above circumstances are not met then just append the {URL_VALUE} string to the end of the entry. case d) we are ignoring ADSURLs.

11. Future proofing. Note first that the official biblatex standard uses eprinttype instead of archivePrefix. A more complete list of eprinttype (aka archivePrefix types), and resolution URLs is given below. In every case the URL string can be built from RESOLUTION URL + EPRINT_VALUE.

Name	archivePrefix/eprinttype	resolution URL
NASA ADS	ads	http://adsabs.harvard.edu/abs/
arXiv	arxiv	http://arxiv.org/abs/
ASCL	ascl	http://ascl.net/
Google Books	googlebooks	http://books.google.com/books?id=
Handles	hdl	http://hdl.handle.net/
JSTOR	jstor	http://www.jstor.org/stable/
PubMed	pubmed	http://www.ncbi.nlm.nih.gov/pubmed/

f1: It is insufficient to rely upon semantic material encoded in the DOI to determine the publisher of record for a DOI.

f2: the GitHub=> Zenodo release mechanism encoded the version tag into the title and there is no explicit versioning in the Zenodo DOI minting. This has to change and be normalized. For now authors have to add such keys by hand.

[augustfly]

the identifiers.org prefix list is probably also very useful:

https://github.com/identifiers-org/prefix/blob/master/prefix.yaml

[augustfly]

Revert version tag documentation and bibtex style to include assume the presence of "v" in the bibtex tag rather than applying it as a bibtex built style.

This is preferred because we do not want to prescribe any versioning style, leaving it up to the author or bibtex provider to specify their bibtex format.

The aasjournal.bst fix is:

FUNCTION {bbl.version}
{ "v" }

to

FUNCTION {bbl.version}
{ "" }

[augustfly]

Norman Gray's urlbst package does some of the identifier hacking described in this discussion issue. https://www.ctan.org/pkg/urlbst