From: John Kitchin <jkitchin@andrew.cmu.edu>
To: Richard Lawrence <richard.lawrence@berkeley.edu>
Cc: emacs-orgmode@gnu.org
Subject: Re: Citations, continued
Date: Mon, 09 Feb 2015 17:32:55 -0800 [thread overview]
Message-ID: <m2386er1o8.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <86wq3rrn9g.fsf@berkeley.edu>
Richard Lawrence writes:
> Hi Tom and all,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> IIUC, Org mode citation syntax needs to capture four pieces of
>> information for an *individual* citation: a =key= into one or more
>> stores of bibliographic information; a =citation-command= that is
>> understood by the =citation-style= specified for the document; a
>> =pre-note= of arbitrary text in any language; and a =post-note= of
>> arbitrary text in any language. At least, this is how the LaTeX world
>> accommodates the almost unconstrained and ever-growing variability in
>> bibliographic styles in the wild.
>
> I think the key, pre-note and post-note are common ground, and everyone
> agrees that they need to be represented in a citation syntax.
>
> I am a bit more hesitant about the citation command, though. My reasons
> for hestitation are the same as other people have expressed here, but I
> think it might be useful to summarize.
I think the critical point is that the syntax must be user
extendable. It should be possible to add these different types, even if
most people do not use them. Otherwise, links will continue to be used
anyway.
>
> As Tom notes, there is basically unlimited complexity in the LaTeX world
> for citation commands. There's a different subset of commands for every
> distinction you might want to express in a given style.
>
> The trouble is that there is close to zero support for this complexity
> in the other export formats that Org supports. As far as I am aware
> (though I could be wrong), HTML, ODT, and other document formats barely
> even have a way of indicating that a piece of text is a citation.
> (HTML5 does have a "cite" element, but it seems to be basically an
> unconstrained semantic element.)
This should not prevent us from making a syntax that can be simple for
these backends, and functional for Latex.
>
> Many of us (including me) are exporting to LaTeX, and if that is what
> you are doing, it is natural to want to have access to all the
> distinctions that LaTeX provides. But if we try to capture those
> distinctions in a high-level Org citation syntax, then we have two
> problems: (a) finding the right syntax to express those distinctions,
> and (b) exporting citations that make use of those distinctions to
> non-LaTeX formats, which provide little support for them. The more
> distinctions we try to capture, the more difficult these problems will
> be to solve.
Again, user extendability is the key to this. You would not use these
for export to other formats, and you do not want to have to use one
notation for some backends, and another for latex. One also does not use
the sophisticated machinery of latex by accident. So I don't think we
lose anything by making it possible.
>
> Thus, I think the right question to ask is: which distinctions are both
> *simple enough* and *important enough* that they are worth encoding in
> Org syntax and supporting in non-LaTeX backends? I think that is the
> right place to draw the line between features of citations that are
> encoded in `citation syntax proper' vs. `escape hatches' that give more
> information about how to format a citation in a particular backend.
I think the new citations should support an export mechanism like links
do. Each backend whould be responsible to take the information it gets,
and use it to create what it needs. Syntax like [see cite@Doe99 for
example] contains all that information, and is pretty readable.
>
> My sense is that a lot of the complexity in LaTeX citations should fall
> in the latter category, but we need to think more about what falls in
> the first category.
>
> One clear candidate for the first category that I think everyone agrees
> on is the distinction between in-text vs. parenthetical citations
> (\citet vs. \citep and similar in LaTeX). For my own case, this is the
> only distinction I need to be directly expressed in syntax.
If these are the default types, I think it is fine. It should be
possible to define new types though. It should be possible to define
this: [citeauthor@Doe99] showed in [citeyear@Doe99] that this was
possible. An alternative approach is illustrated in
Ref. [citenum@Doe100].
>
> Nicolas expressed a similar opinion:
>
>> It seems to me that :type is a LaTeX-only feature and, as such, should
>> be handled in "ox-latex". In the general case, I think that Org should
>> only support inline and parenthesized citations.
I don't think it is a latex only feature. Word could have this feature
too where you differentiate between types, and html, and ascii,
etc... This is handled by the backend.
>
> But in response to a question from Rasmus, Tom also suggested that
> multi-cites are a candidate, in addition to the in-text/parenthetical
> distinction:
>
>> Yes, I typically use what I call a multicite to get multiple citations
>> with biblatex.
If a multicite is something that might render as [1-3] or [1,6,9] in a
backend then yes, multicite is a necessary capability for most
scientific publications.
These could look like (I am mixing :/@ below just to see what it looks like):
[cite:key1,key2] or [cite:key1; cite:key2]
[cite@key1,key2] or [cite@key1; cite@key2]
[cite@key1; see also cite@key2]
>
> I myself never use these, so I don't understand exactly what would be
> required to support them properly in non-LaTeX backends, and I can't
> speak to which category they belong to.
>
> Are there other candidates we should discuss? What other distinctions
> are so important that they are worth figuring out how to express in
> syntax that can be exported by all backends?
I think the examples above cover a lot of the use cases we have
considered. Maybe there is some subtle issues of a citation in a
citation, or of other markup in a citation, e.g. bold/italics, that I
overlooked.
I am pretty sure all those formats can be integrated pretty easily into
something like org-ref for inserting citations. As long as some part of
them is clickable, with a user-defined action, e.g. the cite@key part,
then functionally this would be the same as what we have with links in
org-ref.
converting multicites this way to latex might be a little tricky, but I
think it is doable.
>
> As for supporting the `escape hatch' category, it seems that more
> thought is needed here, too. Right now, the #+ATTR_BACKEND syntax is
> the only way I know of to specify arbitrary export properties for a
> piece of Org syntax. But it only applies to greater elements, and Tom
> at least does not think it is sufficient to only allow specifying the
> citation command, in particular, in an out-of-line (because greater
> element) citation definition.
>
> So maybe we need some kind of inline syntax for backend-specific
> properties of citations, perhaps along the lines that Rasmus has
> suggested. I think this could be a good idea; my only concern is that
> we make a clear separation between this syntax and the main syntax for
> citations. There are two reasons for this: if we don't clearly make
> this separation, then (1) it becomes much harder to figure out and agree
> on which distinctions should be expressed in `the' citation syntax; and
> (2) there is a danger that the complexity of backend-specific properties
> will bleed over into the main citation syntax, which all backends have
> to support.
>
> Best,
> Richard
--
Professor John Kitchin
Doherty Hall A207F
Department of Chemical Engineering
Carnegie Mellon University
Pittsburgh, PA 15213
412-268-7803
@johnkitchin
http://kitchingroup.cheme.cmu.edu
next prev parent reply other threads:[~2015-02-10 1:33 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-31 18:26 Citations, continued Richard Lawrence
2015-01-31 18:42 ` Nicolas Goaziou
2015-02-01 22:07 ` Richard Lawrence
2015-02-02 13:52 ` Rasmus
2015-02-02 17:25 ` Richard Lawrence
2015-02-02 18:09 ` Rasmus
2015-02-02 15:45 ` Erik Hetzner
2015-02-01 22:06 ` John Kitchin
2015-02-02 1:41 ` Richard Lawrence
2015-02-02 4:43 ` Thomas S. Dye
2015-02-02 13:56 ` John Kitchin
2015-02-02 18:11 ` Thomas S. Dye
2015-02-02 19:38 ` John Kitchin
2015-02-02 19:51 ` John Kitchin
2015-02-02 22:47 ` Rasmus
2015-02-03 0:54 ` Thomas S. Dye
2015-02-03 1:36 ` John Kitchin
2015-02-02 14:17 ` Rasmus
2015-02-02 16:58 ` Richard Lawrence
2015-02-02 14:07 ` Rasmus
2015-02-02 13:51 ` Rasmus
2015-02-02 15:09 ` Matt Price
2015-02-02 18:02 ` Richard Lawrence
2015-02-02 19:55 ` Rasmus
2015-02-03 1:56 ` Richard Lawrence
2015-02-03 2:08 ` Vikas Rawal
2015-02-03 10:55 ` Rasmus
2015-02-04 10:35 ` Julian M. Burgos
2015-02-04 16:34 ` John Kitchin
2015-02-03 10:35 ` Rasmus
2015-02-03 12:00 ` Eric S Fraga
2015-02-03 16:27 ` Richard Lawrence
2015-02-03 17:25 ` Eric S Fraga
2015-02-03 3:58 ` Erik Hetzner
2015-02-03 4:41 ` Richard Lawrence
2015-02-03 7:30 ` Erik Hetzner
2015-02-03 16:11 ` Richard Lawrence
2015-02-04 6:30 ` Erik Hetzner
2015-02-04 12:06 ` Nicolas Goaziou
2015-02-04 16:45 ` Richard Lawrence
2015-02-06 10:27 ` Nicolas Goaziou
2015-02-06 22:41 ` Richard Lawrence
2015-02-07 22:43 ` Nicolas Goaziou
2015-02-08 2:46 ` Richard Lawrence
2015-02-08 9:46 ` John Kitchin
2015-02-08 17:09 ` Richard Lawrence
2015-02-08 22:23 ` Thomas S. Dye
2015-02-09 8:46 ` e.fraga
2015-02-09 10:50 ` Rasmus
2015-02-09 11:20 ` Nicolas Goaziou
2015-02-09 11:37 ` Rasmus
2015-02-10 9:06 ` Nicolas Goaziou
2015-02-09 15:09 ` Thomas S. Dye
2015-02-10 8:55 ` Nicolas Goaziou
2015-02-10 9:22 ` Rasmus
2015-02-10 9:41 ` Nicolas Goaziou
2015-02-10 10:01 ` Rasmus
2015-02-10 15:32 ` Thomas S. Dye
2015-02-10 1:50 ` John Kitchin
2015-02-09 17:46 ` Richard Lawrence
2015-02-09 20:13 ` Rasmus
2015-02-10 1:32 ` John Kitchin [this message]
2015-02-10 4:04 ` Richard Lawrence
2015-02-10 5:23 ` John Kitchin
2015-02-10 6:20 ` Thomas S. Dye
2015-02-08 9:58 ` Nicolas Goaziou
2015-02-08 17:18 ` Richard Lawrence
2015-02-08 18:18 ` Nicolas Goaziou
2015-02-08 9:28 ` Rasmus
2015-02-08 10:18 ` Nicolas Goaziou
2015-02-08 10:50 ` Rasmus
2015-02-08 12:36 ` Nicolas Goaziou
2015-02-08 13:40 ` Rasmus
2015-02-08 16:11 ` Nicolas Goaziou
2015-02-09 10:02 ` Rasmus
2015-02-08 17:02 ` Nicolas Goaziou
2015-02-08 17:29 ` Rasmus
2015-02-10 1:54 ` John Kitchin
2015-02-10 8:49 ` Nicolas Goaziou
2015-02-10 9:20 ` Rasmus
2015-02-10 10:05 ` Nicolas Goaziou
2015-02-10 10:36 ` Rasmus
2015-02-10 10:53 ` Andreas Leha
2015-02-10 15:03 ` John Kitchin
2015-02-10 15:54 ` Rasmus
2015-02-10 16:14 ` John Kitchin
2015-02-10 16:22 ` Richard Lawrence
2015-02-10 16:44 ` Stefan Nobis
2015-02-11 2:07 ` Richard Lawrence
2015-02-11 10:19 ` Stefan Nobis
2015-02-11 16:51 ` Richard Lawrence
2015-02-13 2:31 ` Matt Price
2015-02-11 10:47 ` Aaron Ecay
2015-02-11 11:32 ` Rasmus
2015-02-10 16:04 ` Richard Lawrence
2015-02-11 2:10 ` Thomas S. Dye
2015-02-11 2:48 ` Richard Lawrence
2015-02-11 3:53 ` Thomas S. Dye
2015-02-06 23:37 ` Rasmus
2015-02-06 23:16 ` Rasmus
2015-02-04 17:44 ` Erik Hetzner
2015-02-04 15:59 ` Richard Lawrence
2015-02-04 17:58 ` Erik Hetzner
2015-02-04 19:24 ` Richard Lawrence
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=m2386er1o8.fsf@andrew.cmu.edu \
--to=jkitchin@andrew.cmu.edu \
--cc=emacs-orgmode@gnu.org \
--cc=richard.lawrence@berkeley.edu \
/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).