Square Brackets vs Parentheses in Chicago-Author-Date

[coryschires]

Reposted from https://discourse.citationstyles.org/t/square-brackets-vs-parentheses-in-chicago-author-date/1637

Background

Chicago-Author-Date dictates that in-text cites should be placed inside parentheses (e.g. (Smith 2014)).

But (it seems?) there's also a lesser known requirement... If the in-text cite is placed within parentheses, then the in-text cite should be placed inside square brackets – not parentheses as you normally would:

Chicago Manual of Style 17th edition. Pages 902-906.

Chicago Manual of Style 16th edition

Problem / Questions

• As far as I can tell, the CSL spec / Citeproc doesn't cover this behavior. Is that correct?
• Assuming that's correct, how are people handling this requirement?
• Or maybe I'm misunderstanding something?

[bdarcus]

Thanks for this @coryschires!

As I said on discourse, I'd oddly enough never come across this.

I think an easy way to support this would be to add two new attributes to layout: something like inner-prefix and inner-suffix. Default values for those would be nil.

At least, that's my initial thought. Hopefully it's not more complicated than this.

[denismaier]

As on discourse:

I think that is a fairly common rule. You do this in German as well. (Basically like the double quotes-> single quotes flipping if you're in double quotes already.)

The problem here is that you’ll have to check for context – are we in parentheses already or not. (And: the surrounding parentheses will be part of the main text, not of the citation.) In a plain text system that might be possible, but I don’t know if that could work with ms-word etc.

So it's more an api question than for CSL proper. (The csl part should indeed be easy.)

[denismaier]

Also requested by APA 6th edition: https://guides.library.nymc.edu/c.php?g=567729&p=4609898

[bdarcus]

So we should figure this out. I've assigned this to everyone that might have some good ideas.

[denismaier]

We'll perhaps also need input from @dstillman @adomasven and @jgm.

[adam3smith]

Quick note without much time to contribute: This is very much not the first time this has come up. There's a long thread from 10+ years back involving several of us (Bruce, me, Frank): https://forums.zotero.org/discussion/comment/112694/#Comment_112694 I'm linking to Frank's comment announcing a citeproc-js solution for this & linking to a test (only seeing that test on the old bitbucket currently).

…

On Mon, Jun 1, 2020 at 4:24 PM Denis Maier ***@***.***> wrote: We'll perhaps also need input from @dstillman <https://github.com/dstillman> @adomasven <https://github.com/adomasven> and @jgm <https://github.com/jgm>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <https://github.com/citation-style-language/schema/issues/218#issuecomment-637082870>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA7PWQ2S3RX6EMD2PKVO5LRUQE7HANCNFSM4NQB6HNA> .

-- Sebastian Karcher, PhD www.sebastiankarcher.com

[bwiernik]

Yeah, I'm pretty sure I recall Frank coming up with a nice processor solution that flipped parentheses/brackets very nicely a while back.

[bwiernik]

@adam3smith My sense is that this is almost universally required? Does it need to be customizable?

[bdarcus]

So we think this is ideally added in a spec addition, and does not require style syntax changes?

[denismaier]

@bwiernik I would think so too.
Perhaps an attribute on cs:style to disable it nevertheless?
If it's indeed already there: shouldn't we formalize this?

[bdarcus]

@adam3smith My sense is that this is almost universally required? Does it need to be customizable?

I'm skeptical whether all, or even most, styles would require this, so maybe we need an option?

[denismaier]

I'd say most styles require this without even knowing as it's not really a citation style requirement. That's just good practice in copyediting.

[bdarcus]

I'm pretty sure I've never seen it in my field. Parentheses simply get suppressed within a citation.

Another question: we have two big examples, both author-date. Does that apply outside that class of style?

And related, any suggestion for an option name?

[denismaier]

This applies equally to note styles.

(However, browsing through the Zotero thread, I came across a remark by @adam3smith that UK typographic standards prefer parentheses within parentheses, i.e. no flipping to brackets.)

[denismaier]

Regarding the name for the option: normalize-nested-parentheses ?

[bdarcus]

Regarding the name for the option: normalize-nested-parentheses ?

Nice!

And presumably the value should not be a boolean, given the UK example you found?

Is it an option available on cs:style, cs:citation, and cs:bibliography?

And do we couple it with a normalize-nested-quotes? If not in the style, then certainly in the documentation?

[denismaier]

I think the analogy could be punctuation-in-quote. There are defaults per locale, but styles can change them.

[bwiernik]

I think boolean seems appropriate? It's either done or not it seems. In styles that discourage nested brackets at all, I think that falls to the user to write without them (e.g., it would likely product incorrect grammar to blindly replace with commas)

[bdarcus]

I think maybe we have been looking at this case differently. When I see this:

(see [Doe, 2018] for some on foo bar)

... I saw that entire content as a citation, with "see " as prefix, and "for some on foo bar" suffix.

Are we on the same page here?

[coryschires]

@bdarcus This is my same question – and I'm clarifying because I am trying to decide if I should solve this via Citeproc or using custom code in my application.

Based on the discussion above, I am assuming all text would need to be included as part of the in-text cite. Thus, (see [Doe, 2018] for some on foo bar) is all one cite with "see " as prefix and "for some on foo bar" suffix.

In order to provide a more realistic example, here's the sentence which initially sent me down this rabbit hole:

Algorithms that are currently used in the welfare sector include simple decision trees (in Sweden, for example, the so-called Trelleborg model, which has automated decisions on social benefit applications [Kaun and Velkova 2019]); sorting (for example, the sorting algorithm developed by the Austrian Employment Services that automatically sorts applicants into three different categories [Kayser-Bril 2019]); and matching as well as predictive algorithms (for example, a predictive score estimating the likelihood of child abuse in Denmark [Alfter 2018]).

Following the framework @bdarcus described, this snippet would include three in-text cites, each with a long prefix:

1. (in Sweden, for example, the so-called Trelleborg model, which has automated decisions on social benefit applications [Kaun and Velkova 2019])
2. (for example, the sorting algorithm developed by the Austrian Employment Services that automatically sorts applicants into three different categories [Kayser-Bril 2019])
3. (for example, a predictive score estimating the likelihood of child abuse in Denmark [Alfter 2018])

Assuming I understand this correctly, I don't think this behavior would meet my authors' expectations. I believe they would expect this text to include three in-text cites:

1. [Kaun and Velkova 2019]
2. [Kayser-Bril 2019]
3. [Alfter 2018]

For example, if I were making the in-text cites clickable in my UI, I believe they would want only the author name / year clickable – not the entire parenthetical string.

Furthermore, there may be edge cases – and maybe they'd be so rare it doesn't matter – where this behavior wouldn't work. For example,

(Here's an entire paragraph which is parenthetical. It includes a cite [@123]. And then a bunch more text ... And then an entirely different cite which is unrelated to the first [@456].)

---

The more I think about this problem, the more I think the desired behavior is outside the scope of what's possible using Citeproc – specifically because the ideal solution requires broader context about the text in which the cite is placed. As @fbennett noted when describing his solution:

This will not work for text controlled by the word processor, of course; the parens need to be in the affixes of a cite to make them "visible" to the processor.

So, assuming I understand this correctly, we're left with no other choice but to provide Citeproc adequate context by incorporating affixes. I agree this solution works for most cases, but it also feels like we're wandered away from the original requirement:

If the cite appears within parens, then use square brackets rather than parens.

So we end up with a rather roundabout way to implement what initially seems like a simple requirement.

All that said, I'm sure I have less expertise than most folks on this thread, so maybe I am misunderstanding. Also, I don't have a better idea, so 🤷

[bdarcus]

I'll take a closer look tomorrow, but your examples here are what I think @bwiernik was assuming; that the stuff in parenthesis is just part of the body text, and the citation has no affixes.

[bdarcus]

I think we really have two cases here; let me use the pandoc syntax (where the brackets designate the citation] to make clear:

1. author-date citation with affixes: [see @doe18 for some on foo bar]
2. author-date citation within a parenthetical statement: (for example, the sorting algorithm developed by the Austrian Employment Services that automatically sorts applicants into three different categories [@kayser19])

The example you posted from Chicago (15.28) is actually 1 @coryschires, and what I was assuming.

In that case, if switching to a note style, that output would be moved to a note.

But as I said above, the examples you subsequently posted are 2.

In that case, if switching to a note style, that output would stay in the main body.

I think the rule, however, designates the same output formatting in the end.

To me, 1 is easy to resolve by adding an attribute. But we need to allow configuration of whether it uses brackets, or parentheses, or (as is default in my field and in current CSL), nothing.

2 is more difficult, per @denismaier's point above: either the processor needs to be able to scan and modify text around a citation, or a user needs to be able to print a bare citation in text and manually add the brackets around it. I'm not even sure how to do that in the pandoc syntax, which does have the bare @doe19 command, but uses brackets to delineate citations.

Do we all agree this is an accurate statement of the problem?

If yes, what do we do about it?

It seems we could add one or two simple attributes that would require case 1 to be covered by all CSL (1.1) processors, but then what about case 2?

[denismaier]

My understanding is that we are talking about version 2.
I don't think version 1 is currently a problem at all:
[see @doe18 for some on foo bar] => that's a standard citation with a prefix and a suffix.

@coryschires's first example was actually "These processes have… in the United States (see, e.g., Haviland [2003, 767] on …). => that's a narrative citation in a parenthetical context. But I agree with @bdarcus that you can just omit the inner parentheses and use a standard citation with pre- and suffix here.

My understanding of where we stand:

1. We are talking about parentheses in a parenthetical context.
2. Dealing with those is difficult since citeprocs by themselves have no way to know anything about context.
   But:
3. @fbennett has come up with a workaround where the necessary context is included in affixes.

So, problem statement 2 becomes:
Prefix: "(for example, the sorting algorithm developed by the Austrian Employment Services that automatically sorts applicants into three different categories"
Suffix: ")"
citekey: kayser19

Now, the necessary context is there, citeproc-js will detect the parentheses in the affixes, and adapt inner parentheses accordingly.

And yeah that is a workaround, but probably not the most comfortable solution.

Concerning note styles: The problem here is that you'll often have analytical footnotes, narrative prose and references mixed. As you are already in a footnote you can't add the references in another footnote, but you'll have the reference in parentheses. Think of this:

"Parentheses within parentheses are really complicated.[^1]

[^1]: Most people agree on that matter, but there are some details that need to be sorted out. Some say X (D'Arcus, On Citation Styles [Miami: X Press 2020]), others say Y (Maier, On Parentheses [Bern: Y Press 2020]).

---

As I've indicated above, I think the main problem here are the limitations imposed by word processors.

We could, in theory, easily add a new property to citation objects in https://github.com/citation-style-language/schema/blob/2bbf44f8eb51f9ed5fa2cc84f319d8e4833a4174/csl-citation.json#L23
Perhaps something like "citation-context" : "standard" vs. "citation-context" : "in-parens". The question is just how users will select that value.

In a batch processing system like pandoc, org, etc., where you process the text as a whole. you might be able to determine this automatically. In Zotero that's currenly not an option, but you could imagine users selecting a checkbox "Citation inside parentheses."

[bdarcus]

My understanding is that we are talking about version 2.
I don't think version 1 is currently a problem at all:
[see @doe18 for some on foo bar] => that's a standard citation with a prefix and a suffix.

See the section 15.28 example @coryschires posted. I don't see how we support that now. The above, in this example, should be rendered as (see [Doe, 2018] for some on foo bar).

@coryschires's first example was actually "These processes have… in the United States (see, e.g., Haviland [2003, 767] on …). => that's a narrative citation in a parenthetical context. But I agree with @bdarcus that you can just omit the inner parentheses and use a standard citation with pre- and suffix here.

I edited my post to be more explicit that I was referring to his section 15.28 example; the one on the second page of that.

My understanding of where we stand:

1. We are talking about parentheses in a parenthetical context.

Can you reassess this given the above, just so we make sure we're on the same page?

[bdarcus]

Also, for this discussion, I want to avoid talking about a specific implementation and workarounds (hacks), and only what we can and should do with the CSL syntax and spec.

I think, based on my analysis, we need to cover my case 1, and leave space for implementations like pandoc to innovate on case 2.

[denismaier]

My understanding is that we are talking about version 2.
I don't think version 1 is currently a problem at all:
[see @doe18 for some on foo bar] => that's a standard citation with a prefix and a suffix.

See the section 15.28 example @coryschires posted. I don't see how we support that now. The above, in this example, should be rendered as (see [Doe, 2018] for some on foo bar).

I was just saying that [see @doe18 for some on foo bar] is just standard citation with a prefix and a suffix, and I don't think it is @coryschires's example. With pandoc you'll get: (see Doe 2018 for some on foo bar). There are no inner parentheses at all that need to be replaced with brackets.

The example in CMoS 15.28:

These processes have, in turn, affected the way many Latin Americans are treated in the United States (see, e.g. Haviland [2003, 767] on how US courts ...)

I'd understand this as follows:
We have an intext citation "Haviland (2003, 767)" that is itself in parentheses. That's why you change the parentheses to brackets.
(Of course, we also don't fully support the intext citation yet.)

Does that make sense?

[bdarcus]

Yes.

So then you are asserting that the Chicago (and presumably APA) rule ONLY applies to my case 2?

If that's really the case, then it seems maybe we can't support this at this time? Unless we want to formalize a "bare" citation command in the spec, and allow people to manually bracket them?

[coryschires]

Thanks for all the clarification! I think I'm more-or-less up to speed.

Overall, I'd like to +1 @bdarcus's suggestion:

I think, based on my analysis, we need to cover my case 1, and leave space for implementations like pandoc to innovate on case 2.

If Citeproc can figure it out automatically (i.e. case 1), then great. But, if Citeproc cannot determine the correct behavior because it lacks knowledge of the surrounding text (i.e. case 2), then let's give the processing systems a clean / conventional way to manage it (e.g. by setting a flag as suggested by @denismaier).

For what it's worth, this would work for my use case. If I'm understanding correctly, I would need to write a bit of code to determine if the cite is surrounded by parens. If yes, I would set the citation-context" : "in-parens" (or whatever y'all decide) and Citeproc would swap (or not swap) brackets as dictated by the CSL.

[bwiernik]

No, I don’t think this really applies to either of those cases at all.

[bwiernik]

This rule is generally not about putting parentheses/brackets around the “Author, Year” part of the parentheses, which as Bruce notes, would be extremely rare.

The case is for when there is a separate parenthetical comment inside of another parenthetical comment. So, for example:

(see Doe, 1986 for an example [note that this paper was later retracted])

Here, “see” is a prefix and “for an example [note that this paper was later retracted]” is a suffix. If the user entered the suffix with parentheses, those would be normalized to square brackets.

I think the only case that needs to be accommodated is when the user explicitly types parentheses/brackets into the affix fields—those would be normalized to alternate between parentheses and square brackets, including any brackets specified in the citation layout.

[bwiernik]

The code could be implemented by collecting all of parentheses and square brackets for the citation, including any specified as prefix or suffix of the citation layout, converting them to pairs of abstract bracket placeholders, then converting the placeholders back alternating between parentheses and square brackets. This is the same approach used for alternating between single and double quotation marks.

There isn’t a need for an in-parentheses attribute—this can all be handled by examining the bracket characters present in the citation.

If the surrounding body text has parentheses, that is beyond the scope of CSL—CSL would expect that such text would be entered into the prefix/suffix fields for the citation.

[bdarcus]

The code could be implemented by collecting all of parentheses and square brackets for the citation, including any specified as prefix or suffix of the citation layout, converting them to pairs of abstract bracket placeholders, then converting the placeholders back alternating between parentheses and square brackets. This is the same approach used for alternating between single and double quotation marks.

There isn’t a need for an in-parentheses attribute—this can all be handled by examining the bracket characters present in the citation.

If the surrounding body text has parentheses, that is beyond the scope of CSL—CSL would expect that such text would be entered into the prefix/suffix fields for the citation.

So if I understand correctly where we ended up, we add some language to the spec to couple with the quote "flip-flopping" and we're done?

And otherwise, this is out of scope for a CSL processor?

[denismaier]

This rule is generally not about putting parentheses/brackets around the “Author, Year” part of the parentheses, which as Bruce notes, would be extremely rare.

Well, but this is what was asked in the OP.

You're right of course that we are talking about a more general question. And, as said before, the mechanism you describe sounds promising.

@bdarcus Yes, it's probably a spec addition. And an attribute to disable the flipping mechanism (as proposed yesterday).

[bwiernik]

Yes, I think that's it.

Well, but this is what was asked in the OP.

I see. Frankly, that's a pretty silly structuring of that citation. Just use commas. But if a user really wanted that, I think they could accomplish it the spec changes we've described by entering it as two citations, one author-only and then one supress-author. In any event, that is a really niche case (e.g., even APA wouldn't do that--it would just use commas).

[denismaier]

The downside of this approach is that this requires users to enter enclosing parentheses in affixes, which might not be super comfortable. (But everything else will be out of the scope of CSL.)

That said, the general mechanism could be of course ported to a word macro or a scholastica post-processing script, for that matter. (Not related to CSL, but maybe a good idea anyway.)

[bwiernik]

In general, entering nested brackets isn't a great idea. This approach would at least not require users to manually manage their bracket flip-flopping.

[bdarcus]

This rule is generally not about putting parentheses/brackets around the “Author, Year” part of the parentheses, which as Bruce notes, would be extremely rare.

Well, but this is what was asked in the OP.

You're right of course that we are talking about a more general question. And, as said before, the mechanism you describe sounds promising.

@bdarcus Yes, it's probably a spec addition. And an attribute to disable the flipping mechanism (as proposed yesterday).

In that case, I'll remove this from the milestone, and I guess this is ready for a doc PR.

If someone does submit a PR, please simplify it as much as possible; ideally with a clear one or two sentence commit message.

[denismaier]

I'm not really following where we've ended up with this...
We've agreed that we'll just need a spec addition to describe the parens-to-brackets-flip-flop behavior, right?
But I think we'll also want @normalize-nested-parentheses as a localize option so that this behavior can be disabled in certain locales.

Is that correct?