Status of support for NASA ADS

edited June 17, 2021
This discussion was created from comments split from: Support for Smithsonian/NASA ADS Astronomy Abstract Service.
  • Hi, I know this is an ancient thread, but what has been the status for the support of the NASA/ADS? I don't think this is supported feature at the moment.
  • Almost always better to start new threads rather than revive ancient ones. Zotero has supported NASA ADS for many years. The site changed recently and broke the translator, but we've just pushed a fix. Your Zotero Connector should auto-update within 24 hours, or you can update manually by clicking Update Translators in the Advanced pane of the Zotero Connector preferences.
  • Thank you for pointing that out. What I wondered is not about the extension Zotero Connector, but in the Zotero window itself, via "Add item(s) by identifier". It specifically says it accepts ISBN, DOI, PMID, or arXiv ID, but not ADS bibcode. If the extension could do that, I think the main application should also be able to do that. Judging from the thread I tried to revive, I thought that was once a feature.
  • No, that has never existed.

    Technical note: On ADS Bibcodes: https://ui.adsabs.harvard.edu/help/actions/bibcode -- should be possible to recognize these pretty reliably via regex and IIRC Abe is already using the API, so could be something to consider, although I don't think it's been requested much.
  • @hcho.astro, do you frequently have ADS bibcodes that you'd like to add to your library but don't have catalog links for? Is it common in astrophysics to cite ADS articles with only the bibcode, no link?

    We have to draw the line somewhere when it comes to what we support in "Add item(s) by identifier" - there are just too many domain-specific paper ID systems in the world - but if importing via bibcode is a common workflow, I'd be happy to support it.
  • We have to draw the line somewhere when it comes to what we support in "Add item(s) by identifier"
    I was wondering about that -- as long as identifiers are unique enough that they can be detected via regex, is that actually the case? and why? The cost of running through (say) 100 simple regular expressions for an identifier is pretty minimal, and add by identifier is a really useful way to batch import references.
  • Part of the issue is that lookup box behavior is hardwired in the client: https://github.com/zotero/zotero/blob/cdef45d6c3d4297ae0ab4d256410d478f5b26a69/chrome/content/zotero/lookup.js#L45

    (And separately in the translation server.)

    If you enter an ISBN in the box, it'll run each search translator that supports searching for ISBNs, so adding a new ISBN translator wouldn't require any change to client code. Adding a new identifier form altogether would.
  • edited June 23, 2021
    I don't have any particular objection to supporting new identifiers that 1) would see a decent level of usage and 2) can be reliably detected via regex so that they don't trigger false positives or unnecessary network requests (e.g., not like PMIDs, which are just integers).

    A new ISBN translator is actually sort of worse in that it's an additional network request for every ISBN that hasn't yet been found.
  • edited July 1, 2021
    Astronomers use Latex, Bibtex, and NASA ADS almost exclusively. The ADS Bibcodes are thus very commonly used because it is literally the Bibtex cite key for a particular publication. And the Bibcode is actually human-readable, as it is the year, journal, volume, and page -- thus it is not unheard of to memorize Bibcodes for particular publications that you cite often.

    Take this publication as an example:
    https://ui.adsabs.harvard.edu/abs/2007ASPC..382..495K/abstract

    When I'm typing my paper in Latex I would write "\cite{2007ASPC..382..495K}" and thus easily link the citation and bibliography in my Latex document from ADS giving the following entry in my Bibtex:

    "@INPROCEEDINGS{2007ASPC..382..495K,
    author = {{Kent}, B.~R.},
    title = "{Chapter 46: How to Use Cone Search Client Applications}",
    booktitle = {The National Virtual Observatory: Tools and Techniques for Astronomical Research},
    year = 2007,
    editor = {{Graham}, Matthew J. and {Fitzpatrick}, Michael J. and {McGlynn}, Thomas A.},
    series = {Astronomical Society of the Pacific Conference Series},
    volume = {382},
    month = jan,
    pages = {495},
    adsurl = {https://ui.adsabs.harvard.edu/abs/2007ASPC..382..495K},
    adsnote = {Provided by the SAO/NASA Astrophysics Data System}
    }
    "

    using tools such as adstex (https://github.com/yymao/adstex) that create the .bib file from the .tex file using just the ADS Bibcode.

    Therefore if Zotero could also support ADS Bibcodes it would make life easier for a lot of astronomers! Thank you.
  • @katiemmm: Sorry for not updating in this thread, but ADS Bibcode lookup has been added and will be available in the next beta (and next full release if you'd rather not use the beta, of course). I'm happy to hear that it'll make things easier for astronomers! I really hope it's helpful.
  • @katiemmm: This is available now in the latest Zotero beta.
  • Oh awesome, hooray! Thank you so much @AbeJellinek and @dstillman !
  • Another astronomer here - I think this update may have broken the way that Zotero interfaces with some extensions, specifically Better BibTeX. Not all astronomers use the ADS bibcodes as the citation keys in our references. Many (most?) of us use more typical lastnameYY formats, because who can remember all the bibcodes you'd want to?

    Disclaimer: I don't know exactly what changes were made in response to this thread. However in recent Zotero versions when I add a new reference from ADS with the Firefox connector, all entries are auto-populated with text in the "Extra" field. The extra text consists of two lines that list the ADS bibcode, for example:
    Citation Key: 1965ApJ...142..419P
    ADS Bibcode: 1965ApJ...142..419P
    from this paper: https://ui.adsabs.harvard.edu/abs/1965ApJ...142..419P

    The issue is that BBT uses that same "Citation Key: usertext" format to override the citation keys that it generates by default according to the user's preferences. Therefore in recent versions of Zotero you now have to delete that Citation Key line from the Extra field manually every time you add a new ADS reference. This seems not ideal - after all, the bibcode is already being added to Extra, so why add it twice? People that do use the bibcode for cite keys can still access them with BBT through the "ADS Bibcode:" line in Extra, while the rest of us won't have our default preferred cite key format overridden.

    To be concrete, my suggestion is that when importing from ADS, the Extra field should contain only the "ADS Bibcode: bibcode" line, and the "Citation Key: bibcode" line should be removed.

    Like I say, I don't know exactly what updates were made in response to this thread, so apologies if this is a red herring. But I think I've isolated the issue to be within Zotero itself, not BBT.
  • Yes, I think the analysis here is correct, as is, imo, the proposed remedy:
    To be concrete, my suggestion is that when importing from ADS, the Extra field should contain only the "ADS Bibcode: bibcode" line, and the "Citation Key: bibcode" line should be removed.
    As Zotero is planning for a Citekey field in the futre, I think there's virtually no scenario where the citekey should be imported from the web: In general people will either
    a) want it generated algorithmically and/or
    b) be able to set/override it manually
  • I think there's virtually no scenario where the citekey should be imported from the web
    Oh, OK. This was done on purpose, with the idea being that some astronomers might want to use a different citation key but that this would be a reasonable default.

    If you were an astronomer who wanted to use ADS Bibcodes when available and otherwise use a different citation key format, and this wasn't added, it seems like you would need BBT (or built-in functionality from Zotero for this) to know about the "ADS Bibcode" field and use that when available? But the alternative is that any citation key set by a translator would take precedence, with no good way for BBT/Zotero to decide whether to keep it, so I guess that's worse and justifies the removal…
  • I would assume BBT could be scripted to set the bibcode as cite key where it exists?
  • I would assume BBT could be scripted to set the bibcode as cite key where it exists?

    ^ Yes, this is exactly what I assumed could be done.
  • Yeah, I guess the best approach here is to remove the citation key from Extra (while keeping "ADS Bibcode") and leave it up to BBT. Thanks @jspilker for pointing out that using bibcodes as citekeys is less common than I thought.
  • We've pushed out this change. Your Zotero Connector should auto-update within 24 hours, or you can update manually by clicking Update Translators in the Advanced pane of the Zotero Connector preferences.
  • Thanks so much for this, very much appreciated!



    If any astros from the future find this thread, you can use Better Bibtex to swipe the ADS Bibcode from the Extra field and use that as your cite key. This assumes that the format in the Extra field remains as "ADS Bibcode: xxxxxx", but you can also alter it if things change in the future.

    Go to Zotero -> Preferences -> Better Bibtex -> Citation keys (tab), and in the Citation key format box, enter:
    [Extra:transliterate:select=3] | [auth:lower:alphanum][shortyear]

    To break that down:
    - the [Extra:transliterate:select=3] part will search the Extra field, remove any unsafe characters ('transliterate'), and return all words starting with the 3rd. This removes the first two words, "ADS Bibcode:", from the full string so only the bibcode itself is used for the citekey.
    - In case there is no text in the Extra field, the cite key will revert by default to lastnameYY, which is what the [auth:lower:alphanum][shortyear] produces.

    I'm sure there are edge cases here I haven't thought of, but hopefully this is enough to satisfy both the folks who want to use the bibcodes as citekeys and the rest of us too.
  • I didn't account for spaces in the key field; the current version of BBT would have picked up keys without spaces like [extra=ADSBibcode], the next version of BBT will also support [extra=ADS\ Bibcode]
Sign In or Register to comment.