org-cite and org-citeproc

org-cite and org-citeproc

[Richard Lawrence]

[-- Attachment #1: Type: text/plain, Size: 2373 bytes --]

Hi everyone,

I thought I should send an update to let you know that org-citeproc [1],
the command-line citation processing tool I've been working on, now
supports multi-cites.  I believe that means it is now capable of
processing all citations in the basic citation syntax.  It can output
plain text, HTML, and ODT (and a Pandoc native format, mostly useful for
debugging).

org-citeproc hooks up with the Org exporters via Aaron Ecay's org-cite [2]
library, so that it is possible to export a document containing
citations as text, HTML, or ODT.  A sample Org document, bib file, CSL file,
and outputs are attached.

I am pretty convinced at this point that the approach that the
combination of org-cite and org-citeproc represents is viable, even if
org-citeproc is not the tool (or one of the tools) that the Org
community eventually adopts.  If you'd like to help out with developing
it, here are some things that would be useful:

1) If you are comfortable building a Haskell program and running an
unstable branch of Org, it would be great to have people test org-cite
and org-citeproc with more realistic documents, and with other CSL
files.  The basic things work, but there are surely many corner cases to
be weeded out.

2) If you know Haskell, I would appreciate feedback on the org-citeproc
code.  I am pretty new to Haskell and suspect there is a lot in my code
that could be cleaned up or made more idiomatic.

3) If you know Elisp, there are plenty of things still TODO in
org-cite.el.  I haven't hacked on this much except to get it working
with org-citeproc.

4) I would also be interested in seeing a parallel implementation in
org-cite of citation processing via Zotero.  I think the infrastructure
org-cite provides should make it relatively easy to get something like
this working, perhaps in combination with the zotxt plugin.  This would
provide two benefits: it would help prove the org-cite API is general
enough, and it would provide an alternative to org-citeproc for people
who already have a CSL implementation (namely Zotero) installed and
don't want to build/install a separate Haskell program just to process
citations.

Here's the code:

[1] https://github.com/wyleyr/org-citeproc
[2] https://github.com/wyleyr/org-mode  (This branch contains the version
of org-cite needed to work with org-citeproc.)

Thanks for looking!

Best,
Richard


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Test document --]
[-- Type: text/x-org, Size: 3979 bytes --]

#+OPTIONS: ':nil *:t -:t ::t <:t H:3 \n:nil ^:t arch:nil author:t
#+OPTIONS: c:nil creator:comment d:(not "LOGBOOK") date:t e:t
#+OPTIONS: email:nil f:t inline:t num:t p:nil pri:nil prop:nil stat:t
#+OPTIONS: tags:t tasks:t tex:t timestamp:t title:t toc:t todo:t |:t
#+TITLE: Org-Citeproc tests
#+DESCRIPTION: 
#+KEYWORDS:
#+LANGUAGE: en
#+SELECT_TAGS: export
#+EXCLUDE_TAGS: noexport
#+CREATOR: Emacs 23.4.1 (Org mode 8.3beta)
#+CSL_FILE: chicago-author-date.csl
#+BIBDB: bibtex testdoc.bib

* Org markup
** Simple citations
*** Parenthetical 
Some great ideas occur in books [@Brandom1994]. Others in articles
[@Hofweber2007]. Still others are in collections of previously
published work [@Russell1919], or in conference proceedings
[@Rogers1996]; sometimes they are the proceedings themselves
[@RogersKepser2007].  Sometimes, a great idea can be found in a
dissertation [@Caponigro2003], and sometimes on just a handout
[@Ross1985].  Some remain forever unpublished [@Faraci1970].

*** In-text 
Some great ideas occur in books, such as @Brandom1994. Others in
articles, such as @Hofweber2007. Still others are in collections of
previously published work, such as @Russell1919, or in conference
proceedings like @Rogers1996; sometimes they are the proceedings
themselves such as @RogersKepser2007.  Sometimes, a great idea can be
found in a dissertation, such as @Caponigro2003, and sometimes on just
a handout like @Ross1985.  Some remain forever unpublished, such as
@Faraci1970.

*** With prefix and suffix data
Some great ideas occur in books [(cite): see @Brandom1994 chapter 7]. 
Others in articles [(cite): @Hofweber2007 section 1]. Still others
are in collections of previously published work, such as 
[cite: @Russell1919 cf. section 3], or in conference proceedings 
[(cite): e.g., @Rogers1996].  Sometimes, a great idea can be found in a
dissertation, like an idea by [cite: see @Caponigro2003 chapter 1],
and sometimes on just a handout, like others by [cite: e.g., @Ross1985].

*** Citations to works with tricky field data
In some cases, the authors have names which are tricky to represent in
BibTeX, like @BelnapSteel1976, or @Vaanaanen2011.
@denDikkenMeinungerWilder2000 has a lead author that should probably
be capitalized in sentence-initial position. Sometimes, it's the
journal name which is difficult [@Belnap1970].

** Multi-cite citations
*** Parenthetical, keys only
Some great ideas occur in books, articles, or collections
[(cite): @Brandom1994; @Hofweber2007; @Russell1919].  

Some occur in conference proceedings or dissertations
[(cite): @Rogers1996; @RogersKepser2007; @Caponigro2003], and 
sometimes remain unpublished [(cite): @Ross1985; @Faraci1970].

*** Parenthetical, with prefix and suffix data for individual works
Some great ideas occur in books, articles, or collections
[(cite): see @Brandom1994 chapter 7; also @Hofweber2007; @Russell1919 is the locus classicus].  
Some occur in conference proceedings or dissertations
[(cite): @Rogers1996; for an overview, see @RogersKepser2007 and references therein].

*** Parenthetical, with common prefix and suffix data
Some great ideas occur in books, articles, or collections
[(cite): For more on this topic, see ; @Brandom1994; @Hofweber2007; @Russell1919; and references therein].  

*** All in-text, keys only
Some great ideas occur in books, articles, or collections
such as [cite: @Brandom1994; @Hofweber2007; @Russell1919].  

Some occur in conference proceedings or dissertations like
[cite: @Rogers1996; @RogersKepser2007; @Caponigro2003], and 
sometimes remain unpublished, like [cite: @Ross1985; @Faraci1970].

*** All in-text, with common prefix and suffix
Some great ideas occur in books, articles, or collections.
[cite: See: ; @Brandom1994; @Hofweber2007; @Russell1919; and references therein.]  

Some occur in conference proceedings or dissertations. 
[cite: For more on this topic, see ; @Rogers1996; @RogersKepser2007; @Caponigro2003].

* References
#+BIBLIOGRAPHY: here

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: Bibtex database for test document --]
[-- Type: text/x-bibtex, Size: 2610 bytes --]

@book{Brandom1994,
  author={Robert Brandom},
  title={Making it Explicit},
  publisher={Harvard University Press},
  year={1994}
}
@article{Hofweber2007,
  author={Hofweber, Thomas},
  title={Innocent Statements and their Metaphysically Loaded Counterparts},
  journal={Philosophers' Imprint},
  year={2007},
  volume={7},
  number={1},
  month={February}
}
@incollection{Russell1919,
  author={Bertrand Russell},
  title={Descriptions},
  booktitle={The Philosophy of Language},
  publisher={Oxford University Press},
  year={2001},
  editor={A. P. Martinich},
  chapter={15},
  pages={221--227},
  edition={Fourth}
}
@inproceedings{Rogers1996,
  author={James Rogers},
  title={A model-theoretic framework for theories of syntax},
  booktitle={Proceedings of the 34th annual meeting on Association for Computational Linguistics},
  year={1996},
  pages={10--16},
  address={Santa Cruz, CA, USA},
  organization={Association for Computational Linguistics}
}
@proceedings{RogersKepser2007,
  title={Model-theoretic syntax at 10},
  year={2007},
  editor={James Rogers and Stephan Kepser},
  organization={Association for Logic, Language and Information}
}
@phdthesis{Caponigro2003,
  author={Ivano Caponigro},
  title={Free not to ask: On the semantics of free relatives and Wh-words cross-linguistically},
  school={University of California, Los Angeles},
  year={2003},
  note={Cited text available at http://idiom.ucsd.edu/~ivano/Papers/2003_dissertation_revised_7-13-05.pdf}
}
@misc{Ross1985,
  author={Ross, John R.},
  title={The source of pseudocleft sentences},
  howpublished={Handout of a talk given at New York University},
  month={November},
  year={1985}
}
@unpublished{Faraci1970,
  author={Faraci, R.},
  title={On the deep question of pseudo-clefts},
  year={1970}
}
@book{BelnapSteel1976,
  author={Belnap, Jr., Nuel D. and Steel, Jr., Thomas B.},
  title={The logic of questions and answers},
  publisher={Yale University Press},
  year={1976}
}
@book{Vaanaanen2011,
  author={Jouko V\"{a}\"{a}n\"{a}\"{a}nen},
  title={Models and Games},
  publisher={Cambridge University Press},
  year={2011},
  volume={132},
  series={Cambridge studies in advanced mathematics}
}
@article{denDikkenMeinungerWilder2000,
  author={{den Dikken}, Marcel and Andr\'{e} Meinunger and Chris Wilder},
  title={Pseudoclefts and ellipsis},
  journal={Studia Linguistica},
  year={2000},
  volume={54},
  pages={41--89}
}
@article{Belnap1970,
  author={Belnap, Nuel},
  title={Conditional assertion and restricted quantification},
  journal={No\^{u}s},
  year={1970},
  volume={4},
  number={1},
  pages={1--12}
}

[-- Attachment #4: Test document rendered as text --]
[-- Type: text/plain, Size: 7146 bytes --]

			  ━━━━━━━━━━━━━━━━━━━━
			   ORG-CITEPROC TESTS


			    Richard Lawrence
			  ━━━━━━━━━━━━━━━━━━━━


Table of Contents
─────────────────

1 Org markup
.. 1.1 Simple citations
..... 1.1.1 Parenthetical
..... 1.1.2 In-text
..... 1.1.3 With prefix and suffix data
..... 1.1.4 Citations to works with tricky field data
.. 1.2 Multi-cite citations
..... 1.2.1 Parenthetical, keys only
..... 1.2.2 Parenthetical, with prefix and suffix data for individual works
..... 1.2.3 Parenthetical, with common prefix and suffix data
..... 1.2.4 All in-text, keys only
..... 1.2.5 All in-text, with common prefix and suffix
2 References





1 Org markup
════════════

1.1 Simple citations
────────────────────

1.1.1 Parenthetical
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books (Brandom 1994). Others in articles
  (Hofweber 2007). Still others are in collections of previously
  published work (Russell 2001), or in conference proceedings (Rogers
  1996); sometimes they are the proceedings themselves (Rogers and
  Kepser 2007).  Sometimes, a great idea can be found in a dissertation
  (Caponigro 2003), and sometimes on just a handout (Ross 1985).  Some
  remain forever unpublished (Faraci 1970).


1.1.2 In-text
╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, such as Brandom (1994). Others in
  articles, such as Hofweber (2007). Still others are in collections of
  previously published work, such as Russell (2001), or in conference
  proceedings like Rogers (1996); sometimes they are the proceedings
  themselves such as Rogers and Kepser (2007).  Sometimes, a great idea
  can be found in a dissertation, such as Caponigro (2003), and
  sometimes on just a handout like Ross (1985).  Some remain forever
  unpublished, such as Faraci (1970).


1.1.3 With prefix and suffix data
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books (see Brandom 1994 chapter 7).  Others
  in articles (Hofweber 2007 section 1). Still others are in collections
  of previously published work, such as Russell (2001 cf. section 3), or
  in conference proceedings (e.g., Rogers 1996).  Sometimes, a great
  idea can be found in a dissertation, like an idea by Caponigro (see
  2003 chapter 1), and sometimes on just a handout, like others by Ross
  (e.g., 1985).


1.1.4 Citations to works with tricky field data
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  In some cases, the authors have names which are tricky to represent in
  BibTeX, like N. D. Belnap Jr. and Steel (1976), or Väänäänen (2011).
  den Dikken, Meinunger, and Wilder (2000) has a lead author that should
  probably be capitalized in sentence-initial position. Sometimes, it's
  the journal name which is difficult (N. Belnap 1970).


1.2 Multi-cite citations
────────────────────────

1.2.1 Parenthetical, keys only
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, articles, or collections (Brandom
  1994; Hofweber 2007; Russell 2001).

  Some occur in conference proceedings or dissertations (Rogers 1996;
  Rogers and Kepser 2007; Caponigro 2003), and sometimes remain
  unpublished (Ross 1985; Faraci 1970).


1.2.2 Parenthetical, with prefix and suffix data for individual works
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, articles, or collections (see Brandom
  1994 chapter 7; also Hofweber 2007; Russell 2001 is the locus
  classicus).  Some occur in conference proceedings or dissertations
  (Rogers 1996; for an overview, see Rogers and Kepser 2007 and
  references therein).


1.2.3 Parenthetical, with common prefix and suffix data
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, articles, or collections (For more on
  this topic, see Brandom 1994; Hofweber 2007; Russell 2001, and
  references therein).


1.2.4 All in-text, keys only
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, articles, or collections such as
  Brandom (1994), Hofweber (2007), Russell (2001).

  Some occur in conference proceedings or dissertations like Rogers
  (1996), Rogers and Kepser (2007), Caponigro (2003), and sometimes
  remain unpublished, like Ross (1985), Faraci (1970).


1.2.5 All in-text, with common prefix and suffix
╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌╌

  Some great ideas occur in books, articles, or collections.  See:
  Brandom (1994), Hofweber (2007), Russell (2001), and references
  therein.

  Some occur in conference proceedings or dissertations.  For more on
  this topic, see Rogers (1996), Rogers and Kepser (2007), Caponigro
  (2003).


2 References
════════════

  Belnap, Nuel. 1970. “Conditional Assertion and Restricted Quantification.”
  _Noûs_ 4 (1): 1–12.

  Belnap, Nuel D., Jr., and Thomas B. Steel Jr. 1976. _The Logic of Questions and
  Answers_. Yale University Press.

  Brandom, Robert. 1994. _Making It Explicit_. Harvard University Press.

  Caponigro, Ivano. 2003. “Free Not to Ask: On the Semantics of Free Relatives and
  Wh-Words Cross-Linguistically.” PhD thesis, University of California, Los
  Angeles.

  den Dikken, Marcel, André Meinunger, and Chris Wilder. 2000. “Pseudoclefts and
  Ellipsis.” _Studia Linguistica_ 54: 41–89.

  Faraci, R. 1970. “On the Deep Question of Pseudo-Clefts.”

  Hofweber, Thomas. 2007. “Innocent Statements and Their Metaphysically Loaded
  Counterparts.” _Philosophers’ Imprint_ 7 (1).

  Rogers, James. 1996. “A Model-Theoretic Framework for Theories of Syntax.” In
  _Proceedings of the 34th Annual Meeting on Association for Computational
  Linguistics_, 10–16. Santa Cruz, CA, USA: Association for Computational
  Linguistics.

  Rogers, James, and Stephan Kepser, eds. 2007. _Model-Theoretic Syntax at 10_.
  Association for Logic, Language; Information.

  Ross, John R. 1985. “The Source of Pseudocleft Sentences.” Handout of a talk
  given at New York University.

  Russell, Bertrand. 2001. “Descriptions.” In _The Philosophy of Language_, edited
  by A. P. Martinich, Fourth, 221–27. Oxford University Press.

  Väänäänen, Jouko. 2011. _Models and Games_. Vol. 132. Cambridge Studies in
  Advanced Mathematics. Cambridge University Press.

[-- Attachment #5: Test document rendered as HTML --]
[-- Type: text/html, Size: 12689 bytes --]

[-- Attachment #6: Test document rendered as ODT --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 12730 bytes --]

Re: org-cite and org-citeproc

[Eric S Fraga]

[-- Attachment #1: Type: text/plain, Size: 1054 bytes --]

On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote:
> Hi everyone,
>
> I thought I should send an update to let you know that org-citeproc [1],
> the command-line citation processing tool I've been working on, now
> supports multi-cites.  I believe that means it is now capable of
> processing all citations in the basic citation syntax.  It can output
> plain text, HTML, and ODT (and a Pandoc native format, mostly useful for
> debugging).

This looks really good!  Thanks.

However, for some reason, libreoffice doesn't display the citations in
the ODT document you have included.  I have had a look at the actual ODT
file and it looks fine.  Can you suggest what may be wrong?  I'm
attaching a crop of a screenshot to illustrate what I mean.  Highlighted
is where I would have expected to see some text for the citation.

A second question: what will be required to use the new cite syntax with
LaTeX/PDF which will remain my main target for export?

Thanks,
eric
-- 
: Eric S Fraga (0xFFFCF67D), Emacs 24.4.1, Org release_8.3beta-820-gd92ef9

[-- Attachment #2: screendump-20150331091550.png --]
[-- Type: image/png, Size: 38029 bytes --]

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Eric and all,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Saturday, 28 Mar 2015 at 10:53, Richard Lawrence wrote:

>> I thought I should send an update to let you know that org-citeproc [1],
>> the command-line citation processing tool I've been working on, now
>> supports multi-cites.  I believe that means it is now capable of
>> processing all citations in the basic citation syntax.  It can output
>> plain text, HTML, and ODT (and a Pandoc native format, mostly useful for
>> debugging).
>
> This looks really good!  Thanks.

Thanks!

> However, for some reason, libreoffice doesn't display the citations in
> the ODT document you have included.  I have had a look at the actual ODT
> file and it looks fine.  Can you suggest what may be wrong?  

Hmm, you're right.  I don't have LibreOffice on the machine where I am
working on org-citeproc, but I tested it on another machine (OS X,
LibreOffice version 4.2.8.2 I think), and the citation text is indeed
missing.

As you say, the actual file looks fine to me, and it displays correctly
on Google Drive (which is where I originally tested the output).

So LibreOffice might be where the problem is.  That doesn't mean there
isn't a problem with org-citeproc, or the ODT exporter, but given that
the file looks fine and another viewer handles it correctly, LibreOffice
would be my first suspect.

I don't really know anything about the ODT format, though.  My code
more-or-less blindly pastes Pandoc-generated XML into the document
during Org ODT export.  Can someone who knows more about the format take
a look at the file and see if there is some subtle problem I'm not
noticing?

> A second question: what will be required to use the new cite syntax with
> LaTeX/PDF which will remain my main target for export?

I think this needs more discussion, actually.

The citation syntax can basically be mapped directly to BibLaTeX syntax,
so generating LaTeX that will be processed with BibLaTeX is a simple and
straightforward modification to Org's LaTeX exporter, and compiling the
exported document should continue to require no external programs except
the LaTeX distribution itself.  That is, `C-c C-e l whatever' should
continue to be all that is needed from a user's perspective, plus or
minus some LATEX_HEADER setup.

However, there are a couple of other scenarios to think about:

1) Some people may still need to use plain BibTeX.  Generating LaTeX
that is intended to be processed with BibTeX, as opposed to BibLaTeX, is
a little trickier, because (IIUC) BibTeX does not support multi-cite
citations.  Also, I don't know how easy it would be to capture the other
features of citations (e.g., the in-text vs. parenthetical distinction)
without relying on a package like natbib.  If generating
BibTeX-compatible LaTeX is needed, is it OK to rely on such a package?

2) Some people might find it useful *not* to generate LaTeX citation
commands, and instead have a tool like org-citeproc process citations
instead, with the exporter inserting the rendered output into the
document.  This could be useful if e.g. you are preparing to submit to a
journal that provides a CSL file, but not a BibTeX or BibLaTeX style.

If either of these scenarios represents an important use case, it will
be more work to implement.  

I suggest that for now we just target BibLaTeX, but I'd like to hear
from other people about whether there's reason to do more than that.
 
Best,
Richard

Re: org-cite and org-citeproc

[Nick Dokos]

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> However, there are a couple of other scenarios to think about:
>
> 1) Some people may still need to use plain BibTeX.  Generating LaTeX
> that is intended to be processed with BibTeX, as opposed to BibLaTeX, is
> a little trickier, because (IIUC) BibTeX does not support multi-cite
> citations.

I know next to nothing about citations in general, so please bear with
me: if multi-cite support means being able to condense citations (e.g.
[1-3, 5, 9]), then bibtex can do at least some of that
(e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).

> Also, I don't know how easy it would be to capture the other
> features of citations (e.g., the in-text vs. parenthetical distinction)
> without relying on a package like natbib.  If generating
> BibTeX-compatible LaTeX is needed, is it OK to rely on such a package?
>

IMO yes.

Nick

Re: org-cite and org-citeproc

[Thomas S. Dye]

Aloha all,

Nick Dokos <ndokos@gmail.com> writes:

> Richard Lawrence <richard.lawrence@berkeley.edu> writes:
>
>> However, there are a couple of other scenarios to think about:
>>
>> 1) Some people may still need to use plain BibTeX.  Generating LaTeX
>> that is intended to be processed with BibTeX, as opposed to BibLaTeX, is
>> a little trickier, because (IIUC) BibTeX does not support multi-cite
>> citations.
>
> I know next to nothing about citations in general, so please bear with
> me: if multi-cite support means being able to condense citations (e.g.
> [1-3, 5, 9]), then bibtex can do at least some of that
> (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).

Multiple citations with natbib are limited in the sense that individual
citations within them don't carry pre- and post-notes.  BibLaTeX does
away with this restriction.

>> Also, I don't know how easy it would be to capture the other
>> features of citations (e.g., the in-text vs. parenthetical distinction)
>> without relying on a package like natbib.  If generating
>> BibTeX-compatible LaTeX is needed, is it OK to rely on such a package?
>>
>
> IMO yes.

IMO yes, too.

The org-export-cite-add-citation-mode-latex function that Aaron Ecay
wrote allows the author to choose (implicitly) which package to use.  I
like this design because it can accommodate new packages without changes
to the Org mode code.

,-------------------------------------------------------------------------
| Your comment inspired me to implement                                   
| org-export-cite-add-citation-mode-latex in the experimental citation    
| support I just pushed.  So you can do:                                  
|                                                                         
| (org-export-cite-add-citation-mode-latex "tsd"                          
| "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}")       
|                                                                         
| Add to your document:                                                   
|                                                                         
| #+CITATION_MODE: tsd                                                    
|                                                                         
| And citations should just work with your chosen commands.  I’m sure when
| advanced citation support comes along (whether from subtypes or plists),
| a similarly simple wrapper can be implemented.                          
`-------------------------------------------------------------------------

I haven't found time to experiment with the citation developments or to
read through the developing code base.  Was this feature of Aaron's
experimental support subsequently dropped?

All the best,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-cite and org-citeproc

[Eric S Fraga]

On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote:
> Hi Eric and all,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:

[...]

>> However, for some reason, libreoffice doesn't display the citations in
>> the ODT document you have included.  I have had a look at the actual ODT
>> file and it looks fine.  Can you suggest what may be wrong?  
>
> Hmm, you're right.  I don't have LibreOffice on the machine where I am
> working on org-citeproc, but I tested it on another machine (OS X,
> LibreOffice version 4.2.8.2 I think), and the citation text is indeed
> missing.

Thanks for confirming this.  At least it's not me!  I hope somebody
can figure out what is going on here.

[...]

>> A second question: what will be required to use the new cite syntax with
>> LaTeX/PDF which will remain my main target for export?
>
> I think this needs more discussion, actually.
>
> The citation syntax can basically be mapped directly to BibLaTeX syntax,
> so generating LaTeX that will be processed with BibLaTeX is a simple and
> straightforward modification to Org's LaTeX exporter, and compiling the

Although I normally use bibtex, I am happy moving to biblatex if it
means unifying org's citation approaches.  I don't need the extra
features (e.g. multicite) in practice but I'm also not attached to
bibtex.

thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Tom and all,

tsd@tsdye.com (Thomas S. Dye) writes:

>> I know next to nothing about citations in general, so please bear with
>> me: if multi-cite support means being able to condense citations (e.g.
>> [1-3, 5, 9]), then bibtex can do at least some of that
>> (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).
>
> Multiple citations with natbib are limited in the sense that individual
> citations within them don't carry pre- and post-notes.  BibLaTeX does
> away with this restriction.

Just to clarify: our syntax allows both pre- and post-notes for each
individual reference within a citation, plus common pre- and post-notes
for the citation as a whole.  Is it only the latter which BibTeX does
not support?  Or is it also that it can't handle pre- and post-notes for
individual references when there is more than one work cited?  I don't
think I've ever tried to do something that complicated with plain BibTeX.

(Also, do you think it is important to support plain BibTeX at all?  It
seems like we should not bother with this problem unless it's important
for a lot of people.  I personally would be fine with just targeting
BibLaTeX, and it sounds like Eric would be too.)

> The org-export-cite-add-citation-mode-latex function that Aaron Ecay
> wrote allows the author to choose (implicitly) which package to use.  I
> like this design because it can accommodate new packages without changes
> to the Org mode code.
>
> ,-------------------------------------------------------------------------
> | Your comment inspired me to implement                                   
> | org-export-cite-add-citation-mode-latex in the experimental citation    
> | support I just pushed.  So you can do:                                  
> |                                                                         
> | (org-export-cite-add-citation-mode-latex "tsd"                          
> | "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}")       
> |                                                                         
> | Add to your document:                                                   
> |                                                                         
> | #+CITATION_MODE: tsd                                                    
> |                                                                         
> | And citations should just work with your chosen commands.  I’m sure when
> | advanced citation support comes along (whether from subtypes or plists),
> | a similarly simple wrapper can be implemented.                          
> `-------------------------------------------------------------------------
>
> I haven't found time to experiment with the citation developments or to
> read through the developing code base.  Was this feature of Aaron's
> experimental support subsequently dropped?

No, I haven't touched that part of the code, and as far as I know that
should still work.  However, I also haven't been able to make sense of
how the CITATION_MODE and CITATION_STYLE keywords should work in
non-LaTeX backends, so my code doesn't make any use of them, either.  

If I understand correctly, the mode and the style are two pieces of
information that jointly determine how citations should be formatted.
The reason they are separated is that you can have multiple styles
associated with a mode (or is it the other way around?).  Is it right to
say that in LaTeX, choosing a mode and a style determines both
which citation commands are available and what their behavior is?

In the CSL world, both of these pieces of information seem to be
determined by the choice of CSL stylesheet.  Thus, I went with a single
keyword, CSL_FILE, to specify this information.  I guess one could also
go the other way, and try to select a stylesheet based on CITATION_MODE
and CITATION_STYLE, but I wasn't sure how to do that.  I also don't
really know if it would be useful to provide a notion of `custom modes'
outside of LaTeX; as far as I can see, all customization would just come
down to selecting a different stylesheet.  But maybe I'm missing
something important?

Best,
Richard

Re: org-cite and org-citeproc

[Rasmus]

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> I don't really know anything about the ODT format, though.  My code
> more-or-less blindly pastes Pandoc-generated XML into the document
> during Org ODT export.  Can someone who knows more about the format take
> a look at the file and see if there is some subtle problem I'm not
> noticing?

I can't test your code 'cause I, for personal/silly reasons, refuse to
spend any more dealing with compiling Haskell.

That being said, my gut feeling is that you have to define the data
elsewhere.

For example, to add a (sub)title to a odt document the field/keyword is
defined in a file different from contents.xml and will just not be printed
if used in contents.xml only.

Also, the bibliography is not "correct" in the sense that if it was setup
in the right semantic way, it would be gray in LO, like the TOC.

—Rasmus

-- 
Bang bang

Re: org-cite and org-citeproc

[Thomas S. Dye]

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Hi Tom and all,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>>> I know next to nothing about citations in general, so please bear with
>>> me: if multi-cite support means being able to condense citations (e.g.
>>> [1-3, 5, 9]), then bibtex can do at least some of that
>>> (e.g. http://texblog.org/2007/05/28/mulitple-reference-citation/).
>>
>> Multiple citations with natbib are limited in the sense that individual
>> citations within them don't carry pre- and post-notes.  BibLaTeX does
>> away with this restriction.
>
> Just to clarify: our syntax allows both pre- and post-notes for each
> individual reference within a citation, plus common pre- and post-notes
> for the citation as a whole.  Is it only the latter which BibTeX does
> not support?  Or is it also that it can't handle pre- and post-notes for
> individual references when there is more than one work cited?  I don't
> think I've ever tried to do something that complicated with plain BibTeX.

IIUC, plain BibTeX just supports \cite, and it was the natbib style
that introduced parenthetical, \citep, and text, \citet, citation
commands.  The corresponding commands in BibLaTeX styles are \parencite
and \textcite.

With natbib, it is possible to give a pre-note and a post-note to the
citation as a whole, but not to individual citations within it.  In
order to support your syntax fully, I think BibLaTeX is needed.

> (Also, do you think it is important to support plain BibTeX at all?  It
> seems like we should not bother with this problem unless it's important
> for a lot of people.  I personally would be fine with just targeting
> BibLaTeX, and it sounds like Eric would be too.)

Well, one benefit of Aaron's function was to make this choice
superfluous, both now and in the future.  It binds the two citation
commands you've implemented to citation commands implemented in
CITATION_STYLE.  As Aaron notes, it should be easy to modify this (to
bind additional commands) when advanced citation support comes along.

>> The org-export-cite-add-citation-mode-latex function that Aaron Ecay
>> wrote allows the author to choose (implicitly) which package to use.  I
>> like this design because it can accommodate new packages without changes
>> to the Org mode code.
>>
>> ,-------------------------------------------------------------------------
>> | Your comment inspired me to implement                                   
>> | org-export-cite-add-citation-mode-latex in the experimental citation    
>> | support I just pushed.  So you can do:                                  
>> |                                                                         
>> | (org-export-cite-add-citation-mode-latex "tsd"                          
>> | "\\mycitecommand[%s][%s]{%s}" "\\myparencitecommand[%s][%s]{%s}")       
>> |                                                                         
>> | Add to your document:                                                   
>> |                                                                         
>> | #+CITATION_MODE: tsd                                                    
>> |                                                                         
>> | And citations should just work with your chosen commands.  I’m sure when
>> | advanced citation support comes along (whether from subtypes or plists),
>> | a similarly simple wrapper can be implemented.                          
>> `-------------------------------------------------------------------------
>>
>> I haven't found time to experiment with the citation developments or to
>> read through the developing code base.  Was this feature of Aaron's
>> experimental support subsequently dropped?
>
> No, I haven't touched that part of the code, and as far as I know that
> should still work.  However, I also haven't been able to make sense of
> how the CITATION_MODE and CITATION_STYLE keywords should work in
> non-LaTeX backends, so my code doesn't make any use of them, either.  

IIUC, CITATION_STYLE refers to the bibliography style file.
CITATION_MODE makes it possible for an author using your syntax to get
away from the Harvard mode citations that seem to be your target and use
another mode such as the footnote citations common in the humanities.

> If I understand correctly, the mode and the style are two pieces of
> information that jointly determine how citations should be formatted.
> The reason they are separated is that you can have multiple styles
> associated with a mode (or is it the other way around?).  Is it right to
> say that in LaTeX, choosing a mode and a style determines both
> which citation commands are available and what their behavior is?

Typically, a bibliography style file defines several citation commands,
which might belong to one or more modes.  It sounds to me as if the CSL
world conflates styles and modes, but I haven't looked closely.

> In the CSL world, both of these pieces of information seem to be
> determined by the choice of CSL stylesheet.  Thus, I went with a single
> keyword, CSL_FILE, to specify this information.  I guess one could also
> go the other way, and try to select a stylesheet based on CITATION_MODE
> and CITATION_STYLE, but I wasn't sure how to do that.  I also don't
> really know if it would be useful to provide a notion of `custom modes'
> outside of LaTeX; as far as I can see, all customization would just come
> down to selecting a different stylesheet.  But maybe I'm missing
> something important?

I think you might be able to merge CSL_FILE and CITATION_STYLE, since
they both point to a style file.

hth,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-cite and org-citeproc

[Andreas Leha]

Hi,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:
> On Tuesday, 31 Mar 2015 at 12:13, Richard Lawrence wrote:
>> Hi Eric and all,
>>
>> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
> [...]
>
>>> However, for some reason, libreoffice doesn't display the citations in
>>> the ODT document you have included.  I have had a look at the actual ODT
>>> file and it looks fine.  Can you suggest what may be wrong?  
>>
>> Hmm, you're right.  I don't have LibreOffice on the machine where I am
>> working on org-citeproc, but I tested it on another machine (OS X,
>> LibreOffice version 4.2.8.2 I think), and the citation text is indeed
>> missing.
>
> Thanks for confirming this.  At least it's not me!  I hope somebody
> can figure out what is going on here.
>
> [...]
>
>>> A second question: what will be required to use the new cite syntax with
>>> LaTeX/PDF which will remain my main target for export?
>>
>> I think this needs more discussion, actually.
>>
>> The citation syntax can basically be mapped directly to BibLaTeX syntax,
>> so generating LaTeX that will be processed with BibLaTeX is a simple and
>> straightforward modification to Org's LaTeX exporter, and compiling the
>
> Although I normally use bibtex, I am happy moving to biblatex if it
> means unifying org's citation approaches.  I don't need the extra
> features (e.g. multicite) in practice but I'm also not attached to
> bibtex.

I am a happy biblatex user for all my 'own' documents.  But (as was
mentioned previously) scientific journals that accept latex submissions
will require bibtex and won't support biblatex.  So, I'd say that one of
the other methods (preferably bibtex) is still necessary.

Regards,
Andreas

Re: org-cite and org-citeproc

[Richard Lawrence]

Rasmus <rasmus@gmx.us> writes:

> Richard Lawrence <richard.lawrence@berkeley.edu> writes:
>
>> I don't really know anything about the ODT format, though.  My code
>> more-or-less blindly pastes Pandoc-generated XML into the document
>> during Org ODT export.  Can someone who knows more about the format take
>> a look at the file and see if there is some subtle problem I'm not
>> noticing?
>
> I can't test your code 'cause I, for personal/silly reasons, refuse to
> spend any more dealing with compiling Haskell.

Fair enough. :)

> That being said, my gut feeling is that you have to define the data
> elsewhere.
>
> For example, to add a (sub)title to a odt document the field/keyword is
> defined in a file different from contents.xml and will just not be printed
> if used in contents.xml only.

Hmm.  But the citations are all just represented as <text:p>
nodes...surely that doesn't have to be defined elsewhere?

I am now guessing that the problem is that you can't have one <text:p>
inside another.  Each paragraph is wrapped in a <text:p>, but so are the
citations within it...maybe that is not correct and so LibreOffice
doesn't like it.

> Also, the bibliography is not "correct" in the sense that if it was setup
> in the right semantic way, it would be gray in LO, like the TOC.

Do you know what other markup is required in this case?  It looks like
maybe the TOC is gray because it is marked with a "text:protected"
attribute, or maybe because it has an associated "OrgIndexSection"
style?
 
Thanks!

Best,
Richard

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Tom and all,

Thanks for answering my questions!

tsd@tsdye.com (Thomas S. Dye) writes:

> With natbib, it is possible to give a pre-note and a post-note to the
> citation as a whole, but not to individual citations within it.  In
> order to support your syntax fully, I think BibLaTeX is needed.

OK, good to know.

>> (Also, do you think it is important to support plain BibTeX at all?  It
>> seems like we should not bother with this problem unless it's important
>> for a lot of people.  I personally would be fine with just targeting
>> BibLaTeX, and it sounds like Eric would be too.)
>
> Well, one benefit of Aaron's function was to make this choice
> superfluous, both now and in the future.  It binds the two citation
> commands you've implemented to citation commands implemented in
> CITATION_STYLE.  As Aaron notes, it should be easy to modify this (to
> bind additional commands) when advanced citation support comes along.

I think I have to retract what I said earlier: I doubt this part of
Aaron's code still works in my branch, because I think Aaron was
assuming citation objects contain just one reference; in my branch, I've
merged in the parser support Nicolas later implemented for multi-cite
citations.  So a CITATION_MODE needs to know how to turn a list of
works, each with associated prefix and suffix data, into a complete
citation command.

This complicates things enough that probably custom citation modes
should be defined as Lisp functions, rather than via format
strings...what do you think?

I'm still having a hard time seeing what an analogous customization
would look like for non-LaTeX backends.  The LaTeX exporter is unique in
that Org produces output which must then be further processed by another
tool, so having customizable control over how a citation `looks' to that
tool makes sense.  But in other backends, the Org exporter itself
produces the final document; there's no intermediate representation
besides Org's own, plus whatever arguments are passed to a citation
processing tool like org-citeproc.  So, if that's right, the analogous
customization in a non-LaTeX backend would be something like a filter,
one that pre-processes citation objects before they are run through the
external tool, or that post-processes the strings that come back (or
both).  Does that make sense?  Certainly, both of those things are
possible.

> Typically, a bibliography style file defines several citation commands,
> which might belong to one or more modes.  ...
> I think you might be able to merge CSL_FILE and CITATION_STYLE, since
> they both point to a style file.

OK, I see, that makes things clearer.  Would it make sense to have two
keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
thinking it will be tricky to come up with a single set of values for a
CITATION_STYLE keyword that can be correctly mapped to both kinds of
backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like

#+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl

or something similar?

Best,
Richard

Re: org-cite and org-citeproc

[Thomas S. Dye]

Aloha Richard,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Hi Tom and all,
>
> Thanks for answering my questions!
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>> With natbib, it is possible to give a pre-note and a post-note to the
>> citation as a whole, but not to individual citations within it.  In
>> order to support your syntax fully, I think BibLaTeX is needed.
>
> OK, good to know.
>
>>> (Also, do you think it is important to support plain BibTeX at all?  It
>>> seems like we should not bother with this problem unless it's important
>>> for a lot of people.  I personally would be fine with just targeting
>>> BibLaTeX, and it sounds like Eric would be too.)
>>
>> Well, one benefit of Aaron's function was to make this choice
>> superfluous, both now and in the future.  It binds the two citation
>> commands you've implemented to citation commands implemented in
>> CITATION_STYLE.  As Aaron notes, it should be easy to modify this (to
>> bind additional commands) when advanced citation support comes along.
>
> I think I have to retract what I said earlier: I doubt this part of
> Aaron's code still works in my branch, because I think Aaron was
> assuming citation objects contain just one reference; in my branch, I've
> merged in the parser support Nicolas later implemented for multi-cite
> citations.  So a CITATION_MODE needs to know how to turn a list of
> works, each with associated prefix and suffix data, into a complete
> citation command.
>
> This complicates things enough that probably custom citation modes
> should be defined as Lisp functions, rather than via format
> strings...what do you think?
>
> I'm still having a hard time seeing what an analogous customization
> would look like for non-LaTeX backends.  The LaTeX exporter is unique in
> that Org produces output which must then be further processed by another
> tool, so having customizable control over how a citation `looks' to that
> tool makes sense.  But in other backends, the Org exporter itself
> produces the final document; there's no intermediate representation
> besides Org's own, plus whatever arguments are passed to a citation
> processing tool like org-citeproc.  So, if that's right, the analogous
> customization in a non-LaTeX backend would be something like a filter,
> one that pre-processes citation objects before they are run through the
> external tool, or that post-processes the strings that come back (or
> both).  Does that make sense?  Certainly, both of those things are
> possible.

Yes, I think an export filter would work for LaTeX.

The general form for BibLaTeX is:

\cites(⟨multiprenote⟩)(⟨multipostnote⟩)[⟨prenote⟩][⟨postnote⟩]{⟨key⟩}...[⟨prenote⟩][⟨postnote⟩]{⟨key⟩}

where \cites can also be \parencites, \textcites, etc.

For natbib it is:

\cite[⟨prenote⟩][⟨postnote⟩]{⟨key⟩,...⟨key⟩}

where \cite can also be \citep, \citet, etc.


>> Typically, a bibliography style file defines several citation commands,
>> which might belong to one or more modes.  ...
>> I think you might be able to merge CSL_FILE and CITATION_STYLE, since
>> they both point to a style file.
>
> OK, I see, that makes things clearer.  Would it make sense to have two
> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
> style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
> thinking it will be tricky to come up with a single set of values for a
> CITATION_STYLE keyword that can be correctly mapped to both kinds of
> backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like
>
> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl

Won't the backends sort this out without the additional mapping?

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-cite and org-citeproc

[Rasmus]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

Hi,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

>> That being said, my gut feeling is that you have to define the data
>> elsewhere.
>>
>> For example, to add a (sub)title to a odt document the field/keyword is
>> defined in a file different from contents.xml and will just not be printed
>> if used in contents.xml only.
>
> Hmm.  But the citations are all just represented as <text:p>
> nodes...surely that doesn't have to be defined elsewhere?

You are right.  Also, oolatex inserts citations as plain text as well.  As
I recall, it can be done "semantically" and section 6.3 of the odt
standard suggest that this may be true, but it's not immediately obvious
how to do it.

> I am now guessing that the problem is that you can't have one <text:p>
> inside another.  Each paragraph is wrapped in a <text:p>, but so are the
> citations within it...maybe that is not correct and so LibreOffice
> doesn't like it.

I don't think <text:p> can be nested cf.

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949

>> Also, the bibliography is not "correct" in the sense that if it was setup
>> in the right semantic way, it would be gray in LO, like the TOC.
>
> Do you know what other markup is required in this case?  It looks like
> maybe the TOC is gray because it is marked with a "text:protected"
> attribute, or maybe because it has an associated "OrgIndexSection"
> style?

It has to be formatted as a bibliography.

http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography

I've attached a minimal oolatex example (mk4ht oolatex test.tex) of

    \documentclass{article}
    \usepackage[english]{babel}
    \usepackage[authordate]{biblatex-chicago}
    \addbibresource{~/documents/literature/lit.bib}
    \begin{document}
    before \textcite[pre][post]{schulte12} and after
    \printbibliography
    \end{document}

Hope it helps,
Rasmus

-- 
. . . The proofs are technical in nature and provides no real understanding

[-- Attachment #2: test.odt --]
[-- Type: application/vnd.oasis.opendocument.text, Size: 7527 bytes --]

Re: org-cite and org-citeproc

[Eric S Fraga]

On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:

[...]

> I am a happy biblatex user for all my 'own' documents.  But (as was
> mentioned previously) scientific journals that accept latex submissions
> will require bibtex and won't support biblatex.  So, I'd say that one of
> the other methods (preferably bibtex) is still necessary.

Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
requirement for me as well therefore.

Thanks,
eric

-- 
: Eric S Fraga (0xFFFCF67D), Emacs 25.0.50.1, Org release_8.3beta-921-gfd8c84

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Eric and all,

Eric S Fraga <e.fraga@ucl.ac.uk> writes:

> On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:
>
> [...]
>
>> I am a happy biblatex user for all my 'own' documents.  But (as was
>> mentioned previously) scientific journals that accept latex submissions
>> will require bibtex and won't support biblatex.  So, I'd say that one of
>> the other methods (preferably bibtex) is still necessary.
>
> Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
> requirement for me as well therefore.

Can someone suggest how a parenthetical citation with common prefix and
suffix data, like

  [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
  and references therein.] 

should map to plain BibTeX?  Maybe there is no general answer to this
question, but what would a reasonable default be?  Maybe this?

  (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
  and references therein.)

That is, just place the prefix and suffix data in the surrounding text,
inserting commas after the part for each individual work, and wrapping
the whole thing in parentheses?

Thanks!
 
Best,
Richard

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Rasmus,

Thanks, this is helpful.  I will try to fix these things soon.

Rasmus <rasmus@gmx.us> writes:
>
>> Hmm.  But the citations are all just represented as <text:p>
>> nodes...surely that doesn't have to be defined elsewhere?
>
> You are right.  Also, oolatex inserts citations as plain text as well.  As
> I recall, it can be done "semantically" and section 6.3 of the odt
> standard suggest that this may be true, but it's not immediately obvious
> how to do it.
>
>> I am now guessing that the problem is that you can't have one <text:p>
>> inside another.  Each paragraph is wrapped in a <text:p>, but so are the
>> citations within it...maybe that is not correct and so LibreOffice
>> doesn't like it.
>
> I don't think <text:p> can be nested cf.
>
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#__RefHeading__1415138_253892949

OK, good to know.  Looks like <text:reference-mark> or <text:note> might
be the way to go. 

>>> Also, the bibliography is not "correct" in the sense that if it was setup
>>> in the right semantic way, it would be gray in LO, like the TOC.
>>
>> Do you know what other markup is required in this case?  It looks like
>> maybe the TOC is gray because it is marked with a "text:protected"
>> attribute, or maybe because it has an associated "OrgIndexSection"
>> style?
>
> It has to be formatted as a bibliography.
>
> http://docs.oasis-open.org/office/v1.2/os/OpenDocument-v1.2-os-part1.html#element-text_bibliography
>

Also useful.  This might take a while for me to figure out, as Pandoc
does not seem to generate this markup when formatting a
bibliography...maybe I'll see if they are willing to work on this
upstream.

Best,
Richard

Re: org-cite and org-citeproc

[Aaron Ecay]

Hi Richard, hi all,

First of all, thanks very much for your work!

I’ve been (barely) following this discussion, but have been too busy to
do any actual coding.  I sat down today to try to integrate Richard’s
branch with my work, but didn’t get very far.  I think it would be a
waste of effort to try to support more than one citation processor
(citeproc-java vs. org-citeproc).

I went round and round with myself about this, and concluded that we
ought to keep on working on the org-citeproc approach for now (drop
citeproc-java).  But I do think someone eventually ought to reimplement
org-citeproc based on citeproc-js, to yield something that can be
distributed via npm.  This will be less fool-proof than java, but better
than the Haskell experience for many users (such as Rasmus and me – far
from non-technical people!).  You mention zotero as a third option –
it’s possible, but I think we’d be better served by a tool that focuses
solely on processing and is not so closely tied with database
management.

There are a couple of other differences in our approaches.

The first is whether the processor generates the in-text citations (you)
or whether it’s done in elisp (me).  It’s not obvious which is superior.
The real test will come when more diverse citation types are implemented
(e.g. full citations in footnotes or numbers which reference a numbered
bibliography at the end of the document).

The second is whether the processor generates markup in the target
language directly (you) or whether the processor’s output is converted
to org markup, then passed through org’s exporters (me).  I think my
approach here is preferable, since it generalizes to every backend.  Do
you think something like this could work for org-citeproc?  It would
probably require some additional special code in ox-odt.  (But we might
need that in any case, see below.)

It would be good from an intelligibility/maintainability perspective if
you could use the json.el library rather than generating json strings by
hand.  This is part of the emacs core since version 23.something, so
compatibility should not be a big issue.

You wrote (mixing replies to various emails in this thread):

> This complicates things enough that probably custom citation modes
> [in Latex – AE] should be defined as Lisp functions, rather than via
> format strings...what do you think?

I’d rather avoid it, since I think org->latex is going to be an important
usecase for many people.  I see us eventually supporting two flavors of
latex output.  The first should aim to generate a full set of biblatex
commands but with little user customizability.  The second will rely on
just 2 citation commands (paren and non-paren), plus some elisp routines
for combining them into multicites etc.  These two cite commands then can
be customized by the user.

If people need more flexibility but cannot use biblatex, they can
always hack up a custom exporter for themselves.  But I think we ought
to support relatively simple needs with simple configuration settings.

> OK, I see, that makes things clearer.  Would it make sense to have two
> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
> style can vary independently when exporting to LaTeX vs. non-LaTeX?  

Yes.

> I'm thinking it will be tricky to come up with a single set of values
> for a CITATION_STYLE keyword that can be correctly mapped to both
> kinds of backend.  

I agree.

> Or maybe CITATION_STYLE should have "sub"-keywords, like
> 
> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl

This is equivalent (up to bikeshedding) to separate keywords.  I’d like
the bikeshed painted with separate keywords, though, because that leaves
room for passing additional options to biblatex (to be added to the
\usepackage and/or \printbibliography commands).

> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
> 
>   [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
>   and references therein.] 
> 
> should map to plain BibTeX?  Maybe there is no general answer to this
> question, but what would a reasonable default be?  Maybe this?
> 
>   (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
>   and references therein.)
> 
> That is, just place the prefix and suffix data in the surrounding text,
> inserting commas after the part for each individual work, and wrapping
> the whole thing in parentheses?

I agree.  (This is like the second flavor of latex support I described
above.)

> Also useful.  This might take a while for me to figure out, as Pandoc
> does not seem to generate this markup when formatting a
> bibliography...maybe I'll see if they are willing to work on this
> upstream.

I think we should not rely on pandoc to fix this for us.  It makes it
harder to move away from Haskell if (when) we want to.

I used up all the time I had today to understanding the code and
surrounding conceptual issues.  However, I will try to integrate your
changes with my branch sometime in the next few days-week.

Thanks again,

-- 
Aaron Ecay

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Tom and all,

tsd@tsdye.com (Thomas S. Dye) writes:

>> OK, I see, that makes things clearer.  Would it make sense to have two
>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
>> style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
>> thinking it will be tricky to come up with a single set of values for a
>> CITATION_STYLE keyword that can be correctly mapped to both kinds of
>> backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like
>>
>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>
> Won't the backends sort this out without the additional mapping?

Surely they could, but I guess I'm unclear on how that should happen.

Org could keep a variable mapping citation styles to default values for
the respective backends, like:

(defcustom org-cite-citation-styles
  '(("author-year" (biblatex-pkg-args "citestyle=authoryear,bibstyle=authoryear")
                   (csl-file "/path/to/chicago-author-date.csl"))
                   ...))

so in a document, you could just write

#+CITATION_STYLE: author-year

or similar.  Is this what you have in mind?

That seems like a good way to provide reasonable defaults using a
high-level label.  But I think using a high-level label like this will
underdetermine the actual style to use (on both sides, I assume); and
the problem is that if we make the labels more fine-grained, there's no
longer any guarantee that, for a given style label, a suitable style
file will be available on both LaTeX and non-LaTeX backends.

There obviously needs to be some mechanism so authors can specify their
citation style quite precisely for the backends they are interested in.
(Maybe just customizing this variable would do the trick.)  But what
should the fallback mechanism look like when a particular style does not
specify the required information for a given export backend?  E.g., if
CITATION_STYLE is X and we're exporting to HTML, but the entry in
org-cite-citation-styles does not specify a CSL file for style X?  Would
it be enough to have a single 'default clause or similar in
org-cite-citation-styles to use in that kind of case?

Best,
Richard

Re: org-cite and org-citeproc

[Thomas S. Dye]

Hi Richard,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Hi Tom and all,
>
> tsd@tsdye.com (Thomas S. Dye) writes:
>
>>> OK, I see, that makes things clearer.  Would it make sense to have two
>>> keywords, say LATEX_CITE_STYLE and CSL_FILE or similar, so that the
>>> style can vary independently when exporting to LaTeX vs. non-LaTeX?  I'm
>>> thinking it will be tricky to come up with a single set of values for a
>>> CITATION_STYLE keyword that can be correctly mapped to both kinds of
>>> backend.  Or maybe CITATION_STYLE should have "sub"-keywords, like
>>>
>>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>>
>> Won't the backends sort this out without the additional mapping?
>
> Surely they could, but I guess I'm unclear on how that should happen.
>
> Org could keep a variable mapping citation styles to default values for
> the respective backends, like:
>
> (defcustom org-cite-citation-styles
>   '(("author-year" (biblatex-pkg-args "citestyle=authoryear,bibstyle=authoryear")
>                    (csl-file "/path/to/chicago-author-date.csl"))
>                    ...))
>
> so in a document, you could just write
>
> #+CITATION_STYLE: author-year
>
> or similar.  Is this what you have in mind?
>
> That seems like a good way to provide reasonable defaults using a
> high-level label.  But I think using a high-level label like this will
> underdetermine the actual style to use (on both sides, I assume); and
> the problem is that if we make the labels more fine-grained, there's no
> longer any guarantee that, for a given style label, a suitable style
> file will be available on both LaTeX and non-LaTeX backends.
>
> There obviously needs to be some mechanism so authors can specify their
> citation style quite precisely for the backends they are interested in.
> (Maybe just customizing this variable would do the trick.)  But what
> should the fallback mechanism look like when a particular style does not
> specify the required information for a given export backend?  E.g., if
> CITATION_STYLE is X and we're exporting to HTML, but the entry in
> org-cite-citation-styles does not specify a CSL file for style X?  Would
> it be enough to have a single 'default clause or similar in
> org-cite-citation-styles to use in that kind of case?

I was thinking the author would change CITATION_STYLE to fit the export,
but I like your idea of setting up a universal configuration.

As for a fallback mechanism, I like your idea of a user-configurable
default.

All the best,
Tom

-- 
Thomas S. Dye
http://www.tsdye.com

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Aaron,

Thanks for your comments, and for looking over my code!

Aaron Ecay <aaronecay@gmail.com> writes:

> I’ve been (barely) following this discussion, but have been too busy to
> do any actual coding.  I sat down today to try to integrate Richard’s
> branch with my work, but didn’t get very far.  I think it would be a
> waste of effort to try to support more than one citation processor
> (citeproc-java vs. org-citeproc).

In the long run, I agree, though I still think it might be good in the
short term to see how a few different tools behave.

> I went round and round with myself about this, and concluded that we
> ought to keep on working on the org-citeproc approach for now (drop
> citeproc-java).  

(I take that as a compliment -- thanks!  I'm curious as to what persuaded
you.)

> But I do think someone eventually ought to reimplement org-citeproc
> based on citeproc-js, to yield something that can be distributed via
> npm.  This will be less fool-proof than java, but better than the
> Haskell experience for many users (such as Rasmus and me – far from
> non-technical people!).

That is fine with me, as I think citeproc-js is the canonical
implementation, and probably the best supported.  I am not the person to
do this, though, as I don't really know JavaScript, and personally I
have found it rather frustrating to work with whenever I have had to do
so.

(I am a little puzzled, though, as to why you and Rasmus find the
Haskell experience unpalatable.  On my machine, I installed the Haskell
Platform, and after that, building and installing pandoc,
pandoc-citeproc, and other programs via cabal Just Works.  Has that not
been your experience?  Why would instructions like "First install Node.js,
then do: $ npm install org-citeproc" be better than "First install the
Haskell platform, then do: $ cabal install org-citeproc"?) 

> You mention zotero as a third option – it’s possible, but I think we’d
> be better served by a tool that focuses solely on processing and is
> not so closely tied with database management.

Yes, I agree, at least for those of us who don't use a citation manager.
On the other hand, other people already have Zotero, but would find it
difficult to install and configure a command-line tool and supporting
platform.

If there were a common API so that most of org-cite could operate
independently of external tools, but call out to whichever tool was
installed at critical moments, I think that would be beneficial from a
user's perspective.  (That was part of my motivation for representing
citations to org-citeproc as citeproc-js-compatible JSON.)  I know that
would be more work, but it shouldn't lead to too much duplicated effort
if we are careful to separate the tool-independent code from the
tool-dependent code, and to minimize the latter.  It would also make it
easier to support new and better tools in the future as they become
available.

> There are a couple of other differences in our approaches.
>
> The first is whether the processor generates the in-text citations (you)
> or whether it’s done in elisp (me).  It’s not obvious which is superior.
> The real test will come when more diverse citation types are implemented
> (e.g. full citations in footnotes or numbers which reference a numbered
> bibliography at the end of the document).
>
> The second is whether the processor generates markup in the target
> language directly (you) or whether the processor’s output is converted
> to org markup, then passed through org’s exporters (me).  I think my
> approach here is preferable, since it generalizes to every backend.  Do
> you think something like this could work for org-citeproc?  It would
> probably require some additional special code in ox-odt.  (But we might
> need that in any case, see below.)

Yes, I think that could work, and shouldn't be too hard to achieve, as
Pandoc already has an Org writer.  And I agree it is probably preferable
to go this way.  I realized this when I tested org-citeproc with a CSL
file for a note-based style; things start to get complicated when you
have to parse the output format to look for e.g. a footnote reference
and definition.

> It would be good from an intelligibility/maintainability perspective if
> you could use the json.el library rather than generating json strings by
> hand.  This is part of the emacs core since version 23.something, so
> compatibility should not be a big issue.

Ah, ok, I didn't know about json.el.  Yes, I agree.

> You wrote (mixing replies to various emails in this thread):
>
>> This complicates things enough that probably custom citation modes
>> [in Latex – AE] should be defined as Lisp functions, rather than via
>> format strings...what do you think?
>
> I’d rather avoid it, since I think org->latex is going to be an important
> usecase for many people.  I see us eventually supporting two flavors of
> latex output.  The first should aim to generate a full set of biblatex
> commands but with little user customizability.  The second will rely on
> just 2 citation commands (paren and non-paren), plus some elisp routines
> for combining them into multicites etc.  These two cite commands then can
> be customized by the user.
>
> If people need more flexibility but cannot use biblatex, they can
> always hack up a custom exporter for themselves.  But I think we ought
> to support relatively simple needs with simple configuration settings.

Hmm, OK, interesting.  To me, this actually seems more complicated, but
I guess I am probably not typical.  As a fairly technical user I would
personally prefer the flexibility of just writing a function that is
responsible for taking a citation object and returning an arbitrary
string to insert into the output.  This seems simpler than worrying
about which flavor of latex output I need, and therefore which type of
customization is available.  But I can see how things would be different
for someone who doesn't want to learn enough Elisp to manipulate
citation objects.

>> Or maybe CITATION_STYLE should have "sub"-keywords, like
>> 
>> #+CITATION_STYLE: biblatex:authoryear csl:chicago-author-date.csl
>
> This is equivalent (up to bikeshedding) to separate keywords.  I’d like
> the bikeshed painted with separate keywords, though, because that leaves
> room for passing additional options to biblatex (to be added to the
> \usepackage and/or \printbibliography commands).

I agree.

> I used up all the time I had today to understanding the code and
> surrounding conceptual issues.  However, I will try to integrate your
> changes with my branch sometime in the next few days-week.

Alright, I'll try to move to json.el, and possibly change to having
org-citeproc generate Org markup in the meantime.

Best,
Richard

Re: org-cite and org-citeproc

[Rasmus]

Hi,

Aaron Ecay <aaronecay@gmail.com> writes:

> I went round and round with myself about this, and concluded that we
> ought to keep on working on the org-citeproc approach for now (drop
> citeproc-java).  But I do think someone eventually ought to reimplement
> org-citeproc based on citeproc-js, to yield something that can be
> distributed via npm.  This will be less fool-proof than java, but better
> than the Haskell experience for many users (such as Rasmus and me – far
> from non-technical people!).  You mention zotero as a third option –
> it’s possible, but I think we’d be better served by a tool that focuses
> solely on processing and is not so closely tied with database
> management.

I mostly agree.

IMO a non-binary Haskell solution is a non-starter for an "official"
solution.  A binary version is fine: e.g. I'm more or less happy with
git-annex.

I'd prefer java over node-js, but I'm less hostile towards npm.

Could there be an elisp wrapper around citeproc-js?  Likely, org devs
would have an easier time maintaining such a beast.  

> The first is whether the processor generates the in-text citations (you)
> or whether it’s done in elisp (me).  It’s not obvious which is superior.
> The real test will come when more diverse citation types are implemented
> (e.g. full citations in footnotes or numbers which reference a numbered
> bibliography at the end of the document).

IMO externalization is the top priority.  After that I think elisp is
superior as org-devs presumably would have an easier time maintaining
this.


>> This complicates things enough that probably custom citation modes
>> [in Latex – AE] should be defined as Lisp functions, rather than via
>> format strings...what do you think?
>
> I’d rather avoid it, since I think org->latex is going to be an important
> usecase for many people.  I see us eventually supporting two flavors of
> latex output.  The first should aim to generate a full set of biblatex
> commands but with little user customizability.  The second will rely on
> just 2 citation commands (paren and non-paren), plus some elisp routines
> for combining them into multicites etc.  These two cite commands then can
> be customized by the user.

E.g. Natbib has primitives such as \citeauthor and \citeyear so
arbitrarily complex biblatex citations can always be replicated.



>> Also useful.  This might take a while for me to figure out, as Pandoc
>> does not seem to generate this markup when formatting a
>> bibliography...maybe I'll see if they are willing to work on this
>> upstream.
>
> I think we should not rely on pandoc to fix this for us.  It makes it
> harder to move away from Haskell if (when) we want to.

+1

> I used up all the time I had today to understanding the code and
> surrounding conceptual issues.  However, I will try to integrate your
> changes with my branch sometime in the next few days-week.

Richard: do your FSF papers in order.  Or do you plan to get them in
order?

—Rasmus

-- 
Send from my Emacs

Re: org-cite and org-citeproc

[Andreas Leha]

Hi,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:
> Hi Eric and all,
>
> Eric S Fraga <e.fraga@ucl.ac.uk> writes:
>
>> On Wednesday,  1 Apr 2015 at 08:49, Andreas Leha wrote:
>>
>> [...]
>>
>>> I am a happy biblatex user for all my 'own' documents.  But (as was
>>> mentioned previously) scientific journals that accept latex submissions
>>> will require bibtex and won't support biblatex.  So, I'd say that one of
>>> the other methods (preferably bibtex) is still necessary.
>>
>> Ahhh, yes, I'd forgotten that journals expect bibtex.  This is a key
>> requirement for me as well therefore.
>
> Can someone suggest how a parenthetical citation with common prefix and
> suffix data, like
>
>   [(cite): For more on this topic, see:; @Work1 for a review; @Work2;
>   and references therein.] 
>
> should map to plain BibTeX?  Maybe there is no general answer to this
> question, but what would a reasonable default be?  Maybe this?
>
>   (For more on this topic, see: \cite{Work1} for a review, \cite{Work2},
>   and references therein.)
>
> That is, just place the prefix and suffix data in the surrounding text,
> inserting commas after the part for each individual work, and wrapping
> the whole thing in parentheses?
>

To me that seems a reasonable thing to do.  At least I would write it
probably in such a way.

Depending on the citation style ("author, year") I might add a comma
after the citation, so that it becomes

  (For more on this topic, see: Max Mustermann, 2015, for a review, 
   The Internet Consortium, 2014, and references therein.)

compared to

  (For more on this topic, see: Max Mustermann, 2015 for a review, 
   The Internet Consortium, 2014 and references therein.)

But:
- I am no native English speaker and comma placement in English
  is very unclear to me
- my citation requirements are quite low, I guess...

Best,
Andreas

Re: org-cite and org-citeproc

[Richard Lawrence]

Rasmus <rasmus@gmx.us> writes:

> Richard: do your FSF papers in order.  Or do you plan to get them in
> order?

I haven't done them yet (never had a reason to!) but I have no problems
with it and I'll get started on it.  

Best,
Richard

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Aaron and all,

Richard Lawrence <richard.lawrence@berkeley.edu> writes:

> Alright, I'll try to move to json.el, and possibly change to having
> org-citeproc generate Org markup in the meantime.

Just a heads up: I've pushed some changes to my branch of Org to make
org-cite use json.el, and to add a basic Org format writer to
org-citeproc.

I have not made any other changes to org-cite to use the Org formatted
output from org-citeproc, though, as I believe doing this properly will
involve parsing the output and inserting it into Org's exporter's parse
tree (to accommodate the bibliography and note-based styles).  I won't
have time to work on that this week, but I'll come back to it.

Best,
Richard

Re: org-cite and org-citeproc

[Matt Price]

[-- Attachment #1: Type: text/plain, Size: 3584 bytes --]

On Mon, Apr 6, 2015 at 2:51 PM, Richard Lawrence <
richard.lawrence@berkeley.edu> wrote:

> Hi Aaron and all,
>
> Richard Lawrence <richard.lawrence@berkeley.edu> writes:
>
> > Alright, I'll try to move to json.el, and possibly change to having
> > org-citeproc generate Org markup in the meantime.
>
> Just a heads up: I've pushed some changes to my branch of Org to make
> org-cite use json.el, and to add a basic Org format writer to
> org-citeproc.
>
> I have not made any other changes to org-cite to use the Org formatted
> output from org-citeproc, though, as I believe doing this properly will
> involve parsing the output and inserting it into Org's exporter's parse
> tree (to accommodate the bibliography and note-based styles).  I won't
> have time to work on that this week, but I'll come back to it.
>
> Best,
> Richard
>
> Hi Richard et al,

I'm wondering what kind of work is required to make use of org-cite and
org-citeproc at present. In particular, I'm wondering what kinds of changes
I'll need to make to my current setup, and whether it's worthwhile to use
my ultra-slow coding skills to create whatever glue is still necessary.

Here's my setup at present:

I currently use Zotero for most of my bibliography management; it's
relatively easy to get zotero to export a bibtex bibliography (cf.
https://github.com/robintw/AutoZotBib), and I will switch to bibtex if
absolutely necessary.  I'd rather just keep using Zotero, though.

I use zotxt-emacs to insert references in org files.

I export my work to html and odt.  I use this small bit of code to manage
exports:

;; zotxt
(org-add-link-type "zotero"
                   (lambda (rest)
                     (zotxt-select-key (substring rest 15)))
                   (lambda (path desc format)
                     (if (string-match "^@\\(.*\\)$" desc)
                         (cond ((eq format 'latex)
                                (format "\\cite{%s}" (match-string 1 desc)))
                               ((eq format 'md)
                                desc)
                               ((eq format 'html)
                                (deferred:$
                                  (zotxt-get-item-bibliography-deferred
`(:key , (substring path 15)))
                                  (deferred:nextc it
                                    (lambda (item)
                                      (plist-get item :citation-html)))
                                  (deferred:sync! it)))
                               ((eq format 'odt)
                                (deferred:$
                                  (zotxt-get-item-deferred `(:key ,
(substring path 15)) :248bebf1-46ab-4067-9f93-ec3d2960d0cd)
                                  (deferred:nextc it
                                    (lambda (item)
                                      (plist-get item
:248bebf1-46ab-4067-9f93-ec3d2960d0cd)))
                                  (deferred:sync! it)))
                               (t nil)
                               nil))))

currently this grabs a full html citation and pastes it into the html
export, while for odt it produces strings of the form { | Herzig, 2006 | |
|zotero://select/items/0_SKDIF737}, which Zotero can understand withthe aid
of an RDF/ODF scan plugin.

All of this is fine for my current purposes, but I would like to figure out
a more flexible and enduring solution, so I'd like to try out org-cite and
org-citeproc.  But I'm not quite sure what's required, and whether there's
support currently for odt and html export.

Thanks very much for your help,

Matt

[-- Attachment #2: Type: text/html, Size: 5448 bytes --]

Re: org-cite and org-citeproc

[Richard Lawrence]

Hi Matt,

Matt Price <moptop99@gmail.com> writes:

> I'm wondering what kind of work is required to make use of org-cite and
> org-citeproc at present. In particular, I'm wondering what kinds of changes
> I'll need to make to my current setup, and whether it's worthwhile to use
> my ultra-slow coding skills to create whatever glue is still necessary.

At the moment, org-cite/org-citeproc has no way of talking to Zotero.
So you'd need to manually export citation data from Zotero to a format
that pandoc-citeproc understands, like BibTex.  It sounds like zotxt and
zotxt-emacs provide a lot of what's needed to glue org-cite together
with Zotero; so one thing that would be helpful, if you're up for it, is
hacking org-cite to pull bibliography data from Zotero in a format that
can be passed to org-citeproc.  I don't use Zotero myself, so this is
something I'm unlikely to do anytime soon without some help.  (Borrowing
code from zotxt-emacs and putting it in org-cite is probably the way to
go here, as I doubt that we want to make zotxt-emacs a dependency of
org-cite.)

> All of this is fine for my current purposes, but I would like to figure out
> a more flexible and enduring solution, so I'd like to try out org-cite and
> org-citeproc.  But I'm not quite sure what's required, and whether there's
> support currently for odt and html export.

`Flexible and enduring' does not describe org-citeproc at the moment. :)
I'd be very happy to have you test out org-citeproc and give feedback
that will help improve it, but I can't recommend that you rely on it or
switch to it for serious work any time soon.  It is a working
proof-of-concept, but only that.

Still, there is support in org-cite/org-citeproc for both HTML and ODT
export, and it handles quite a few of the common cases.  So let me know
if you're interested in trying it out.  There are brief installation
instructions in the README (https://github.com/wyleyr/org-citeproc); let
me know if you need more than that.
 
Best,
Richard