Readscheme, BibTeX and S-expressions vs JSON Lassi Kortela (22 Feb 2020 11:49 UTC)
|
Re: Readscheme, BibTeX and S-expressions vs JSON
John Cowan
(22 Feb 2020 17:30 UTC)
|
Re: Readscheme, BibTeX and S-expressions vs JSON
Lassi Kortela
(22 Feb 2020 18:02 UTC)
|
Re: Readscheme, BibTeX and S-expressions vs JSON
Alaric Snell-Pym
(23 Feb 2020 12:04 UTC)
|
schemedoc/bibliography (Re: Readscheme, BibTeX and S-expressions vs JSON)
Amirouche Boubekki
(29 Feb 2020 06:35 UTC)
|
Readscheme, BibTeX and S-expressions vs JSON Lassi Kortela 22 Feb 2020 11:49 UTC
I tried converting some citations in the readscheme repo maintained by Amirouche into an S-expression format that stores the same information as the ubiquitous BibTeX format (http://www.bibtex.org). The really nice thing about BibTeX is that Google Scholar has a button that gives you the BibTeX code for any paper in its search results. So you can copy/paste that code, edit it lightly, and then add any missing information from the existing Markdown entries. (Since Google Scholar indexes tons of papers, its entries are often missing some information.) Here's one BibTeX entry given by Google Scholar: @inproceedings{germain2006concurrency, title={Concurrency oriented programming in termite scheme}, author={Germain, Guillaume and Feeley, Marc and Monnier, Stefan}, booktitle={Erlang Workshop}, pages={20}, year={2006}, organization={Citeseer} } As an S-expression it could be: ((type inproceedings) (name germain2006concurrency) (title "Concurrency Oriented Programming in Termite Scheme") (author #(("Germain" "Guillaume") ("Feeley" "Marc") ("Monnier" "Stefan"))) (booktitle "2006 Workshop on Scheme and Functional Programming") ;; (booktitle "Erlang Workshop") (pages 20) (year 2006) ;; September (organization "Citeseer") (pdf "https://raw.githubusercontent.com/scheme-live/library.readscheme.org/master/repository.readscheme.org/ftp/papers/sw2006/09-germain.pdf") (pdf "http://schemeworkshop.org/2006/09-germain.pdf") (pdf "http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.125.1527&rep=rep1&type=pdf")) I made some edits based on Amirouche's readscheme Markdown: - Capitalized the paper's title - it's capitalized in the PDF. - Split the authors into a list. This may be a good or bad idea. BibTeX does not split them as far as I can tell. - The paper has been presented in both the Scheme and Erlang workshops. Google gives the Erlang workshop, whereas Readscheme gives the Scheme workshop. - Added the month of the year as a comment (September). Does BibTex support months? - Added PDF URLs where one can download the paper. This will be very important for usability if we generate web pages and other tools based on this stuff. IMHO it's good to have alternative URLs, as some copies sometimes disappear from the internet. Comments? In particular, since the JSON SRFI (180) is being done right now, and there seems to be widespread agreement that Scheme should represent JSON objects as alists and JSON arrays as vectors by default, it might make sense to use a S-expression syntax that mirrors that. But will such a syntax be intuitive to read and write by humans? In particular, JSON-object-as-alist means we would use the consing dot a whole lot: ((type . "inproceedings") (name . "germain2006concurrency") (title . "Concurrency Oriented Programming in Termite Scheme") (author . #(((last-name . "Germain") (first-names . "Guillaume")) ((last-name . "Feeley") (first-names . "Marc")) ((last-name . "Monnier") (first-names . "Stefan")))) ...) We also can't use symbols as values if we want to be JSON-compatible, since JSON can only do string values. Probably it'd be nice to have some lightweight schema that would let us write some more idiomatic S-expressions: (bibtex (type inproceedings) (name germain2006concurrency) (title "Concurrency Oriented Programming in Termite Scheme") (authors (author (last-name "Germain") (first-names "Guillaume")) (author (last-name "Feeley") (first-names "Marc")) (author (last-name "Monnier") (first-names "Stefan"))) ...) I would prefer to write something like the latter if we can find a way to write some automated translation rules to convert it to the JSON-equivalent thing.