A post on the forums (
http://forums.zotero.org/discussion/8616/accepted-in-print-and-submitted-in-cit-and-bib-how/)
reminded me that we still don’t have a good solution for styles that need to
output item status. For CSL, would it make sense to create a new conditional
(“status”) with some predefined values (e.g. the BIBO values: accepted,
draft, forthcoming, nonPeerReviewed, peerReviewed, published, rejected,
unpublished)? Each value could have an accompanying term, and having the
conditional would make it easy to control style layout.
Rintze
Why the need for a conditional? I see it as just a simple variable.
Bruce
So it would be just a string, without preset (and localized) values?
Rintze
Probably. But even if not, I don’t think that changes things WRT to
any conditionals (just need to add terms).
Bruce
Terms? How would you select the right term?
Rintze
So it would be just a string, without preset (and localized) values?
Probably. But even if not, I don’t think that changes things WRT to
any conditionals (just need to add terms).
Rendering can be done through text+term=“status” in the usual way.
But a conditional would be needed where the style requires in-press
cites to be formatted differently. To handle that, the test should
return true only if the status variable is set to “in press”, and
false if it is set to some other value.
So it would be just a string, without preset (and localized) values?
Probably. But even if not, I don’t think that changes things WRT to
any conditionals (just need to add terms).
Rendering can be done through text+term=“status” in the usual way.
But a conditional would be needed where the style requires in-press
cites to be formatted differently. To handle that, the test should
return true only if the status variable is set to “in press”, and
false if it is set to some other value.
Have done some poking around, and I must confess that I don’t see any
cases where the format of a citation changes radically because the
source is not yet published. The only case I can think of where a
change in form might be needed is a bibliography style that sorts on
status, to list unpublished or in-press works separately. But I’ll
admit that I haven’t seen such a creature.
There’s another little wrinkle to consider. The possible values in
the status field may vary from style to style. The permissible values
in the data should cover a full range of possibilities (see the list
below), but a style might choose to ignore some of them, or to use a
single label to stand for several of them. I think this second issue
can be covered adequately by just manipulating the locale term
definitions.
So perhaps we could put the conditional idea on hold, to see if there
is specific demand for it, and just be sure that there is a full set
of terms in place to describe status, as Bruce recommends.
From bibo, via Rintze:
bibo:status
bibo:status/accepted
bibo:status/draft
bibo:status/forthcoming
bibo:status/nonPeerReviewed
bibo:status/peerReviewed
bibo:status/published
bibo:status/rejected
bibo:status/unpublished
But how do you select between terms, depending on the content of the
status-field? E.g. a style might use both “accepted” (which is not yet “in
press”) and “in press”.
RintzeOn Fri, Sep 11, 2009 at 12:40 AM, Frank Bennett <@Frank_Bennett>wrote:
Maybe we need to clarify the use case for CSL:
“accepted” makes no sense in a citation. The most typical value if
going to be “forthcoming”, as in “this article is going to be
published, but it’s not as I put together this bibliography.”
Right?
Bruce
So perhaps we could put the conditional idea on hold, to see if there
is specific demand for it, and just be sure that there is a full set
of terms in place to describe status, as Bruce recommends.
But how do you select between terms, depending on the content of the
status-field? E.g. a style might use both “accepted” (which is not yet “in
press”) and “in press”.
Wouldn’t you just print the term? The field content maps to a locale
term, and the string from the locale term is fed in to the processor,
just like any other term rendered through the text element.
This style guide gives both examples of “in press” items and
"publish-ahead-of-print manuscripts":
http://aem.asm.org/misc/journal-ita_org.dtl#03 (references 2 & 6, plus
section (iv)).
Rintze
I have been thinking about this some more, and I can’t think of an analogue
case in CSL 1.0. The current opinion seems to have converged to defining the
different statuses as terms (so they can be localized), and restricting the
value of the status field to the names of these status terms (“forthcoming”,
etc.). However, using cs:text to render the contents of the "status"
variable would greatly deviate from the way cs:text normally operates when
used to render variables. Instead of rendering the unparsed contents of the
variable, here the variable contents would be replaced by the contents of
the matching term. In CSL 1.0, I think we only see something similar happen
for cs:label (where the term used depends on the creator type), cs:number
(where ordinal terms are used based on the numeric value of the variable)
and cs:date (where a “long” or “short” month term is selected based on the
month parsed from the input date). Are we comfortable adding this type of
behavior to cs:text, or should we revisit the conditional-based solution (or
think of something else)?
RintzeOn Fri, Sep 11, 2009 at 9:31 AM, Frank Bennett <@Frank_Bennett>wrote:
So just so we’re on the same page, my understanding was we’d see something like:
<cs:text term=“status”/>
I don’t see anything odd about that. The question, I guess, is how a
processor knows what, if any, term to print.
Perhaps we ought to borrow the approach used for months?
<cs:term name=“status-1”>in press</cs:term>
Bruce
If we do choose to use cs:text, calling the “status” variable seems to make
more sense, as the status is part of the item metadata, e.g.:
<cs:text variable=“status”/>
But replacing the content of a variable (e.g. { “status” = “in press” } by a
matching term ( in press ) would be unique
behavior for cs:text.
Rintze