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.
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?
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.
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.
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.
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.
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.
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.
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.
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....
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).
(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).)
The second reply to this thread seemed to have a sufficiently good solution to this issue. But I still can't see any "status" field and "pubstate" is still unused for biblatex output.
not really -- we have implemented the status variable in a number of citation styles (APA and some management styles for sure, I think also Chicago), but Zotero doesn't have a status field so that's not of a ton of help.
If you really need this to work without modifying citations, you can hack a pseudo status field in Zotero by placing {:status: in press} in the Extra field, but that's not officially supported and I can't promise that it will be transferred in a status field once that makes it into Zotero.
A workaround meanwhile is to put the status (submitted etc) in the field for the publication's volume. It's easy to imagine circumstances for which that won't solve the challenge, but hopefully this will help someone for now.
If I'm in the right place, here are some thoughts:
1. I strongly disagree with restricting the possible input of the date field, especially if it would only address the most common types (some above are even suggesting merging "forthcoming" and "in press").
The practice of using a wide variety of forthcoming types is widespread, and importantly varies by field. While you might argue that isn't the best practice, Zotero shouldn't explicitly restrict it. Individual styles can of course restrict that, but Zotero shouldn't unilaterally tell me that I have to write "forthcoming" instead of "in press" or that I can't write "in preparation", etc.
Just as one example, the most variation seems to occur when authors are citing themselves, and this is a common situation where "in preparation" comes up. I'm writing from the perspective of Linguistics, which of course has its own traditions that differ from other fields, but one important perspective there is that forthcoming citations serve a different purpose from published works: they often provide data sources (a description of a language that is in progress, for example) or just additional information about arguments, rather than any sort of scientific consensus.
So being able to cite even vaguely planned future works can be useful, and being able to specify the status seems useful. (Again, there are arguments against doing that, and some styles might not allow it.)
I can't imagine a restricted input system that would cover everyone's needs, and I just don't think that's necessary. If the field parses as a typical, numerical date, then parse it as such. If not, treat it literally, and display it that way. This will also allow other less common date systems (I see discussion elsewhere about Taiwanese dates, for example.)
2. For many author-date formats, it is standard practice to use the 'status' in place of the date. For all intents and purposes, it IS the date. "Forthcoming" should not be moved to a separate "status" field, despite how popular that is in the comments above.
This is a completely separate issue from "ahead of print" publications. For that, adding a separate "status" field would be fine, although I don't see why that can't be handled with the "volume" field (or "pages", etc.). It would be a mistake to merge "forthcoming" and "ahead of print". They mean completely different things, even though both are broadly related to future dates.
3. As others have said, treating future dates as forthcoming makes no sense on a practical level. There's the fundamental issue with the same year as publication, but there's also a problem with not allowing known future dates to be cited (rare, but it happens). Again, Zotero should not be restricting what users can do, even if it isn't necessarily best practice.
4. I'm not sure how Zotero could handle style-based differences, such as Chicago vs. APA / forthcoming vs. in press. But I'd much rather see this left up to the user than restrict us in how we can use the input fields. Most users will know the standard practice in their fields and default to that, and not need to change too often. From what I can tell, text matching and replacement like "forthcoming">"in press" is not possible in current CSL styles, so that would have to be sacrified (not included) in the styles currently. But that trade-off is worth it, rather than just having, for example, one option per style. Note that it is much easier to collapse information into a single category than it is to split it, so Zotero should encourage all possible contrasts, and as applicable collapse them (or allow users to do that manually for the final draft).
---
Now, from a practical perspective:
I'm surprised that there aren't more users echoing what @Grover20 wrote above. Just typing in "forthcoming" (or whatever) to the date field has worked for me, and I didn't even realize this was a question/problem for Zotero until I started trying to customize my own style. I assumed it was obvious that "forthcoming" would go in the date field, because it IS a date (see point 1 above).
This works almost flawlessly. I'm only aware of three issues (which I why I ended up here now):
1. Complex dates are problematic. Date ranges, unknown dates, etc. But at least using the "issued:" variable in 'extra' is a reasonable workaround for now!
Actually, my first thought in response to that would be to have less parsing of dates, to simply treat that field literally. There are a few issues with that (e.g., citing a day-month-year date in the bibliography but only wanting year to appear in in-text citations), but arguably fewer than trying to overly restrict the input that can be there. But that isn't the main focus of my comment at the moment, and it seems like there are other things going on (like "original date", etc.) that are meant to address some of those concerns.
The two points that interest me the most at the moment are:
2. Capitalization, which seems easy enough to solve, as shown here: https://forums.zotero.org/discussion/comment/313791/#Comment_313791 The only thing I wonder about there is why a date can be capitalized and if (I hope not!) Zotero will "fix" that in the future, especially with some of these (worrying!) proposals above about restricting input.
3. Sorting This is the big one. Zotero seems to treat any non-date input as "0000" for the year. This shows up in the sorting within Zotero's UI, which is ugly, but an easy enough convention to get used to.
However, the fundamental problem is that it seems absolutely impossible to get the CSL styles to treat the date as text rather than a date for sorting in a bibliography. In other words, any "forthcoming" paper is treated as "0000", that is, the oldest paper by that author. I've tried several workarounds-- please let me know if I'm missing something-- nothing seems to work. @Grover20 also asked about this above.
The simple solution here would be for Zotero to treat non-numeric dates not as "0000" but as "9999". If anything, that's actually more logical, because it's a future date rather than arguably one that might exist for someone writing about Ancient Rome for example. What would be even better is some way in the CSL style to detect whether a date is numeric or not, but if sorting by date treated "forthcoming" as "9999" then that wouldn't be a problem. Cross-reference to question about this specific issue: https://forums.zotero.org/discussion/73013/sort-non-numeric-dates-last
--
Alright, I've written a very long post here. But I do hope these thoughts may be helpful for someone. The solution as-is of just using literal text in the date field almost works smoothly. I'd strongly encourage using that rather than attempting to anticipate the "important" options people might want, then restricting others.
The advantage of pre-specified categories is a) localizability and b) the ability to automatically convert the terms according to style requirements.
I think these weigh very heavily in favor of a controlled vocabulary. I don't think it's the case that the majority of researchers wants maximum flexibility in their citations. They want correct citations out of the box. The ability to convert between citation styles is at the core of CSL. You're writing with one specific style and purpose in mind. That is not universally, nor even most commonly, the case for researchers using citation managers.
(Also, please be mindful of the costs of long posts like this if you actually want something to get done. To put it quite starkly, at least on the CSL end, attention is a scarce resources. If you're not able to make a case for something in two succinct paragraphs, chances of it being implemented in the next couple of years are low).
The problem isn't "correctness", it's that there are many standards. It's clear from the discussion here, even among those who agree that restricted input is the best approach, it is not clear which style to follow. That's not going to work out well in the long run.
You're right about my long reply, and I'm sorry about that. But I really feel this will be a mistake for Zotero, and it will be hard to undo once implemented, so I wanted to express some complex thoughts about it.
Upgrade Storage
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?
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.
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.
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.
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.
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....
Is the trac bugtracker still used? Or should there be a bug on the github tracker for this?
The new variable may find its way into the next major Zotero release (not 3.0.x, but 3.5).
No news as of yet, I guess?
When is 3.5 supposed to be released?
Gratefully yours,
Citation: (Bebber & Jones, in press)
Bibliography: Bebber DP & Jones AB 2014. An exciting paper. Journal of Stuff, in press.
Thanks!
I'm just curious whether there has been any further development on this issue. Is there now any sort of "in press" option?
Thanks a lot.
If you really need this to work without modifying citations, you can hack a pseudo status field in Zotero by placing {:status: in press} in the Extra field, but that's not officially supported and I can't promise that it will be transferred in a status field once that makes it into Zotero.
If I'm in the right place, here are some thoughts:
1. I strongly disagree with restricting the possible input of the date field, especially if it would only address the most common types (some above are even suggesting merging "forthcoming" and "in press").
The practice of using a wide variety of forthcoming types is widespread, and importantly varies by field. While you might argue that isn't the best practice, Zotero shouldn't explicitly restrict it. Individual styles can of course restrict that, but Zotero shouldn't unilaterally tell me that I have to write "forthcoming" instead of "in press" or that I can't write "in preparation", etc.
Just as one example, the most variation seems to occur when authors are citing themselves, and this is a common situation where "in preparation" comes up. I'm writing from the perspective of Linguistics, which of course has its own traditions that differ from other fields, but one important perspective there is that forthcoming citations serve a different purpose from published works: they often provide data sources (a description of a language that is in progress, for example) or just additional information about arguments, rather than any sort of scientific consensus.
So being able to cite even vaguely planned future works can be useful, and being able to specify the status seems useful. (Again, there are arguments against doing that, and some styles might not allow it.)
I can't imagine a restricted input system that would cover everyone's needs, and I just don't think that's necessary. If the field parses as a typical, numerical date, then parse it as such. If not, treat it literally, and display it that way. This will also allow other less common date systems (I see discussion elsewhere about Taiwanese dates, for example.)
2. For many author-date formats, it is standard practice to use the 'status' in place of the date. For all intents and purposes, it IS the date. "Forthcoming" should not be moved to a separate "status" field, despite how popular that is in the comments above.
This is a completely separate issue from "ahead of print" publications. For that, adding a separate "status" field would be fine, although I don't see why that can't be handled with the "volume" field (or "pages", etc.). It would be a mistake to merge "forthcoming" and "ahead of print". They mean completely different things, even though both are broadly related to future dates.
3. As others have said, treating future dates as forthcoming makes no sense on a practical level. There's the fundamental issue with the same year as publication, but there's also a problem with not allowing known future dates to be cited (rare, but it happens). Again, Zotero should not be restricting what users can do, even if it isn't necessarily best practice.
4. I'm not sure how Zotero could handle style-based differences, such as Chicago vs. APA / forthcoming vs. in press. But I'd much rather see this left up to the user than restrict us in how we can use the input fields. Most users will know the standard practice in their fields and default to that, and not need to change too often. From what I can tell, text matching and replacement like "forthcoming">"in press" is not possible in current CSL styles, so that would have to be sacrified (not included) in the styles currently. But that trade-off is worth it, rather than just having, for example, one option per style. Note that it is much easier to collapse information into a single category than it is to split it, so Zotero should encourage all possible contrasts, and as applicable collapse them (or allow users to do that manually for the final draft).
---
Now, from a practical perspective:
I'm surprised that there aren't more users echoing what @Grover20 wrote above. Just typing in "forthcoming" (or whatever) to the date field has worked for me, and I didn't even realize this was a question/problem for Zotero until I started trying to customize my own style. I assumed it was obvious that "forthcoming" would go in the date field, because it IS a date (see point 1 above).
This works almost flawlessly. I'm only aware of three issues (which I why I ended up here now):
1. Complex dates are problematic. Date ranges, unknown dates, etc. But at least using the "issued:" variable in 'extra' is a reasonable workaround for now!
Actually, my first thought in response to that would be to have less parsing of dates, to simply treat that field literally. There are a few issues with that (e.g., citing a day-month-year date in the bibliography but only wanting year to appear in in-text citations), but arguably fewer than trying to overly restrict the input that can be there. But that isn't the main focus of my comment at the moment, and it seems like there are other things going on (like "original date", etc.) that are meant to address some of those concerns.
The two points that interest me the most at the moment are:
2. Capitalization, which seems easy enough to solve, as shown here:
https://forums.zotero.org/discussion/comment/313791/#Comment_313791
The only thing I wonder about there is why a date can be capitalized and if (I hope not!) Zotero will "fix" that in the future, especially with some of these (worrying!) proposals above about restricting input.
3. Sorting
This is the big one. Zotero seems to treat any non-date input as "0000" for the year. This shows up in the sorting within Zotero's UI, which is ugly, but an easy enough convention to get used to.
However, the fundamental problem is that it seems absolutely impossible to get the CSL styles to treat the date as text rather than a date for sorting in a bibliography. In other words, any "forthcoming" paper is treated as "0000", that is, the oldest paper by that author. I've tried several workarounds-- please let me know if I'm missing something-- nothing seems to work. @Grover20 also asked about this above.
The simple solution here would be for Zotero to treat non-numeric dates not as "0000" but as "9999". If anything, that's actually more logical, because it's a future date rather than arguably one that might exist for someone writing about Ancient Rome for example. What would be even better is some way in the CSL style to detect whether a date is numeric or not, but if sorting by date treated "forthcoming" as "9999" then that wouldn't be a problem.
Cross-reference to question about this specific issue: https://forums.zotero.org/discussion/73013/sort-non-numeric-dates-last
--
Alright, I've written a very long post here. But I do hope these thoughts may be helpful for someone. The solution as-is of just using literal text in the date field almost works smoothly. I'd strongly encourage using that rather than attempting to anticipate the "important" options people might want, then restricting others.
a) localizability and
b) the ability to automatically convert the terms according to style requirements.
I think these weigh very heavily in favor of a controlled vocabulary. I don't think it's the case that the majority of researchers wants maximum flexibility in their citations. They want correct citations out of the box. The ability to convert between citation styles is at the core of CSL. You're writing with one specific style and purpose in mind. That is not universally, nor even most commonly, the case for researchers using citation managers.
(Also, please be mindful of the costs of long posts like this if you actually want something to get done. To put it quite starkly, at least on the CSL end, attention is a scarce resources. If you're not able to make a case for something in two succinct paragraphs, chances of it being implemented in the next couple of years are low).
The problem isn't "correctness", it's that there are many standards. It's clear from the discussion here, even among those who agree that restricted input is the best approach, it is not clear which style to follow. That's not going to work out well in the long run.
You're right about my long reply, and I'm sorry about that. But I really feel this will be a mistake for Zotero, and it will be hard to undo once implemented, so I wanted to express some complex thoughts about it.