Done.

I've just checked in the changes that nas made, though I didn't really have a chance to do much with it, nor to test it.

Also, there was one major question mark I had (namely whether the 'source' macro is really needed), which is included as a comment in the file.

Another question about cases that probably needs to be referred to another department. There is no place in the Case template for docket numbers. Most citation formats don't use them, but they are sometimes useful, especially for cases that are still being litigated. to whom should I address this?
Thanks

Maybe I am being dense, but I updated the bluebook style and still can't get it to work. Here's a sample

1 Griggs v. Duke Power Co., 401 U.S. 424 (1971).
2 Furnco Construction Corp. v. Waters Et Al., 438 U.S. 567 (1978).
3 , supra note___.

My db entry for Griggs has "Griggs" filled in under short title and fn 3 should say Griggs supra note __

OOPS sorry, updated supra works fine. I forgot to restart after reinstalling -my bad :(

Thanks!

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.

Many thanks.

It's a bug.

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)?

Thanks! It's a great plugin and very helpful.

--Matt

@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.

thanks! working great.

Is there a timetable for merging the Bluebook code to the OpenOffice extension?

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!

@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)).

Thanks!

First, is the CSL file all that is required for all style operations?

Yes.

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?

See here.

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.

One more for the wish list, anyway.

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. :)

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.

Just a short note to bump this item. I have put up a fresh tarball containing hacked database images and Firefox installers, one each based on the Zotero 1.0 branch and on the development trunk. This is only for testing, certainly not production, but I would be grateful for feedback from anyone with an interest who is able to take a look at the code, or to take the kit out for a trial spin. If I'm totally on the wrong track, now is probably a good time to find out!

Thanks again for your work on this.

I can't really review these patches, since almost none of the original code is mine, but I've created a ticket. Upload your patch there (with a .patch extension), and we'll see if we can get it reviewed, though, since this is a pretty big patch, I don't know how soon that might happen.

A few quick notes before you upload the patch, though:

1) There are too many changes here for 1.0, so the patch will need to be against the trunk.

2) I noticed that you made some changes to the CSL schema. I mentioned this before, but we can't make any unilateral changes to the schema, so you'd have to propose your schema changes on the XBib list and get consensus there before we could support them.

3) If I understand it correctly, container author, while existing in the CSL spec, is something that would be part of hierarchical item type support in Zotero, not a regular creator type. Now, it's possible that we should add it as a stopgap solution (along with, for example, original publication field) and simply migrate that data into parent items once there's more sophisticated support, but we'd have to make that decision. (Also, you have the localized term as "Sponsor", which wouldn't be right for a generic creator type. We can map item-type-specific fields to base fields if necessary.)

If anyone hitting this thread would like to take a look, I have put up a click-install experimental version of Zotero with (most of) the infrastructure for full Bluebook support. It covers only secondary material at the moment (no statutes or cases yet), but secondary materials, including id. and supra are handled correctly. I'll be working on statutes and cases over the next couple of weeks, so that's coming.

This is based on a recent Zotero Sync 1.5 development snapshot. All of the caveats relating to that series apply (plus the additional warning that I wrote my first full line of Javascript code about a month ago).

Frank Bennett

oschwald,

I've done some work on an alternative Bluebook style, but it is not yet compatible with mainstream Zotero, and isn't suitable for anything more than experimentation (a caveat that applies to everyone, including me). I'm tied up at the moment with a writing a new CSL citation processor for Zotero. When that's out of the way, I'm planning to turn back to the Bluebook stuff, probably sometime during the summer.

If you're technically inclined and would like to take a crack at adapting the style to be CSL conformant and to run in the new processor, let me know. I could certainly use a hand!

(On the periods thing, that's a small bad habit of Zotero. Just refresh the citations, and the period pops up.)

Frank Bennett

I have been taking a stab at an alternate Bluebook citation style. I've never edited any code before, so I'm running into a few problems. Can anybody tell me the proper variable name for statutes (i.e., what to put in a <text variable=“??????”> syntax line)? Thanks. --Matt