Proposal: add "volume-title" as a CSL variable

CSL Development
1

I’d like to repeat a proposal first made by adam3smith in Jan 2013 at
https://github.com/ajlyon/zotero-bits/issues/54, which apparently has
not been posted on a CSL list or issue tracker before.

The proposal is to add “volume-title” as a CSL variable, intended to
hold (a) the title of a single volume that is itself part of a
multi-volume monograph, or (b) the title of a special issue of a
journal.

Rationale: CMoS requires a distinction between the title of a single
volume (CSL: “volume-title”) and the title of a multi-volume monograph
(CSL: “title”, or “container-title” for book chapters etc.), and both
need to be distinguished from series (CSL: “collection-title”).

adam3smith’s original post follows:> http://forums.zotero.org/discussion/26476/helpfeature-request-individual-volumes-as-parts-of-multivolume-works/#Item_3

2

background for re-posting is here:
http://osdir.com/ml/general/2013-09/msg04463.html
I actually disagree with Bruce on the nature of the discussion on
zotero-bits: It has a specific tag for csl changes and everyone who writes
or helps to write the specs is active there. Before we make any spec
changes (and certainly before we introduce new variables) we’ll write them
up and post about them here so implementers can comment. We’d also likely
move things over to the CSL issue tracker once work on a new version of
specs begins (which isn’t currently the case). But until then, zotero-bits,
inspite of its name, seems like a perfectly apt place for such details.

3

But the fact remains, the zotero-bit discussion focuses on the needs
of zotero users. By definition, it does not include other communities.

That’s all I really meant to say.

Bruce

4

I would be more than happy to transfer ownership of the zotero-bits repo to
Zotero proper, to clean that bit of history up. It’s an accident of history
that the issue tracker ended up being the one on my personal repo.

5

Since zotero-bits has been entirely community-led so far (with
community = Zotero users), I don’t see the issue in having you as the
owner. Making it an repository of the “zotero” GitHub organization
might proof even more confusing (and if it were to be transferred, the
repository name should probably change to something more descriptive).
I’d say we keep things as they are, but retire zotero-bits once the
current issues have been dealt with.

Rintze

6

On Wednesday, 4 September 2013 13:00:47 UTC+2, Bruce D’Arcus wrote, on
https://groups.google.com/forum/#!topic/pandoc-discuss/-SajbqoPX8k:

Yeah, I’m saying that a journal is (should be) really a collection, as is a book series, a legal code, etc.

But let’s move this to the CSL venues.

I dont’t actually think so. Monographs and journals are conceptually
on the same level: they are the major independent bibliographic units,
most bibliographic conventions dictate that their titles (and only
their titles) are italicized, etc.

Thus, I do not see a problem in continuing to use “container-title”
for journal titles.

Some journals do include series information, but this is conceptually
very much unlike book series information: For journals, this is
typically of the form “New series”, or “2nd series”, and indicates a
subdivision of one journal, and appears immediately after the journal
title, and in databases sometimes even as part of the title. It seems
CSL does not have a variable for his kind of information yet. The CSL
variable “section” comes close, but not quite.

Upshot: I do not feel existing title variables (“title”,
“container-title”, “collection-title”) would need to be changed; it’s
only that one that is missing so far (“volume-title”) needs to be
added.

Variable names of course, could be reconsidered. Even “volume-title”
is not ideal since in the context of an article it would rather mean
“issue-title”, but for the sake of simplicity this could prabably be
accepted.

7

yeah, I’m with Nick here - using container-title for volume title is a
very uncomfortable fit.

8

I’m not at this point making any particular recommendation. All I’m
saying is that we need to step back and consider the use cases, and we
need to do that within the context of the existing design.

If we’re talking about multi-volumed books, we have: item (book),
volume (what is actually a collection of books), and optionally,
series (also a collection of books, and/or book volumes). So that’s
awkward, particularly if you consider possibility of edited books.

If we’re talking special journal issues, we have: item (article),
issue (what I’d say is a container), and journal (a collection). I
made a design decision, that may or may not have been conscious at the
time, to effectively through out the issue level in terms of its
mapping to the basic logical levels.

I don’t much like at first glance adding something quite so concrete
and orthogonal as “volume-title.”

9

So there are two parts to my proposal:

  1. A volume-title variable to be used for books. As I say in the original
    proposal, this needs to be distinct from title, container-title, and
    collection-title. It is analytically in line with “volume” - in other
    words, currently the only way we describe volumes of books is by their
    number, but it’s not uncommon for citation styles to also require their
    title.
  2. Using the same variable for the title of special issues. There, too, the
    only way we describe an individual item is via number(s) (the combination
    of issue and volume number) but for special issues, many citation styles
    require a title as a descriptor. Technically this is an issue title and not
    a volume-title, but it has the same logic. As for:

If we’re talking special journal issues, we have: item (article),
issue (what I’d say is a container), and journal (a collection).
but that’s not how we’re using these terms in CSL. The journal title has
always been mapped to “container-title” so the journal is the container not
a collection. (And as per Nick, that also makes sense given bibliographic
conventions - a journal and a monograph are at the same level
bibliographically. Their titles are italicized, they get assigned a single
call number in libraries etc.).

I’m not wedded to calling this volume title, but what we need is a title to
describe items that we currently only describe by numbers.

10

Fine, I’ll try to clarify a bit more:

To represent book chapters in multivolume monographs as required by
CMoS and others, four different kinds of title variables are needed:
title, (the proposed) volume-title, container-title, and
collection-title.

In the following example,

Diener, Ed. 2009. “Cross-Cultural Correlates of Life Satisfaction and

Self-Esteem.” In Culture and Well-being, Vol. 2 of The Collected
Works of Ed Diener, 71–92. Social Indicators Research Series.
Dordrecht: Springer.

“Cross-Cultural Correlates of Life Satisfaction and Self-Esteem” quite
clearly is the title (of the chapter); and “Social Indicators Research
Series” is the series title, i.e., in CSL, the collection-title. I
would argue that the title of the multivolume monograph, The
Collected Works of Ed Diener, is the container-title, and that for
the title of the single volume, Culture and Well-being, a new
variable, “volume-title” should be introduced.

Again, the name is not that important, but it should be clear that the
introduction of one additional CSL variable simply cannot be avoided.

If anyone thinks this is not the case, I’d like to ask them to point
out why not, and what solution they’d offer.

Now, if we agree that a new variable needs to be introduced (again, I
maintain that’s unavoidable), deliberations I’ve seen in this thread
on repurposing variables no longer make that much sense.

Of course, for a book, the existing three kinds of title variables are
sufficient: title for the single-volume title, container-title for the
title of the multivolume monograph, and collection-title for the
series title.

And, yes, in principle, for a journal article the existing three kinds
of title variables could also be repurposed somehow: title for the
title of the article, container-title for the title of the special
issue, and collection-title for the title of the journal – but I feel
this would only create confusion. I also feel (as I said before) that
journals and multivolume monographs are conceptually on the same level
and that their titles thus should both be “container-title”. Finally,
since the introduction of something like “volume-title” is necessary
anyway, I see no reason not to simply use this for the title of a
special issue, and leave container-title for the title of the journal,
as it has alwys been.

As to variable names, I can appreciate the idea of using abstract
terms. In this case, however, I still feel “volume-title” might be the
best solution. But for those who feel it should be more abstract: What
about “component-title”?

11

And, yes, in principle, for a journal article the existing three kinds
of title variables could also be repurposed somehow: title for the
title of the article, container-title for the title of the special
issue, and collection-title for the title of the journal – but I feel
this would only create confusion.

Putting aside the discussion whether repurposing variables is a good
idea, changing the use of existing variables would severely delay
implementation. It would be a backward incompatible change, since
practically all existing styles would have to be changed to use the
new mapping, requiring a “big” CSL update (i.e. 1.1), for which we
have no ETA.

As to variable names, I can appreciate the idea of using abstract
terms. In this case, however, I still feel “volume-title” might be the
best solution. But for those who feel it should be more abstract: What
about “component-title”?

I’m pretty convinced by Nick and Sebastian. I’m just wondering if it
would be preferable to introduce two new variables instead of one:
“volume-title” and “issue-title”, which would be analogous to the
number variables “volume” and “issue”. I don’t like the dual-purpose
“component-title”, since we currently don’t use the term “component”
anywhere in CSL, and it’s rather vague.

Rintze

12

is there any downside to having two variables? In terms of clarity, I think
Rintze is right that issue-title for journals and volume-title for books
makes more sense. The main reason we want to keep variables limited is so
that code is more modular, but issue titles and volume titles - while
conceptually quite similar I think - get used very differently so giving
them the same variable name wouldn’t help here.

The remaining question is whether there may be other item types the require
something similar like a volume or an issue title. I can’t think of
anything currently and I don’t think we have anything in our list of
proposed changes, but if there were, that would be the case for something
more abstract.

13

The other types of, um, types, where these issues could conceivably
show up are, and so we want to double-check, include:

legal documents (Frank?)
(perhaps) multimedia types like broadcasts, films, etc.

If all the cases related to these types are already covered, then
volume-title and issue-title may be the cleanest way to address this,
per Rintze’s point.

14

(this is slightly off-topic, but regardless of the outcome of this
discussion, the variable descriptions in the specification can
probably use some work. I didn’t spend too much time on these
descriptions, and many variables predate my involvement in the CSL
project. For some (like the “container” date variable and
"original-author" name variable) I couldn’t even come up with a
possible use case.)

Rintze