I just downloaded everything, and I truly appreciate all of the work on the Bluebook citations! I am beginning to work with the program, and I noticed four things:
1. My "id." is ending with two asteriks, like this: Id. at 402**
2. The "supra note __" should have a comma between this and the page number, like this: "supra note ___, at 23." (see BB Rule 4.2)
3. There does not appear to be any consistency with when the program puts a period at the end of a citation.
4. I can't seem to figure out how to update all of the citations at once - do you have to update them individually (when, for example, you move footnotes around so that what was the 2nd short reference to an article becomes the 1st reference, and therefore should be in the long form).
I am sure some of this is user error on my part, and for that I apologize. But, if there is some help/information you can provide about these issues, I would appreciate it.
Overall, though, fantastic work - as others have noted, the BB is tricky and arcane.
Bluebook Law Review is great. I've noticed two small bugs:
1. When citing to a case, the reporter name shows up in small caps, but it should be in regular font (e.g. F. Supp. 2d is showing up in small caps instead of regular text).
2. When citing to a case for the first time, the court name should show up in the parens along with the year of the case, but it doesn't (e.g. if the case took place in the Delaware Supreme Court, the final citation might look like 882 A.2d 452, 452 (Del. 2005)).
Is it possible to get these fixed, or are they just bugs in the system?
Also, I know you can edit individual citations within the Microsoft Word plugin by opening the add/edit citations dialogue. Is there a way to edit the citations from the Zotero Firefox plugin (other than entering data into the info fields)?
@bdarcus: Thanks for taking the time to do this. I appreciate it.
Plain roman typeface for reporters is illustrated by examples in Rule 10.1 Basic Citation Forms (p. 79-80 in my BlueBook). There is not a specific rule that explicitly states this, but the examples are clear and that is where the BlueBook index refers you to if you look up 'Reporter typeface.'
Parenthetical including the court of decision and year the case was decided is required by Rule 10.4 Court of Jurisdiction (p. 89) and Rule 10.5 Date or Year (p. 90). See also blue pages B5.1.3.
One more thing: I'm also getting the same double asterisk at the end of "id" citations that some of the earlier posters got as well.
Thanks again for working on this. I've enjoyed testing it out.
One big issue that just occurred to me: supra should not be used when citing cases subsequent times (nor statutes, constitutions, etc.). See rule 4.2 (p. 66). Instead of using supra, you use a short form of the case name plus the volume and reporter (but not the original page number) and pincite. If there is no pincite, then you use the original page number. See Rule 10.9, p. 97.
For example, if original case cite was "Doe v. California, 12 U.S. 234, 56 (2008)." a citation to a specific page of same case would be "Doe, 12 U.S. at 78." If it was a general citation to the case, it would be "Doe, 12 U.S. 234."
Id. is still used for case citations that come in the immediate subsequent footnote.
Also, thought I'd post the other suggestions:
1. When using Id., the page number should only appear if it is a different page number from the previous citation. If it is the exact same page number or page range, then it should be dropped.
2. Id. should be used if the source in the citation is the same as the previous citation, but not if there is more than one source in the previous citation. Otherwise, short form (cases) or supra (other materials) should be used.
3. In "supra" citations, there should be a comma after the "note ___" and before the "at". (e.g. "Casename, supra note 12, at 345.")
Does any programmer think they might have time to update the Bluebook style with the suggestions from on Oct. 5th, and the inclusion of the court from the post on Sept. 30th? Am about to begin writing a new paper, and am trying to decide whether to Zotero for the citations. Thanks!
@mmazzotta: I'm swamped, so can't promise anything. But re: previous post, in case anyone else finds time:
One big issue that just occurred to me: supra should not be used when citing cases subsequent times (nor statutes, constitutions, etc.). See rule 4.2 (p. 66). Instead of using supra, you use a short form of the case name plus the volume and reporter (but not the original page number) and pincite. If there is no pincite, then you use the original page number. See Rule 10.9, p. 97.
This should be doable; just means adding a conditional to the subsequent definition.
1. When using Id., the page number should only appear if it is a different page number from the previous citation. If it is the exact same page number or page range, then it should be dropped.
Hmm ... sounds like it means tweaking one of the option settings.
2. Id. should be used if the source in the citation is the same as the previous citation, but not if there is more than one source in the previous citation. Otherwise, short form (cases) or supra (other materials) should be used.
Well, so I think you're saying this has the same rules as general "ibid" handling?
3. In "supra" citations, there should be a comma after the "note ___" and before the "at". (e.g. "Casename, supra note 12, at 345.")
That easy enough to fix, but note that it's also easy for you to fix manually, since you already have to fix the note number.
@bdarcus: Thanks. I totally understand. The biggest one is the first (non-numbered) item. The rest are all more minor tweaks that would be helpful.
Regarding #2: Yes, I believe this is the same as "ibid." "Id." is used when citing the same authority as in the immediately preceding citation, but only when that immediately preceding citation contains only one authority. BB Rule 4.1
Regarding #3: Yes, you are definitely correct on the user being able to fix it by inserting the comma. However, the use of commas varies for different styles of documents, and toggling back and forth between them as a user can get confusing.
Finally, if anyone can figure out how to incorporate the court name in the parens at the end of long form case citations (i.e., the first time a case is cited), that would be ideal. The parens is supposed to include both the court name and the year of decision. BB Rule 10.4. (e.g. if the case took place in the Delaware Supreme Court, the final citation might look like 123 A.2d 456, 457 (Del. 2005)).
Hello. I have done a bit of programming in the past (including attempts, long ago, to automate Blue Book citations and cross references in LaTeX), and currently I teach and supervise students who use the Blue Book style. Improved Zotero support for this style would make my life a bit easier, and I would like to have a crack at fixing some of the problems with BB support, including items mentioned in this thread. I've gotten as far as viewing the XML for the Blue Book CSL file on screen, and before I wade into this any further, I have some questions.
First, is the CSL file all that is required for all style operations? At first glance, it seems very sparse. If this single XML file covers all of the logic driving the style in its current form, that will be very good news. But I'd like to confirm that this is so.
Second (especially if there's a puddle of code somewhere that isn't in that XML), is there a way to get SVN login access? I can work locally if necessary, but it would save a bit of time and hassle to just co and go.
Thanks and congratulations for this project. I know from hard experience what a swamp citation management is, and it sure looks to me as though you've got the bases covered.
Okay, I've done some rattling around in the code, and I think I have a grip on the basics. One thing we're going to want to do is to extend this to handle multiple jurisdictions. It looks like doing that the right way may require some extension of Zotero itself. I'm not sure what the prospects are for that, so I'd better pose a few questions before I start messing up the code.
For many countries, we will require transliterations of selected data fields. For example, the standard short name for a common reporter of civil cases in the Japanese Supreme Court is 民集. In an article using native Japanese citation style, this should be written in that form, so the Reporter field should contain this text. A romanized citation style such as Bluebook should use its transliteration, Minshū.
Translations will also be required for some references. For example, a book in Mongolian needs to be cited with the original title (in cyrillic script or a romanized transliteration, depending on the typesetting conventions of the citation style), with a translation in braces. The original title is needed in order to locate the work, while the translation is needed as a guide for readers unable to read Mongolian.
Handling these cases will require additional fields for holding the necessary transliterations and translations. Because that data is only required in exceptional cases, I reckon there will be interface issues that want to be addressed, in order to prevent runaway clutter in the UI. But to be useful beyond the parochial bounds of North American resources, this needs to be in there.
Is this kind of facility already built into Zotero (an I've missed it) or is there a prospect for extending the engine in this way?
Quite right, that multilingual support is not specific to Bluebook. I've found some of the other threads now, I'm only beginning to catch on to the scope of the community you have going here.
Thanks for the link. The discussion in that thread talks about the possibility of relations between references. This would be very valuable in Bluebook and other legal styles, to represent procedural history. For example, a case decided in trial court might be affirmed in a court of appeal, then overruled on appeal to the jurisdiction's supreme tribunal. The chain can be longer, with remands back to the lower court and multiple appeals. It would be sweet if an initial reference to a judgment could slurp in the entire subsequent history known to Zotero -- including this subsequent history is always desired, for accuracy.
The Semantic Relations document suggests one relation useful for procedural history:
# reverses (legal only?)
I'm not sure whether relations will be shared between references (i.e. an index pointer accessible from either end), or be one-way reference IDs attached to only one reference of the pair. If the latter, this and any similar items ("affirms", etc.) should be forward-looking, so that the subsequent history can be induced from the "root" reference:
# reversed by (legal only?)
Shared pointers would be better, with both a forward and a backward reference field in the UI.
See also the related bibo rdf work. I tried to make sure the basics at least of legal requirements were covered, but I'm not a lawyer or a legal scholar or librarian.
Really interesting stuff. I'm not a serious programmer, but I have an idea what this is about. Would you like feedback on the legal categories included in the OWL documentation?
@bdarcus: I've refactored the published Bluebook style file with a view to simplifying individual macros, as a first step toward extending the style to cope with all cites in the "Typical Legal Citations Analyzed" section at the front of the Bluebook, and fixing the back-reference issues that have been mentioned in this thread. I've sent along a copy of the revised CSL file off-forum. If it looks okay, I'll start puttering on the extension work as time permits. Otherwise, I guess I'll have a go at revising again. :)
Thanks to Bruce for comments. There are some small organizational issues in my current crack at the style file that I'll try to sort out before "officially" offering it up. The main thing to note is that the style file in its current state (and in my revision) is a very rough thing, and shouldn't be relied on for anything more than test documents. It covers only a narrow subset of legal materials (US cases and common or garden secondary materials). This leaves out important categories of stuff, including foreign judgments (including decisions of the English courts), UN documents and treaties, as well as statutes, ordinances, model codes and administrative rules. In other words, it's unlikely an author will get beyond the introduction to an academic article before running out of supporting gas in the style.
Achieving support for these items will take awhile (putting it mildly), but I'm going to try to sensibly partition support for individual citation types in the style file, so that the work of extending it to cover new categories of material can be shared out to a thronging population of eager contributors as the style grows over time.
Bluebook citation is pretty demanding, and I'm pretty sure that it pushes or exceeds the limits of zotero here and there. I'm no expert in zotero (I'm an academic lawyer, for what it's worth, but in computing I'm a lazy hobbyist, and "novice" doesn't quite come in low enough to describe my level of ignorance), so as I come across things that look like they might cause difficulties, I'll post a note to this thread, in the hope of being corrected or contradicted.
One thing that will be a considerable problem is the handling of singular and plural locators -- i.e. markers for pages (p. vs. pp.), notes (n. vs. nn.), paragraphs (the marker or markers), sections (ditto), etc.
As I understand it, in normal operation, the user of a zotero client can select the appropriate locator for a pinpoint reference in an individual instance of the citation. This is passed through to the style file, together with a flag telling whether the string entered by the user represents a singular or a plural pinpoint. The style file, through the label directive, then selects the appropriate marker from a list made available by Zotero, and includes this in the citation.
Judging from the source code, Zotero apparently makes the singular/plural decision on the basis of a string search. Strings containing hyphens or commas are deemed plural, otherwise the string is reported to be singular. You might say that ampersands could be added to the list of items scanned for, but the bigger problem is that a simple scan doesn't capture the semantics of the user-entered string. For example, the following should be singular, on Bluebook rules (the user string is in square braces):
sec. [19(a)-(c)]
This would also be singular:
p. [345 nn.14, 15 & 17]
The verbal syntax of these pinpoint strings is basically a dog's breakfast, and there's a good chance that attempts to improve the hit-rate for automated interpretation will end up costing more than they're worth. I would think that it would be more certain and less stressful to just provide a "singular/plural" radio button in the citation client UI, so that users can just force it one way or the other. Any chance that things might move in that direction?
Update: After all my huffing and puffing above, I'm very happy to report that this is no longer an issue, and the tweak is (in the way of the wonderful people who built this house) much cleaner than my tortured vision of simplicity. In recent 1.0 snapshots, quote marks will force a field to be recognized as non-numeric. Since pinpoints generally include numbers, this can be used in styles as a flag requesting special treatment. The style designer therefore has the option of allowing users to enter a literal string to cover examples like those given above. Problem gone.
I am working on an experimental version of the Bluebook style. I've set up a list of existing issues on a separate forum thread. The experimental code, which is still very incomplete and requires patches to run, is available for inspection, and will be updated from time to time.
Upgrade Storage
1. My "id." is ending with two asteriks, like this: Id. at 402**
2. The "supra note __" should have a comma between this and the page number, like this: "supra note ___, at 23." (see BB Rule 4.2)
3. There does not appear to be any consistency with when the program puts a period at the end of a citation.
4. I can't seem to figure out how to update all of the citations at once - do you have to update them individually (when, for example, you move footnotes around so that what was the 2nd short reference to an article becomes the 1st reference, and therefore should be in the long form).
I am sure some of this is user error on my part, and for that I apologize. But, if there is some help/information you can provide about these issues, I would appreciate it.
Overall, though, fantastic work - as others have noted, the BB is tricky and arcane.
Many thanks.
why always are there some "\scaps" in the citation?
1. When citing to a case, the reporter name shows up in small caps, but it should be in regular font (e.g. F. Supp. 2d is showing up in small caps instead of regular text).
2. When citing to a case for the first time, the court name should show up in the parens along with the year of the case, but it doesn't (e.g. if the case took place in the Delaware Supreme Court, the final citation might look like 882 A.2d 452, 452 (Del. 2005)).
Is it possible to get these fixed, or are they just bugs in the system?
Also, I know you can edit individual citations within the Microsoft Word plugin by opening the add/edit citations dialogue. Is there a way to edit the citations from the Zotero Firefox plugin (other than entering data into the info fields)?
Thanks! It's a great plugin and very helpful.
--Matt
Plain roman typeface for reporters is illustrated by examples in Rule 10.1 Basic Citation Forms (p. 79-80 in my BlueBook). There is not a specific rule that explicitly states this, but the examples are clear and that is where the BlueBook index refers you to if you look up 'Reporter typeface.'
Parenthetical including the court of decision and year the case was decided is required by Rule 10.4 Court of Jurisdiction (p. 89) and Rule 10.5 Date or Year (p. 90). See also blue pages B5.1.3.
One more thing: I'm also getting the same double asterisk at the end of "id" citations that some of the earlier posters got as well.
Thanks again for working on this. I've enjoyed testing it out.
One big issue that just occurred to me: supra should not be used when citing cases subsequent times (nor statutes, constitutions, etc.). See rule 4.2 (p. 66). Instead of using supra, you use a short form of the case name plus the volume and reporter (but not the original page number) and pincite. If there is no pincite, then you use the original page number. See Rule 10.9, p. 97.
For example, if original case cite was "Doe v. California, 12 U.S. 234, 56 (2008)." a citation to a specific page of same case would be "Doe, 12 U.S. at 78." If it was a general citation to the case, it would be "Doe, 12 U.S. 234."
Id. is still used for case citations that come in the immediate subsequent footnote.
Also, thought I'd post the other suggestions:
1. When using Id., the page number should only appear if it is a different page number from the previous citation. If it is the exact same page number or page range, then it should be dropped.
2. Id. should be used if the source in the citation is the same as the previous citation, but not if there is more than one source in the previous citation. Otherwise, short form (cases) or supra (other materials) should be used.
3. In "supra" citations, there should be a comma after the "note ___" and before the "at". (e.g. "Casename, supra note 12, at 345.")
Thanks!
Regarding #2: Yes, I believe this is the same as "ibid." "Id." is used when citing the same authority as in the immediately preceding citation, but only when that immediately preceding citation contains only one authority. BB Rule 4.1
Regarding #3: Yes, you are definitely correct on the user being able to fix it by inserting the comma. However, the use of commas varies for different styles of documents, and toggling back and forth between them as a user can get confusing.
Finally, if anyone can figure out how to incorporate the court name in the parens at the end of long form case citations (i.e., the first time a case is cited), that would be ideal. The parens is supposed to include both the court name and the year of decision. BB Rule 10.4. (e.g. if the case took place in the Delaware Supreme Court, the final citation might look like 123 A.2d 456, 457 (Del. 2005)).
Thanks!
First, is the CSL file all that is required for all style operations? At first glance, it seems very sparse. If this single XML file covers all of the logic driving the style in its current form, that will be very good news. But I'd like to confirm that this is so.
Second (especially if there's a puddle of code somewhere that isn't in that XML), is there a way to get SVN login access? I can work locally if necessary, but it would save a bit of time and hassle to just co and go.
Thanks and congratulations for this project. I know from hard experience what a swamp citation management is, and it sure looks to me as though you've got the bases covered.
Frank Bennett
Nagoya
JAPAN
For many countries, we will require transliterations of selected data fields. For example, the standard short name for a common reporter of civil cases in the Japanese Supreme Court is 民集. In an article using native Japanese citation style, this should be written in that form, so the Reporter field should contain this text. A romanized citation style such as Bluebook should use its transliteration, Minshū.
Translations will also be required for some references. For example, a book in Mongolian needs to be cited with the original title (in cyrillic script or a romanized transliteration, depending on the typesetting conventions of the citation style), with a translation in braces. The original title is needed in order to locate the work, while the translation is needed as a guide for readers unable to read Mongolian.
Handling these cases will require additional fields for holding the necessary transliterations and translations. Because that data is only required in exceptional cases, I reckon there will be interface issues that want to be addressed, in order to prevent runaway clutter in the UI. But to be useful beyond the parochial bounds of North American resources, this needs to be in there.
Is this kind of facility already built into Zotero (an I've missed it) or is there a prospect for extending the engine in this way?
Just to be clear in case there's any confusion, this is orthogonal to the question of legal citations and the bluebook.
Thanks for the link. The discussion in that thread talks about the possibility of relations between references. This would be very valuable in Bluebook and other legal styles, to represent procedural history. For example, a case decided in trial court might be affirmed in a court of appeal, then overruled on appeal to the jurisdiction's supreme tribunal. The chain can be longer, with remands back to the lower court and multiple appeals. It would be sweet if an initial reference to a judgment could slurp in the entire subsequent history known to Zotero -- including this subsequent history is always desired, for accuracy.
One more for the wish list, anyway.
Achieving support for these items will take awhile (putting it mildly), but I'm going to try to sensibly partition support for individual citation types in the style file, so that the work of extending it to cover new categories of material can be shared out to a thronging population of eager contributors as the style grows over time.
Bluebook citation is pretty demanding, and I'm pretty sure that it pushes or exceeds the limits of zotero here and there. I'm no expert in zotero (I'm an academic lawyer, for what it's worth, but in computing I'm a lazy hobbyist, and "novice" doesn't quite come in low enough to describe my level of ignorance), so as I come across things that look like they might cause difficulties, I'll post a note to this thread, in the hope of being corrected or contradicted.
As I understand it, in normal operation, the user of a zotero client can select the appropriate locator for a pinpoint reference in an individual instance of the citation. This is passed through to the style file, together with a flag telling whether the string entered by the user represents a singular or a plural pinpoint. The style file, through the label directive, then selects the appropriate marker from a list made available by Zotero, and includes this in the citation.
Judging from the source code, Zotero apparently makes the singular/plural decision on the basis of a string search. Strings containing hyphens or commas are deemed plural, otherwise the string is reported to be singular. You might say that ampersands could be added to the list of items scanned for, but the bigger problem is that a simple scan doesn't capture the semantics of the user-entered string. For example, the following should be singular, on Bluebook rules (the user string is in square braces):
sec. [19(a)-(c)]
This would also be singular:
p. [345 nn.14, 15 & 17]
The verbal syntax of these pinpoint strings is basically a dog's breakfast, and there's a good chance that attempts to improve the hit-rate for automated interpretation will end up costing more than they're worth. I would think that it would be more certain and less stressful to just provide a "singular/plural" radio button in the citation client UI, so that users can just force it one way or the other. Any chance that things might move in that direction?
Update: After all my huffing and puffing above, I'm very happy to report that this is no longer an issue, and the tweak is (in the way of the wonderful people who built this house) much cleaner than my tortured vision of simplicity. In recent 1.0 snapshots, quote marks will force a field to be recognized as non-numeric. Since pinpoints generally include numbers, this can be used in styles as a flag requesting special treatment. The style designer therefore has the option of allowing users to enter a literal string to cover examples like those given above. Problem gone.