gistfile1.txt

NEW

``disambiguate-add-year-suffix`` [Step (4)]
    If set to "true" ("false" is the default), an alphabetic year-suffix is
    added to ambiguous cites (e.g. "Doe 2007, Doe 2007" becomes "Doe 2007a, Doe
    2007b") and to their corresponding bibliographic entries. The assignment of
    the year-suffixes follows the order of the bibliographies entries, and
    additional letters are used once "z" is reached ("z", "aa", "ab", ..., "az",
    "ba", etc.). By default the year-suffix is appended to the cite, and to the
    first year rendered through ``cs:date`` in the bibliographic entry, but its
    location can be controlled by explicitly rendering the "year-suffix" variable
    using ``cs:text``. If "year-suffix" is rendered through ``cs:text`` in the
    scope of ``cs:citation``, it is suppressed for ``cs:bibliography``, unless
    it is also rendered through ``cs:text`` in the scope of ``cs:bibliography``,
    and vice versa.

OLD

``disambiguate-add-year-suffix`` [Step (4)]
    If set to "true" ("false" is the default), a year-suffix is added to
    ambiguous cites (e.g. "Doe 2007, Doe 2007" becomes "Doe 2007a, Doe 2007b").
    The placement of the year-suffix, by default appended to each cite, can be
    controlled by explictly rendering the "year-suffix" variable using
    ``cs:text``.

There's no rush, but if you can provide a test that illustrates the issue.

So then we don't have one?

We will if you provide one.

Not entirely done, but can you take a look at this and tell me if I have it basically right (there are no existing styles for the bibliography mode), and what you suggest naming it?

https://gist.github.com/1030700

Thanks. I've added the test to the suite, with a few fixes to the CSL and a few tweaks to the input data to align the names with the expected result. This one passes out of the box.

Great; thanks. Do you think whether or not it included citation output with et al shortening should have any impact on the suffix values? If yes, we might need another test.

All of the names in the input data are different, although the initials for families Doe, Jones and Smith are all the same. If the initialize-with attribute is removed from the cs:name node in cs:citation, the year suffixes will disappear from the output, despite the fact that the entries are ambiguous in the bibliography.

That result is due to the underlying assumption I stated above, that the bibliography entries contain enough information to identify each entry uniquely, and that cites contain less information. Removing initialize-with from the cs:citation name node would violate that expectation -- the cites would then contain more information than is available in the bibliography. That may seem at first blush to be a troublesome case, but it's one that we can safely ignore, since bibliographies and their companion cites are never set up that way in production.

I've added two variants, with more and with less information in the citations. The year suffixes applied differ in each case, which is the expected behavior.

As a side note, in a recent trawl through old correspondence, I noticed a comment by Simon, two years ago, that disambiguation queries were one of the most frequent topics raised on the forums. That's no longer the case -- queries are now rare, and invariably resolved with a link to the disambiguation section of the wiki on zotero.org. I take that as evidence that we have gotten this right.

All of the names in the input data are different, although the initials for families Doe, Jones and Smith are all the same. If the initialize-with attribute is removed from the cs:name node in cs:citation, the year suffixes will disappear from the output, despite the fact that the entries are ambiguous in the bibliography. That result is due to the underlying assumption I stated above, that the bibliography entries contain enough information to identify each entry uniquely, and that cites contain less information.

This is what still has me uneasy; i just have never taken the view that suffix behavior has anything to do with the details of the cites. It's certainly not how I coded my implementation. Admittedly, though, the behavior likely only gets exposed in rare circumstances. I'll take another read through Chicago tomorrow and see if it offers any insight. Would really like to see how the APA guide explains suffixes, but I don't own that.

APA: http://owl.english.purdue.edu/owl/resource/560/06/ (at "Two or More Works by the Same Author in the Same Year")

Well, but that description of the suffix is like mine; isn't it?

…

On Jun 16, 2011 11:49 PM, "rmzelle" < ***@***.***> wrote: APA: http://owl.english.purdue.edu/owl/resource/560/06/ (at "Two or More Works by the Same Author in the Same Year") ## Reply to this email directly or view it on GitHub: https://gist.github.com/1029888

This is what still has me uneasy; i just have never taken the view that suffix behavior has anything to do with the details of the cites.

In the absence of cites, year-suffixes are useless in bibliographies, even in cases where bibliographic entries would otherwise be identical, as they don't add any information. Their value is in establishing a unique and therefore unambiguous pointer/cite to a bibliographic entry.

In the absence of cites, year-suffixes are useless in bibliographies, even in cases where bibliographic entries would otherwise be identical, as they don't add any information. Their value is in establishing a unique and therefore unambiguous pointer/cite to a bibliographic entry.

I have the sneaking suspicion that this is more complicated than either of us initially assumed. I think it's possible that both of us are right. I should have a chance to look at the full APA guide today, but in looking again at Chicago, the language of the suffix description is the same the APA summary you linked to, and the same as I've been consistently saying: that the suffix is only a property of the bibliography list. If that's true, then there may be two different rules to create a suffix, and so consequently both of us are also wrong (your explanation does not work for APA and Chicago, and mine doesn't work for Elsevier, etc.). More later.

There is also a relevant APA snippet at http://owl.english.purdue.edu/owl/resource/560/03/, again under "Two or More Works by the Same Author in the Same Year"

In any case, I do suggest clarifying the proposed spec language by expanding the first sentence. E.g.:

If set to "true" ("false" is the default), applies to conditions where there are multiple items from the same author and year. Under these conditions, an alphabetic year-suffix is added to each of these bibliographic items, and to their corresponding cites (e.g. "Doe 2007, Doe 2007" becomes "Doe 2007a, Doe 2007b"). [insert exceptions, or further explanation]

+1

That's not precise enough. Year-suffixes can be required even when the names aren't the same. E.g. (Doe 2000a, b) for a style that doesn't do name disambiguation, and has to disambiguate papers, one by John and one by Jane Doe.

If that's true, then there may be two different rules to create a
suffix, and so consequently both of us are also wrong (your
explanation does not work for APA and Chicago, and mine doesn't work
for Elsevier, etc.).

There might be, but again, we haven't seen any examples that are not correctly handled under the existing specification. The APA, Chicago and Elsevier guides describe disambiguation in different language, but as they are editorial guides (rather than specification documents), none of them dictate a comprehensive set of mandatory rules, complete with a description of the logical sequence of operations needed for machine-driven disambiguation. The question should not be whether these guides can be read to require output that CSL is incapable of producing, but whether copy editors actually do read them in that way. It never hurts to gather more information about editorial processes, but at the moment we have zero evidence of that.

That's not precise enough. Year-suffixes can be required even when the names aren't the same. E.g (Doe 2000a, b) for a style that doesn't do name disambiguation, and has to disambiguate papers, one by John and one by Jane Doe.

True, but the examples are sensible. Perhaps Bruce would be willing to see the text amended to read "multiple cites to the same author and year"?

On Fri, Jun 17, 2011 at 11:08 PM, fbennett ***@***.*** wrote: > That's not precise enough. Year-suffixes can be required even when the names aren't the same. E.g (Doe 2000a, b) for a style that doesn't do name disambiguation, and has to disambiguate papers, one by John and one by Jane Doe.

Is this a hypothetical concern, or a real one? If a real one (and so there are style editors perverse enough to actually require this), then I think a description of these cases should be included in that placeholder I put at the end. I wasn't intending it to be all-encompassing.

True, but the examples are sensible. Perhaps Bruce would be willing to see the text amended to read "multiple cites to the same author and year"?

Does that really address Rintze's concern? Bruce

On Sat, Jun 18, 2011 at 3:59 AM, bdarcus reply@reply.github.com wrote:

On Fri, Jun 17, 2011 at 11:08 PM, fbennett ***@***.*** wrote: > > That's not precise enough. Year-suffixes can be required even when the names aren't the same. E.g (Doe 2000a, b) for a style that doesn't do name disambiguation, and has to disambiguate papers, one by John and one by Jane Doe. Is this a hypothetical concern, or a real one?

It's a real case, there are styles that work this way.

If a real one (and so there are style editors perverse enough to actually require this), then I think a description of these cases should be included in that placeholder I put at the end. I wasn't intending it to be all-encompassing. > True, but the examples are sensible. Perhaps Bruce would be willing to see the text amended to read "multiple cites to the same author and year"? Does that really address Rintze's concern?

I don't know. Rintze?

…

Bruce ## Reply to this email directly or view it on GitHub: https://gist.github.com/1029888

I'll have to think about it a bit more.

The description of "disambiguate-add-year-suffix" should only discuss the reason for disambiguation if it differs from the reason for the other disambiguation options. Any shared requirements that activate disambiguation should be discussed in the introduction of the disambiguation section of the spec.

Would it be correct to say that, for all disambiguation methods, except for "disambiguate-add-givenname" with "givenname-disambiguation-rule" set to "all-names", "all-names-with-initials", "primary-name", or "primary-name-with-initials", disambiguation is performed to create an unambiguous link between the cite and the target bibliographic entry?

Yes. In those four cases, adding initials or full given names is more aggressive than strictly necessary for resolving cite/bib ambiguities. If one were to be picky, it would be a little more accurate to say "disambiguation is performed only when needed to create an unambiguous link between the cite and the target bibliographic entry".

Yes. In those four cases, adding initials or full given names is more aggressive than strictly necessary for resolving cite/bib ambiguities. If one were to be picky, it would be a little more accurate to say "disambiguation is performed only when needed to create an unambiguous link between the cite and the target bibliographic entry".

+1 Picky is good in specification work.