Open ddbrierton opened 6 months ago
If I'm reading the biber-tool config right, even the ones I do use aren't right; from what I can gather, these name
fields are allowed on @movie
:
but that just seems wrong. @njbart?
Vanilla biblatex has no specific support for @video
at all (it's just an alias of @misc
).
The most popular candidates offering support are probably biblatex-chicago and biblatex-apa, albeit with very different approaches.
The OP's example is similar to biblatex-chicago, and if that is indeed the style the OP has in mind, I would use the biblatex-chicago manual (Version 2.3a, 26 ff. & 113 ff., with quite detailed explanations) and the package's sample .bib files as a guide.
In the case of biblatex-apa, check out its sample .bib files as well, since that's the only documentation there is.
As it happens my default style is indeed chicago-notes
, but obviously one must conform to whatever bibliographic style might be imposed from elsewhere. Currently chicago-notes
outputs this for the above entry:
I have no idea to what extent that actually conforms to what The Chicago Manual of Style says (and I can't find one single example now of a film being cited in any of my books to see what they do), but purely in terms of the information being printed it is not correct. Dave Johns, Hayley Squires, and Sharon Percy were not the scriptwriters of that film.
It's going to take me some time to go through the biblatex-chicago manual. I have so far parsed biber-tool.conf with the idea that I could programmatically determine what fields are valid for what entries, but if that's not complete for realistic use, I'll have to write out the rules myself.
@ddbrierton - Ok, so you're using biblatex-chicago-notes, most likely by putting the line:
\usepackage[notes,backend=biber]{biblatex-chicago}
in your document preamble, right?
What happens if you change
editora = {Laverty, Paul and Johns, Dave and Squires, Hayley and Percy, Sharon},
editoratype = {scriptwriter},
to
editora = {Laverty, Paul},
editoratype = {scriptwriter},
editorb = {Johns, Dave and Squires, Hayley and Percy, Sharon},
editorbtype = {none},
?
@njbart yes that is correct, and I believe that the change you have above would be correct. But I am not authoring my bib
file by hand, it is generated by this project from Zotero.
@retorquere I totally understand, and there is no urgency whatsoever.
I can make the change ahead of a more structural solution.
Does it matter whether it is
editora = {Laverty, Paul},
editoratype = {scriptwriter},
editorb = {Johns, Dave and Squires, Hayley and Percy, Sharon},
editorbtype = {none},
or
editora = {Johns, Dave and Squires, Hayley and Percy, Sharon},
editoratype = {none},
editorb = {Laverty, Paul},
editorbtype = {scriptwriter},
if it's not, it would be easier to generalize an authorX
mapping, because I could just dynamically grab a new one as needed as I map the creators.
@ddbrierton do you have an MWE for me that renders the entry as you want?
Apparently "none" is not correct, despite what the documentation for biblatex-chicago
says. I just tried both your above suggestions, @retorquere . In both cases "none" followed by the three names is actually printed out. In the first version above I get:
Ken Loach, director, “I, Daniel Blake”, scriptwriter Paul Laverty, none Dave Johns, Hayley Squires and Sharon Percy (Sixteen Films, Why Not Productions, Wild Bunch, 9th June 2017), Drama.
and in the second I get:
Ken Loach, director, “I, Daniel Blake”, none Dave Johns, Hayley Squires and Sharon Percy, scriptwriter Paul Laverty (Sixteen Films, Why Not Productions, Wild Bunch, 9th June 2017), Drama.
it does change the order, as editora
is listed before editorb
regardless of the type. Does chicago say anything about creator order?
@retorquere sorry I was posting my above comment just as you were posting yours. The main thing is that if Zotero distinguishes between Scriptwriter and Contributor then Better BibTeX shouldn't merge them together. From looking at the biblatex-chicago
docs, it seems that
editora = {Laverty, Paul},
editoratype = {scriptwriter},
editorb = {Johns, Dave and Squires, Hayley and Percy, Sharon},
editorbtype = {none},
ought to be correct.
I don't have any particular idea what a reference to a film is supposed to look like. But I think it will be possible for me to hack something in LaTeX to suppress the none field.
No the biblate-chicago
docs don't mention order at all. I don't have access to the actual Chicago Manual of Style I'm sorry to say.
I agree it's best not to lump them together, but then I do need to know their types as derived from Zotero data.
Or, I suppose changing "none" to "starring" would make some sense in this particular case, but might not be good for other examples like a documentary for example.
Thinking about it a bit more, I would have thought that the only thing crucial for a film when referencing it is the director, title, date and production companies. Maybe Better BibTeX should just put any other info into an annotation field? At least as a temporary solution.
:robot: this is your friendly neighborhood build bot announcing test build 6.7.164.2802.5904 ("fix for #2802")
This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 6.7.164.2802.5904, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
For what purpose would I add them to an annotation field rather than just omitting them?
I just tried out 6.6.164.2802.5904 and it now outputs this:
video{Loach:DanielBlake2017,
type = {Drama},
entrysubtype = {film},
title = {I, {{Daniel Blake}}},
editor = {Loach, Ken},
editortype = {director},
editora = {Laverty, Paul},
editoratype = {scriptwriter},
editorb = {Johns, Dave and Squires, Hayley and Percy, Sharon},
editorbtype = {none},
date = {2017-06-09},
publisher = {Sixteen Films, Why Not Productions, Wild Bunch},
abstract = {After surviving a heart-attack, a 59-year-old carpenter must fight bureaucratic forces to receive Employment and Support Allowance.},
keywords = {bureaucracy,psychological violence,United Kingdom},
annotation = {IMDb ID: tt5168192 event-location: United Kingdom, France, Belgium}
}
which conforms to what biblatex-chicago
recommends.
It's quite possible that I will be able to tell BibLaTeX to ignore editora
and editorb
so I think we should say this particular issue is closed, unless you think that a more robust solution for others would be to omit the Scriptwriter and Contributor fields.
I believe this works for me. Thank you!
This is just a test build though.
I would have thought that the only thing crucial for a film when referencing it is the director, title, date and production companies.
Right, and that's what Zotero itself does when used with chicago-fullnote-bibliography.csl
or chicago-author-date.csl
. The user is thus limited in, or, if you wish, relieved of any decision.
biblatex, on the other hand, assuming that users know what they are doing, usually reproduces most if not all of the fields of an item, including (and that was news to me, too) the order of editor
, editora
, editorb
, etc.
Difficult to say what's best for BBT, emulating Zotero and omitting fields, or outputting as much as possible and letting biblatex users deal with the result somehow.
I have no opinion on this, but if BBT doesn't just output the director, it could of course follow a certain order with respect to the editor[abc] fields, e.g. in the order used in the first CMOS (17e, 14.265) example below: "directed by …", "written by …", "featuring …". ("Producer" is a Zotero role as well, but is not to be found in any of the CMOS examples.)
It's quite possible that I will be able to tell BibLaTeX to ignore editora and editorb […]
That certainly is an option, e.g., by using the biblatex \DeclareSourcemap
mechanism.
I usually choose to do what gets reasonable rendering without extra biblatex work. I am considering dropping the extra creators by default and allowing adding them in a postscript, or maybe a config file on disk.
:robot: this is your friendly neighborhood build bot announcing test build 6.7.178.2802.6115 ("update tests")
This update may name other issues, but the build just dropped here is for you; it just means problems already fixed in other issues have been folded into the work we are doing here. Install in Zotero by downloading test build 6.7.178.2802.6115, opening the Zotero "Tools" menu, selecting "Add-ons", open the gear menu in the top right, and select "Install Add-on From File...".
I've added an export option to enable biblatex-chicago exports. If you could give this a spin, I can cut a new release.
I have no opinion on this, but if BBT doesn't just output the director, it could of course follow a certain order with respect to the editor[abc] fields, e.g. in the order used in the first CMOS (17e, 14.265) example below: "directed by …", "written by …", "featuring …". ("Producer" is a Zotero role as well, but is not to be found in any of the CMOS examples.)
Order is then determined by the a
/b
/c
postfix, not the editor<abc>type
?
I've installed and tested the test build. All seems good to me. Scriptwriter and collaborator are no longer merged into the same field.
Thank you!
Order is then determined by the
a/b/c
postfix, not theeditor<abc>type
?
Right. (In fact, editor
without a postfix comes first, so the order is, editor
, editora
, editorb
, editorc
; same for the types.)
Interestingly, the biblatex-chicago manual has this:
However, in my tests,editorc
works, too. (editord
doesn’t, as expected.)
Also, biblatex-chicago does support a number of types/roles (“all associated with specific bibstrings”), including director
, producer
, and none
, but not scriptwriter
or the like. One could put written by
in the appropriate editor…type
field, but this would work in English only, of course.
In addition, none
leads to nonoptimal results when the corresponding names are printed after names associated with some role: Compare the output from a source containing:
editorc = {Johns, Dave and Squires, Hayley and Percy, Sharon}, editorctype = {none},
with the output based on:
editorc = {Johns, Dave and Squires, Hayley and Percy, Sharon}, editorctype = {featuring},
These last two issues (scriptwriter and none/featuring) could be fixed, temporarily, on the BBT side by writing written by
and featuring
into the appropriate editor…type
fields. Again, this would work for English output only, but then again pretty much everything could be bent into shape for other languages at LaTeX runtime by employing biblatex’s \DeclareSourcemap
mechanism.
A more universal solution would be a fix on the biblatex-chicago side, where bibstrings for scriptwriter
and featuring
(or possibly cast_member
or the like) would have to be introduced, plus some way of deciding when “featuring“ should be included in the final output and when not. Feel free to contact the biblatex-chicago author, pointing out that both “written by” and “featuring” actually do appear in the Chicago Manual’s examples.
Debug log ID
J4GNPRJ5-refs-euc/6.7.163-7
What happened?
If you use Zotero's Connector browser extension to create an entry for a movie from an IMDb page, it creates a Director field, a Screenwriter field, and then several Contributor fields for actors. However, on export the Screenwriter and Contributor fields are merged together:
In the above case Paul Laverty is the screenwriter and Dave Johns, Hayley Squires, and Sharon Percy are actors.
Now I don't have the foggiest idea how a BibLaTeX entry for a movie should look like, this is the first time I have ever needed to create one! I have also read the entirety of #1837 and have acquired some understanding of how this is an area where there seems to be little clarity.
However, given that Zotero does distinguish between a scriptwriter and other contributors, it does strike me that they probably shouldn't all be merged into one field on export. Frankly I don't really care what happens to the contributor fields as I suspect no bibliography style would ever include them.
Thank you for this absolutely invaluable extension!