Standardize #+BIBLIOGRAPHY line

Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

(Fixed up the subject and CC line.)

As for #+ATTR_BACKEND lines, they *must* be prefixed with the citation
processor's name.

It is unlikely that there will be a convergence of what Org-wide
':citation-style' values are.  In that case, they can be converted to
citation-processor specific style.

#+ATTR_LATEX: :bib-style plain
#+ATTR_HTML: :bib2html-style apa
#+ATTR_ODT: :jabref-style chicago-author-date

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

In ODT case, I translate (latex-frag ...) to (citation-reference ....)
I have the following defcustom to choose JabRef as the "citation
processor" for ODT backend.

If we standardize on this convention, one can for example choose JabRef
or Zotero as the citation processor for various backends.


    (defcustom org-odt-citation-transcoders
      '(ox-jabref-citation-reference . ox-jabref-bibliography)
      "Transcoders to handle citations."
      :type '(choice (const :tag "Don't process citations" nil)
                     (cons  :tag "Citation transcoders"
                            (function :tag "For \\cite{} fragments" :value ox-jabref-citation-reference)
                            (function :tag "For BIBLIOGRAPHY     " :value ox-jabref-bibliography)))
      :group 'org-export-odt
      :version "24.1")


You *may* want to wrap this aspect in to a tool.

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

<- The following part is same as earlier message ->

Nicolas

I am finalizing JabRef support for ODT.  At *some* future point in time,
I will include ox-jabref.el (and all other patches) in official Emacs
distribution.

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

Meanwhile, could you standardize the syntax for some `keyword' elements
so that they can be parse with `org-export-read-attribute'.

Currently, I am interested in BIBLIOGRAPHY.  You may also want to do the
same for #+toc: lines.


#+ATTR_ODT: :jabref-intext-filter chicago.ODF.text :jabref-reference-filter chicago.ODF.reference
#+ATTR_HTML: :bib2html-options "-a b -c -d"
#+BIBLIOGRAPHY:  :bib-file MyLibrary.bib :citation-style "chicago-note" :limit t

    :bib-file will be mandatory.  (It is basically the input database, need
    not *necessarily* be a .bib file.)

    :citation-style will be advisory.  Backends may choose to ignore or
    honor the style.

    :limit t can be supported by ODT via jabref.

You may also want to review the #+TOC settings, more for consistency
than anything else.

Instead of
        #+toc: headlines 4

we can have 
        #+toc: headlines :levels 4

or 
        #+toc: :type headlines :levels 4

Re: Standardize #+BIBLIOGRAPHY line

[Nicolas Goaziou]

Hello,

Jambunathan K <kjambunathan@gmail.com> writes:

[...]

> I am finalizing JabRef support for ODT.  At *some* future point in time,
> I will include ox-jabref.el (and all other patches) in official Emacs
> distribution.

Thanks for you work. 

However, I think it ought to be merged in ox-bibtex.el instead.
"ox-bibtex" name is misleading as it is not directly related to "bibtex"
program. At its core, it merely introduces a BIBLIOGRAPHY keyword and
[[cite:...]] links. It also provides accessors and predicates wrt them:

 - org-bibtex-get-file
 - org-bibtex-get-style
 - org-bibtex-get-arguments
 - org-bibtex-citation-p
 - org-bibtex-get-citation-key

So, if you use them, you don't have to bother about BIBLIOGRAPHY keyword
syntax (at least for now).

Also, if we ever use ox-bibtex.el as a basis to implement bibliography
handling in Org core, it will be easier to have most major back-ends
already behaving uniformly.

> You may also want to review the #+TOC settings, more for consistency
> than anything else.
>
> Instead of
>         #+toc: headlines 4
>
> we can have
>         #+toc: headlines :levels 4
>
> or
>         #+toc: :type headlines :levels 4

Initially, as its name suggests, `org-export-read-attribute' was meant
to make attributes keywords more consistent across back-ends. As it is
a bit heavy, I'm not convinced that it would be a good generic syntax
for all keywords.

Also, the problematic is slightly different. "attr_backend" is generic,
so it makes sense if its value starts with some :keyword. But what
about:

  #+BEAMER_THEME: Madrid

It would be redundant to use #+BEAMER_THEME: :theme Madrid (or :name
Madrid).

On the other hand, I admit that, currently,

  #+BEAMER_THEME: Rochester [height=20pt]

is not great either.

Maybe all of this calls for a generalization of the reader function.
Something like "stuff everything before the first keyword as the value
of a generic keyword". IOW,

  #+keyword: :a val :b val2    =>    (:a "val" :b "val2")
  #+keyword: text :a val       =>    (:head "text" :a "val")
  #+keyword: text :head other  =>    not good


Regards,

-- 
Nicolas Goaziou

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Nicolas

Getting Citation right to cater to general needs is going to be complex.
This is mainly because 

    1. Org's object syntax is very rudimentary and not "extensible" 
    2. "real-world" citations may need some annotations page number etc.

I think it is good to *atleast make a move* in standardizing the cite
elements.  My gut feeling is that cite objects - for now - should be
coded as \cite { } latex objects.  This specifically means that link
syntax for cite should NOT BE ENCOURAGED (or STRONGLY DISCOURAGED).

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

As an aside, I am inclined to think of cite objects as "special class"
of "footnote" elements.  Footnotes are unique in that it "interlinks"
both object and element worlds.  Elements can have attributes attached
to them.  Consider for example, a syntax like this.

    Joshu's "Mu" [cite: blyth_zen_1966] is a koan that a practioner must
    break through.

    #+ATTR_PAGE:  :page 17
    [cite:blyth_zen_1966]  Zen and Zen Classics, Volume 4, Mumonkan

Now what goes within the brackets - "blyth_zen_1966" - is just a label.
The attributes of that object are set in a paragraph that is
"introduced" with that label (as above).

> However, I think it ought to be merged in ox-bibtex.el instead.

Does the author have copyright assignments for contributing to Emacs?

        Taru Karttunen <taruti@taruti.net>

As a personal policy, I don't want to touch a file which wouldn't end up
in Emacs proper.  

Any changes that I make to Emacs - that includes Org-mode - is
*guaranteed* to end up in Emacs proper.  It's going to happen in it's
own time.

> "ox-bibtex" name is misleading as it is not directly related to "bibtex"
> program. At its core, it merely introduces a BIBLIOGRAPHY keyword and
> [[cite:...]] links. It also provides accessors and predicates wrt them:
>
>  - org-bibtex-get-file
>  - org-bibtex-get-style
>  - org-bibtex-get-arguments
>  - org-bibtex-citation-p
>  - org-bibtex-get-citation-key

These wouldn't be necessary if the reader syntax is improved.  

Why not create an ox-cite.el, make yourself the author and move your own
changes to that file.  You can also FAKE a `citation-reference' object
so that the backend consumers are totally unaware of how these objects
are represented in the Org document.


We can have separate ox-bibtex.el and ox-jabref.el - I call them as
"citation processors".  They will be providing the "standard"
transcoders - `org-CITATION-PROCESSOR-citation-reference' and
`org-CITATION-PROCESSOR-bibliography'.  As noted in previous mail,
having first class transcoders will help, in switching an export backend
to switch to someother citation processor.  One just has to switch the
translators.


> Maybe all of this calls for a generalization of the reader function.
> Something like "stuff everything before the first keyword as the value
> of a generic keyword". IOW,
>
>   #+keyword: :a val :b val2    =>    (:a "val" :b "val2")
>   #+keyword: text :a val       =>    (:head "text" :a "val")
>   #+keyword: text :head other  =>    not good

How about, making the keyword itself as a property, if the option string
DOESN'T is not introduced by a symbol.

        #+keyword: :a val :b val2    =>    (:a "val" :b "val2")
        #+keyword: text :a b :c d    =>    (:keyword text :a b :c d)

>   #+toc: headlines :levels 4

        (:toc headlines :levels 4)

>   #+BEAMER_THEME: Madrid

        (:beamer-theme Madrid)

>   #+BEAMER_THEME: Rochester [height=20pt]

        (:beamer-theme Rochester [height=20pt])

These all will become "values" of a `keyword' element.

> Regards,

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

>>   #+toc: headlines :levels 4
>
>         (:toc headlines :levels 4)

Btw, I forgot to mention that BIBLIOGRAPHY is itself a "table of
citations".

Re: Standardize #+BIBLIOGRAPHY line

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

> Getting Citation right to cater to general needs is going to be complex.
> This is mainly because 
>
>     1. Org's object syntax is very rudimentary and not "extensible" 
>     2. "real-world" citations may need some annotations page number etc.
>
> I think it is good to *atleast make a move* in standardizing the cite
> elements.  My gut feeling is that cite objects - for now - should be
> coded as \cite { } latex objects.  This specifically means that link
> syntax for cite should NOT BE ENCOURAGED (or STRONGLY DISCOURAGED).

I understand. You can still use ox-bibtex.el for now, and just ignore
all the "[[cite:...]]" part.

> As an aside, I am inclined to think of cite objects as "special class"
> of "footnote" elements.

I tend to agree. There was a discussion on the ML about a possible
syntax. I think it is a bit early to set it in stone anyway. As you
said, the point here is to make a move towards standardization, even if
it means using \cite{...} and `defadvice' for now.

> Does the author have copyright assignments for contributing to Emacs?
>
>         Taru Karttunen <taruti@taruti.net>
>
> As a personal policy, I don't want to touch a file which wouldn't end up
> in Emacs proper.  
>
> Any changes that I make to Emacs - that includes Org-mode - is
> *guaranteed* to end up in Emacs proper.  It's going to happen in it's
> own time.

Nobody can guarantee that code relative to bibliographies will become
mainstream. What if normalization fails, for one reason or another?

Anyway, I don't think assignment is a problem. If we decide to handle
bibliographies in Org core, ox-bibtex will have to be rewritten anyway
(and will become ox-bibliography or something like that). Though, it
would obviously be best if original "org-bibtex.el" author (Cc'ed) had
already signed FSF papers.


Regards,

-- 
Nicolas Goaziou

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

> I understand. You can still use ox-bibtex.el for now, and just ignore
> all the "[[cite:...]]" part.

Each citation processor should reside in it's own file.  So ox-jabref.el
is the right place for my changes.

It seems that you are not interested in introducing ox-cite.el or a
make-shift `citation-reference' element.  That's fine.  Atleast, I have
explored to see whether we can strike a common ground.

> Though, it would obviously be best if original "org-bibtex.el" author
> (Cc'ed) had already signed FSF papers.

Ok.

> Regards,

Re: Standardize #+BIBLIOGRAPHY line

[Nicolas Goaziou]

Jambunathan K <kjambunathan@gmail.com> writes:

>> I understand. You can still use ox-bibtex.el for now, and just ignore
>> all the "[[cite:...]]" part.
>
> Each citation processor should reside in it's own file.  So ox-jabref.el
> is the right place for my changes.

LaTeX and HTML processors already reside in ox-bibtex.el. If you want to
create a new file, so be it, but try at least to require ox-bibtex and
use existing accessors and predicates to maintain compatibility.

> It seems that you are not interested in introducing ox-cite.el or a
> make-shift `citation-reference' element.

I don't know what led you to this conclusion.

I'm very much interested in supporting bibliographies from Org. I also
know it will require to implement a new citation object in the process.
I'm just pointing out two things:

  - ox-bibtex will have to be implemented differently (e.g., no more
    defadvices). So, it's not just about moving ox-bibtex into another
    directory.
  - before discussing (again) citations syntax, we must ensure that this
    is a realistic goal. IOW we need a proof of concept for, at least,
    every major back-end (including ASCII).


Regards,

-- 
Nicolas Goaziou

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Let me state unequivocally that I am willing to co-operate .

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> I'm just pointing out two things:
>
>   - ox-bibtex will have to be implemented differently (e.g., no more
>     defadvices). 

Citation are "obivously" objects, whatever be their underlying syntax.
I am not happy with the defadvices and a recent change to introduce cite
links.  I feel like puking when I look at "#+BIBLIOGRAPHY" line.

So, let's start with standardizing "#+BIBLIOGRAPHY" line.  Having a bib
file or a bib database would be a good start.

> So, it's not just about moving ox-bibtex into another directory.

My mails don't make references to "moving ox-bibtex in to another
directory" at all.  We are talking about standardizing #+BIBLIOGRAPHY
line, that is all.  I have no other agenda.


>   - before discussing (again) citations syntax, we must ensure that this
>     is a realistic goal. IOW we need a proof of concept for, at least,
>     every major back-end (including ASCII).

Ascii should be the easier with JabRef atleast.  Ofcourse, interested
people should take up issues with JabRef team and sort out issues or
clarify what their layout format mean.

My intention is to merely show via a prorotype that JabRef seems like a
viable citation processor.

If you (or someone else) is going to implement Citation processor in
elisp itself, it's going to be a bigger effort.  Nothing wrong with it.

    1. It is wrong to assume ".bib" files as the "only" input database.
       (Zotero is gaining traction and is apparently well-funded.  But
       the tool itself is not mature.)

    2. Org can NEVER be a full-blown document preparation system.  It is
       going to be good enough for pre-prints or for one of sharing of
       documents.  Nothing more.

(2) implies that we can as well settle for a "simpler" cite syntax. 

As I see it, there will be ox-jabref.el, ox-bibtex.el and ox-zotero.el.
The responsibility from the ox.el side of things is to merely bless a
specific arrangement.  

The citation processors are not good enough to get in to the core Emacs,
but they can definitely be included in GNU ELPA.

I insist on Emacs and GNU ELPA not because I earn any brownie points or
feeds my pride but because it will ensure the longevity of work and to
some extent bitrot-proof-ness.

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> before discussing (again) citations syntax

I understand that talking about citations syntax will lead to
bike-shedding.  Every one - including me - seem to have an (un)informed
opinion of it.  The intent of the mail - as the subject - says is to

    1. To standardize the in buffer syntax for Bibliography based on
       existing implementations.  

    2. To check your interest in "faking" a citation-reference object.
       This is a programmatic interface as opposed to a specific Org
       syntax.

> we must ensure that this is a realistic goal.

It is, unless we want the whole earth and sky.

Re: Standardize #+BIBLIOGRAPHY line

[Rasmus]

Nicolas Goaziou <n.goaziou@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Getting Citation right to cater to general needs is going to be complex.
>> This is mainly because 
>>
>>     1. Org's object syntax is very rudimentary and not "extensible" 
>>     2. "real-world" citations may need some annotations page number etc.
>>
>> I think it is good to *atleast make a move* in standardizing the cite
>> elements.  My gut feeling is that cite objects - for now - should be
>> coded as \cite { } latex objects.  This specifically means that link
>> syntax for cite should NOT BE ENCOURAGED (or STRONGLY DISCOURAGED).
>
> I understand. You can still use ox-bibtex.el for now, and just ignore
> all the "[[cite:...]]" part.

I wouldn't go with \cite{·}.  When I did in the past  I often got into
trouble due to newlines. E.g.:

\parencite[this is my very long note before the author][this is my
long quote after the ]{key}

would be escaped by Org.  Perhaps it works better with ox, I haven't
tested.  But the above is printed as:

\parencite[this is my very long note before the author][this is my
long quote after the ]\{key\}
                      ^^^^^^^ 

As expressed elsewhere I think

  [cite:key :pre xxx :post yyy :mycrazykey zzz] 

is the most desirable syntax.

>> As an aside, I am inclined to think of cite objects as "special class"
>> of "footnote" elements.
>
> I tend to agree. 

Me too.  Although I think FN should be a special case of
[FUN:whatever] where FUN could be CITE or FN or whatever. . .

> There was a discussion on the ML about a possible
> syntax. I think it is a bit early to set it in stone anyway. As you
> said, the point here is to make a move towards standardization, even if
> it means using \cite{...} and `defadvice' for now.

Citation-support is a hack atm, and I think it's an area that would do
well with some standardization.

The system should exhibit some flexibility supporting e.g. notes,
parencite (prenote, key, year, postnote) and textcite key (prenote,
year, postnote).  But there could be others.  E.g. someone mentioned
using DOIs etc.

>> Does the author have copyright assignments for contributing to Emacs?
>>
>>         Taru Karttunen <taruti@taruti.net>
>>
>> As a personal policy, I don't want to touch a file which wouldn't end up
>> in Emacs proper.  
>>
>> Any changes that I make to Emacs - that includes Org-mode - is
>> *guaranteed* to end up in Emacs proper.  It's going to happen in it's
>> own time.
>
> Nobody can guarantee that code relative to bibliographies will become
> mainstream. What if normalization fails, for one reason or another?
>
> Anyway, I don't think assignment is a problem. If we decide to handle
> bibliographies in Org core, ox-bibtex will have to be rewritten anyway
> (and will become ox-bibliography or something like that). Though, it
> would obviously be best if original "org-bibtex.el" author (Cc'ed) had
> already signed FSF papers.

I'd be willing to put in work on ox-bibliography, although I don't
know if my 'skillz' suffice.

–Rasmus

-- 
A page of history is worth a volume of logic

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Rasmus <rasmus@gmx.us> writes:

> The system should exhibit some flexibility supporting e.g. notes,
> parencite (prenote, key, year, postnote) and textcite key (prenote,
> year, postnote).  But there could be others.  E.g. someone mentioned
> using DOIs etc.

I am not a scholar.  I have never used Bibliographies before nor do I
foresee that I would have a need for it.

If someone is keen, it wouldn't be difficult to compile a common cases
of "what" of citation specification.  Atleast the minimal that the
community itself has used in the past.

    I want to include year, 
    page, some phrase          =>    Output should look like this - both
    in cite                          Intext & Reference.
    

How the syntax is specified and how it is implemented in Elisp should be
left to others.

For example, you can create a "bibliography.org" page in Worg (or may be
in some other Wiki).  You simply record the fact that wrapping of cite
fragments is an issue.  

To make progress, all information should be collected in a manner that
someone else can build upon.

Re: Standardize #+BIBLIOGRAPHY line

[Rasmus]

Jambunathan,

I'll just reply to your four emails in one.

Jambunathan K <kjambunathan@gmail.com> writes:

> Rasmus <rasmus@gmx.us> writes:
>
>> The system should exhibit some flexibility supporting e.g. notes,
>> parencite (prenote, key, year, postnote) and textcite key (prenote,
>> year, postnote).  But there could be others.  E.g. someone mentioned
>> using DOIs etc.
>
> I am not a scholar.  I have never used Bibliographies before nor do I
> foresee that I would have a need for it.

OK.

> If someone is keen, it wouldn't be difficult to compile a common cases
> of "what" of citation specification.  Atleast the minimal that the
> community itself has used in the past.
>
>     I want to include year,
>     page, some phrase          =>    Output should look like this - both
>     in cite                          Intext & Reference.

From a social science point of view and using the biblatex manual as a
reference.  (k is one or more keys below, K is the author, x,y are
strings).

     - 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

Biblatex also has a autocite that switches between parencite and
footcite depending on the loaded style. 

In real sciences they often use [n] where n corresponds to the nth
entry of the bibliography. Only cite is needed.  (Correct me if I'm
wrong).

But the formatting is really not the job of Org, but whatever is
choose in by the backend (perhaps except for ascii).

CLS/Citeproc can be used for style and formatting in Libreoffice, html
and probably text, but may rely on.  It's what Zotero uses for
formatting.  Here's a nice example of citeproc-js clearly showing that
the processing should be left for better tools

   - citeproc-js examples :: http://gsl-nagoya-u.net/http/pub/citeproc-demo/demo.html
     - citeproc-js home with info :: https://bitbucket.org/fbennett/citeproc-js/wiki/Home
   - biblatex examples :: http://www.ctan.org/tex-archive/macros/latex/contrib/biblatex/doc/examples


Unfortunately, the Internets say that CLS isn't supported by
LaTeX. . .  There's some work on Zotero integration to org:

       http://permalink.gmane.org/gmane.emacs.orgmode/72538

and this one I just saw (org-zotero.el):

    https://bitbucket.org/egh/zotero-plain

Jambunathan K <kjambunathan@gmail.com> writes:

>> As expressed elsewhere I think
>>
>>   [cite:key :pre xxx :post yyy :mycrazykey zzz]
>>
>> is the most desirable syntax.
>
> Where would the pre, post text would go.

See above.

> Will it go as part of "in text" or will it go in to References list or
> both.  For command line based processing, I see foresee issues with:
>
>     1. Multiple keys.

Why reinvent the wheel?  These issues have been dealt with by people
who thought long about it. . .

>     2. Stuff like "Ibid."

I think ibid is mainly used in the humanities, but I'm on thin ice
here.  It's supported by Biblatex out of the box if so desired.  Not
an Org issue.  It seems to also have been solved in by the
CLS/Citeproc people.  At least this page mentions ibid

        http://www.zotero.org/support/word_processor_plugin_usage

--8<---------------cut here---------------start------------->8---
Type "ibid" to automatically select the last cited work. This works
with all citation styles, regardless of whether “ibid” is actually
used in citations.
--8<---------------cut here---------------end--------------->8---


>     3. Sort order of keys.
>     4. Numbering of entries.

It's the job of the processor (e.g. bibier+biblatex or CLS file and
citeproc-*).


>> The system should exhibit some flexibility supporting e.g. notes,
>> parencite (prenote, key, year, postnote) and textcite key (prenote,
>> year, postnote).  But there could be others.  E.g. someone mentioned
>> using DOIs etc.
>
>> I'd be willing to put in work on ox-bibliography, although I don't
>> know if my 'skillz' suffice.
>
> This is just escaping :-).  You already have some ideas on "what"s and
> "how"s.  You put "what" in "what" and "how" in "how".

This esacped me. 

> IME, Confusion, lethargy or escapism starts when "what" gets mixed
> with "how".  "Collection" can happen now.  "Processing" can happen
> later.


Jambunathan K <kjambunathan@gmail.com> writes:

> Jambunathan K <kjambunathan@gmail.com> writes:
>
>> Will it go as part of "in text" or will it go in to References list or
>> both.  For command line based processing, I see foresee issues with:
>>
>>     1. Multiple keys.
>>     2. Stuff like "Ibid."
>>     3. Sort order of keys.
>>     4. Numbering of entries.
>
> To add to that list, will Citation entry be intermixed as a footnote
> with other regular footnotes.

IMO no, it would be way to painful to have to go to then end.
Currently I do C-c C-) and Reftex opens.  I select a type.  I give a
search word click RET and select the x keys that I want.  It inserts
as [[CITE:k1,k2,...kX]] where CITE is usually parencite or textcite.

–Rasmus

PS: Your posts do not show up on the archive
cf. http://news.gmane.org/gmane.emacs.orgmode

--
May the Force be with you

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

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

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

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

> As expressed elsewhere I think
>
>   [cite:key :pre xxx :post yyy :mycrazykey zzz] 
>
> is the most desirable syntax.

Where would the pre, post text would go.  

Will it go as part of "in text" or will it go in to References list or
both.  For command line based processing, I see foresee issues with:

    1. Multiple keys.
    2. Stuff like "Ibid." 
    3. Sort order of keys.
    4. Numbering of entries.

> The system should exhibit some flexibility supporting e.g. notes,
> parencite (prenote, key, year, postnote) and textcite key (prenote,
> year, postnote).  But there could be others.  E.g. someone mentioned
> using DOIs etc.

> I'd be willing to put in work on ox-bibliography, although I don't
> know if my 'skillz' suffice.

This is just escaping :-).  You already have some ideas on "what"s and
"how"s.  You put "what" in "what" and "how" in "how".

IME, Confusion, lethargy or escapism starts when "what" gets mixed with
"how".  "Collection" can happen now.  "Processing" can happen later.

Re: Standardize #+BIBLIOGRAPHY line

[Jambunathan K]

Jambunathan K <kjambunathan@gmail.com> writes:

> Will it go as part of "in text" or will it go in to References list or
> both.  For command line based processing, I see foresee issues with:
>
>     1. Multiple keys.
>     2. Stuff like "Ibid." 
>     3. Sort order of keys.
>     4. Numbering of entries.

To add to that list, will Citation entry be intermixed as a footnote
with other regular footnotes.