Hi,
I propose to get rid of “disambiguate-add-title”.
It is not used by any style so far (which means it is not necessary)
and it can be implemented with the condition, as the
MLA style does.
The problem with it is that it is a call for bug reports and
enhancement requests: it does not let you define any formatting or
quoting, and it is not possible to relay on (and thus inherit) the
formatting options of the names/year groups.
And indeed, MLA is not using “disambiguate-add-title”, but to add some formatting to the added title.
Cheers,
Andrea
Before we do that, can we clarify what disambiguate=true actually means?
And if we do this, then I presume we’d support the “date” example that
Elena posted using the same mechanism?
If, as I assume, yes, then how would one encode a style that uses both
"date" and “title” for disambiguation?
Bruce
I propose to get rid of “disambiguate-add-title”.
It is not used by any style so far (which means it is not necessary)
and it can be implemented with the condition, as
the
MLA style does.
The problem with it is that it is a call for bug reports and
enhancement requests: it does not let you define any formatting or
quoting, and it is not possible to relay on (and thus inherit) the
formatting options of the names/year groups.
And indeed, MLA is not using “disambiguate-add-title”, but to add some formatting to the added title.
Before we do that, can we clarify what disambiguate=true actually
means?
And if we do this, then I presume we’d support the “date” example that
Elena posted using the same mechanism?
Yes please.
If, as I assume, yes, then how would one encode a style that uses both
“date” and “title” for disambiguation?
Consecutive if statements? I.e., first evaluate, add date, then
evaluate again, add title if the citation is still the same:
<choose>
<if disambiguate="true">
<text macro="issued"/>
</if>
</choose>
<choose>
<if disambiguate="true">
<text macro="title"/>
</if>
</choose>
Also remember that this is not implemented in Zotero yet–it would be
great to know for sure if Simon plans to add this to Zotero.
Best,
Elena
And if we do this, then I presume we’d support the “date” example that
Elena posted using the same mechanism?
Yes please.
Sure!
If, as I assume, yes, then how would one encode a style that uses both
“date” and “title” for disambiguation?
Consecutive if statements? I.e., first evaluate, add date, then
evaluate again, add title if the citation is still the same:
<choose>
<if disambiguate="true">
<text macro="issued"/>
</if>
</choose>
<choose>
<if disambiguate="true">
<text macro="title"/>
</if>
</choose>
this is working here. But also this could be done:
this style:
http://gorgias.mine.nu/csl/disambig/disamb_titleAndDate.csl
is producing this output:
http://gorgias.mine.nu/csl/disambig/test_ifDis.html
Notice:
Caso, Same Author Different Editors Second, 2005; Caso, Same Author Different Editors First, 2005;
Rossato, Same Author and No Date First; Rossato, Same Author and No Date Second;
(the second group are citations to references without a date field set).
Andrea
This is how citeproc-hs implements disambiguation:
-
if there are disambiguation options citations are divided into 3
categories:
A. citations that can be disambiguated by adding names or
given-names;
B. citations that require a year suffix
C. citations that requires something more (because a date is not
present in the output or because “year-suffix” is missing).
-
then disambiguation options are checked:
-
if both “add-names” and “add-give-names” are present, names are
added till full disambiguation to citations of type A;
-
if only “add-names” or “add-given-names” are present only the
appropriate names are added to citation of type A.
-
then the “year-suffix” is checked: if present, year suffixes are
added to citation of type B. Year suffixes are calculated when
evaluating the bibliography. In order for a suffix to be added to a
citation/reference, two citations with the same
author/editor/translator and year must be present in the
bibliography;
-
if citations of type C are present, and the style has at least an
element, citations of type C. are re-evaluated
with a global “disambiguate” variable set to true, so that will evaluate to true. If this way the citation
output is modified it is substituted to the original output.
Does it sound correct? It is the best I could conceive, I think…
Andrea
ps: I’m still cleaning everything up (and I just pushed a patch
because, while writing this message, I found that citations of type B
should end up as citations of type C if ‘year-suffix’ is not present).
Before we do that, can we clarify what disambiguate=true actually means?
This is how citeproc-hs implements disambiguation:
Note that I was asking specifically about the disambiguate condition.
- if there are disambiguation options citations are divided into 3
categories:
A. citations that can be disambiguated by adding names or
given-names;
B. citations that require a year suffix
C. citations that requires something more (because a date is not
present in the output or because “year-suffix” is missing).
Title and date disambiguation is typically used in “author” style;
e.g. those that look like ‘(Doe)’ rather than ‘(Doe, 1999)’. That is
of course just a specific case of your more general explanation, but I
just wanted to be clear on the primary use case.
- then disambiguation options are checked:
-
if both “add-names” and “add-give-names” are present, names are
added till full disambiguation to citations of type A;
-
if only “add-names” or “add-given-names” are present only the
appropriate names are added to citation of type A.
-
then the “year-suffix” is checked: if present, year suffixes are
added to citation of type B. Year suffixes are calculated when
evaluating the bibliography. In order for a suffix to be added to a
citation/reference, two citations with the same
author/editor/translator and year must be present in the
bibliography;
-
if citations of type C are present, and the style has at least an
element, citations of type C. are re-evaluated
with a global “disambiguate” variable set to true, so that will evaluate to true. If this way the citation
output is modified it is substituted to the original output.
Does it sound correct? It is the best I could conceive, I think…
Yes, except I’m still unclear about the last one. As an example, the
substitute element contains an ordered list of substitutions. One
substitutes the first one that returns non-null. This seems similar,
but am not really clear what we’re saying on the processing.
ps: I’m still cleaning everything up (and I just pushed a patch
because, while writing this message, I found that citations of type B
should end up as citations of type C if ‘year-suffix’ is not present).
Right.
Bruce
Before we do that, can we clarify what disambiguate=true actually means?
This is how citeproc-hs implements disambiguation:
Note that I was asking specifically about the disambiguate condition.
Yes, sure. Actually I wrote this also to document the code (which has
no comments yet): this way I’ll know where to start reading when
trying to understand it…
Does it sound correct? It is the best I could conceive, I think…
Yes, except I’m still unclear about the last one. As an example, the
substitute element contains an ordered list of substitutions. One
substitutes the first one that returns non-null. This seems similar,
but am not really clear what we’re saying on the processing.
Take into account that we are talking about formatted citations:
substitutes will produce a list of names (with given-names, etc.). If
two citations share that list of names and given names, either
generated by the first variable or by a substitute, they will be
categorized as needing year suffix or, when ‘add-year-suffix’ is not
present, re-evaluation with if-disambiguate set to true.
Hope this clarifies the problem.
Andrea
It may just be my lack of clarity today, but I’m afraid it doesn’t. If
I have this in a style:
..
What does that condition do WRT to processing? Right now, we have this
explanation in the schema:
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.
That would seem (though I don’t think it’s very clear) to suggest that
the only way to achieve the example I was talking about previously
would be to do:
I do NOT think that this, for example, should correctly yield the
expected result:
So I think we need to clarify this.
While we’re at it, a related issue is the problem of formatting the
"et-al" term. That’s not possible ATM, but would be if we added the
ability to condition based on “et-al” being true,
Bruce
Hope this clarifies the problem.
It may just be my lack of clarity today, but I’m afraid it doesn’t. If
I have this in a style:
..
What does that condition do WRT to processing? Right now, we have this
explanation in the schema:
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.
At the present time my implementation will only re-evaluate the
citation. If it doesn’t change with re-evaluation there’s not other
way to disambiguate anyway: is the last resort.
That would seem (though I don’t think it’s very clear) to suggest that
the only way to achieve the example I was talking about previously
would be to do:
If title and date are substitute, yes, this is the only way.
I do NOT think that this, for example, should correctly yield the
expected result:
This will print both title and date when both are set.
While we’re at it, a related issue is the problem of formatting the
“et-al” term. That’s not possible ATM, but would be if we added the
ability to condition based on “et-al” being true,
I doo’t understand how, though. Do you mean that it should be the
style to provide the “el-al.” term with a within some <if
“et-al”=“true”> condition?
Andrea
Sounds good to me. I think we added this before the disambiguate
conditional, but it’s now obsolete.
Simon