There is JavaScript/TypeScript in the web client code, C++ in AvogadroLibs, and wrapped C++ from AvogadroLibs capable of going from checkpoint files to Chemical JSON. I think it is fair to say it is essential for the inner workings of the platform, but the intent is to offer that in addition to other formats for import/export of data. The Chemical JSON GitHub repository (https://github.com/openchemistry/chemicaljson) is mentioned when discussing examples.
There is nothing formal, there is a repository referenced in the paper. It is a working format developed to support several projects that can move quite quickly. The authors (Hanwell and de Jong) helped organize an initial workshop, and started discussions with MolSSI shortly after MolSSI was founded to spur standardization.
It is already in a number of codebases, ultimately it could be merged but in efforts to standardize it became clear that the velocity of QCSchema was too slow to accommodate projects with a shorter timeframe for development. The primary effort is to ensure QCSchema/similar support everything in Chemical JSON. We have added text to make this approach clearer - thank you for the questions. Please see the final paragraph of "Handling Data and Metadata" for some further detail elicited from this line of questioning.
Absolutely, as discussed in the early part of "Handing Data and Metadata", and a concluding remark in the new paragraph making it clear our belief is that binary formats are essential for large calculations. JSON offers valuable room to explore the space before mapping to binary formats that share similar structures such as MessagePack or the more traditional HDF5.
These are not addressed at this stage, they would of course be useful additions to support in the platform without doubt. For QM/MM one of the format extensions will be to label atoms as quantum or classical, and force field description. Some of these are currently being looked at in the QCSchema.
Not at this time.
This is the biggest gap right now, we have guides for local single machine developer deployments, AWS deployments with cloud clusters, and a SPIN-based deployment using NERSC at LBNL. This should be possible, but the team has not explored it focusing primarily on local development and the NERSC/AWS deployments. As with many things, this could certainly be accomplished given further development time.
MolSSI and QCArchive arrived after we began working on this project, and there are some distinct differences. During early discussions it was clear that we focused on individual calculations, and retain more data so that electronic structure can be visualized for example. We also enable search based on name, InChI, SMILES etc which is (or at least was) difficult in QCArchive. They focus on large parameter sweeps, and generating inputs for machine learning/MD potentials.
Good point, added some description to the introduction in the final paragraph.
Thank you, we agree on their importance, and the section on "Containers for Chemistry Codes" discusses the various containers, and why more than one kind is needed at this time. I added two paragraph to highlight some of these points at the end of the introduction section, and thank you for your suggestions and highlighting these points. We wholeheartedly agree.