Not signed in (Sign In)
 

Quick Links

Vanilla 1.1.10 is a product of Lussumo. More Information: Documentation, Community Support.

    • CommentAuthorfbennett
    • CommentTimeSep 25th 2009 edited
     
    I also think future dates would not work too good. I have an article coming out soon (product placement alert!), in a journal that publishes one volume per year. The date field will show "2009". It's currently in press, next month it will be published, but this scheme would show it as in press until January of next year.

    Besides that problem with granularity, many journals have stated dates of publication that are askew from the actual date on which the published copy becomes available.

    Also agree with Bruce about placing this particular value in a separate field. Parsing in the date field is already under strain, and having the value in a separate field would allow users to select and sort on it, which would be useful.

    From the discussion so far, it sounds as though an "in-press" tick-box, with a default value of "false" (unticked) would cover the bases --- styles could then decided which terms to apply by inspecting the other data available in the item. That would be the simplest solution for users. Would it be sufficient?
    • CommentAuthorcmbarton
    • CommentTimeSep 28th 2009
     
    I think an in-press check box would cover many of the bases, but not all of them. The original issue is what happens to the date. If something is "in press" (accepted for publication and working through whatever is involved in getting from an accepted corrected MS to the final publication) at a journal, it *might* have a date year or it might not. The editor might not know yet whether it will come out in the last issue of 2009 or first issue of 2010. More ambiguous are books and book chapters. Even with the MS approved for publication by the publisher, it can take over a year for the book to actually see the light of day.

    In both of these latter cases, the author will not know the year of publication. So there needs to be a date value to indicate this uncertainty. I think that "n.d." will probably work in the greatest majority of cases for this. This is different from a style-related "(in press)" or "(forthcoming)" added to the end of the bibliography. Without a placeholder like "n.d.", the in-text citation of (Smith, n.d.), becomes simply (Smith) and the bibliography style is likewise borked up.

    So my question is: can we get by with "n.d." in the date field of all of these kinds of publications in the future, with a specifier like "in press" at the end (as indicated in a number of posts above), or do people think that it is necessary to have "in press" and the like show up in place of the date in the citation an bibliography?

    Michael
    • CommentAuthorfbennett
    • CommentTimeSep 28th 2009
     
    The "n.d." term can be supplied by the CSL processor if the date field is empty. Would that cover it, or is there a need to distinguish between the item-has-no-date-full-stop and item-needs-date-but-date-unknown cases? (If the answer to that is "yes", worked examples of an affected cite would be great to have.)
    • CommentAuthorcmbarton
    • CommentTimeSep 28th 2009
     
    AFAIC, an "n.d." supplied by the CSL processor if the date field is empty would do the trick. This seems like a nice solution to multiple issues. I don't know about other folks.
    • CommentAuthoradamsmith
    • CommentTimeSep 28th 2009
     
    this can currently be specified and many styles have that -
    but no, I don't think it's going to be enough.
    There are definitely cases that have "forthcoming" or "in press" in lieu of a date.
    Sorry, I don't have any time to track them down right now.
    • CommentAuthorcmbarton
    • CommentTimeSep 28th 2009
     
    Does anyone know which styles implement the "n.d." instead of a data option? Normally, the date must be a number or date of some kind.
    • CommentAuthorfbennett
    • CommentTimeSep 28th 2009
     
    @adamsmith, That might not be a problem. The bundle of item data would have separate values for "status" and "date". If no date is entered, then a test of variable="date" will be false, and otherwise true. That should be enough to produce any of the following forms, in any combination (not sure if all of them are used in actual styles, but by way of example):

    ## Date field empty, status has value "in-press" ...
    Doe, My Book (n.d.) (forthcoming).
    or
    Doe, My Book (forthcoming)

    ## Date field has value, status has value "in-press" ...
    Doe, My Book (2000) (forthcoming).
    or
    Doe, My Book (forthcoming in 2000).

    ## Date field empty, status field empty ...
    Doe, My Book (n.d.)
    or
    Doe, My Book
    • CommentAuthorzeynep
    • CommentTimeJan 9th 2010
     
    So, what are people doing currently? I've manually typed forthcoming or n.d. so far but I agree that it would be good to have this automated. "Forthcoming" "in press" and "n.d." would cover all reasonable bases for me.
    • CommentAuthorgregor
    • CommentTimeApr 28th 2010
     
    Typing the status in manually might be workable until a status system is implemented. In the meantime it would be useful if text entries in the date field were listed as newest and not oldest when sorting by date. Ie, 'forthcoming' or 'in press' require that the citation be listed at the top of a date descending list.
    • CommentAuthorbobanello
    • CommentTimeMay 22nd 2010
     
    I observed that a recent release now defaults to "n.d." when the date in a database entry is blank. This is a good feature, but it does cause a problem with my existing use of Zotero for historical research citations. For example, in documenting the history of an organization, where there is a stable format for meetings, I have put the information other than meeting date in the database (e.g., John Jones, "Meeting Minutes,"....) and qualified the database entry in the citation by putting the date in the box where the page, chapter, book, etc. are entered (e.g., John Jones, "Meeting Minutes," January 1, 1900,....). With the new date default, my entries now show up as (John Jones, "Meeting Minutes," n.d., January 1, 1900,....). One suggestion to resolve this problem would be to incorporate into the "Add/Edit Citation Window" a "Suppress n.d." check box functionality similar to the "Suppress Author" check box. Another suggestion would be to include "date" in the options for the "page, book, chapter, etc." drop down box, and if date was selected, "n.d." would be suppressed. Thank you for any consideration you may give to this request.
    • CommentAuthorfbennett
    • CommentTimeMay 22nd 2010 edited
     
    I didn't realize that current Zotero had been configured to do this. The new CSL processor will do this also, so this is in a sense an early shakedown for it.

    (Edit: see adamsmith's comment below, and my note on CSL 1.0 below that.)

    First question: why are you not putting the date in the date field?
    • CommentAuthorbobanello
    • CommentTimeMay 22nd 2010
     
    Good question. I am currently writing about pedagogy and administration of selected educational institutions, and I've seen this at several schools in my research. The faculty meet every week, the same person takes notes year after year, and years of faculty meeting notes are archived in the same box. Thus the only difference is date. With historical studies, the archive name, collection or record group, box number and name, and location are part of the initial citation. That chews up a lot of lines if you are making an unique database entry/citation for each week cited (literally pages in a chapter). Before the "n.d." functionality was put in, several chapters back in my writing, I set up one generic "Faculty Meeting Minutes" entry for each faculty scribe, with all the archive information, and then record the date where page number, book chapter, etc. usually goes. As a result, only the first citation has all the archive information and the subsequent citations are much shorter.
    • CommentAuthoradamsmith
    • CommentTimeMay 22nd 2010
     
    the n.d. currently isn't actually a Zotero feature but a style feature.
    I agree with Frank that it might be a good idea to go to a standard formatting, but for the time being this should be easy enough to change in whatever style you're using. Which is it?
    • CommentAuthorbobanello
    • CommentTimeMay 23rd 2010
     
    Chicago Manual of Style (Full Note with Bibliography)
    • CommentAuthorfbennett
    • CommentTimeMay 23rd 2010 edited
     
    Another question: which item type are you using for this category of material?
    • CommentAuthorbobanello
    • CommentTimeMay 23rd 2010
     
    Document. BTW-Thanks to both of you for this assist.
    • CommentAuthorfbennett
    • CommentTimeMay 24th 2010
     
    Okay, we'll try some rough surgery first.

    Go here: http://gist.github.com/411693

    then download the style, using the "Raw" link on the top right.
    Install by dragging the downloaded file into an open Firefox Window.

    This will eliminate the "n.d." behavior completely. If you need it for other entries, let us know and we'll work out a more targeted approach.

    Please report back.
    • CommentAuthorfbennett
    • CommentTimeMay 24th 2010 edited
     
    I didn't realize that current Zotero had been configured to do this. The new CSL processor will do this also, so this is in a sense an early shakedown for it.
    (per fbennett)

    the n.d. currently isn't actually a Zotero feature but a style feature.
    (per adamsmith)

    An update on this. The implicit rendering of "n.d." by the new CSL processor, and its inclusion in the CSL 1.0 specification, was apparently based on a suggestion I posted to this very thread back in September of 2009. After careful reconsideration of the feature in light of bobanello's query, the CSL group have concluded that, as it would alter the behavior of existing styles, would reduce the transparency of CSL code, and wouldn't enable any behavior that cannot be achieved without it, it should be dialed out of the specification.

    So scratch my comment quoted above: in this respect, CSL 1.0, dates will behave in the same way as in 0.8.1. As a result, any fix applied for bobanello's case in the current version of CSL will map through smoothly to the new schema and specification.
    • CommentAuthorbobanello
    • CommentTimeMay 29th 2010
     
    Thank you very much for the modified style! I tested it this morning and it works wonderfully.
    • CommentAuthorChris_hk
    • CommentTimeAug 22nd 2010
     
    Let me join in the masses who think this issue needs to be addressed and bump this thread up.

    There is also a related issue. When you cite classics, lets say a book published in 1919, but your edition is published in 1999, you would often like to let the reader know that you are referring to the 1919 book. Yet, simply putting 1919 in the date field would be misleading, so the standard solution for in-text citations seems to be square brackets like: Weber ([1919]1999). Would be nice if the date field in Zotero would have this as an option too.
    • CommentAuthorbobanello
    • CommentTimeAug 24th 2010
     
    Chris, you bring up a topic similar to one that I dealt with. There are situations in which the date -- even sometimes the year -- are not directly stated, but need to be inferred from the document content. This even occasionally occurs in published books. The brackets are the typical way to specify inferred information. ZOTERO performs well in determining "Y" and "Y M D" from dates entered, but brackets entered in the date field are not displayed when the citation is formatted through the style. I get around that by entering carrots "^" in the date field as a reminder and modifying the citation in the "Add/Edit Citation Window" editor. It would be helpful to have the ability to tell ZOTERO that date needs to be "freeform" in which no implied date format is used, and the data in the date field is presented in the citation exactly as it is entered in the date field.
    • CommentAuthorbdarcus
    • CommentTimeAug 24th 2010
     
    I just feel the need to again bring up the point that free form dates only really work for some type of citation styles (like note-based); they otherwise break basic functionality like sorting that are critical for other styles.
    • CommentAuthoradamsmith
    • CommentTimeAug 24th 2010
     
    also, note that support for a set of date-types is planned and/or forthcoming - so no need to keep pressing this - search the forum for original date of publication to get a sense of where development stands with respect to that particular demand.
    • CommentAuthorChris_hk
    • CommentTimeAug 24th 2010
     
    Ok. Thanks for the update.
    • CommentAuthorcarhogg
    • CommentTimeFeb 20th 2012
     
    I was wondering if the issue of adding In press instead of a date has been addressed.

    I need it to follow the instructinos for Limnology and Oceanography http://www.aslo.org/lo/instructions/authors.html#References

    From searching I can't find any mention in the documentation or fora other than this.

    The best work around I can think of is to add the suffix to the in text reference and alter the citation in the Edit Bibliography dialogue. This works for me at the moment.

    An update or better suggestions would be great.

    Thanks as ever.
    • CommentAuthoradamsmith
    • CommentTimeFeb 20th 2012
     
    we're unfortunately not anywhere further on this, no. I really hope this happens in 3.5 - at this point the list of citation-related things that we'd like in 3.5 is rather daunting, though.
    • CommentAuthorGrover20
    • CommentTimeMay 17th 2012
     
    Thanks for the update adamsmith...

    The temporary solution I am using, in case it is of help to others, is writing in the date field the text string I want to appear in the citations in my document. So under date I write "in press" or "submitted" or "to appear" depending on the needs of the current project. Given that its such a small % of citations (and mostly only my own work I'd cite this way), this seems doable for my needs.

    In the past this didn't work, but with the update word add on I installed today, it is working fine. I haven't tried it yet in Lyx or Latex....
    • CommentAuthornaught101
    • CommentTimeSep 19th 2012
     
    Any movement since May? I have a couple of in-press/under-review citations that I'm wondering how to deal with.

    Is the trac bugtracker still used? Or should there be a bug on the github tracker for this?
    • CommentAuthorfbennett
    • CommentTimeSep 20th 2012 edited
     
    No further movement as of yet. It's just a matter of passing through a value for the "status" variable to the processor, as far as I know (easy as far as the processor is concerned, but non-trivial at the Zotero end since adding the variable will affect sync).

    The new variable may find its way into the next major Zotero release (not 3.0.x, but 3.5).
    • CommentAuthoradamsmith
    • CommentTimeSep 20th 2012
     
    (trac is being phased out - i.e. all new tickets go on github - but there is no need to replicate existing trac tickets on github (unless you want to attach code for a patch).)
    • CommentAuthorivogruner
    • CommentTimeJan 28th 2013
     
    push push.

    No news as of yet, I guess?
    When is 3.5 supposed to be released?

    Gratefully yours,

Zotero Forums are powered by Vanilla 1.1.5a