Biblatex custom fields, @incollection vs. @inbook or querying a variable value in CSL

[Quintus]

Dear all,

this is more of a question than as a bug report or feature request, but I would like the raise the issue nonetheless. Regretably, CSL does not have an equivalent to Biblatex's @incollection type, which I use quite heavily; both @incollection and @inbook are mapped to the CSL chapter, while I need to distinguish the two. In German law scientific literature, it is common to honour established scientists with books consisting of collected articles, which we call "Festschrift" (celebrating someone's typically higher-age birthday) or "Gedächtnisschrift" (when the book was collected at the occasion of the recipient's passing away). These books are cited significantly differently from other books with collected works like handbooks; for the former, I use @incollection while for the latter I use @inbook.

That being said, I have not found an ideal way to properly represent all metadata in Biblatex either. These celebrational collections are typically cited as “(article author), in: (type of collection) (last name of recipient), (publishing year), (first page of article)”, even though these books typically (not always) do have an actual booktitle (i.e. the booktitle is not cited). The type of collection is a journal-specific short term for "Festschrift" or "Gedächtnisschrift" -- the JuS journal shortens to "FS" resp. "GS", but some other journals use "Festschr."/"Gedächtnisschr." or write it out fully as "Festschrift"/"Gedächtnisschrift". I would need a CSL term for that. To my knowledge, this kind of work is not properly represented by any existing judicial CSL style either, so I am trying to adapt my personal CSL style to them for the moment.

Take this as an incomplete example:

@InCollection{bklehmann1995cpvr,
    author = {Michael Lehmann},
    title = {Das Urhebervertragsrecht der Softwareüberlassung},
    pages = {543-569},
    booktitle = {Urhebervertragsrecht},
    booksubtitle = {Festgabe für Gerhard Schricker zum 60. Geburtstag},
    year = {1995},
    editor = {Friedrich-Karl Beier and Horst-Peter Götting and Michael Lehmann and Rainer Moufang},
    publisher = {C.H. Beck},
    location = {München},
    langid = {german}
}

This thing should be cited in the JuS journal as “Lehmann, in: FS Schricker, 1995, 543". How should I proceed to get the required metadata into that entry? I see that CSL has a variable recipient which I could leverage in the CSL file, but there appears to be no corresponding Biblatex field for recipient. Biblatex however provides something called /custom fields/ (Biblatex manual § 2.2.4), which sounds like a good candidate; in this case, I could just use the namea custom field. For differenciating the two kinds of these works I could use the new type/genre mapping, which would at least allow me to specify one possible writing of the kind of work. This would result in the following entry (new fields at the end):

@InCollection{bklehmann1995cpvr,
    author = {Michael Lehmann},
    title = {Das Urhebervertragsrecht der Softwareüberlassung},
    pages = {543-569},
    booktitle = {Urhebervertragsrecht},
    booksubtitle = {Festgabe für Gerhard Schricker zum 60. Geburtstag},
    year = {1995},
    editor = {Friedrich-Karl Beier and Horst-Peter Götting and Michael Lehmann and Rainer Moufang},
    publisher = {C.H. Beck},
    location = {München},
    langid = {german},
        namea = {Gerhard Schricker},
        type = {Festschrift}
}

However, apart from the fact that I have no idea how I should access the namea custom field from within the CSL style file or map it into CSL's recipient variable, it falls short of allowing me to use the journal-specific variants of "Festschrift" (e.g. "FS" for the JuS journal). At least, I have not found a way in the CSL 1.0.1 specification to query the value of a text variable inside an if declaration. I would need something like

<choose>
    <if variable="type" value="Festschrift">
    </if>
    <else>
    </else>
</choose>

, but CSL does not provide that.

So instead, I thought I could use CSL's container-title-short variable, which at least alleviates for the problem that I cannot query namea from the CSL file. I can put shortjournal into the entry (as Biblatex for whatever reason does not have a bookshorttitle field) and it will show up in the CSL variable container-title-short:

@InCollection{bklehmann1995cpvr,
    author = {Michael Lehmann},
    title = {Das Urhebervertragsrecht der Softwareüberlassung},
    pages = {543-569},
    booktitle = {Urhebervertragsrecht},
    booksubtitle = {Festgabe für Gerhard Schricker zum 60. Geburtstag},
    year = {1995},
    editor = {Friedrich-Karl Beier and Horst-Peter Götting and Michael Lehmann and Rainer Moufang},
    publisher = {C.H. Beck},
    location = {München},
    langid = {german},
        shortjournal = {FS Schricker}
}

But that falls short of the requirements as well, because the CSL file has no possibility to find out whether the editors need to be cited or not. They are not to be cited for an @Incollection (Festschrift/Gedächtnisschrift), but they are to be cited if this work is an @Inbook (any other collective work). At that point, I gave up and wrote this ticket. Is there a way to query from the CSL XML if I am dealing with an @Incollection or an @inbook?

Or, any other ideas how I properly represent that work? As said, if it was a singular example, I would file it under @misc and deal with it somehow, but these kinds of works are frequent in the German judicial science, so I need to work it out properly.

-quintus

[bdarcus]

I'm not remembering @denismaier - have we discussed this case? If yes, did we resolve it?

[denismaier]

We haven't discussed that particular case. But, IIUC, this is equivalent to things like Chicago's distinction between normal chapters and untitled introductions, which have to be cited differently. We've discussed that here. @cormacrelf has proposed some way to add style specific schema enhancements, but I think I was the only one who was sympathetic to the idea.

Another idea that came up was to add content checking for certain fields, e.g. genre. I still need to fully digest what was discussed back then. but I think we settled on this: we'll introduce a new syntax for terms and a new test for equality. Once that is implemented the only missing piece will be a "Festschrift"-Term.

[andras-simonyi]

Well, it'd be trivial to implement most of the proposed solutions in citeproc-el, so if there is a consensus on how to handle this I might as well implement the proposal. As for the concrete problem, it seems to me that the most reasonable solution would be to treat genre similarly to type and allow testing for it together with having terms for (some of?) the allowed values. IIUC the current standard doesn't even make it possible to localize, e.g., Doctoral dissertation. (There might be a similar problem with publication state, BTW.) On the biblatex side we could just map something (namea?) to the CSL recipient field for Festschrifts.

[Quintus]

Just to be clear -- CSL already allows and citeproc.el in my tests handles well style-specific terms. I can use something like

<terms>
    <term name="celebcoll">Festschrift</term>
</terms>

in a style's locale section and can then access it with <text term="celebcoll"/> whereever needed. From that angle, I don't need much more, so I don't request to add a new term to CSL for Festschriften. Granting that would effectively mean that CSL tries to include a list of all journal-specific terms ever invented, which I do not think is feasable.

The journal-specific localisation of the term "Festschrift" is a secondary problem. While I would like it to be properly specifyable as a localisable term, I can live without it. I need to submit my writings in this abomination of a format that is DOCX anyway, so doing a search&replace after exporting from org-mode to ODT is possible for me. (I will then use Word to convert the ODT to DOCX).

The correct goal is letting people keep creating documents with the same reference library and data-entry conventions while upgrading to new releases of styles.

I sympathise with this one very much. I have a large collection of entries in my main .bib file and the more I can use from it without changing it, the better. That's why I try to encode as much metadata into the entries in a portable way as possible. The fact that we jurists use unusual citation styles has been problematic in this regard (not even Biblatex covers all my needs by default -- where's bookshorttitle?), so my situation currently is that I write both Biblatex and CSL styles myself to work with just my specific library of bibliography entries. I don't mind changing those styles (specifically CSL styles are really pleasant to write, compared to writing a Biblatex style, thank you all for that), but changing the Biblatex entries once they have entered my main .bib file is something I want to avoid as much as possible. While writing Biblatex styles is pretty complex, it's flexibility is great. That pays off specifically with the arch-enemy of all citation systems, German judicial commentaries, for which I use @commentary, an entry type unsupported by all styles but my personal ones. I have not even tried to extensively use those with CSL yet, so this is something that I will come back with later on. Let's focus on the problem at hand for now.

If there is a consensus on how to handle this I might as well implement the proposal.

I can live with whatever the CSL designers deem useful. I just need a way to distinguish these types of chapter from other chapter things. If that is by adding a new type matching @incollection to CSL, by mapping some Biblatex field to CSL's recipient, by querying the value of the type variable in a new kind of if statement in CSL, by allowing entirely style-specific schemas or by whatever other means is of no importance to me. The problem with the introduction chapters seems indeed to be similar to the issue I am facing here: a specific kind of chapter to be used differently. Again, that's why Biblatex provides both @Inbook and @Incollection, at least that's how I always thought.

On the biblatex side we could just map something (namea?) to the CSL recipient field for Festschrifts.

Note that Biblatex does not actually care for the entry names. In fact, you can write foobarlalala = {abc whatever} into an entry and Biblatex will simply ignore it (in fact, I use the entirely nonstandard field signature to record a reference number for books I have in my bookshelves). Since namea may be used differently depending on the entry, it might be worthwhile to just allow recipient as a key in the Biblatex parser and map that one to the CSL recipient variable. That way citeproc-el would support more than Biblatex, but I don't think it is an actual incompatibility with Biblatex since Biblatex simply does not have a recipient field or even something equivalent to it.

I suppose any change to CSL itself will take its time anyway. In the meantime, I would be grateful if citeproc-el could just map namea (or the non-biblatex recipient) to CSL's recipient variable as a name variable. It might come in handy in other places as well, given there is no other possibility to fill in the recipient variable from a Biblatex database anyway, so there is not much to lose here. In the CSL file I can then just query the presence of the recipient variable, and if it is there, I know it's a Festschrift and to whom it's dedicated. That's enough to build the citation properly (except for the localisation of the term "Festschrift", but see above for that).

-quintus

[denismaier]

Well, I think if you really want you can just do that yourself. IIUC, you'll need to adapt the mapping here: https://github.com/andras-simonyi/citeproc-el/blob/2857f9bb819d0d0a6e6ed91cc38b165e506bfc2e/citeproc-biblatex.el#L122

Add this to your init and see if it does what you want:

(defconst citeproc-blt--to-csl-names-alist
  '((author . author)
    (editor . editor)
    (bookauthor . container-author)
    (translator . translator)
    (recipient . recipient))
  "Alist mapping biblatex name fields to the corresponding CSL ones.")

[Quintus]

Well, I think if you really want you can just do that yourself. IIUC, you'll need to adapt the mapping here:

Thanks for the pointer -- you are in principle right with this. I settled for namea rather than recipient in order to maintain some pseudo-compatibility with Biblatex and then amended my CSL style to check recipient:

<choose>
    <!-- Festschrift/Gedächtnisschrift (@inbook) -->
    <if variable="recipient">
        <text variable="genre" suffix=" "/><!-- this is the 'type' field from Biblatex -->
        <names variable="recipient">
            <name form="short" delimiter="/" name-as-sort-order="all"/>
        </names>
    </if>
    <else>
        <!-- Handbuch o.ä. (@incollection) -->
        <names variable="editor" suffix=", ">
            <name delimiter="/" name-as-sort-order="all" sort-separator=", " form="short"/>
            <label form="short" prefix=" (" suffix=")"/>
        </names>
        <text variable="container-title" form="short" suffix=", "/>
    </else>
</choose>

Voilà. This resolves the problem for me for the moment, with the localisation of the "Festschrift" term being left as the search&replace workaround to be applied in Word at the final stage before submission.

However, given the -- marker on citeproc-blt--to-csl-names-alist: @andras-simonyi any chance you can turn this from an internal variable to a public one? Actually, being able to influence the Biblatex field -> CSL field mapping via user-facing options seems like a useful thing in general to me.

[andras-simonyi]

Sure, I can switch those internal constants to "public" variables if that is useful. FYI, I've looked into the code and I think it would require only adding a single line to implement "genre checking" along the lines of

<if genre="festschrift">

and I don't see any associated performance penalty either, so can go and add it if that would be helpful.

[Quintus]

Sure, I can switch those internal constants to "public" variables if that is useful.

For me, it certainly would be. This approach is compatible with official CSL and hence probably has more future than your alternate suggestion

FYI, I've looked into the code and I think it would require only adding a single line to implement "genre checking" along the lines of

<if genre="festschrift">

and I don't see any associated performance penalty either, so can go and add it if that would be helpful.

It would certainly make things work for me, but the result would be non-standard CSL. The resulting CSL file would not be usable with other CSL implementation than citeproc.el. Such a compatibility problem is bound to be problematic on the long run; such a construct should better be added to the CSL specification itself before it is implemented in citeproc.el.

[denismaier]

It would certainly make things work for me, but the result would be non-standard CSL. The resulting CSL file would not be usable with other CSL implementation than citeproc.el.

You probably know that there is also an extended CSL version csl-m tailored specifically for multilingual and legal demands. @cormacrelf originally planned to implement this also in his rust citeproc. One idea was to add support for extensions that can be enabled in a particular style. Think of version=1.0+genreTesting. Some of the features in csl-m will be added to the CSL specification in a future release.

[Quintus]

Actually I was not aware that there is such an extended version; I recall finding something called juris-m linked on the CSL homepage, but it turned out to be a complete application. Since I want to use Emacs I quickly dropped that one from my software selection (and in fact, did not return to CSL for quite a while). When I noticed citation support is to be merged into mainline org, I got interested again in CSL and here we are now.

With Emacs and vanilla CSL I have nearly everything I need by now and I do not really see the need to use an extended CSL version with no support in Emacs. After all, CSL itself does contain types like "legal_case" which do work just the way required.

Prompted by your suggestion, I took a look again and found the csl-m specification. It's too large for me to make a qualified judgment about whether it fits my needs in a glance. As explained, I am rather content with vanilla CSL except for a few details like the matter discussed here (which as we have seen can be resolved by simply making the Biblatex->CSL variable mapping non-internal in parts), so I do not feel convinced to thoroghly dive into csl-m at the moment. As for multilingual support, I don’t have that need; my articles are written in just one language, currently simply German.

But I will take a look on the csl-m specification at some point and maybe file some tickets here regarding it when I have digested it (specifically I will look at what csl-m has to say to the Festschrift problem described in this ticket). To the extend possible, I would however like to stick to vanilla CSL in order to not overwhelm Andras.

[denismaier]

Well, there are actually a lot of features that I'd love to have in CSL... Anyway, for this issue there's the genre extension. In csl-m that covers other use cases than the "Festschrift" issue, but the general mechanism could of course be extended to this question as well.

[andras-simonyi]

Sure, I can switch those internal constants to "public" variables if that is useful.

For me, it certainly would be.

Done, so I plan to close this issue soonish (tm).

[Quintus]

Thank you!

[Quintus]

For completeness, after a discussion with my professor, it turned out that the English literature equivalent for a Festschrift is rare, but does exist in form of a liber amicorum. This just as an FYI if one ever comes about this issue later.