# Extension of disambiguate="true"

**URL:** <https://discourse.citationstyles.org/t/extension-of-disambiguate-true/695>\
**Category:** CSL Development\
**Created:** [July 23, 2009, 9:09pm UTC](https://discourse.citationstyles.org/t/extension-of-disambiguate-true/695 "2009-07-23T21:09:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [July 23, 2009, 9:09pm UTC](https://discourse.citationstyles.org/t/extension-of-disambiguate-true/695/1 "2009-07-23T21:09:59Z")

</div>

A problem with the disambiguate=“true” conditional has just been  
raised in the forums.[1] The issue turns out to be critical to many  
note styles, including Bluebook.

When evaluating the disambiguate= conditional, the current CSL  
processor in Zotero looks at the authors (creators?), and the year in  
“issued”. The new citeproc-js processor looks at the rendered and  
undecorated short form of the citation, which produces similar  
results. In both processors, disambiguate= will ordinarily be FALSE  
across a pool of cites by the same author, if they all have different  
years of publication. This leaves many note styles in the lurch, if  
they require the title to be added to subsequent references whenever  
the author (creator?) names match.

Some means of handling at least the two known use cases (current  
behaviour and names-only) is needed. The simplest thing would seem to  
be to let disambiguate= accept (real) variable names, so:

This would work, if the variables used for comparison are rendered in  
the form they would appear in a “subsequent” citation, without  
decorations.[2] If “true” is also recognized, the revised schema  
would be backward compatible.

If this is acceptable, I’ll submit an explanatory text for the schema  
for review, and add this change to the todo list in citeproc-js.

[1] Here’s the relevant forum thread:

> **[Disambiguate by adding title](https://forums.zotero.org/discussion/2688/disambiguate-by-adding-title/)**
>
> Hi,
> 
> I'm trying to edit the "Society for Biblical Literature" style (based on chicago) for the rules that my theological college uses.

  
[2] Rendering is needed, to catch cites which are ambiguous only when  
the et al. conditions are applied.

Frank

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [July 24, 2009, 11:12am UTC](https://discourse.citationstyles.org/t/extension-of-disambiguate-true/695/2 "2009-07-24T11:12:50Z")

</div>

> > - @line 800-803 in  
> > [XBib download | SourceForge.net](http://xbiblio.svn.sourceforge.net/viewvc/xbiblio/csl/schema/trunk/csl.rnc?view=markup:)  
> > “If text inside an block can be used to  
> > differentiate two otherwise identical citations, it will be added. If  
> > the citations remain identical after its addition, it will not be  
> > added.” I don’t understand how this works. Is this test available both  
> > in citation clusters as well as in  
> > bibliographies? And doesn’t the test compare all the citations,  
> > instead of pair-wise comparisons (“two otherwise identical  
> > citations”). It’s very well possible to have more than two citations  
> > that are the same, so I don’t understand the “two” here.
> 
> A problem with the disambiguate=“true” conditional has just been  
> raised in the forums.[1] The issue turns out to be critical to many  
> note styles, including Bluebook.
> 
> When evaluating the disambiguate= conditional, the current CSL  
> processor in Zotero looks at the authors (creators?), and the year in  
> “issued”. The new citeproc-js processor looks at the rendered and  
> undecorated short form of the citation, which produces similar  
> results. In both processors, disambiguate= will ordinarily be FALSE  
> across a pool of cites by the same author, if they all have different  
> years of publication. This leaves many note styles in the lurch, if  
> they require the title to be added to subsequent references whenever  
> the author (creator?) names match.
> 
> Some means of handling at least the two known use cases (current  
> behaviour and names-only) is needed. The simplest thing would seem to  
> be to let disambiguate= accept (real) variable names, so:
> 
> This would work, if the variables used for comparison are rendered in  
> the form they would appear in a “subsequent” citation, without  
> decorations.[2] If “true” is also recognized, the revised schema  
> would be backward compatible.
> 
> If this is acceptable, I’ll submit an explanatory text for the schema  
> for review, and add this change to the todo list in citeproc-js.

One further thought on this. Much as I hate to say it, I think it  
might be better to handle this through yet another option, such as:

The reason is that if the variables are stated as options to  
disambiguate=“…”, that opens the possibility of setting different  
variables on the attribute in different locations in the layout, which  
(a) shouldn’t ever be necessary, (b) could arise from oversight or  
typographical error, and (c) would be very difficult to handle  
gracefully.

---

<div class="post-metadata">

**Author:** ![Frank\_Bennett](https://yyz1.discourse-cdn.com/flex029/user_avatar/discourse.citationstyles.org/frank_bennett/32/198_2.png) [@Frank\_Bennett](https://discourse.citationstyles.org/u/Frank_Bennett)\
**Post date:** [July 24, 2009, 12:09pm UTC](https://discourse.citationstyles.org/t/extension-of-disambiguate-true/695/3 "2009-07-24T12:09:16Z")

</div>

Never mind this thread. I overlooked something in the target use case  
that makes this a complete non-issue. The disambiguate=“true” form  
covers the cases with no problem. Sorry for the extra list traffic.

Frank