From: Richard Lawrence <richard.lawrence@berkeley.edu>
To: "András Simonyi" <simonyi@all.hu>,
"Nicolas Goaziou" <mail@nicolasgoaziou.fr>
Cc: tumashu <tumashu@163.com>, emacs-orgmode <emacs-orgmode@gnu.org>,
John Kitchin <jkitchin@andrew.cmu.edu>
Subject: Re: Should wip-cite branch be merged to master?
Date: Wed, 25 Apr 2018 12:19:47 -0700 [thread overview]
Message-ID: <87efj39jqk.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <87in8jaywk.fsf@all.hu>
[-- Attachment #1: Type: text/plain, Size: 5364 bytes --]
Hi everyone,
I don't have too much to add to this, though I do want to thank
everyone for their continued interest in citations, and the work
that has been done!
Since the question of syntax has come up again, I guess I want to
address one point that András made:
András Simonyi <simonyi@all.hu> writes:
> From the citeproc-el/CSL point of view, the current syntax is
> perfect with the notable exception of the provided citation
> commands. Currently only `cite' and `(cite)' are supported,
> where the latter seems to be intended to provide the
> parenthetical version of a basic citation, e.g. in an
> author-date style `cite' would produce something like `Smith
> 2018` while `(cite)' `(Smith 2018)'. Now I think that for
> author-date styles `cite' should produce the parenthetical
> version and that `(cite)' probably shouldn't be among the
> commands at all. The main reason is that most citation
> processors (biblatex, CSL processors etc.) support not only
> author-date citation styles but footnote-based ones as well, and
> the concept of a `parenthetical citation' doesn't really make
> sense for the latter.
I think this actually gets at one of the fundamental problems with
citations, namely, they resist attempts to separate 'content' from
'style'. It is hard to insert citations into a document without
making any assumptions about how they will be rendered by the
citation processor. And so it is hard to come up with a syntax
that is general enough to represent widely different citation
styles, in a way that makes those assumptions explicit in the
syntax of the unprocessed citation, so that the content of the
citation can be separated from how it will be rendered. Thus we
see the huge proliferation of different citation commands in
e.g. BibLaTeX, natbib, and similar packages. András' proposal
would reintroduce some of the complexity of BibLaTeX citation
commands at the level of Org syntax.
Maybe having multiple citation commands is ultimately the best way
to go, but I want to point out that one of the goals of the
original discussion to come up with an Org syntax that is simpler
and does a better job of separating content and style. Anyway,
that was one of my goals in synthesizing people's various
suggestions and needs into a concrete syntax proposal. I think we
should try to avoid proliferation of citation commands.
If that is a reasonable goal, then I think there is really just
one distinction that deserves to be represented at the level of
citation commands: the distinction between 'in text' and
'parenthetical' citations, that is, the distinction between
'cite:' and '(cite):' in the current syntax in wip-cite. That
brings me to this point:
> A more abstract characterization which is applicable to all
> styles is that normally references are not part of the main
> text, they are set off either by brackets or in a note. Since
> this is the most frequent, basic form, I think this the one
> which should be produced by the `cite' syntax, that is, when
> used in normal text `cite' should produce something like `(Smith
> 2018)' for author-date styles and a note with the reference for
> note styles.
I think András' abstract characterization is exactly right: the
issue here is not really about whether the citation has brackets
around it. Instead, it is about whether the rendered citation is
intended to be *read as part of the surrounding sentence*
('in-text'), or whether it is *grammatically independent* of the
main text ('parenthetical'). I disagree, however, that
'parenthetical' citations are the normal or usual case; I think
that depends completely on one's field, writing style, etc. (In
my dissertation, for example, in-text citations outnumber
parenthetical citations roughly 3:2.)
The 'in-text' vs. 'parenthetical'/'out-of-text' distinction is
really the fundamental one that you can't abstract from as an
author. And it seems to me that apart from this decision, most of
the other decisions about styling can handed off to the citation
processor, via a choice of CSL file, at least for the out-of-text
case: is it a note-based style, or a Harvard-like one? etc.
The in-text case is a little trickier because you need a way to
represent the different kinds of data that might be intended to
fit into the surrounding sentence (author name? year? both? just a
number? etc.). But there are many many possibilities here, and
for that reason I think it is better to avoid making them
primitive citation commands. Instead we should just stick to one
command for the in-text case, and have some extensible way to
represent the data that should be rendered, e.g. maybe like
[cite: @Jones2018 :year]
or (as I think was proposed at one point):
[cite:author @Jones2018]
Again, maybe it's worth having some shortcuts here for the common
cases, but I think in general we want to try to avoid
proliferation of basic citation commands. So for that reason I
think we should just stick with the 'cite'/'(cite)' distinction as
the two basic commands, perhaps with a more
extensible/compositional syntax in each case for expressing the
variations on these two basic types of citation.
--
Best,
Richard
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]
next prev parent reply other threads:[~2018-04-25 20:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-04-20 23:01 Should wip-cite branch be merged to master? tumashu
2018-04-21 7:26 ` Nicolas Goaziou
2018-04-21 8:43 ` Christian Moe
2018-04-22 18:17 ` András Simonyi
2018-04-23 19:42 ` John Kitchin
2018-04-25 19:19 ` Richard Lawrence [this message]
2018-04-26 23:34 ` Bastien
2018-04-27 21:07 ` András Simonyi
2018-04-27 23:34 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87efj39jqk.fsf@aquinas.i-did-not-set--mail-host-address--so-tickle-me \
--to=richard.lawrence@berkeley.edu \
--cc=emacs-orgmode@gnu.org \
--cc=jkitchin@andrew.cmu.edu \
--cc=mail@nicolasgoaziou.fr \
--cc=simonyi@all.hu \
--cc=tumashu@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).