Re: exporting zotxt or orgref links to HTML and ODF

[Matt Price <moptop99@gmail.com>]

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

I am very eager to see this work of yours, Christian.  I also would very
much like to find a way to have a single, well-supported citation framework
in org -- I certainly think John's work looks incredible, and zotxt is very
powerful, but it would be fantastic if one could just choose a
bibliographic backend and export seamlessly to any supported format.  It
would be a big step forward.  I guess I don't quite see, yet, what has to
happen for the work of various contributors to be consolidated; clearly
Erik, You, and John have worked in overlapping and distinct directions, but
I would be veyr enthusiastic about helping a unified approach emerge,
espeically one that supported Zotero.

Thanks everyone,
Matt

On Tue, Jan 27, 2015 at 3:01 PM, Christian Moe <mail@christianmoe.com>
wrote:

>
> Richard Lawrence writes:
>
> > It looks to me like Pandoc has a quite general solution, and it also
> > looks like Org could use Pandoc's citation syntax as-is.  I would
> > suggest borrowing this syntax as a starting point for building citation
> > support into Org.
>
> It's been years since I looked at Pandoc, and I think they've added some
> functionality since then. Prefix, locator, suffix, and multiple
> references in one human-readable citation: Great! And /much/ nicer to
> look at than latex \cite commands with their frankly bizarre placement
> of locators etc.
>
> > Blah blah [see @doe99, pp. 33-35; also @smith04, ch. 1].
>
> In my current homebrewn solution for Zotero, I have tried to do
> something similarly readable using Org link syntax (sorry, Rasmus!) with
> the database entry ID as link target, and parsing the description part
> for prefix/author-date/locator/suffix, but with a slightly different
> syntax than Pandoc uses. In my solution the above would be:
>
> Blah blah [[zotero:0_A43F89;0_E25CB3][(see: Doe 1999: p.33-35; also:
> Smith 2004: ch. 1)]].
>
> > A minus sign (-) before the @ will suppress mention of the author in the
> > citation. This can be useful when the author is already mentioned in the
> > text:
> >
> > Smith says blah [-@smith04].
>
> In my current Zotero solution:
>
> Smith says blah [[zotero:0_E25CB3][(2004)]].
>
> > Does anyone have citation needs that this syntax doesn't cover?
>
> It's great, as long as your database uses mnemonic citekeys like
> doe99. Zotero doesn't, but uses keys that are meaningless to humans,
> like 0_A43F89.  Unfortunately [see @0_A43F89, p. 5] wouldn't look nearly
> as nice as [see @doe99, p.5], and it wouldn't help you remember what you
> referenced.
>
> I think the typical workflow combining Zotero with Pandoc is to export a
> BibTex file from Zotero and reference the BibTex citekeys from
> there. I could live with that much of the time.
>
> But that workflow doesn't help with something I often want to do, which
> is to export to ODT and have 'live' Zotero citations that I can continue
> to work with in LibreOffice.
>
> > Using this syntax would also have the advantage that Pandoc can already
> > parse it, which would reduce friction for Org users who convert their
> > documents with Pandoc (and Pandoc users who need to deal with Org
> > inputs).  Since this seems like a significant contingent of Org users,
> > that's something to consider.
>
> That's a good point. OTOH, don't Org users convert their documents with
> Pandoc mostly because cross-backend citation support is lacking?
>
> > The bigger question is whether, in addition to a citation *syntax*, it
> > would be a lot of work to add support for the various citation database
> > formats, as well as the various output styles, and which ones to
> > support.
>
> Possibly more work if it's worth if we adopt Pandoc syntax,
> since Pandoc-citeproc seems to handle nearly everything that is based on
> plain text.
>
> To truly support citations natively, we'd essentially have to implement
> something like citeproc in elisp. Not that I haven't been thinking about
> that...
>
> Yours,
> Christian
>
>
>
>
>
>
>

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