Does your style say: "Omit the month for journals" (if you have an issue number)?

I'm fishing for info on something for a patch I'm proposing to the BibTeX exporter.

Do your citation style guidelines say (as Chicago does in CMS 17.161) that academic journals should be cited by Title, volume, and issue number. And specifically that the month should NOT be normally given EXCEPT for journals that use no issue numbers?

Many online periodical databases populate a full date field for journal articles. Zotero imports it, and (for example) Zotero's BibTeX exporter exports it. But if this field ends up in a BibTeX database most citation style engines (which is to say at any rate the one I use: biblatex-chicago-df) will put it to use, assuming that the user knows best and put it there for a reason! That's sort of the logic in BibTeX: only put in your database what you want to cite.

So I've patched the BibTeX exporter to pay attention to this and skip the "month" field in the case of a journal which also has an issue number.

But I'd be glad for feedback to enlarge my experience of citation styles. Does yours (whatever it is) omit the month from periodical citations where there is a proper volume and issue number? (And BibTeX users please comment if you don't want this to happen, if you need both the month and the issue number AND your BibTeX style handles this gracefully)

Thanks.
  • Zotero-generated BibTeX files are also used for data exchange & there are certainly cases where you'd want to preserve as much information about the resource as possible.

    The right place to fix this would seem to be in .bst style that you're using.
  • edited June 10, 2010
    JabRef and bibutils both copy the month over from imported RIS files.

    I tested all bst files on my system. The following do NOT export a month with my test data:achemso
    aer
    aertt
    agecon
    agu
    agu04
    agufull
    agufull04
    aipauth4-1
    aipauth4-1long
    ajae
    ametsoc
    amsalpha
    amsplain
    apalike
    apecon
    apsrevM
    apsrmp4-1
    apsrmpM
    asaetr
    ascelike
    biochem
    cc
    cc2
    classic
    dcbib
    ecca
    econometrica
    econometrica-fr
    ecta
    elsarticle-num
    elsarticle-num-names
    erae
    fr-mtc
    ijmart
    itaxpf
    jpe
    klunamed
    klunum
    ltugbib
    mslapa
    naturemag
    newapave
    oega
    regstud
    sageep
    siam
    tandfx
    thubib
    ussagus
    worlddev
    The following DO export the month:abbrv
    abbrvnat
    achicago
    acm
    acmtrans
    aiaa
    aipnum4-1
    aipnum4-1long
    alpha
    apsrev4-1
    apsrev4-1long
    apsrmp4-1long
    cje
    dtk
    elsarticle-harv
    en-mtc
    gatech-thesis
    hc-en
    hc-de
    ieeepes
    ieeetr
    IEEEtran
    IEEEtranM
    IEEEtranMN
    IEEEtranN
    IEEEtranS
    IEEEtranSA
    IEEEtranSN
    ier
    imac
    nddiss2e
    plain
    plainnat
    psuthesis
    savetrees
    spiebib
    thesnumb
    unsrt
    unsrtnat
    usmeg-a
    usmeg-n
    vancouver
    xplain
    Which of these do you use & is it possible to change them upstream?
  • which is to say at any rate the one I use: biblatex-chicago-df
    Do you mean biblatex-chicago-notes-df?
  • (Written before you posted the last two posts, but only posted now)
    The right place to fix this would seem to be in .bst style that you're using.
    I thought of that, but one problem seems that BibTeX styles tend to assume that the data you pass them in your database is an intentional indication of the output you want ---where edge cases are concerned.

    For example in my bibtex style, you're allowed to add the "pages" field to a @book entry if for some reason your 'book' (all of it I mean, not just the part you are citing) has a page range. You do that by including a "pages" field. But (following the principle of fullsome data export and make-it-round-tripable if we can) Zotero exports its "# of pages" field to BibTeX's "pages" field for @books. This mostly results in Not What I Want in citations, however helpful it is for pushing bibliographic data around.

    It's similar with 'months' in @articles. CMS says: "Neither month nor season is necessary (though it is not incorrect to include one or the other) when the issue number is given." (17.164). The author or publisher makes the choice on what to include based on their preference, convention, and how the periodical enumerates itself. In BibTeX (for better or worse), one way of enacting that choice is by manipulating the '.bib' file. If you want original publication information (1st German edition of Das Kapital, say), you put it in the .bib file. If you don't, you leave it out. Even the ambitions of biblatex don't extend to making those kinds of choices in the document. In Bruce D's grand vision of universal DOI's and shared databases, they'd better evolve to this, but in the meantime I have a thesis to do...

    I'm not proposing that Zotero itself go along with such a model (yikes!), just that, in the logic of BibTeX. there are decent reasons not to push the problem off to the .bst files and make them 'take any data and treat it all the same.'

    If I'm right that BibTeX style users have some reason to want to keep their styles the way they are, then my option is to develop a personal version of my style that accommodates Zotero's BibTeX output. This is not unthinkable in the general case. I suppose, but it's not that great either. For example, the style that I use is a very complex, well-developed and frequently updated implementation of Chicago-notes, using biblatex (biblatex-chicago-notes-df). It's a lot of clever code and its documentation runs to 51 printed pages. I don't relish the thought of keeping a personal version of that as biblatex evolves. I also want to minimize the hacks Zotero has to recommend to BibTeX users to make it all work---where possible. I'm suggesting it's possible here.

    Plus, for those reasons I suspect that in BibTeX files used for data exchange with BibTeX users, people don't include months for academic journals, or the "pages" field for books, except where they want them.

    I'd be glad to hear about your personal experience. I know you use Zotero and BibTeX. You said in another thread that you often use .bst files provided by publishers. What do you have to munge, if anything? Does your Zotero-produced BibTeX meet stock .bst styles with reasonable harmony?

    Until we have plugin that allows flexible production of BibTeX output from Zotero, maybe what we need are two (or three) BibTeX export styles: one whose principles are guided more by fullsome export and maximal round-tripping and another one or two whose principles are guided by 'Does Mostly What I Want' with existing BibTeX styles. I know the latter ones will still be an unhappy collection of compromises, and won't do what She wants if it does what He wants, etc. But it would be a step ahead from what seems to me like an impasse. The idea of BibTeX files as a data exchange format (which these days should be enough to make a man weep ;-) seems to get in the way of easy use of Zotero's BibTeX export in more than one case. Or?

    Stuff that has a reasonable case for being removed from such a DMWIW export includes: ISBNs and ISSNs; URL's and DOI's for print based resources; the "pages" field for @book item types, and the month field for @articles with an issue number. (All of those get added to my citations if they are there). I suspect that this collection of compromises would hit the mark closer than the present export for more than just me. But my experience with different bibtex styles and the use of BibTeX data files is limited. That's why I started this thread. To try to see if one particular field might be (sometimes) eliminated in our standard BibTeX export.

    Of course the other way to handle this is post-processing, which for a while I thought was the the perfect solution. But the two main scriptable post processing engines (bibtool and the new bibtexformat) don't handle UTF-8 bibtex data--- though the latter will soon. They' have a reasonably high technical threshold to get up and running.. And postprocessors add a step. I update my data all the time, going back and forth from web sources to my Zotero database to my .bib files and to my PDF latex output. A postprocessing step (particularly if that involved actually opening my file and making manual changes with e.g. JabRef) is a significant inconvenience.

    So hence my brewing patches, my proposal to add some of them to the stock BibTeX.js (or a slimmer DMWIW BibTeX exporter) and this thread to open the discussion up.

    A tome, I know, but I couldn't do it in less.
  • edited June 10, 2010
    Interesting tests. I suspect the results mean that some .bst styles do what mine does and let you influence the outcome by the data you pass in your .bib file, and some enforce a policy of 'no month mentioned when you have an issue #'. In either case it doesn't really tell us what their relationship to the style spec is---in cases where that's codified in some official place like the APA book or the CMS15. Some .bst files might have have taken the path of limiting flexibility for the sake of simplicity---or indeed to handle less regular input data. Others (like biblatex-chicago-notes-df, your're right, that's the one I use) might be explicitly allowing the full flexibility of their style spec (And Chicago notes is the height of human-crafted, all-edge-cases-treated-with-care flexible specificity).

    As to whether biblatex-chicago-notes-df could be modified, perhaps. The developer does a decent job of responding to requests, and arguably it would be a good idea for such a style to have a user option to 'cut flexibility marginally to handle less specially tailored inputs with relative success.' Be liberal about what you accept for input and all that. Yeah, I'll ask.

    But I'm only partly looking for a solution for my own case (I have what I want at the moment, since I hacked the BibTeX.js file to give it to me.) I'm trying to see if Zotero's BibTeX export can't be made easier for Joe LaTeX to pick up and use---today, even if going upstream or hacking his .bst isn't practical. Or he can't figure out Perl to use Munge::BibTeX (grin), or can't find the command line to compile bibtool on Windows. (The word 'cygwin' should not appear in our user docs.)

    What do you think of the suggestion that we should forget holding to a single catch-all BibTeX export in Zotero? I suggest that even a single other one would usefully advance the cause of 'being strict about what we output' since it would let us meet the requirements of different purposes differently. It wouldn't end the compromises necessary (as I say above) but I do see it as a way to do a few important compromises better. (For Joe's sake)
  • I thought of that, but one problem seems that BibTeX styles tend to assume that the data you pass them in your database is an intentional indication of the output you want ---where edge cases are concerned.
    That is true for some styles, but not all. And if other tools that are better tested and more popular with BibTeX users than Zotero don't cater to such cases, I don't know that we should. I happen to use styles that work fine for month (particularly for Elsevier journals), so was surprised to see this as an issue (things like url, etc. render in a lot more styles & some programs output this as something like 'opt_url' to prevent rendering. I've never seen something like 'opt_month', though).
    But (following the principle of fullsome data export and make-it-round-tripable if we can) Zotero exports its "# of pages" field to BibTeX's "pages" field for @books.
    I'd consider it to be a bug (based on a dubious Wikipedia article) & it should be fixed. See discussion at http://forums.zotero.org/discussion/10603/bibtex-import-book-with-field-pages/
    It's similar with 'months' in @articles. CMS says: "Neither month nor season is necessary (though it is not incorrect to include one or the other) when the issue number is given." (17.164).
    I'd say this is not so similar: unlike numPages/pages, Zotero is actually exporting valid data & it is your style file that is failing to adhere to the style manual.
    If I'm right that BibTeX style users have some reason to want to keep their styles the way they are
    Why would they wish to keep styles that didn't adhere to the style manuals they're named after?
    I'd be glad to hear about your personal experience....What do you have to munge, if anything? Does your Zotero-produced BibTeX meet stock .bst styles with reasonable harmony?
    It meets my needs reasonably. Removing fields is easy & you really do have to do it w/ most bibliographic software to meet the needs of some styles. I change citekeys (personal preference, not strictly needed), and sometimes (not always) remove urls/dois. I haven't documented everything I do, but I'll start doing this.
    Until we have plugin that allows flexible production of BibTeX output from Zotero, maybe what we need are two (or three) BibTeX export styles: one whose principles are guided more by fullsome export and maximal round-tripping and another one or two whose principles are guided by 'Does Mostly What I Want' with existing BibTeX styles.
    I (and some non-BibTeX using Zotero users) disagree strongly that there should be a lot of BibTeX configuration. I also don't think there should be multiple separate BibTeX export formats that ship with Zotero. See, e.g. http://flyosity.com/iphone/kill-the-settings-build-opinionated-software.php

    Perhaps you might modify the BibTeX CSL to suit your needs?
    To try to see if one particular field might be (sometimes) eliminated in our standard BibTeX export.
    Maybe. But I don't think the first candidate should be 'month'!
    A tome, I know, but I couldn't do it in less.
    I hope you don't mind receiving this somewhat extraordinary letter --- and indeed, I confess, its also quite a long one, because I've never learned to be brief --Donald Knuth
  • What do you think of the suggestion that we should forget holding to a single catch-all BibTeX export in Zotero?
    In case it was not clear: I disagree. Strongly. Having multiple user-installable CSL files would be fine with me.
  • While you can count me in as one of the non-BibTeX-using opponents of multiplying options for BibTeX.js, I'll reiterate my advice that the Zotero+BibTeX crowd look into building off of LyZ to make a Zotero-specific utility for the various hoops that Zotero+BibTeX users often finding themselves jumping through.
  • edited June 10, 2010
    I happen to use styles that work fine for month
    By this I assume you mean they ignore the month value if an issue number is given? And your style specs basically don't want the month do be included in those circumstances? I suspect this is true of academic styles more generally. Which makes the month field a safe bet to exclude in these circumstances---if you can stomach the thought of excluding perfectly good data for a higher good. There are a lot of styles in the list above which I suspect don't do the right thing with the month field (assuming that they include it when it's given to allow for flexibility, but are used where the prevailing convention would be to only use the issue number).

    I see your point about exporting the most data which fits within the spec, but I guess we don't see eye to eye on leaving out legitimate data for a 'higher good'.
    Why would they wish to keep styles that didn't adhere to the style manuals they're named after?
    Well they wouldn't if they contract the style specs. But when the BibTeX styles merely allow for the flexibility or ambiguity present in the specs, as mine does in this case? CMS doesn't prohibit the the inclusion of the month, only recommends against it.

    And what about ISBN/ISSN? Zotero exports those, it's legitimate data and the style spec allows it. But in my academic field no one would include them in a bibliography, still less a footnote. Still the .bst does what it thinks is the right thing by including it if I 'tell it to' (= if it's in my data).

    Including something like the ISSN is (you could say) the de facto BibTeX way of saying, 'let me see this in my citations' Especially for style specs which are flexible in what they permit and leave such decisions to authors and publishers.

    Which is perhaps one of the differences between BibTeX users (and between us?) Some styles simply specify more. Perhaps scientific styles tend in this direction? Others specify less and advise more Chicago certainly tends in this direction. I think especially about the problems of the latter.

    And there remains the question of the URL. It's legal Chicago, but most print humanities publications simply would not use it for other print resources. I'd be glad (again, unselfishly thinking of Joe LaTeX here) for Zotero to leave it out or rename it.
    some programs output this as something like 'opt_url' to prevent rendering
    That'd work, and my style would cheerfully ignore it. You'd probably have to write an input filter that would either take that or a 'url' and put it into Zotero's url field.
    I hope you don't mind receiving this somewhat extraordinary letter --- and indeed, I confess, its also quite a long one, because I've never learned to be brief --Donald Knuth
    Glad not to be alone.

    I just wrote to the maintainer of biblatex-chicago-notes-df to suggest user options for ignoring those fields. But that doesn't change my basic desire to make it easy for the user to omit them from their Zotero export.

    I really haven't found omitting fields as easy as you say. The problems are four.

    1) The older tools don't handle Unicode. the rest of my toolchain does. I like it. (It's also the 'opinionated' modern option).

    2) Simply removing a single field (ISBN) from all items is doable by a hundred scripting environments, but doing it conditionally based on item type or other fields takes a tool with BibTeX smarts. (removing URL's from non-@misc items and removing the month from @article items with a "number" field both count here. "pages" in @book entries counts until we get that fixed.)

    3) If there were a tool that would do both of the above (handle conditional field removals and do Unicode in a scriptable way)---and I really think there isn't---you'd have to learn it. I weakly insist that if we can avoid users having to do this, we should.

    4) The only tools that can do the trick are full-blown BibTeX managers like JabRef, which to my knowledge aren't scriptable. This is no problem if you have your database done, if it's in perfect shape and if you want to munge your data once. It's fun even. But if you're gathering, writing, fixing, citing in a circle, and you want your paper results at any one point to reflect the best state of the data you have, it's a lot of work.

    I do like the opinionated-software vibe, and I'm sympathetic to arguments based on those ideas. But I'm a pragmatist as well, and when you don't have the user's whole work-flow under your own software's scope, it's sometimes worth going for 'making easy things easy and hard things possible'.

    So I still do think we do the user a service by being upfront about BibTeX not being a univocal concept, but I'm sure there are ways to do that, and to interface with the diversity of BibTeX dialects and uses that we can both agree on: a Zotero extension or user installable BibTeX translators.

    But about BibTeX CSL files. My CSL is cursory, but aren't it's control structures (the 'if' conditionals, for example) a little weak for the kinds of moderately intricate transformations we're talking about? What about just multiple Javascript translators? Anyway a decent BibTeX export plugin (or an extension of LyZ) should make everyone happy. That way no one needs to see any options who isn't already desperate for them.
  • Which makes it a safe bet to exclude---if you can stomach the thought of excluding perfectly good data for a higher good.
    We shouldn't decide based on styles that don't work for you and do work for me. We can decide on the basis of what most other more popular (and, arguably, better) programs do. And they leave month in.
    And what about ISBN/ISSN?
    Because I'm aware of some software that treats them specially, I think those could actually be debatable. Month really does not seem to be, because we don't have any strong push to remove it from users other than you or based on what other programs are doing.
    1) The older tools don't handle Unicode
    Complete removal can be done by scripts/text editors, though
    but doing it conditionally based on item type or other fields takes a tool with BibTeX smarts.
    Since everyone else is putting out similar data, though, it should really be fixed by the BibTeX styles, themselves. There are plenty of BibTeX styles that get this right!
    3) If there were a tool that would do both of the above (handle conditional field removals and do Unicode in a scriptable way)---and I really think there isn't---you'd have to learn it. I weakly insist that if we can avoid users having to do this, we should.
    Meh. While I think BibTeX/LaTeX is (at least) the lesser of evils in academic publishing, they are used by a minority of Zotero uses. Such users should be expected to be able to learn and use those tools. Particularly when every other reference manager expects the same!
    4) The only tools that can do the trick are full-blown BibTeX managers like JabRef, which to my knowledge aren't scriptable.
    JabRef is somewhat scriptable. What does it do that you like? Because I don't think a feature is to "exclude the month".
    But about BibTeX CSL files. My CSL is cursory, but aren't it's control structures (the 'if' conditionals, for example) a little weak for the kinds of moderately intricate transformations we're talking about?
    Most changes you're talking about are ones of omission. CSL can handle that without a hitch.
    What about just multiple Javascript translators?
    If we had user-installable translators, then yes. But I think Zotero should ship with one-and-only-one.
    Anyway a decent BibTeX export plugin (or an extension of LyZ) should make everyone happy.
    I agree. But even then: I don't know what it'd look like or how many people would actually use it.
Sign In or Register to comment.