Upgrade StorageDoes 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.
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.
The right place to fix this would seem to be in .bst style that you're using.
I tested all bst files on my system. The following do NOT export a month with my test data:
achemsoThe following DO export the month: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
abbrvWhich of these do you use & is it possible to change them upstream?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
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.
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)
Perhaps you might modify the BibTeX CSL to suit your needs?Maybe. But I don't think the first candidate should be 'month'!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
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'. 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. 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. 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.