Following situation:
The MHRA style currently prints only author names in subsequent notes,
adding title-short when disambiguate evaluates to true. So far that’s
working great.
Now, some materials - especially interviews and letters - often don’t have
titles, others - e.g. webpages - may have the same title and author.
I tried adding issued date with if disambiguate=“true” - but at least in
Zotero/citerproc-js that means that date and short title are printed
whenever the authors are the same, which, most of the time, is incorrect.
Twofold question:
- Is there a way I’m overlooking that would allow me to add the date only
if disambiguation by title fails? (obviously I can test for presence of a
title, but that still doesn’t help when titles are the same).
- Are the other citeproc implementations behaving the same way as
citeproc? Or are some evaluating the conditionals sequentially?
code example, where both the title-short and the date-disambiguate macro
start with
:
...
--
Sebastian Karcher
Ph.D. Candidate
Department of Political Science
Northwestern University
Following situation:
The MHRA style currently prints only author names in subsequent notes,
adding title-short when disambiguate evaluates to true. So far that’s
working great.
Now, some materials - especially interviews and letters - often don’t have
titles, others - e.g. webpages - may have the same title and author.
I tried adding issued date with if disambiguate=“true” - but at least in
Zotero/citerproc-js that means that date and short title are printed
whenever the authors are the same, which, most of the time, is incorrect.
Twofold question:
- Is there a way I’m overlooking that would allow me to add the date only
if disambiguation by title fails? (obviously I can test for presence of a
title, but that still doesn’t help when titles are the same).
- Are the other citeproc implementations behaving the same way as citeproc?
Or are some evaluating the conditionals sequentially?
I was wondering when this issue would come around. 
citeproc-js is currently coded as you describe: it’s all or nothing.
I’ve wondered about setting up a staged invocation, setting one node
at a time to “true” until the cite clears or disambiguation fails. It
would be a neat trick, since it could be done without changes to CSL.
So with Sebastian, I’ll ask: has anyone implemented
disambiguate=“true” in that way?
The ‘disambiguate’ conditional is not implemented at the moment in Papers.
I’ve implemented incremental application of disambiguate=“true” in
citeproc-js (release 1.0.451). There is a test for it here:
https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default
Frank
Sebastian Karcher <@Sebastian_Karcher> writes:
Following situation:
The MHRA style currently prints only author names in subsequent notes,
adding title-short when disambiguate evaluates to
true. So far that’s working great.
Now, some materials - especially interviews and letters - often don’t
have titles, others - e.g. webpages - may have the
same title and author.
I tried adding issued date with if disambiguate=“true” - but at least
in Zotero/citerproc-js that means that date and
short title are printed whenever the authors are the same, which, most
of the time, is incorrect. Twofold question:
- Is there a way I’m overlooking that would allow me to add the date
only if disambiguation by title fails? (obviously I
can test for presence of a title, but that still doesn’t help when
titles are the same).
No, but the specification is quite clear on this: if evaluating a
citation with disambiguate=“true” does not lead to disambiguation the
ambiguous citation is rendered as it stands.
Incremental application of the conditional may be added to the
specification even though I’m not sure I like Frank’s implementation and
the proposed test.
- Are the other citeproc implementations behaving the same way as
citeproc? Or are some evaluating the conditionals
sequentially?
The Haskell implementation only tries the conditional once.
Best,
Andrea
Frank Bennett <@Frank_Bennett> writes:
I’ve implemented incremental application of disambiguate=“true” in
citeproc-js (release 1.0.451). There is a test for it here:
https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default
Actually I’m not sure I like this approach because I find it a bit
confusing. If “disambiguate” is “true” then it should always evaluate to
“true” and so both the title and the edition should be printed. The
example is not confusing because all the disambiguate conditionals are
grouped together. When coded in macros their order of occurrence may be
more difficult to understand and predict, thus becoming a source of
possible bugs.
I understand that my perception may be due to different coding cultures
– Haskell is a purely functional language and the value of a variable
is not going to change depending on the context --, still I wanted to
share my perspective.
Andrea
Frank Bennett <@Frank_Bennett> writes:
I’ve implemented incremental application of disambiguate=“true” in
citeproc-js (release 1.0.451). There is a test for it here:
https://bitbucket.org/bdarcus/citeproc-test/src/tip/processor-tests/humans/disambiguate_IncrementalExtraText.txt?at=default
Actually I’m not sure I like this approach because I find it a bit
confusing. If “disambiguate” is “true” then it should always evaluate to
“true” and so both the title and the edition should be printed. The
example is not confusing because all the disambiguate conditionals are
grouped together. When coded in macros their order of occurrence may be
more difficult to understand and predict, thus becoming a source of
possible bugs.
I understand that my perception may be due to different coding cultures
– Haskell is a purely functional language and the value of a variable
is not going to change depending on the context --, still I wanted to
share my perspective.
Andrea
No, you’re right. This adds elements incrementally from the
first-occurring to the last (in rendering order), and it would be good
to have more control over the sequence. That would involve some
changes to the specification, but could be done.
Shall I move that test out of the suite, pending further discussion of
the approach? There’s no urgency, and it would be good to explore the
possibilities further.
I agree that relying on the rendering order for incremental disambiguation is not a great solution.
Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
<if disambiguate="true">
<text macro="disambiguate1" />
<text macro="disambiguate2" />
<text macro="disambiguate3" />
<text macro="disambiguate4" />
</if>
<else>
<text macro="normal" />
</else>
Charles
I agree that relying on the rendering order for incremental disambiguation is not a great solution.
Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
<if disambiguate="true">
<text macro="disambiguate1" />
<text macro="disambiguate2" />
<text macro="disambiguate3" />
<text macro="disambiguate4" />
</if>
<else>
<text macro="normal" />
</else>
Charles
In that case, how would you control the placement of the incremental
elements? Would the idea be for each one to encapsulate an entire
citation, separately constructed in the respective macros? (I might be
missing something but) if so, it seems like the style code might be
kind of tricky to maintain.
I agree that relying on the rendering order for incremental disambiguation is not a great solution.
Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
<if disambiguate="true">
<text macro="disambiguate1" />
<text macro="disambiguate2" />
<text macro="disambiguate3" />
<text macro="disambiguate4" />
</if>
<else>
<text macro="normal" />
</else>
Charles
In that case, how would you control the placement of the incremental
elements? Would the idea be for each one to encapsulate an entire
citation, separately constructed in the respective macros? (I might be
missing something but) if so, it seems like the style code might be
kind of tricky to maintain.
Yes, that’s what I meant by needing the construct to be quite high in the rendering tree. That would of course only be necessary for more complicated cases where ading one disambiguation somewhere in the rendering tree is not enough.
To be clear, I am not saying this is ideal, nor is it based on any insight in creating styles. I was just thinking out loud, and it might very well be more flexible disambiguation is needed too often for such a solution to be practical.
The other downside of this is that it becomes very hard to specify the behavior when the style contains multiple of that nature.
So probably not a very good idea
Charles
I agree that relying on the rendering order for incremental disambiguation is not a great solution.
Note that there is one situation where we have something similar, which is the element, that tries each child in order. In a way, that might be a saner solution, if not as flexible. For more complex situations, the would have to be quite high up in the rendering tree, and would look something like this:
<if disambiguate="true">
<text macro="disambiguate1" />
<text macro="disambiguate2" />
<text macro="disambiguate3" />
<text macro="disambiguate4" />
</if>
<else>
<text macro="normal" />
</else>
Charles
In that case, how would you control the placement of the incremental
elements? Would the idea be for each one to encapsulate an entire
citation, separately constructed in the respective macros? (I might be
missing something but) if so, it seems like the style code might be
kind of tricky to maintain.
Yes, that’s what I meant by needing the construct to be quite high in the rendering tree. That would of course only be necessary for more complicated cases where ading one disambiguation somewhere in the rendering tree is not enough.
To be clear, I am not saying this is ideal, nor is it based on any insight in creating styles. I was just thinking out loud, and it might very well be more flexible disambiguation is needed too often for such a solution to be practical.
The other downside of this is that it becomes very hard to specify the behavior when the style contains multiple of that nature.
So probably not a very good idea
Charles
The more ideas, the better!