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 21:23:44 -0800 [thread overview]
Message-ID: <m2wq3qpcf3.fsf@andrew.cmu.edu> (raw)
In-Reply-To: <86siees98e.fsf@berkeley.edu>
Richard Lawrence writes:
>
> My concern is just that we clearly distinguish the `main' or `proper'
> citation syntax from the user-extensible part, as I said here:
>
> Rasmus has also expressed support for something like this, and I can see
> that it is important for a user to be able to define types which are
> backend-independent (and can thus be exported differently for different
> backends by some user-supplied function), much like links.
>
> On the other hand, before we adopt such a facility, it's important to
> think about what the interface would look like. What can reasonably be
> expected of the user function? What information needs to be given to it?
> (Just the citation and its properties? a reference to the bibligraphy
> file? a data structure representing the referenced work?) What happens
> when the user doesn't define behavior for a particular backend?
The pieces of information we have converged on (I think) are key, pre
text, post text, command, and that could be packaged in some data
structure. You also need the backend, and there is a final piece that is
important and that is the bibliography database(s). In org-ref we use a
bibliography link or rely on a default variable setting if that is not
found. Another option is #+BIBLIOGRAPHY: information.
The user function should take that information, and provide the
formatted string to replace the citation. As with latex, the function
may have to run a few times, e.g. to get the citations, construct the
bibliography, and then go back through the text to put in the formatted
numbers, author-year, etc... in latex we have the convenience to let
latex/bibtex handle that, and other backends would need to duplicate at
least some of that capability.
This can also be used to specify where a bibliography should be placed
in the document.
For undefined behavior, the only thing that can happen is the the same
thing that happens with links. Nothing.
> I don't quite like the examples you have illustrated here because they
> don't make the distinction I was urging above, between the `main'
> citation syntax and the user-extensible part. As a result it's really
> unclear to an author/editor, when reading the document, which backends
> can be expected to support which citations, and which citations can be
> expected to break if all you have is a default setup. (Imagine you
> didn't write the document or the custom citation type!) From the
> exporter's perspective, it's also really unclear what should happen when
> there's no behavior defined for, say, the "citeauthor" type for the HTML
> backend. If it defaults to just a "normal" citation, the output is very
> likely to be unreadable in the general case, but what other option is
> there?
That is true enough. That is already the case for every custom link
anyone makes in org-mode. the default behavior there is that the link is
dead and exports as plain text. This is also the case in Latex, if you
do not use the right package, sometimes you cannot get the right format
out.
>
> It's easy (and correct) to say: "These are the user's problems." But
> we're all users, so let's think some more about how to make things easy
> for ourselves. :)
>
> For these reasons, I'd prefer something like Rasmus' suggestion; maybe
> syntax like
>
> [@Doe99 :custom-type author-only] showed in [@Doe99 :custom-type year-only]
> that this was possible. An alternative approach is illustrated in
> [@Doe :custom-type refnum].
>
> where, basically, ":custom-type" is a nice big flag that says: "Here be
> dragons: you are responsible for exporting this citation yourself."
>
>> 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.
>
> Can you (or Tom, or someone else) make the case that it is important
> enough to have multicites that non-LaTeX backends should support them
> out of the box? (I'm not doubting it, I just don't have any idea why
> since I don't use them myself.)
My case is that if this is not supported out of the box, we could not
use the citation syntax for any of our scientific publishing needs. In
a recently published paper we had four citations with 4 references in
it, four with three references, 10 with two references and 15 single
citations. That is probably typical in our work, and in review work it
is common to have even more than four references in a citation. This is
a feature of modern publications because of tools like Endnote, zotero,
etc... which make it trivial to add citations, and independent of the
ultimate format (which is usually pdf, but sometimes html, and sometimes
Word).
If the new syntax allows us to handle citations the way links do today,
I can see a transition pathway to the new syntax. If not, I doubt it can
be adopted for scientific writing if you need two syntaxes for
citations. There are other, important types of writing this may support,
and maybe it makes sense to have separate approaches.
>
> 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 5:23 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
2015-02-10 4:04 ` Richard Lawrence
2015-02-10 5:23 ` John Kitchin [this message]
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=m2wq3qpcf3.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).