Extension of disambiguate="true"

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:


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

Frank

  • @line 800-803 in
    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 © would be very difficult to handle
gracefully.

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