Support for the various biblatex title fields?
Bibliography format interconversion.
Brought to you by:
cdputnam
Menu
▾
▴
Dear citeproc-hs and bibutils authors/maintainers:
Do you have any idea how the various biblatex title fields could be supported by bibutils/citeproc-hs/pandoc?
For @book, @inbook, @collection, @incollection and similar types, biblatex supports the fields:
title, subtitle, titleaddon;
booktitle, booksubtitle, booktitleaddon;
maintitle, mainsubtitle, maintitleaddon.
For @article, @journal and related entry types:
journaltitle = journal, journalsubtitle;
issuetitle, issuesubtitle.
(see http://mirrors.ctan.org/macros/latex/contrib/biblatex/doc/biblatex.pdf)
One example of an @inbook entry where distinguishing title, booktitle, and maintitle obviously makes sense is:
@inbook{lear, Author = {Shakespeare, William}, Title = {King Lear}, Bookauthor = {Shakespeare, William}, Booktitle = {Tragedies}, Maintitle = {Collected Works}, Date = {2000}, Origdate = {1606}, Location = {The Publisher’s Location}, Publisher = {The Publisher}, Volume = {1}, Pages = {53-159}, }Presently, using pandoc 1.9.4.5, compiled with citeproc-hs 0.3.6, texmath 0.6.1.1, highlighting-kate 0.5.3.3, plus chicago-author-date.csl ("updated 2012-10-25") on Mac OS 10.7.5, only title and subtitle, plus booktitle and booksubtitle make it into the output, with separators between title/subtitle and booktitle/booksubtitle missing.
From what I read at http://forums.zotero.org, I gather that we must not expect any kind of support, not even for subtitle from there.
MODS however, according to http://sourceforge.net/p/bibutils/home/Working%20with%20MODS/, does at least support subtitles.
So, the question is: Is there any sensible way to accomodate all these title parts as distinct entities in some MODS schema which citeproc-hs could then process to generate something CSL styles can digest, i.e., joining, e.g., title, subtitle, and titleaddon, while at the same time adding appropriate separators, too (like "Title: Subtitle. Titleaddon.") -- or would it be better if bibutils did this conversion instead?
It is even less clear to me how "maintitle" could be handled. Please note that in addition to a maintitle ("The main title of a multi-volume book, such as Collected Works") an entry might also have a "series" field, so using any MODS equivalent of a series field for biblatex's "maintitle" would probably be a less than ideal solution.
Thank you for your time.
The biblatex title schemes always struck me as more than a little confusing, and this is why bibutils isn't really doing anything with them at the moment. But I'm glad you understand them and can weigh in on the issue.
In your "obvious" example, what does the 'Maintitle' refer to? A single volume, multiple volumes? And if it's multiple volumes, shouldn't we just treat it as a series? I guess that'd be my current bias, even if it does the wrong thing for a multivolume entity in a series (which probably is really rare). This might be a case where perfect is the enemy of good.
As for dealing with 'titleaddon', which even after reading the biblatex documentation still confuses me, we can't simply "add" stuff to MODS and still be compliant with the DTD and be generally useful to the community at large. Within titleInfo, we have
I'm very much against trying to leverage any subfields other than
Last edit: Chris Putnam 2012-12-12
Thank you for your response. (Btw, after "Within titleInfo, we have" I see a few blank lines. Something missing here?)
Now it'll be interesting how the citeproc author sees this ...
In the meantime, the idea of "--unifytitle" sounds like a huge step forward.
In fact, for me the current handling of subtitles has been the most annoying bit: If you have them in your biblatex data, they do even appear in pandoc's output, but there seems to be no way of getting any separator. So, getting title/subtitle + booktitle/booksubtitle right would already be a huge improvement.
Having a maintitle in addition indeed seems obvious to me: "King Lear" (title) is part of a volume "Tragedies" (booktitle) which is in turn part of "Collected Works" (maintitle). However, you're probably right that also having a series on top of all this is rather rare. Still, if possible, I'd keep maintitle and series apart. But if this simply can't be done, of course I'd accept anything that at least preserves the information.
As to the various titleaddon fields, these are supposed to hold additional information, as, e.g., in a Festschrift: "Title: Subtitle. In Honour of Dr. Strangelove." According to the biblatex manual, titleaddons are supposed to be typeset in a different font, i.e., for books etc., non-italic.
That's why I feel that they should not be treated like subtitles, even if a proper subtitle does not exist, and that if title+subtitle+titleaddon are joined, subtitles should always be preceded by a colon, and titleaddons by a full stop (even if there is no subtitle).
Some more information I found:
http://www.loc.gov/standards/mods/mods-changes-3-4.html introduces the concept of a “multipart monograph”: “A type of monographic resource issued in two or more parts (either simultaneously or successively) that is complete or intended to be completed within a finite number of parts (e.g., a dictionary in two volumes or three audiocassettes issued as a set).”
That's excactly the type of resource for which biblatex's maintitle, mainsubtitle, and maintitleaddon are supposed to be used.
This also helps clarifying the distinction between “maintitle” in the sense of “title of multipart monograph” and “series”: The former is “complete”, the latter open-ended (see also http://www.nlm.nih.gov/tsd/cataloging/sercat.html).
Is this of some help for identifying more precisely where such “maintitle”/“multipart monograph” information should go in the official MODS schema and in implementing it in bibutils? It would be much appreciated.
An additional, related, bug:
biblatex2xml converts the following biblatex file:
@inbook{Author-2012-Title, Address = {London}, Author = {Author, Andy}, Booktitle = {Title of the Individual Volume (field "booktitle")}, Pages = {15-78}, Edition = {7}, Maintitle = {Title of the Multivolume Work (field "maintitle")}, Publisher = {Macmillan}, Title = {Title of Chapter, or Part of Book (field "title")}, Year = {2012}, }to
Problem: The title of the multivolume work (biblatex field "maintitle") becomes "the" MODS title in place of the biblatex "title" field".
Also, I am astonished about the "
""s -- is it necessary to recode quotation marks here?Update on the "maintitle" issue:
The "Chicago Manual of Style", 16th ed., distinguishes titles of individual volumes, of multivolume works, and of series; see 14.121–14.127 ("Multivolume Works") and 14.128–14.32 ("Series"), in particular 14.130 ("Series or multivolume work?") and 14.131 ("Multivolume work within a series").
One more example that clearly shows the usefulness of such a distinction, and that an item might easily require all four of the biblatex fields title, booktitle, maintitle and series would be
Also, at CSL one seems to be open to the idea of implementing this; see http://forums.zotero.org/discussion/26476/helpfeature-request-individual-volumes-as-parts-of-multivolume-works/.
The remaining question is, then, how could MODS represent a maintitle, distinct from title, booktitle, and series?
Upon re-reading http://sourceforge.net/p/bibutils/home/Working%20with%20MODS/ I noticed that some bits seem to be missing (see “??”):
“These types of scenarios were more difficult for me to initially understand, but once I appreciated them, it shows how MODS really shines. Every MODS reference can also include a ??, which is another MODS reference and potentially other ??. The ?? and ?? refer to a larger collection that contains the reference. Thus it's possible to nest a chapter of a book in a series thusly:”
Still, what I take from this passage is that it seems quite straightforward to represent biblatex’s nested hierarchy of title/booktitle/maintitle/series in MODS. Some appropriate term for the level between “host” and "series", corresponding to biblatex's “maintitle”, could probably be found, I imagine.
I hope you have been making progress in this area: It would be very much appreciated. Though it would not make an immediate difference when working with pandoc since neither citeproc-hs nor csl are ready yet, I see the introduction of a (however preliminary) MODS schema as a prerequisite for convincing the other parties involved (citeproc-hs and csl) to start moving forward here.
Last edit: Nick Bart 2012-12-10
Thanks. Sourceforge was eating my XML tags.
I think proper handling of maintitle needs more thought from me. (I'm trying very hard to get version 4.16 finished up as it includes a number of nice bug fixes and a really important fix for RIS output that I broke in 4.15 due an attempt to abuse git in regression testing that ate commits.)
I can envision trying to introduce a maintitle as a special <relatedItem> element; however, this will break many, many assumptions that are currently in my MODS-handling code. This won't be 4.16 material.
My plan is for 4.16 to do titleaddons reasonably (I hesitate to say properly) and expansion of the effect of the current command line switch -nt, --nosplit-title.
Sounds great, thank you.
My suggestion as to
maintitlewas based on the information that MODS allows multiply nestedrelatedItems. There might, however be a different approach:http://wiki.dlib.indiana.edu/confluence/download/attachments/24288/DLFMODS_ImplementationGuidelines.pdf (which, b.t.w., looks like a very useful guide to MODS) has
This might work, too. Will think about it ...
As to title/subtitle/titleaddon and
--nosplit-title: Thank you for putting work into this, it’s much appreciated. Of course it’s work in progress, and in part a stopgap measure.With regard to pandoc, by rights, citeproc-hs should be processing title and subtitle properly itself (and titleaddon, if we had a MODS element to put it into). I did raise this issue on http://code.google.com/p/citeproc-hs/issues/ but haven’t seen any reaction there for weeks.
Your
--nosplit-titleoption at least promises a workable solution in the near future, so thank you again for that.A further thought:
To aid users dealing with one unfortunate bit of CSL’s design, biblatex2xml could copy the
titlefield (without subtitle or titleaddon) intoHowever, in case a biblatex
shorttitlefield is present, it would be even better to put this into MODS’s abbreviated title.Background:
CSL allows a single “title” field only (and, regrettably, CSL maintainers are unsympathetic towards the idea of adding, e.g., “subtitle”). As a result, workarounds are required. For bibliographic styles using notes and requiring shorter titles, CSL has “Short Title”, which usually just duplicates the title without subtitle but could also hold an even further abbreviated version of the title.
Example of usage, biblatex:
title = {A Very Long and Inaccurate History of England}, subtitle = {From the Earliest Times to the Present}, shorttitle = {History of England}Maybe an (almost) clean solution for biblatex’s
titleaddonfield:http://www.loc.gov/standards/mods/userguide/titleinfo.html states:
“
<namePart>[most probably a typo for<partName>] subelement includes all parts of a title not covered by the other subelements of<titleInfo>.”So, a biblatex -> MODS conversion of titles could be:
title-><titleInfo><title>subtitle-><titleInfo><subTitle>titleaddon -> <titleInfo><partName>For MODS -> biblatex this would mean putting everything found in any of the
<partName>(and<partNumber>) elements intotitleaddon.What do you think?
Last edit: Nick Bart 2012-12-15
A few further thoughts on “
maintitle” issues, and a suggestion:Some of the biblatex entries that bibutils presently cannot handle fully include either
maintitleorissuetitlefields. Such entry types aremaintitle(optionallymainsubtitleandmaintitleaddon)inbookincollection(with aliasinreference)inproceedingsbookcollection(with aliasreference)proceedingsissuetitle(optionallyissuesubtitle)articleperiodical(biblatex has also introduced the entry types
mvbook,mvcollection(with aliasmvreference), andmvproceedingsto indicate explicitly that these are what MODS calls multipart monographs. However, these create no additional difficulties here.)For both broad cases, monographic and periodical, we need to distinguish up to four different levels (each with a separate title, plus authors, editors, and other details associated with that title):
(Potentially, there could be more levels. biblatex, however, does not have more than four, and in CMoS I cannot find any example with more than four levels, either. )
A rather straightforward MODS schema that promises to be useful, both for general conversion and as an input for citeproc-hs, would probably look like this:
or
I also briefly considered whether
<relatedItem type="constituent">could be used to specify, e.g., an issue as part of a journal. However, from MODS experts I hear that “working in one direction only”, i.e., using either host or constituent, but not both within one<mods>element, is considered to be a good idea to avoid confusion.Now, I assume one could use either schemata with a fixed number of
<relatedItem type="host">levels, or flexible ones where certain levels (either individual volume, or multivolume, or issue, or series) could be omitted if not needed.I favour the second approach. This of course requires identifiers for the levels involved, and the best ones I can think of are the ones already used by bibutils:
<genre>elements. In particular, the MARC Genre Term List http://www.loc.gov/standards/valuelist/marcgt.html does cover almost every level required here:And since
<genre>elements may be repeated, I see no problems if other classification systems used<genre>as well, e.g.,<genre>poetry</genre>.Then the schemata would look like this:
or
As to
<issuance>, MODS 3.4 has added "single unit", "multipart monograph", "serial", and "integrating resource" to the existing "monographic" and "continuing", but for the present purpose this is still not fine-grained enough.Of course, editors will have to be associated with the right levels (in biblatex, e.g., if an
articleentry has issue and editor fields, the default assumption is that editor is the editor of the issue, neither of the article nor of the journal as a whole. If all oftitle,booktitle,maintitleare present, then editor is, as a default, the editor of the maintitle, etc.) In addition, when crossrefs are involved, some biblatex fields will need to be renamed appropriately (see biblatex manual, ver. 2.4, p. 281–2, “Default Inheritance Setup”).Do you think something along these lines could work?
Last edit: Nick Bart 2013-01-09