emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
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 --]

  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).