Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Two citations in one note: expected behavior for position="ibid" #122

Closed
denismaier opened this issue Sep 9, 2020 · 18 comments
Closed

Two citations in one note: expected behavior for position="ibid" #122

denismaier opened this issue Sep 9, 2020 · 18 comments
Labels

Comments

@denismaier
Copy link
Member

Related to #121: What's the expected behavior if we have two citations in one footnote, both referring to the same source?

[1] @doeA. Bla bla bla, bla bla bla.. See also @doeA.
@bdarcus
Copy link
Member

bdarcus commented Sep 9, 2020 via email

@bdarcus
Copy link
Member

bdarcus commented Sep 9, 2020 via email

@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

From Chicago 15th edition:

It [ibid] must never be used if the preceding note contains more than one citation.

So, yes, position="ibid" and position="ibid-with-locator" should probably never activate when the previous citation includes multiple items (that might already be the case in citeproc-js? @fbennett). Instead, position="subsequent" is immediately used.

In the case where ibid is appropriate because the previous citation has only one item, I have occasionally seen examples like:

[1] Ibid. But see also John, Rebuttal, 2016.

I have, however, also seen styles explicitly forbid that, and instead require for clarity

[1] Smith. But see also John, Rebuttal, 2016.

Given that, even in styles using "Ibid", it would usually be acceptable to use the author name instead if it adds clarity, my suggestion would just be to say position is never ibid/ibid-with-locator when either citation includes more than one item. To do otherwise would make styles following the second example difficult to implement without other attributes to fine-tune. Alternatively, we could add a new value position="ibid-alone" to mean that case--"ibid and no other citations of affixes".

What do you think @adam3smith ?

See also #121 (comment)

@denismaier
Copy link
Member Author

Ok, but what about my example: both citations are in the same note.

Should that be:

[1] Doe, p23. Bla bla bla, bla bla bla.. See also Doe, p. 89.

Or:

[1] Doe, p23. Bla bla bla, bla bla bla.. See also ibid, p. 89.

@bwiernik bwiernik added the 1.0.2 label Nov 4, 2020
@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

Do you mean that "Doe" there is the same item, just with multiple comments/locators? We don't currently have a provision in CSL to allow the same item to be cited twice in one citation. I would generally expect such a citation to be handled with multiple locators or just as an affix:

[1] Doe, p23. Bla bla bla, bla bla bla.. See also p. 89.

@adam3smith
Copy link
Member

My view is that

[1] Ibid. But see also John, Rebuttal, 2016.

is generally fine and I'd avoid yet another option unless we have a clear sense of need. (I don't follow denismaier's example either)

@denismaier
Copy link
Member Author

denismaier commented Nov 4, 2020

My example is:
We have one footnote that contains two citations and some text in between. Both citations refer to the same item. As in:

\footnote{\cite[12]{doe}. Bla bla bla bla. See also \cite[23]{doe}.}

@bdarcus
Copy link
Member

bdarcus commented Nov 4, 2020 via email

@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

We don't really have a notion for that as a special case in CSL currently. Most CSL applications don't even allow that (e.g., it's not possible in Zotero or Mendeley).

My recommendation would be that the user should omit the second cite from the citation and just include a suffix or additional locator. I don't think we need to include any special treatment here. The current behavior in pandoc-citeproc and citeproc-js is to treat the second as position="ibid" or position="subsequent" depending on if there were intervening items within that citation.

If we adopted my proposal that position="ibid" only applies if citations have single-items, then it would be treated as position="subsequent". I think that that is fine.

@adam3smith
Copy link
Member

You can absolutely do this in Zotero simply by inserting two consecutive citations in the same footnote (just like Denis does in the markdown example) and I've just confirmed that this is currently treated as ibid.

@denismaier
Copy link
Member Author

You can absolutely do this in Zotero simply by inserting two consecutive citations in the same footnote (just like Denis does in the markdown example) and I've just confirmed that this is currently treated as ibid.

Was just about to upload a screenshot documenting this...

@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

Oh, I thought I recalled that Zotero wouldn't return an item twice in the search results in that case.

@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

Okay, so three options:

  1. Restriction position="ibid" to single-item citations on both sides, including this case. (my vote).
  2. Prohibit position="ibid" if the previous citation was multi-item, but allow it if the current citation is multi-item. That makes all of these forms possible if Jones 2010 is the previous citation:
    1. [2] Ibid. See also Smith, 2012.
    2. [2] Smith, 2012. See also Ibid.
      It also allows (on the first appears of Jones 2010):
    3. [2] Jones 2010, See also Ibid.

  1. Prohibit position="ibid" if the previous citation was multi-item. Also prohibit it if the current citation is multi-item, unless all of the references are to the same item.
    • That is, allow specifically @denismaier's example, while prohibiting the perhaps-more-ambiguous case of [2] Smith, 2012. See also Ibid.

@adam3smith
Copy link
Member

I think you're misunderstanding Denis's use case. This isn't the same item twice in the same citation, it's two citations to the same item which happen to be both in the same footnote. Footnote text behaves like any other text here.

Given that, and the fact that I think 2 (ii) is a real problem (given that citations can sort, so you can't easily say "the first item needs to be ibid"), I'd also vote for 1).
2(i) (which I think is a real use-case) can again be accomplished simply by using two citations.

@bdarcus
Copy link
Member

bdarcus commented Nov 4, 2020

I think you're misunderstanding Denis's use case. This isn't the same item twice in the same citation, it's two citations to the same item which happen to be both in the same footnote. Footnote text behaves like any other text here.

Yes, this is what I was thinking (my response at top was misunderstanding).

@bwiernik
Copy link
Member

bwiernik commented Nov 4, 2020

Okay. Do you agree @denismaier ?

@denismaier
Copy link
Member Author

Yep, @adam3smith's understanding of this case is what I've had in mind. Two citation which happen to be in one footnote. The current behaviour in Zotero/citeproc-js is that if position="ibid" tests true for the second citation. This also seems to conform to CMoS rules.

So, I guess this is ok as is. Not really a need to change anything here.

But the question if such a footnote might affect citations in the next footnote:

[1] @doeB. Bla bla bla, bla bla bla.. See also @doeA
[2] @doeA.

Here, the citation processor would need to know that footnote 1 contains two citations and some text, to prevent an "ibid" in footnote 2. Should be possible with pandoc, but I'm not sure if that is possible with a Zotero/Word-Combination. (But that's more for #121, anyway.)

@bwiernik
Copy link
Member

bwiernik commented Nov 5, 2020

I think that's outside of the scope of CSL. To properly handle ibid there, the user should enter both items into the same citation and use affixes for the commentary text, rather than directly inserting the citation into the footnote. There isn't any way that a processor could detect otherwise.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants