search

zotero / zotero-bits

CSL-related community feedback for Zotero
54 stars 8 forks source link

Request CSL exposure of the words prefix e.g. "see, e.g., "; "compare " and relevant change to Zotero. #80

Closed JohnLukeBentley closed 6 years ago

JohnLukeBentley commented 6 years ago

Key

As advised at https://github.com/citation-style-language/zotero-bits/wiki/Zotero-types-whiteboard

My Goal

In Zotero using Chicago Manual of Style 17th edition (author-date) (chicago-author-date.csl) can yield a citation like

(see, e.g., Heidegger 2008, 10-12)

However, I'd like the kind of brackets to be conditional. Specifically I'd like to be able to have in the one document the following citation formats:

The motivation for this is that when essays focus on the works of a particular author it is (sometimes) conventional to use abbreviated titles of their work. But such an essay might be interspersed with claims about other authors. In that case we might want to use the usual author-date citation form. So my goal is to be able to produce something like ...

Nietzsche called for such-and-such [see, e.g., Z, 30-34], then contrasted that with thing [BGE, 90-95]. An idea we find in Heidegger (see, e.g., Heidegger 2008, 10-12).

... where the square brackets "[]" signal that the citation uses a short title form; and round brackets "()" signals that the citation uses the usual author-date form.

Wih the current version of Zotero a CSL file can be coded so the bibliography is formatted desirably. However, achieving the citation formatting as in the above example seems currently impossible. I suggest a few changes to CSL and Zotero to enable it...

Terminology

Consider again a conventional author-date citation like 

(see, e.g., Heidegger 2008, 10-12).

The parts of that citation have slightly different names in a Zotero versus Citation Style Language (CSL). Specifically, with regard to the the use of "prefix":

To see this in Zotero do the following ...

So, to distinguish the two contexts and uses of "prefix" I'll use the terms ...

I don't mean to necessarily promote this terminology beyond this thread.

CSL Problem

In Chicago Manual of Style 17th edition (author-date) (chicago-author-date.csl) there is the following CSL citation.

<citation et-al-min="4" et-al-use-first="1" disambiguate-add-year-suffix="true" disambiguate-add-names="true" disambiguate-add-givenname="true" givenname-disambiguation-rule="primary-name" collapse="year">
  <layout prefix="(" suffix=")" delimiter="; ">
    <group delimiter=", ">
      <choose>
        <if variable="issued accessed" match="any">
          <group delimiter=" ">
            <text macro="contributors-short"/>
            <text macro="date-in-text"/>
          </group>
        </if>
        <!---comma before forthcoming and n.d.-->
        <else>
          <group delimiter=", ">
            <text macro="contributors-short"/>
            <text macro="date-in-text"/>
          </group>
        </else>
      </choose>
      <text macro="point-locators"/>
    </group>
  </layout>
</citation>

We can see this working in MS Word:

All good so far.

Consider a change to the citation code as follows ...

<citation et-al-min="4" et-al-use-first="1" disambiguate-add-year-suffix="true" disambiguate-add-names="true" disambiguate-add-givenname="true" givenname-disambiguation-rule="primary-name" collapse="year">
  <layout prefix="*" suffix="*" delimiter="; ">
    <choose>
      <if variable="title-short" match="any">
        <group prefix="[" suffix="]" delimiter=", ">
          <text variable="title-short" />
          <text macro="point-locators" />
        </group>
      </if>
      <else>
        <group prefix="(" suffix=")" delimiter=", ">
          <choose>
            <if variable="issued accessed" match="any">
              <group delimiter=" ">
                <text macro="contributors-short"/>
                <text macro="date-in-text"/>               
              </group>
            </if>
            <!---comma before forthcoming and n.d.-->
            <else>
              <group delimiter=", ">
                <text macro="contributors-short"/>
                <text macro="date-in-text"/>
                <text variable="title" font-style="italic" />
                <text variable="title-short" prefix="!" suffix="!" />
              </group>
            </else>
          </choose>     
          <text macro="point-locators" />
        </group>
      </else>
    </choose>
  </layout>
</citation>

Essentially I've:

        ...
        <group prefix="[" suffix="]" delimiter=", ">
        ...
        <group prefix="(" suffix=")" delimiter=", ">

In Zotero, given our Nietzsche entry has a "Short Title" of 'Z' (and so will trigger the <if variable="title-short" match="any"> conditional), then our short title citation format yields:

*see, e.g., [Z, 30–34]*

... however what we want, when a "Short Title" is set (and so will trigger the <if variable="title-short" match="any"> conditional), is ...

[see, e.g., Z, 30–34]

... and the problem is that the Zotero processor inserts the "words prefix", here "see, e.g., ", behind the scenes. This is quite unlike <text macro="point-locators" /> which eventually relies on the relevant variable CSL exposes, locator.

That is, CSL and the Zotero processor exposes a locator variable for csl authors to use, but no words-prefix (nor words-suffix) variable to use.

The Suggested Solution

My suggested solution is to:

With those changes I'd be able to do something like

<citation ...  words-affix-variables-on=true ...>
  <layout prefix="" suffix="" delimiter="; ">
    <choose>
      <if variable="title-short" match="any">
        <group prefix="[" suffix="]" delimiter=", ">
          <text variable="words-prefix" />
          <text variable="title-short" />
          <text macro="point-locators" />
        </group>
      </if>
      ...

To yield, when the <if variable="title-short" match="any"> conditional is matched, the desired output ...

[see, e.g., Z, 30–34]

... and, when the <if variable="title-short" match="any"> conditional is not matched, I'll be able to get from the <else> clause ...

(see, e.g., Heidegger 2008, 10-12)

Edit: Removed unnecessary "has".

fbennett commented 6 years ago

I think the second feature is covered by the Indigo Signals plugin:

https://juris-m.github.io/downloads/

FB

On Tue, Apr 17, 2018, 14:28 John Luke Bentley notifications@github.com wrote:

Key

As advised at https://github.com/citation-style-language/zotero-bits/wiki/Zotero-types-whiteboard

  • Zotero field labels: quotes. "# of Pages"
  • Zotero field name: bold numPages
  • CSL field names: bold number-of-pages

My Goal

In Zotero using Chicago Manual of Style 17th edition (author-date) (chicago-author-date.csl) can yield a citation like

(see, e.g., Heidegger 2008, 10-12)

However, I'd like the kind of brackets to be conditional. Specifically I'd like to be able to have in the one document the following citation formats:

  • "(see, e.g., Heidegger 2008, 10-12)", if the Zotero entry has a blank "Short Title"; and
  • "[see, e.g., Z, 88-90]", if the Zotero entry has a non-blank "Short Title" (here it is given "Z", short for, say, a "Title" of "Thus spoke zarathustra: a book for everyone and no one" ... a work by Nietzsche).

The motivation for this is that when essays focus on the works of a particular author it is (sometimes) conventional to use abbreviated titles of their work. But such an essay might be interspersed with claims about other authors. In that case we might want to use the usual author-date citation form. So my goal is to be able to produce something like ...

Nietzsche called for such-and-such [see, e.g., Z, 30-34], then contrasted that with thing [BGE, 90-95]. An idea we find in Heidegger (see, e.g., Heidegger 2008, 10-12).

... where the square brackets "[]" signal that the citation uses a short title form; and round brackets "()" signals that the citation uses the usual author-date form.

Wih the current version of Zotero a CSL file can be coded so the bibliography is formatted desirably. However, achieving the citation formatting as in the above example seems currently impossible. I suggest a few changes to CSL and Zotero to enable it... Terminology

Consider again a conventional author-date citation like

(see, e.g., Heidegger 2008, 10-12).

The parts of that citation have slightly different names in a Zotero versus Citation Style Language (CSL). Specifically, with regard to the the use of "prefix":

  • In a CSL context "prefix" typically references the left hand bracket type you choose "[,{,(, etc." (although CSL does not restrict your prefix choice to brackets). For example in chicago-author-date.csl there is

  • In a Zotero context "prefix" references the "see, e.g., " part.

To see this in Zotero do the following ...

  • {Zotero Standalone} open.
  • {Firefox} > Surf to https://www.amazon.com/Being-Harper-Perennial-Modern-Thought/dp/0061575593/ref=sr_1_1?s=books&ie=UTF8&qid=1522473346&sr=1-1&keywords=heidegger
  • Save this to Zotero.
  • {MS Word} open. Blank document.
  • {MS Word} > |Zotero| ribbon menu. > [Document Preferences]. Choose "Chicago Manual of Style 17th edition (author-date)". [OK]
  • Click anywhere in your blank Word doc.
  • {MS Word} > |Zotero| ribbon menu. > [Add/Edit Citation]. Type "Heidegger". Press enter when "Being and Time" appears in the dropdown box.
  • Observe "Heidegger, 2008" is given in a blueish ellipse in the red bordered citation text box. Click inside the blueish ellipse. A dialogue box appears to supply ad hoc values for the citation:
    • Prefix: enter "see, e.g., " (include the trailing space).
    • Page: enter "10 - 12".
    • [OK]. [OK]
  • Observe in your Word document the citation: "(see, e.g., Heidegger 2008, 10-12)" .

So, to distinguish the two contexts and uses of "prefix" I'll use the terms ...

  • "bracket prefix" E.g. "("; and
  • "words prefix" E.g. "see, e.g., ".

I don't mean to necessarily promote this terminology beyond this thread. CSL Problem

In Chicago Manual of Style 17th edition (author-date) (chicago-author-date.csl) there is the following CSL citation.

We can see this working in MS Word:

-

{Zotero Standalone} open.

{MS Word} > Zotero MS Word Plugin > [Add/Edit Citation ...]

Citation box (red bordered) > Start typing "Heid" to bring up the "Heidegger" entry previously stored in Zotero.

Click on the chosen entry to edit:

  • the words prefix of "see, e.g., "; and
    • A page locator value of "10-12"; ...

  • [OK], [OK]

  • ... then the following kind of citation is inserted into the body of our MS Word document:

    (see, e.g., Heidegger 2008, 10-12)

All good so far.

Consider a change to the citation code as follows ...

Essentially I've:

  • Made it so there are two citation formats that are conditioned on whether there is, in Zotero, a "Short Title" value.

  • Given different brackets affixes to these two citation formats, namely ...

    ...
<group prefix="[" suffix="]" delimiter=", ">
...
<group prefix="(" suffix=")" delimiter=", ">

  • I've given asterisks "*" to the layout element affixes for debugging purposes, to make clear how the processor currently behaves ...

    ...

    ....

In Zotero, given our Nietzsche entry has a "Short Title" of 'Z' (and so will trigger the conditional), then our short title citation format yields:

see, e.g., [Z, 30–34]

... however what we want, when has a "Short Title" is set (and so will trigger the conditional), is ...

[see, e.g., Z, 30–34]

... and the problem is that the Zotero processor inserts the "words prefix", here "see, e.g., ", behind the scenes. This is quite unlike <text macro="point-locators" /> which eventually relies on the relevant variable CSL exposes, locator.

That is, CSL and the Zotero processor exposes a locator variable for csl authors to use, but no words-prefix (nor words-suffix) variable to use. The Suggested Solution

My suggested solution is to:

  • Change the CSL spec:
    • Create a variable, something like words-prefix (again I'm not necessarily wedded to this terminology), that will expose to processors, like Zotero, the relevant user entered string, like "see, e.g., ".
    • For symmetry also create words-suffix.
    • For backwards compatibility create a citation attribute, something like words-affix-variables-on.
      • The default is words-affix-variables-on=false, to maintain the present behaviour. With this (default) option the processor inserts the words affixes in the background, as it currently does.
      • With words-affix-variables-on=true csl authors have words-prefix and words-suffix available to them and the processor does not insert the words affixes in the background (so the processor relies on the presence of words affix variables that the CSL author can choose to include or exclude).
    • Change the Zotero processor to support the above.

With those changes I'd be able to do something like

<citation ... words-affix-variables-on=true ...>

... To yield, when the conditional is matched, the desired output ... [see, e.g., Z, 30–34] ... and, when the conditional is not matched, I'll be able to get from the clause ... (see, e.g., Heidegger 2008, 10-12) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub , or mute the thread .
fbennett commented 6 years ago

The first feature (setting parens or brackets depending on the content of a variable) can be done in a custom version of the style. It's a non-standard change, so it wouldn't be accepted to the repository for general circulation; but you can certainly adjust the code in Chicago author-date to do this. Be sure to also change the ID and style name in the header of the CSL file, to avoid confusion and to prevent your custom code from being overwritten by an automatic update.

JohnLukeBentley commented 6 years ago

Thanks Frank.

I'd count only one feature request, albeit with parts, in my first post: the exposure of words prefix, e.g. "see, e.g., ", at the CSL level and the use of this by Zotero. I'd include in that feature, for completeness, the supporting things I mentioned: exposing a suffix prefix words suffix and the backwards compatibility mechanisms.

But you are counting features in a different way and so I'll address your count ...

I think the second feature is covered by the Indigo Signals plugin: https://juris-m.github.io/downloads/

I'm grateful for your having pointed me to this. However, from the description of the "Indigo Signals" at https://github.com/Juris-M/bluebook-signals-for-zotero ...

A simple plugin that adds a menu of standard Bluebook signals to the Prefix field of the Zotero/MLZ work procesor plugins.

... this is not what I'm after in this thread. I'm not wanting (for the purposes of this thread) standardized words prefixes (aka "signals") but exposure of a words prefix variable in CSL in order to conditionally set brackets (and allow other CSL authors doing all sorts of other things with an exposed words prefix).

The first feature (setting parens or brackets depending on the content of a variable) can be done in a custom version of the style.

Well, that affords me opportunity to be clearer, I demonstrate the use of a custom style to produce different brackets depending on the content of a variable. I produced ...

*see, e.g., [Z, 30–34]*
*see, e.g., (Heidegger 2008, 10–12)*

(I failed to make it explicit in my first post that "*see, e.g., (Heidegger 2008, 10–12)*" was produced)

The issue is to do this in a manner that conditionally outputs the outer most brackets while including the words-prefix part. That is, so that both of the following can be produced in the one document.

[see, e.g., Z, 30–34]
(see, e.g., Heidegger 2008, 10-12)

If by "you can certainly adjust the code in Chicago author-date to do this" you mean (with or without the Indigo Signals plugin) you can produce the later set of output by modding Chicago author-date, I'd love to see how this is done.

But at the moment this appears impossible to me because all the following are true:

    <layout prefix="*" suffix="*" delimiter="; ">

As an incidental point, and tacking a tip from your having been over this territory before, a "signal prefix" and "signal-suffix" is probably better terminology than "words prefix" and "words suffix". But for this thread I'll stick with my original terminology to avoid causing whiplash to readers.

Edit 01:

It's [conditional brackets] not a non-standard change, so it wouldn't be accepted to the repository for general circulation; ...

Indeed. As far as I'm aware it's not something accommodated by the usual Style Manuals. Although there is latex/biblatex accommodations of "abbreviations" lists in a bibliography which serve the same purpose. But, yes, at this point I have no desire to advocated for a CSL style so changed to accommodate this, to be included in the repository for general circulation.

Be sure to also change the ID and style name in the header of the CSL file, to avoid confusion and to prevent your custom code from being overwritten by an automatic update.

Indeed ... as we recently discovered with JurisM.

Edit 02: "suffix prefix" to "words suffix".

fbennett commented 6 years ago

I just refer to them as signals because that's what they call them in US legal writing. Just a habit. As to the proposal, this would be very tough to implement, with complexity that would ripple from the CSL specification, through the citation style engines that implement it, and on into the applications (Zotero, Mendeley, pandoc, others) that consume CSL. Since, as you say, styling of this kind is not a feature of most (of any?) style manuals, it's very unlikely to be adopted by CSL. The styling language needs to strike a balance between (maximal) coverage and (minimal) complexity, and I fear that this ramps up complexity quite a bit to achieve only a very modest gain in coverage.

adam3smith commented 6 years ago

I only read this quickly (please try to keep these short; I appreciate wanting to go into detail, but this is overkill and the level of details actually does more to obsure than elucidate the key points).

What I'm seeing as the user story are basically two different citation layouts. The problem both for this idea in general and for the proposal are citations with multiple items, which are one of the main reasons the affixes need to sit on layout. For one, the proposal doesn't address that putting affixes on groups would cause (Heidegger 2008)(Ahrendt 1960) instead of (Heidegger 2008; Ahrendt 1960) I'm sure there's some way around this, but not without adding more complexity to this.

I was first thinking we could just solve this by allowing different layouts on citations as per your second comment -- use the one where title-short="true" and the other where it's false -- but that only works if a citation is a single item. What to do when it's a group and the condition evaluates differently for elements of the group? Again, it's probably possible to address this, but not without significant added complexity. I'm not seeing us add something this complex unless there's massive demand, sorry.

bdarcus commented 6 years ago

Yes, I would second plea from @adam3smith to keep these much more concise. I don't have the time to try to understand this anytime soon.

But, on first glance, I don't see any references to style guides. When I see a request like this, my immediate response is "seems like overkill without broad practical need," so important to have that documentation to help us to assess need.

Also, again not having read this in depth, are there not existing work arounds for what you're after? Like, if you want different brackets, you could manually do the brackets, and then tell Zotero to not output the default one?

JohnLukeBentley commented 6 years ago

Thanks @fbennett, @adam3smith and @bdarcus.

Solving multiple items in a citation

@adam3smith

What I'm seeing as the user story are basically two different citation layouts.

With respect to my exemplifying conditional brackets affixes style, that's right.

@adam3smith

The problem both for this idea in general and for the proposal are citations with multiple items, which are one of the main reasons the affixes need to sit on layout. For one, the proposal doesn't address that putting affixes on groups would cause (Heidegger 2008)(Ahrendt 1960) instead of (Heidegger 2008; Ahrendt 1960)

That's a helpful point to raise ....

I was first thinking we could just solve this by allowing different layouts on citations ... -- use the one where title-short="true" and the other where it's false -- ....

That is a promising solution ...

but that only works if a citation is a single item. What to do when it's a group and the condition evaluates differently for elements of the group? ... it's probably possible to address this, but not without significant added complexity.

I think I see this objection. But I think this can be addressed with a small change.

... I think you are noticing a problem of indeterminacy with my example style, so far stipulated. That is, if my example style rules are (as they have been):

... then, on those rules, when there are multiple items for the one citation, the format is indeterminate. That is, it's not clear if (given "Z" is a title-short for a work by Nietzsche) we should output ...

This can be overcome by imagining a third style rule to resolve the indeterminacy. E.g. "If there are multiple items, then choose the square brackets format if any of the items has a short-title". This is a somewhat arbitrary rule. But that there needs to be one rule or another, to resolve the indeterminacy.

And to support that sort of rule in CSL we could add to the if element an items-match attribute taking values "all", "any", or "none" (somewhat echoing the match attribute). The items-match attribute makes the if element apply to all items in the citation. So:

So, if I've thought this through correctly, all of the following formats could be achieved in the one document ...

... with a structure like ...

<citation ...>
    <choose>
      <if variable="title-short" items-match="any">
        <layout prefix="[" suffix="]" delimiter="; ">
          ...
          <text variable="title-short" />
          ...
        </layout>
      </if>
      <else>
        <layout prefix="(" suffix=")" delimiter="; ">
          <choose>
            <if variable="issued accessed" match="any">
              <group delimiter=" ">
                ...          
              </group>
            </if>
            <else>
              <group delimiter=", ">
                ...
              </group>
            </else>
          </choose>     
          ...
        </layout>
      </else>
    </choose>
  </layout>
</citation>

So, unlike my previous code example (in my first post), the bracket affixes now sit on a layout rather than a group ... in line with your suggested solution. The two if statements above also exemplify using items-match as I propose and match as normal.

That solution achieves conditional brackets affixes without exposing the words prefix (like "see, e.g.,") at the CSL level.

it's probably possible to address this, but not without significant added complexity.

If that addition to your solution works then it is an addition of more complexity, as you intuited. I don't think the added complexity is significant but there's room for disagreeing (particularly if there are further problems that would need to be addressed).

The updated proposal

In my prior posts I've had it in mind that a change be made only to expose the words prefix (and words suffix for completeness). That is, my style of having conditional brackets affixes was intended only to serve as an example of why exposing the words prefix could be valuable. But given we've just seen how conditional brackets affixes could be provided without exposing the words prefix, I'll propose both as separate matters. That is, my suggestion is now that CSL (and Zotero) be changed to allow both:

... with conditional brackets affixes being the more important suggestion.

The need for these

fbennett wrote

the proposal, .... would ripple from the CSL specification, through the citation style engines that implement it, and on into the applications (Zotero, Mendeley, pandoc, others) that consume CSL.

That would be the intention, that all processors that rely on CSL make the change. This is the same for any proposed change to CSL. Of course you raise this point to mention that the ramifications of the change may not be worth the gain, a point repeated by both adam3smith and bdarcus .....

adam3smith

I'm not seeing us add something this complex unless there's massive demand, sorry.

bdarcus:

When I see a request like this, my immediate response is "seems like overkill without broad practical need,"

Certainly, if there was existing popular demand for the suggested changes then that would strongly justify making the changes. But there is not popular demand for either change ...

bdarcus:

But, on first glance, I don't see any references to style guides.

From my second post ...

As far as I'm aware [conditional brackets affixes is] not something accommodated by the usual Style Manuals. Although there is latex/biblatex accommodations of "abbreviations" lists in a bibliography which serve the same purpose.

Given you've mentioned the issue of existing usage (as might be represented by a Style Guide) I'll provide further detail ...

The need for conditional brackets affixes

My conditional brackets affixes style is, as I've mentioned, an alternative way to style an existing (occasional) two-formats convention when the works of a particular author is examined. I'm not aware of a Style Guide that promotes that two-formats convention (although I'm not particularly across all the Style Guides). However, to demonstrate that it exists as a (an occasional) convention behold an entry in the Stanford Encyclopedia of Philosophy, a respected academic publication: https://plato.stanford.edu/entries/nietzsche/

We can observe two citation formats in the following:

extremely elliptical and allusive (e.g., GS 109), or highly metaphorical and quasi-hermetic (Z III, 2, 13) .... Many later commentators have focused instead on the existential or practical significance of the thought (Magnus 1978; Nehamas 1980, 1985), or its “mythological” import (Hatab 2005). [Italic original]

... in this entry in order to differentiate the two formats the short title is italicised. There's no conditional brackets affixes: there's just one bracket style.

Incidentally, and to give a fuller picture of the used convention, the bibliography lists the short titled works first, followed by the Author-Date works ...

GS The Gay Science, Walter Kaufmann (trans.), New York: Vintage, 1974 (1st ed. 1882, 2nd ed. 1887). (I also consulted The Gay Science, J. Nauckhoff (trans.), Cambridge: Cambridge University Press, 2001.)
Z Thus Spoke Zarathustra, Walter Kaufmann (trans.), New York: Viking, 1954 (1883–5).
...
Magnus, Bernd, 1978, Nietzsche’s Existential Imperative, Bloomington, IN: Indiana University Press.
Nehamas, Alexander, 1980, “The Eternal Recurrence”, The Philosophical Review, 89(3): 331–56. doi:10.2307/2184393
–––, 1985, Nietzsche: Life as Literature, Cambridge, MA: Harvard University Press.

All that can be (more or less) achieved, both the two citation formats and the two bibliography formats, using CSL and Zotero as they exist today.

I think that's sufficient evidence of the (occasional) two-formats convention of differentiating a particular author's work from other authors. But it is not evidence of usage of my conditional brackets affixes style. That's because I don't think my conditional brackets affixes style is used by anybody else. At least I'm not aware of it being used by anybody else.

However, I don't think past cases of style use is the only important metric. I'd suggest a style language ought be supporting future possible styles having potential value. That is, to facilitate style authors innovating styles, unshackled from tradition. Because, of course, there may be ways to improve upon tradition.

And my alternative styling, having conditional brackets affixes, for differentiating a particular author's work from other authors strikes me as superior. The two kinds of citations are more clearly visually marked with different brackets rather than the more subtle italics.

But this is to mention only one possible application of conditional brackets affixes. They could be used for any document where kinds of works could be usefully visually differentiated. For example:

... that is, conditional brackets affixes could find value in styles that support differentiating works into a wide array of two or more possible categories.

The need for exposing words affixes

Given that conditional brackets affixes can be achieved without having to expose words affixes at the CSL level, there's less of a need for exposing words affixes. Personally, if conditional brackets affixes was implemented, and words affix exposure was not, then this would give me everything I'd be after.

However some future style author my like to apply some formatting to a words affix, e.g. to code something like <text variable="words-prefix" font-style="italic" />. That would count as a (defeasible) reason for exposing words affixes at the CSL level.

Workarounds

bdarcus:

Also, again not having read this in depth, are there not existing work arounds for what you're after? Like, if you want different brackets, you could manually do the brackets, and then tell Zotero to not output the default one?

I do as you suggest (at least a version of it) in my first post precisely to demonstrate how it doesn't produce the desired output (see the second code block under "CSL Problem").

Brevity

I apologize for not being clear in the "CSL problem" section of my first post. I feel that was rectified in my second post.

But I don't think the criticism from both of you, adam3smith and bdarcus, that I needed to be briefer (with respect to my first post overall) is true. Mine was a simple assertion about what ought be, and a simple assertion is captured concisely by the title. But that simple assertion requires an explanation with length and precision to provide motive, remove ambiguity, and avoid misinterpretation. Particularly since this problem was, at least for me, hard to describe.

It is, in general, plausible to say someone ought cover more ground with fewer words - here you've both complained that my post failed to cover ground that you think it ought have - for example on the multiple items in a citation issue, and on style guides, respectively. Those were helpful and relevant points to raise (or emphasize), and I've expanded upon them above. But to frame those as a failure by me to mention something I should have, somewhat undercuts your criticisms that I ought to have said less.

And bdarcus, in particular, it is fine to flag that you've skimmed the post and may well have missed my mentioning points that you then raise. But when those points turn out to be things that I have indeed raised then ... to complain that I should have both said more and less ... is a somewhat strained complaint.

But I don't think any of us will have an interest in settling that matter, on whether I ought have said less. For brevity we could continue to disagree.

The present post has length. The hope is that the time saved by not having to make inferences about the issue, because those inferences are laid out in the post, well compensate the time lost in reading. And that, therefore and moreover, any responding post is enabled to be far shorter than my own.

fbennett commented 6 years ago

That is certainly a lengthy treatment of the proposal. Let's take a step back and think about the process of preparing a manuscript.

You have a very concise citation format for the commonly cited works: one or two letters followed by a pinpoint. I don't see any advantage in using dedicated software to generate these references. It seems much simpler to just write in the references as text. That will be considerably faster than inserting Zotero citations. At the final stage of production, the full references to each item can be added to the bibliography as uncited items, the document can be stripped of Zotero codes, and the short-form identifiers can be entered in front of each item in the bibliography. If I understand correctly, that yields a finished document that conforms to the style conventions you describe.

JohnLukeBentley commented 6 years ago

Thanks @fbennett. I am welcoming of that sort of lateral consideration. Yes something close to that procedure could give me the style conventions I describe. However, I'd regard that as a workaround.

The advantage in using software (and we'll have in mind something like the Zotero Word Plugin) to generate a citation for a short-form citation is the same for using software to generate the long form-citation: having links to a central database that affords ready updating to all the linked fields.

If, in one's 3000 word essay, an abbreviation for a commonly cited work needs to change (for example, because you want to refer to another work of the commonly cited author with a title which, if abbreviated, would collide with a prior abbreviation referring to a different work) then updating the "Short Title" field in Zotereo and refreshing the many existing citations in your essay is a great aid.

This is why you'd pay the price of using the Zotero Work Plugin Citation mechanism rather than just using Quick Copy from Zotero Standalone (or just typing the citation out, as you suggest). Or put another way I don't think that cost-benefit differs significantly for (Heidegger 2008, 34) compared with [Z, 55].

adam3smith commented 6 years ago

Thanks for the additional details. It boils down to this:

However, I don't think past cases of style use is the only important metric. I'd suggest a style language ought be supporting future possible styles having potential value. That is, to facilitate style authors innovating styles, unshackled from tradition. Because, of course, there may be ways to improve upon tradition.

No, sorry. CSL is a reactive project. There are many good reasons for this: we already can't keep up with existing tradition; we don't think we have a good way of predicting what innovation will stick; and at least as individuals (not sure if CSL has a position on this) most of us believe that citation styles should see more standardization, not more diversity, so we're certainly not going to encourage such diversity.

As you say, the case for allowing abbreviated citations to works is indeed strong and some version of abbreviation and a "classical work" item type (the way they already exist in @fbennett 's juris-m fork of Zotero/CSL) will likely be implemented to address those. We'll worry about allowing different layouts if this does become a thing. Closing this.

JohnLukeBentley commented 6 years ago

Thanks Sebastian.

and at least as individuals (not sure if CSL has a position on this) most of us believe that citation styles should see more standardization, not more diversity, so we're certainly not going to encourage such diversity.

In a sense, you'll have to count me as a believer too. I'm unclear if there's a single ideal citation style that could handle all possible relevant documents, but if not the hope would be that there would a mere few citation styles that emerge as standard. But as of today at https://www.zotero.org/styles we have 9070 styles. Academic Journals seem frequently to stipulate their own variant "house" style.

That seems to suggest, as a matter of history, we are still in a phase where we are still experimenting with styles. It also seems that the path toward more standardization will entail a competition between these styles, to knock most of them out. And that competition needs to occur along with all sorts of experimenting innovations (some of which turn out to be bad innovations).

we don't think we have a good way of predicting what innovation will stick

Indeed. Which is why, I'd suggest, we should be loathe to prevent a set of innovations at the level of the style language.

But this is probably too broad a point to have a bearing on the present (now closed) issue.

And you even if you found that persuasive my prejudice will be that you'll fall on the negative side of

I don't think the added complexity is significant but there's room for disagreeing ...

I note also "we already can't keep up with existing tradition" (and we might say, the many clearly more high priority issues).

Or, at least, I think you've understood my arguments sufficiently such that your closing the issue is sufficiently considered. So I don't won't to persuade you to reopen it. Thanks very much for the consideration!

Edit: "suggestion" to "suggest".