schema
schema copied to clipboard
Collapse multiple child items into one parent item
I open this ticket mostly to elevate the issue described at https://github.com/andras-simonyi/citeproc-el/issues/96 to CSL proper.
Is your feature request related to a problem? Please describe.
I sometimes deal with books containing contributions from multiple authors. I want to write a CSL style which creates only one single bibliography entry for the book, while being able to cite individual entries seperately. For example, let us say there is a liber amicorum for John Doe, edited by William Shakespeare, which contains contributions in form of articles devoted to topics John Doe has concerned himself with over his expansive academic life. These contributions are written by different authors. If I now want to cite two of those articles in a footnote-based style, I want to be able to achieve this:
1. Someone Else, in: William Shakespeare (ed.), liber amicorum for John Doe, 1999, pp. 208-215 (211).
2. Peter Smith, in: Shakespeare (see N. 1), pp. 100-115 (104).
If there is a real bibliography at the end of the article, it should be possible to have only one single bibliographic entry for the liber amicorum:
Shakespeare, William (ed.). liber amicorum for John Doe, 1999. Cited as: Name, in: Shakespeare.
This is currently not possible with CSL, because it requires citations tracking one another.
Describe the solution you'd like
I would like to have a conditional expression in CSL that allows me to check whether the current item is part of a larger work which is only meant to be cited in full once. For instance, my first example might be written like this:
<choose>
<if collection="parent">
<choose>
<!-- First appearance of the parent being cited inline -->
<if position="first">
<names variable="editor">
<name delimiter="/" form="long"/>
<label form="short" prefix=" (" suffix=")"/>
</names>
<text variable="title" form="long" prefix=", "/>
<date variable="issued" date-parts="year" form="text" prefix=", "/>
</if>
<else>
<!-- Subsequent appearance of the parent being cited inline -->
<names variable="editor">
<name delimiter="/" form="short"/>
</names>
<text variable="first-reference-note-number" prefix=" (see N." suffix=")"/>
</else>
</choose>
</if>
<else-if collection="child">
<!-- Child item cited in footnote -->
<names variable="author" suffix=", in: ">
<name delimiter="/" form="short"/>
</names>
<text variable="collection-parent" suffix=", "/><!-- ← Renders content from above branch collection='parent' -->
<label variable="locator" form="short" suffix=" "/>
<text variable="page" prefix=" "/>
<text variable="locator" prefix=" (" suffix=")"/>
</else-if>
</choose>
New here is:
- New conditional
collection, which either holdsparentwhen the parent is being referenced from within another citation, orchildif this is the referencing entry. If it is a standalone item, i.e., neither parent or child, it holds "standalone". first-reference-note-numbernotices that it is in a nested citation and refers to the first mention of the nested citation, i.e., the parent.- New variable
collection-parent, which triggers the nested rendering of the parent item, i.e. sets thecollectionconditional toparent-reference.
My second example is more complicated. Writing it could look like this:
<citation>
<layout delimiter="; " suffix=".">
<choose>
<if type="chapter">
<choose>
<if collection="parent">
<text term="cited-as" prefix=". " suffix=": " font-style="italic"/>
<text term="cited-as-name" suffix=", in: "/>
<names variable="editor">
<name delimiter="/" form="short"/>
</names>
</if>
<else-if collection="child">
<names variable="author" suffix=", in: ">
<name delimiter="/" form="short"/>
</names>
<text variable="collection-parent" suffix=", "/><!-- ← Renders content from above branch collection='parent' -->
<label variable="locator" form="short" suffix=" "/>
<text variable="page" prefix=" "/>
<text variable="locator" prefix=" (" suffix=")"/>
</else-if>
</choose>
</if>
</choose>
</layout>
</citation>
<bibliography>
<layout>
<choose>
<if collection="child">
<!-- Skip and do not render at all -->
</if>
<else>
<choose>
<if type="chapter">
<names variable="editor">
<name delimiter="/" form="long"/>
<label form="short" prefix=" (" suffix=")"/>
</names>
<text variable="title" form="long" prefix=", "/>
<date variable="issued" date-parts="year" form="text" prefix=", "/>
<!-- The below should of course match what is formatted
in the footnotes... -->
<choose>
<if collection="parent">
<text term="cited-as" prefix=". " suffix=": " font-style="italic"/>
<text term="cited-as-name" suffix=", in: "/>
<names variable="editor">
<name delimiter="/" form="short"/>
</names>
</if>
</choose>
</if>
</choose>
</else>
</choose>
</layout>
</bibliography>
New here is:
- Again, the
collectionconditional. As shown, it should also be available in thebibliographysection. - Again, the
collection-parentvariable. It has the same function as in the earlier example. - Two new terms are introduced,
cited-as(English default: “Cited as“) andcited-as-name(English default: “Name”). The latter is a placeholder to be printed so the reader knows he has to insert an author name here. It might be useful to instead introduce a completely new element<cited-as/>instead of directly requiring term formatting as shown.
Finally, it should be mentioned that implementing this proposal requires changes to CSL-JSON as well, because there needs to be a way to denote which entries are parents and which are children. Biblatex has a simple crossref key that comes quite close to this, even if it is only actually meant for shortcutting. It might be possible to add a key parent to CSL-JSON, which would take a target key and would automatically designate the target as a parent and the source as a child.
Describe alternatives you've considered
There is a container tracking feature in CSL-M using new constructs track-containers, consolidate-containers, first-container-reference-note-number, position="container-subsequent", container-multiple, container-subsequent. I find the CSL-M spec on how they work highly unclear; please refer to the discussion in https://github.com/andras-simonyi/citeproc-el/issues/96 for details.
Even if it somehow was clear, there’s a simple reason for me not to use it. citeproc-el does not implement CSL-M. Additionally, I think this collapsing mechanism is something other styles may find useful as well; I do not think this is something inherently tied to legal citing.
Additional context
This is used for example in the citation styles of:
- Juristische Schulung Style Guide
- Die Öffentliche Verwaltung Style Guide
As much as I'd love to have a feature like this, we currently don't have the concept of "parent" and "child" items in CSL. Currently, the datamodel is entirely flat. Do you think the proposed solution would work even in that case?
As much as I'd love to have a feature like this, we currently don't have the concept of "parent" and "child" items in CSL. Currently, the datamodel is entirely flat. Do you think the proposed solution would work even in that case?
With a completely flat data model, it is difficult. One would have to guess which items could be children, which might work or might not work that well. A possible way out would be to construct a virtual parent entry automatically by looking at all items and noticing those which have identical editor/collection-title/date/etc. fields (better have the fields configurable for the user). If a certain global option is set – let’s call it collapse-collections, a CSL processor would honour that and act as outlined in the OP.
That’s off the top of my head. Guessing will always lead to false positives and negatives, but I cannot really judge how grave these deviations will be. There might me tolerably few. On the positive side, the guessing approach would free the user from creating a parent entry in his database and setting relationship fields manually.
I'm experimenting with a rewrite of CSL. That does have a more relational input model, so there the container could be represented unambiguously.
The actual configuration would likely just be a simple parameter (since that's the approach in that experiment).
Correct that this kind of pattern would likely only be seen in note-based styles?
Correct that this kind of pattern would likely only be seen in note-based styles?
It's probably the most common case, but I think I've seen something similar in author date styles already.
It's probably the most common case, but I think I've seen something similar in author date styles already.
I can see that.
It doesn't really matter in terms of implementation; just wondering.