is-phrase condition?

As part of my continuing campaign to precipitate feature bloat, I would like to request an "is-phrase" condition, as a complement to is-date and is-numeric. This would return true if a space character is contained in the field. What prompts this request is a few illustrative citations reproduced in (again) the Bluebook:
The Bluebook: A Uniform System of Citation R. 1.2(e), at 24 (Columbia Law Review Ass'n et al. eds., 17th ed. 2000).

The Bluebook: A Uniform System of Citation 293 tbl. T.10 (Columbia Law Review Ass'n et al. eds., 17th ed. 9th prtg. 2000).

William Shakespeare, The Second Part of King Henry the Sixth act 4, sc. 2.
The first and the last examples are not a problem. They each involve only a locator, entered through the GUI. Because in Bluebook, for the book type, the locator "page" will ordinarily prefix the locator with a single space, the user can just call it a "page" and enter the full string text of the pinpoint.

The middle example will be a problem, though, because the "ed." suffix is automatically generated. By entering the literal string, you would get an extraneous suffix, like this:
The Bluebook: A Uniform System of Citation 293 tbl. T.10 (Columbia Law Review Ass'n et al. eds., 17th ed. 9th prtg. ed. 2000).
If an is-phrase condition were available, the default suffix could be suppressed in these special cases. Most styles use the number declaration to format the edition, and so would pass through only the edition number, formatting it as ordinal or whatever as require; so content with extraneous strings should play well there as well.

The alternatives would be either to add a "Printing" field to the GUI, or to list an erratum for the Zotero Bluebook style. An is-phrase extension is more satisfactory than the latter, and constitutes a smaller hammer than the former.

Anyway, that's the use case and the argument. Hope this can be taken onboard.
  • I have modified the code of Zotero 1.5 to accomplish this on my laptop. Can provide as a patch to anyone interested.
  • edited December 16, 2008
    Frank: I don't really understand the issue here, and unfortunately can't really deal with this ATM, as I'm almost out the door for a few weeks of travel. But, it's not a good idea to be patching Zotero AND CSL, given that they are independent, and any styles dependent on this change will be invalid ;-)

    It would be nice if someone else (Rintze? Dan?) could take a look at this issue and figure out if there are other ways to handle this.
  • Sure thing. Have a good trip; I'm grateful for the time you've taken out for advice on this. No cause for alarm, I'm not working under any sort of deadline; fiddling with code is just my way of thinking out loud. Dan has opened a ticket, I'll post what I've got and let the team decide what to do from there.

    Understood about the independence of Zotero and CSL. The roles of the components in the wider world is starting to come into focus.
  • Can you perhaps elaborate a bit on the middle example? I'm not familiar with Bluebook, and I don't exactly understand which part of the output is generated automatically, and which part you enter as a locator. I also don't even recognize all fields (what do "293 tbl. T.10" and "9th prtg." mean?).
  • @Rintze: Ive just put up a patch against Zotero Sync Preview 1.5 under a ticket kindly opened by Dan, that addresses this issue.

    Here's a breakdown of the actual data entered for the citation elements:
    Title: The Bluebook: A Uniform System of Citation
    Page: 293 tbl. T.10
    Editor: Columbia Law Review Ass'n
    Editor: Harvard Law Review Ass'n
    Editor: Pennsylvania Law Review
    Editor: Yale Law Journal
    Edition: 17th ed. 9th prtg.
    Date: 2000

    I think that the "293 tbl. T.10" refers to table number 10 in section T, on page 293. The "9th prtg." string means "9th printing".
  • Sorry, in the above, "293 tbl. T.10" is Locator: not Page.
  • For what it's worth, this issue you're describing with the edition field is really similar to this one:
    http://forums.zotero.org/discussion/4956/difficulty-formatting-complex-book-editions-in-bibliography/

    I don't really like the addition of a printing field, as it seems to be used so sparsely. I do think an escape character could to the trick. For example, if the edition field contains the escape character (e.g. quotes: "17th ed. 9th prtg."), it makes sense to just skip any automatic addition of terms like "ed." in the citation output.
  • @Rintze: I agree, recognizing enclosing quotes as an escape would be a good solution.
  • Frank, you added a patch to the ticket that adds an "is-quoted" operator, but the new operator doesn't strike me as necessary. Couldn't is-numeric just always fail if the string was enclosed in quotes? The styles already do passthrough in those cases, and this is (as far as I know, though I'll admit I haven't looked at this very closely) just a way of forcing passthrough for strings that begin with numbers...
  • This would be used to force literal interpretation of strings, suppressing the prefix or suffix that would ordinarily be attached to it. This would allow override in exceptional cases where the default processing of a style does the wrong thing, but accomodating the case in automated processing within CSL & Zotero would be excessively burdensome. An example would be:

    John Doe, Anonymous Man (1st ed. 2nd prntg. 2000)

    There is no "printing" field, and it's so uncommon that it's probably not worth the candle to add one. But entering "1st ed. 2nd prntg." to the edition field would yield "1st ed. 2nd prntg. ed.", which is wrong. A quote-escape could be picked up in the style to suppress the final "ed."
  • Further to the quoted-escape thing, quoted content would admittedly be incorrect for some other styles. It's sort of a choose-your-poison thing. But you would be able to more easily collect a body of information on practice, by checking databases people have built for quoted strings, to see what people are doing with it, and get a handle on what utility there might be in particular extensions.
  • Further further to the is-quoted thing. The example I gave could be handled by a failure of is-numeric. But there are other cases where it would be useful. For example, in the locator, a user might want to force a correct singular-form prefix where the Zotero heuristics get it wrong, as would be the case with "23 nn.1-3", for notes 1 through 3 on (singular) page 23.
  • I don't know—it seems, in that case, the is-plural heuristics should just be improved. Adding is-quoted would essentially require arbitrary, style-specific hacks that would be difficult to communicate to users. There's nothing inherent about a quoted locator string that should result in its getting a singular-form prefix—or, if there is, it should happen for all styles. But, as far as I can tell, this particular example would require only a slight tweak to is-plural.
  • I understand your reluctance. Partly I'm reacting to the unknown; the Bluebook is a mass of exceptions and special cases, and I'm fearful that without an escape mechanism, I will end up playing even uglier incompatibility games (with weird field assignments and the like) in order to get acceptable output.

    Probably the best next step is for me to push things as far as they'll go in the current environment. I'm about to start working through examples in the style manual, starting with Books, Pamphlets and Other Nonperiodic Materials. When I have a finite list of exceptional cases from this section, I'll post again, and see if we can work out acceptable ways of handling them. Thanks for your feedback, Dan, it means a lot.
  • Strings enclosed in double quotes now fail is-numeric in the latest 1.0 branch and trunk builds, and the quotes are stripped on output to CSL. This isn't really my department, so please test this and let me know if it works as expected.
  • Thanks, this works like a charm!

    I'll keep this escape trick as a last-ditch resort. I'm about 50 cites into the "books" section of the Bluebook, about 1/3 of the way through that bit. Doing these test cases is certainly proving helpful. I'll be able to offer a much more more well-composed set of suggestions/requests/minor whinges when I've finished with this first batch.

    I may have neglected to say earlier that Zotero is a real pleasure to work with. I've shown the system to my senior colleague in our academic writing program, and we're now aiming to roll out the style to students from April, with (touch wood) at least basic legal citation support for the US, the UK, Japan, Cambodia, Laos, Mongolia, Uzbekistan and Vietnam.
  • Oops. Actually, turns out there was a little gotcha in the new quoting code. Apparently there are some vars (JS vars typed numeric?) that don't have the *.match method used to apply the regexp, and it can cause cite editing or creation to block when it is invoked.

    Here's the change needed in chrome/content/zotero/xpcom/cite.js, at around line 2144:
    // Quoted strings are never numeric
    - if(value.match(Zotero.CSL._quotedRegexp)) {
    + if(value != "" && value.toString().match(Zotero.CSL._quotedRegexp)) {
    For awhile there I thought I was having problems with available memory or OO bugs or some other weird source of discouragement. But the change above appears to have cleared everything up.
Sign In or Register to comment.