emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Jambunathan K <kjambunathan@gmail.com>
To: Rasmus <rasmus@gmx.us>
Cc: Nicolas Goaziou <n.goaziou@gmail.com>, emacs-orgmode@gnu.org
Subject: Re: Standardize #+BIBLIOGRAPHY line
Date: Thu, 25 Jul 2013 14:17:20 +0530	[thread overview]
Message-ID: <87iozzhvqf.fsf@gmail.com> (raw)
In-Reply-To: <87txjmb6w1.fsf@gmx.us> (rasmus@gmx.us's message of "Mon, 22 Jul 2013 23:51:26 +0200")


I am not sure how many people will read this or make sense out of it.
Anyways, here I go.

Rasmus <rasmus@gmx.us> writes:

>      - textcite k :pre x :post y   → K (pre, year, post)
>      - parencite k :p x :post y    → (pre, K, year post)
>      - cite k :pre x :post y       → K pre K year post
>      - footcite k :pre x :post y   → [fn::pre K Year post.]
>      - citeauthor k :pre x :post y → pre K post
>      - citeyear k :pre x :post y   → pre year post

JabRef's command line doesn't take pre and post arguments.  Both JabRef
and Zotero use LibreOffice application APIs to insert citations.  i.e.,
citations are introduced manually, by hand.  

But JabRef lets you "translate a key" be it k -> Author(k) or k->Date(k)
or k->Author-Date(k) in a "context-free" manner.  By "contex free", I
mean, it wouldn't bother about whether the key occurs for the first time
or whether it occurs for second time (think Ibid) etc.

----------------------------------------------------------------

Writing in Org should feel natural.  It should be fuzzy but powerful.

Specifically, it shouldn't read like Lisp.  So having ":pre" and ":post"
elements or going extra lengths to get the precise parenthesis (Is it []
or ()?) or the separators (Is it , or ;?) would be an overkill.

The immediate requirement should be to create a good enough working
draft that can be circulated among peers or sent to the publisher for a
professional processing.

Parser enhancements or introducing new syntax elements - that are
heavy-weight - should be avoided all costs.  What is needed is
"expressivity" not "extensibility"

Pre and Post are inherently positional.  So, if one can identify where
the middle part is - in all your examples it a Key or f(Key), for some
"f" - then identifying a pre and post components should be easy provided
the "cite span" is delineated by explicit markup or "natural"
boundaries.

----------------------------------------------------------------

Approach 1: Delineate a "cite span" using []

Con: Parser enhancement could be non-trivial because it introduces a new
Org-syntax delimiter.

One can map this,

  \autocite[59][See also](Becker2010) => See also Becker, 59

to this Org syntax:

  [See also [cite:Becker2010] 59]

Let pre and post occur in natural order but use extra markers to
indicate a "span" or a stretch.

----------------------------------------------------------------

Approach 2: Delineate using natural boundaries.

Con: Parser enhancement is pretty localized just footnote elements.
Less bugs and better expressivity.

Another variation could be 

  #+BEGIN_SRC org

       [fn:Becker2010p59] and [fn:Becker2010p503]

  [fn:Becker2010p59] See also [cite:Becker2010] 59
  [fn:Becker2010p503] See also [cite:Becker2010] 503
  #+END_SRC

Here Becker2010p59 and Becker2010p503 are opaque labels.  They could as
well be tom and harry, for example.

  #+BEGIN_SRC org
       [fn:tom] and [fn:dick]

  [fn:tom] See also [cite:Becker2010] 59.  Some extra note, if the note
  is to be stored right within Org.
  [fn:dick] See also [cite:Becker2010] 503
  #+END_SRC


  #+BEGIN_SRC org
       [fn:tom] and [fn:dick]

  #+ATTR_?: See also [cite:Becker2010] 59.  
  [fn:tom] Some extra note, if the note is to be stored right within
  Org.  [fn:dick] See also [cite:Becker2010] 503
  #+END_SRC


Here "the content of an object" is specified using a combination of
"label" and "element". The leading sentence/phrase or paragraph of
footnote definition, if it contains [cite: ] element, can assumed to
specify pre and post.  The rest of the sentence or paragraph can be a
"note" that augments the specific citation.  The [cite:...]  elements
itself delineates (by virtue of it's position) the pre and post
elements.


----------------------------------------------------------------

The use of object designated with label + element could be used in
conjunction with Image links as well.  This is just what ASCII uses to
translate links but with a "ATTR_" twist attached to the "labeled
paragraph"


  See [Orgmode Logo]


#+ATTR_HTML:  Put whatever here.
[Orgmode Logo] http://orgmode.org/org-mode-unicorn.png

----------------------------------------------------------------

  reply	other threads:[~2013-07-25  8:45 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22  7:25 Standardize #+BIBLIOGRAPHY line Jambunathan K
2013-07-22  9:03 ` Nicolas Goaziou
2013-07-22 13:16   ` Jambunathan K
2013-07-22 13:19     ` Jambunathan K
2013-07-22 13:31     ` Nicolas Goaziou
2013-07-22 13:47       ` Jambunathan K
2013-07-22 13:58         ` Nicolas Goaziou
2013-07-22 16:09           ` Jambunathan K
2013-07-22 19:33           ` Jambunathan K
2013-07-22 14:15       ` Rasmus
2013-07-22 16:29         ` Jambunathan K
2013-07-22 21:51           ` Rasmus
2013-07-25  8:47             ` Jambunathan K [this message]
2013-07-22 17:01         ` Jambunathan K
2013-07-22 19:34           ` Jambunathan K

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=87iozzhvqf.fsf@gmail.com \
    --to=kjambunathan@gmail.com \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \
    --cc=rasmus@gmx.us \
    /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).