biblatex icon indicating copy to clipboard operation
biblatex copied to clipboard

Allow hassle-free disambiguation of title-year entries in author-date styles

Open alex-ball opened this issue 5 years ago • 5 comments

TLDR; In author-year styles, shouldn't extradate (or some replacement counter) disambiguate across whatever is in the label position and the year, not just the labelname and year, to cope with cases where titles are shown at the head of a reference?

Since #11 was closed, biblatex has had the ability to track when entries with the same title occur in the same year. According to the manual, this is what the labeltitleyear option and the labelyearextra counter are for. But consider the following (contrived) scenario:

@online{test1,
  author={Joe Bloggs},
  title={Test},
  date={2020-01-01},
  url={http://example.com/1}}
@online{test2,
  author={Joe Bloggs},
  title={Test},
  date={2020-03-01},
  url={http://example.com/2}}
@online{test3,
  title={Test},
  organization={Cyclopedia},
  date={2020-05-01},
  url={http://example.com/3}}
@online{test4,
  title={Test},
  organization={Cyclopedia},
  date={2020-12-31},
  url={http://example.com/4}}

Imagine with the third and fourth entries we are comparing how an entry in online encyclopedia changed over the course of a year; and the two URLs point to version snapshots.

If you were cite these four in a document...

\textcite{test1}. \textcite{test2}. \textcite{test3}. \textcite{test4}.

...even with labeltitleyear=true you'd get the following:

Bloggs (2020a). Bloggs (2020b). Test (2020). Test (2020).

Given that extradate is supposed to track labelname, one might try this:

\DeclareLabelname{%
  \field{shortauthor}
  \field{author}
  \field{shorteditor}
  \field{editor}
  \field{translator}
  \field{title}
}

but it doesn't work, presumably because title is a literal rather than a name field.

So to get proper disambiguation, you have to go through and replace all instances of \printfield{extradate}, including deep down in \mkdaterangefullextra and \mkdaterangetruncextra@i, and of course specify an appropriate field format.

From the discussion in the manual, I'd be tempted to replace it with this:

\iffieldundef{extradate}{\printfield{extratitleyear}}{\printfield{extradate}}

But the result is not entirely satisfactory since in this particular case labelyearextra disambiguates all four entries:

Bloggs (2020a). Bloggs (2020b). Test (2020c). Test (2020d).

To get a more intuitive result, one has to use labelalpha=true and \printfield{extraalpha} instead with a suitable label alpha template, like this:

\DeclareLabelalphaTemplate{
  \labelelement{
    \field{label}
    \field{labelname}
    \field{labeltitle}
  }
  \labelelement{
    \field{labelyear}
  }
}

Bloggs (2020a). Bloggs (2020b). Test (2020a). Test (2020b).

It would be great if there was an easier way to be able to use a suitably defined extraalpha instead of extradate (i.e. disambiguating across whatever is in the label position, instead of just labelname) in author-year entries.

alex-ball avatar Oct 19 '20 19:10 alex-ball

How about we just use labeltitle as a fallback if there is no labelname when generating extradate? This would have to be changed in biber plus some documentation changes. I have put this into biber DEV (2.19) to try. It should just work out of the box with your example now.

plk avatar Aug 19 '22 08:08 plk

I am in two minds about how useful it would be to allow this to be customisable. It would be relatively easy to introduce a macro to allow the user to determine the fallback chain for the field that is used with the date to determine extradate. So far, it's been hard-coded to labelname. The enhancement in DEV currently is to use hard-coded labelname and then labeltitle. I can't think of any real use case for something other that these but if you can, I'm open to just making this configurable with some sensible default.

plk avatar Aug 19 '22 12:08 plk

I am trying to think of cases where something other than a name or a title would be at the head of a reference. Things that come to mind are standard numbers – which should be unique and therefore not an issue – and descriptors or library names for manuscripts, both of which can be catered for by \DeclareLabeltitle and labeltitlefield.

alex-ball avatar Aug 19 '22 14:08 alex-ball

I guess if labelname is a name list and labeltitle is a literal field, then the only likely datatype unrepresented is the literal list (organization, publisher), but it's usual to expect users to put these as author if they want them at the head of the reference. Even if a hypothetical style always put the title at the head and fell back to a name (!), judicious use of the use<name> options would cater for that eventuality.

alex-ball avatar Aug 19 '22 14:08 alex-ball

Thinking about this some more, I think there may be use cases when people are using arbitrary bib lists (lists of bibliography data that are not really reference lists per se, which biblatex supports) and so I have generalised this into a user-facing macro since it's not very difficult to do while I'm looking at it. There is now a user-facing macro \DeclareExtradateContext' which declares a fallback list for what constitutes the extradate` context. The default is:

\DeclareExtradateContext{%
  \field{labelname}
  \field{labeltitle}
}

and is is available as a global or per-entrytype option.

Currently in biblatex dev 3.19 and biber dev 2.19.

plk avatar Aug 20 '22 14:08 plk