BibTeX export for corporate authors (single name only)

I may be missing something as this is a fairly well-known BibTeX issue, but I'll ask anyway. I have the problem where a citation record is for a corporate/institutional author, such as "United Nations". As I understand it, standard practice to prevent this being parsed as firstname+lastname is to wrap the entry with double braces in the .bib file:

author = {{United Nations}}

The standard BibTeX export does not handle this, and no combination of placing those name elements in the firstname or lastname fields in Zotero resolves the problem.

Could I suggest that a simple clause be added to the doExport function from line 2042 (in current version, 2.1.9), to change the existing code:

if (creator.firstName) {
creatorString = creator.lastName + ", " + creator.firstName;
}
To simply add the double braces if no firstName is populated (forgive any crappy coding...):

if (creator.firstName) {
creatorString = creator.lastName + ", " + creator.firstName;
} else { // lastName only, assume corporate author
creatorString = "{" + creator.lastName + "}";
}

I've been manually modifying translators/BibTeX.js to do this for about a year and it's worked well.

Thanks.
  • The correct way to test for single-field authors (corporate authors), is to look for "fieldMode == true".

    But it looks like that logic is currently not present in BibTeX.js regardless. Perhaps our BibTeX experts in house can comment on whether the proposed change is worth making? It looks fine to me.
  • We discussed this before:
    http://forums.zotero.org/discussion/15095/
    If the single field is usually used for corporate authors & if people don't have a problem with the capitalization, I guess it is a reasonable thing to do.
  • Fixed in repository.
  • Not sure if anyone would see this, but I was just updating my slightly modified version of BibTeX.js (for LyZ export) and found that the "fieldMode == true" logic had been applied for corporate author.

    But it doesn't seem to actually work for my simple test cases (ie, using the latest update from early May 2012): corporate author comes out as "{Some Company}" rather than "{{Some Company}}".

    (Actually, in reality it would be "{{{Some} Company}}" because of the whitespace preservation elsewhere.)
  • @jwood - do you still have this issue with the newest bibtex export? It works fine for me for single field authors. Are you sure you have the author actually set to single field?
  • edited September 2, 2012
    I just tried it and the BibTeX export is still only using single braces:
    @misc{united_nations_kyoto_1998,
    title = {Kyoto Protocol to the United Nations Framework Convention on Climate Change},
    url = {http://unfccc.int/kyoto_protocol/items/2830.php},
    author = {United Nations},
    year = {1998},
    file = {kpeng.pdf:/Users/justin/Zotero/storage/D5JXTRCZ/kpeng.pdf:application/pdf}
    }

    author needs to be {{United Nations}} for this to be correct, so it doesn't seem to be working for me. Zotero 3.0.8 on ffox 15.0, on OS X Lion 10.7.4; BibTeX.js "lastUpdated": "2012-09-03 02:45:00".

    And yes, I'm very sure my corporate authors are entered in full only in the lastname field. Extract from a Zotero RDF export:

    <bib:authors>
    <rdf:Seq>
    <rdf:li>
    <foaf:Person>
    <foaf:surname>United Nations</foaf:surname>
    </foaf:Person>
    </rdf:li>
    </rdf:Seq>
    </bib:authors>

    If there's any testing I could do, please let me know.
  • edited September 2, 2012
    And yes, I'm very sure my corporate authors are entered in full only in the lastname field.
    I do believe that. But that differs from what you get if you click the icon to the right of the creator name so that it changes from two fields to a single field. The single field entry version gets braced, as expected, with the current BibTeX translator.
  • I do believe that. But that differs from what you get if you click the icon to the right of the creator name so that it changes from two fields to a single field. The single field entry version gets braced, as expected, with the current BibTeX translator.
    It surely does! /facepalm. I had no idea that function was there... Or rather, I think I did but hadn't put two and two together. Thanks heaps!
  • edited November 12, 2012
    (Actually, in reality it would be "{{{Some} Company}}" because of the whitespace preservation elsewhere.)
    The excess braces in "{{{Some} Company}}" are actually causing a problem when trying to use the exported bibtex file with biblatex/biber. The problem is that biblatex/biber does not work unless one deletes a pair of braces, i.e. using {{Some Company}}. See here (under "[UDPATE] SOLUTION of the problem") and here.
    It is my understanding that two sets of braces should be enough? In other words: Is there a reason for (not deleting the) excess braces on bibtex export?
  • I don't think there is a reason, no - it might just be a bit tricky to fix.
    Someone remind me why exactly we have the brackets around "Some"?
  • There isn't a good reason for "Some" to be braced. In this case, "{Some" is being braced because the case preservation code only looks to see that the first letter is not a CLOSING brace or whitespace. We should add an open brace as one of the characters that is not braced.

    That being said, extraneous bracing should be made to work in biber (it works just fine in bibtex).
  • Issued a pull request to not treat '{' as an initial character.

    This fixes it for many authors. It doesn't address the issue completely, but it does get around what I'd consider to be a bug (considering an initial brace a start-of-word character). So we get "{{Some Company}}"

    But a corporate author like "National DNA Database" will render as "{{National {DNA} Database}}".

    Not sure proper behavior here. Will ANY input that has ANY brace not need case preservation? Should we just check for initial/closing braces?
  • edited November 13, 2012
    Thanks noksagt. Three opening braces or rather two opening braces within the outer set of braces seem to be the only problem regarding biblatex according to my tests (i.e. '{Doe, John and {{Some} Company}}' will issue will cause biblatex to issue an error and stop. The biblatex issue "is mostly because biber does lots of tricky things with generating initials and this is a tradeoff with edge cases like this", according to Philip Kime, one of the authors of biblatex. So there seems to be a good reason why excess braces do not work with biblatex/biber. (Though your fix should make it work with biblatex now, as far as I understand).

    It's probably best though not to look to much at what works with biblatex/biber or not, but what is correct according to the standard or what works in most cases. I am not sure whether the bibtex standard defines how many braces are allowed, but it is my understanding that '{{National DNA Database}}' should render just the same as '{{National {DNA} Database}}'. Thus two pairs of braces are enough for all ends an purposes and any additional set is redundant!? So two pairs is the most robust solution.

    Regarding 'tricky to fix': Isn't it possible to add a line that cleans up and deletes the excess braces in the end?

    BTW is there a general reason why the 'Preview Post' does not work for me anymore. It just shows 'Preview' in big light grey letters, but not the text I added. Or is it just an problem on my side (e.g. a Firefox addon)?
  • it is my understanding that '{{National DNA Database}}' should render just the same as '{{National {DNA} Database}}'. Thus two pairs of braces are enough for all ends an purposes and any additional set is redundant!? So two pairs is the most robust solution.
    This is, more or less, true. The question is whether it is worth implementing a fix & addressing edge-cases (where escaped brackets are part of the title cases), when the BibTeX we emit is valid. One edge-case advantage of the current method is that it does easily allow the outer braces to be removed if people don't wish corporate authors to be initial-capped (e.g. "National DNA database").

    No idea why preview isn't working.
  • edited December 4, 2012
    @noksagt: Sorry, it took a while before I was able to test your fix. As far as I see the bibtex translator ("lastUpdated": "2012-11-24 03:25:00") still exports three pairs of braces for authors with all caps - e.g. {{{OECD}}}. This is redundant and gives an error in biblatex, as mentioned. So can you fix that, too?

    Regarding your last comment: I am not sure whether more than two sets of braces is valid or not. As far as I know there does not seem to be an explicit rule regarding this. In that case I would rather go with the more robust than the edge-case solution, in general.
    Having said that, my only concern currently is that the exported bibtex files work with biblatex, and according to my preliminary tests {{National {DNA} Database}} should do that.
  • edited December 4, 2012
    Contrary to what you say, multi-level bracing is not only allowed in 'bibtex', but (sometimes) explicitly encouraged. See:
    ftp://ftp.tex.ac.uk/tex-archive/biblio/bibtex/contrib/doc/btxFAQ.pdf
    http://tug.ctan.org/tex-archive/info/bibtex/tamethebeast/

    We do use multi-level bracing for TeX entity preservation (as is encouraged for 'bibtex' users) & this will apparently cause biblatex to fail occasionally. From my perspective, biblatex will need to be fixed, either way.

    Of course, we also use multi-level bracing in many cases where it is permitted, but probably not encouraged. We emit valid, though (as PLK correctly notes) messy bibtex. We should probably clean some of that up.

    I suspect we can avoid using the per-word case-preservation if the entire field has already been brace protected. But I want to think about it & point out why the issue is not as trivial as it might seem & also point out why brace reduction after-the-fact is not the correct approach.
  • @all is there any progress on this issue? for some reasons (e.g. multilingual bibliographies) I have to use biblatex and there is no other way for me. With for example {{{UNESCO}}} for corporate author fields, however, I still cannot use it!
    This hasn't been a problem until biber became obligatory for biblatex-chicago (for example).
    Probably I just didn't understand everything you folks said above, but is there no (temporary or permanent) fix for double brace protected corporate author fields to avoid further bracing all capital words? There is no good reason for this, is there? or a line cleaning up redundant triple braces...?
    If I only was able to do it myself... unfortunately I'm not...
    if someone could just give me the code that I could then paste into the bibtex.js and then you could take your time to decide whether this is a good idea for everyone or not...? :)
    any help would be much appreciated!
  • The BibLaTex export translator avoids triple brackets and everyone using biber/biblatex should be using that anyway, so this is solved for all practical purposes.
  • I think I found a way the to solve this issue. It works well for me for me and my BibLaTex. Just put the name of the institution inside the last-name-field in the zotero app using quotation marks. So you got for example : "Parliament of New Zealand", (first name)

    just in case anyone is still looking for a solution.
  • BBT should automatically double-brace if you use a single-part name.
  • edited August 3, 2020
    +1 to @ghost_trevor, putting quotations "" around the lastname worked like a charm. And to @emilianoeheyns point, it should be automatic. A bit surprised this is still an issue after the original post (9 years ago).
  • I'm confused what "the issue" is. Both Zotero BibTeX and Zotero's BibLaTeX exporter will export single-field authors protected with double braces, which is what the initial post was about.
    If they don't, you're likely entering corporate authors incorrectly, see the discussion above.

    (It's also the behavior of the Better BibTeX --BBT -- add-on written by emilianoeheyns, so when he says "should" he means "will, unless there's a bug" (https://github.com/retorquere/zotero-better-bibtex )

  • That's indeed what I meant to say.
Sign In or Register to comment.