John:
> Basically LGTM except for one thing:  IMAO you should *not* attempt to
> parse or otherwise mess with names.  Worldwide, names are far too
> complex and variable to put in a lastname-firstname(s) straitjacket.
> See my rant "Against Structured Names and Telephone Numbers"
> <https://docs.google.com/document/d/1Of_rL8gMtHcfPaE5DfZ1xahrOtOaxFEHiQkcxvvR3lY>
> and the links at the bottom of the names section.

Excellent and thorough rant. Let's keep each name as one unit then. We
don't need to worry about sorting for this application, since each
paper's authors/publishers decide the order of the names.

The BibTex from Google Scholar has had "Lastname, Firstname" for
ordinary Western-style names in all cases I have encountered. I don't
know what they do with languages where the surname comes first. Maybe
the BibTex user community has standard rules for it.

AFAICT BibTeX is supposed to be independent of citation styles, but I
don't know how fully that vision is realized.

> I don't see any need to be JSON-compatible.  The internal JSON
> representation is for ease of internal use, and the current conventions
> make it trivial to serialize as an S-expression in almost any Lisp.
> JSON-compatible data structures should be serialized as JSON.

OK, let's go with a custom S-expression syntax that's easy to write by
hand and permits a simple conversion rule to the JSON-equivalent data model.

Amirouche:
> For what it is worth, I was considering LOSE format.

Interesting idea. Would it be something like this?

(type inproceedings)
(name germain2006concurrency)
(title "Concurrency Oriented Programming in Termite Scheme")
(author "Germain, Guillaume")
(author "Feeley, Marc")
(author "Monnier, Stefan")
(booktitle "2006 Workshop on Scheme and Functional Programming")
(pages 20)
(year 2006)

Should LOSE be standardized somewhere? The closest thing to a spec right
now is
<https://srfi.schemers.org/srfi-176/srfi-176.html#_line_oriented_s_expressions_lose>.

For <https://github.com/lispunion/lila> (still coming soon) I need to
define a completely portable S-expressions subset that doesn't need to
be line-oriented. LOSE should have the same concepts, but with the added
constraint of expressions fitting on a single line. It's mostly just a
difference in what whitespace is permitted between tokens.