proper citeproc-js -> coins/mail-attachment export

[bibliocoll]

we have data from crossref in citeproc-json, there is a stub/demo environment for running citeproc-js client side, but it lacks useful features.

i would like to have a basket view / checkout action that allows exporting to zotero/mendeley/onenote, et al. via some well-supported mechanism (coins?), and the option to mail citation data in a format of choice to the user.

the bad thing here is that citeproc-js currently runs client side while the mailer runs server side. this whole thing with piping client-provided data through phpmailer seems like asking for pwnage.

[krugar]

consider switching to citeproc-php

[krugar]

kicking this can down the road to 0.4 because i want to have a proper data model before i start this

[krugar]

this means that bibtex export will not be in 0.3. disabling that option in checkout.php for release

[zuphilip]

I am interested to understand what your goal is here. You have imported CSL JSON and want to export it into some other format to do what? Is this connected to a reference management system?

[krugar]

The feature goal is to provide (kiosk) users with a way to get article citation data from a JournalTouch basket into their citation management software of choice.

I don't want the JT server to blindly trust data it gets from a client, especially if that data is to be sent to a client-supplied email adress in the name of the JT server.

We could do the first part with transforming the data with citeproc-js on the client side and handing it back to the server, but that breaks the second requirement.

My goal for this feature is for the server to query a preconfigured resource (e.g. crossref), transform the data it gets into the format the user has chosen from a server-supplied list and then hand it out via mail or whatever other mechanism makes sense in the setting (display on the page, download as a file, etc.). this means transforming on the server side, and since we are using php there, citeproc-php seems to be a good fit.

[zuphilip]

Okay, I see a little clearer. I would like to add some ideas and comments:

• a.) The metadata formats COinS, BibTeX, RIS all have some problems, when used as an exchanged format and they may miss some cases and/or be interpreted differently because they are not well standardized. The richest format you actually already have is CSL JSON. Moreover, Zotero can import already from CSL JSON and actually also Mendeley uses internally a csl-processor for outputing the citations.
• b.) There are some implementations you could consider for the transformation between different formats. I am thinking here especially about Zotero itself. There is a server version (only the translator part) and it might also be possible to just use the translators itself (AFAIK ProQuest is doing that). There export options are currently: BibLaTeX, Bibliontology RDF, BibTeX, COINS, CSL JSON, CSV, Endnote XML, MODS, RIS, Simple Evernote Export, TEI, Unqualified Dublin Core RDF, Zotero RDF.
• c.) I think that the citeproc-php is quite old and maybe deprecated (last commit from June 2013). AFAIK, citeproc-js is very well maintained (mainly by Frank) and widely used. It should be possible to rund this also in node.js on server side. However, I am not sure how citeproc will help you anyway, because its goal is to create formatted bibliographies and not to export into another format.

[krugar]

sadly, zotero seems to be not very good at importing citeproc-json data, even tho it uses that format (and the citeproc-js component itself) internally. maybe i just haven't looked hard enough, but otoh, if i've got problems there, someone else might as well.

this is why i wanted to include something to convert the data we get from the, as you stated, most complete format into something that can be easily imported into whatever program someone is using (if that program can handle citeproc-json, all the better). i agree that citeproc may be overkill for that, but there is a CSL stylesheet for BibTex, so (mis)using citeproc for conversion between metadata formats is mostly plug & play, with the ability to output journal-specific citation strings as an added benefit.

tbh, i've considered moving this whole project to node.js and ember-cli and never look back at that stinking pile of whatever php is supposed to be (and then complain in the same tone about js), but we want this project to be easily accessible by our target audience, and that means: librarians. the chance that you will find one that is also a reformed hipster brogrammer cult dropout from 2013 that is able to get something running on node.js is rather slim ;) the same is probably true for middle aged IT departments, where you can ask for a LAMP stack and maybe get something, but a request for a MEAN stack might just get you mean looks instead. i guess we should all be happy that we're not running on perl scripts in an IIS cgi-bin folder or something like that :smile_cat:

for the reasons i tried to convey in the rant paragraph above, we're trying to keep this project on a minimal installation footprint, e.g.: i have a longing for something to store stuff in that isn't the filesystem, but as long as we can wing it without, i'm going to keep this optional if i add it. cf #44

[zuphilip]

If you experience problems with CSL JSON import in Zotero you can report that and they should be handled. It looks that this data format is very close to the internal format of zotero itself and the mapping here looks quite simple. Moreover, there is also a CrossRef translator which imports the metadata without CSL JSON data.

However, maybe that is not the direction you want to go. I haven't thought about the client/server-side issues you mentioned and I can't speak for other librarians or IT departements.

[krugar]

i've reason to assume i will have to accomodate marc21 records in this project at some point down the road, so my current working hypothesis for a data model is something that is a superset of both the marc, mab and citeproc formats and is able to output itself in each of those (and the minimal format required for most of what we do here). this will seem like overkill for this project and i'll try to make it modular to some extent, but it should pay off in the long run. i've got to focus on a different project for the next 2-3 weeks, so there will be no code popping up for this for a while.

[krugar]

once more kicking this can down the road :S