Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

JSON QCSchema update #366

Open
tovrstra opened this issue Jul 8, 2024 · 1 comment
Open

JSON QCSchema update #366

tovrstra opened this issue Jul 8, 2024 · 1 comment

Comments

@tovrstra
Copy link
Member

tovrstra commented Jul 8, 2024

Our JSON QCSchema implementation is a bit outdated and incomplete, despite significant efforts to get this to work. (I appreciate all the hard work that has been done.)

The two main problems are:

Some points need further discussion before embarking on an update:

  • Are there stability guarantees for QCSchema? How is it versioned?
  • Validation in our current implementation is done through Python conditionals, which is laborious for both development and maintenance. A more systematic validation with the jsonschema package (or something similar) would simplify this aspect.
@PaulWAyers
Copy link
Member

I guess the philosophical issue is whether we should expend effort to support QCSchema, or prioritize it over other json schema associated with quantum chemistry. When I first envisioned including it, I thought it was going to end up being the "universal framework for quantum chemistry calculations" which (I think) was the original intention. But it seems that uptake has been limited; I'm not sure how many packages use QCSchema or QCElemental (which, in my biased view, is basically subsumed by AtomDB anyway). There are a decent number of stars and forks on GitHub, and it is linked into the rest of the MolSSI ecosystem (QCArchive, QCEngine, etc.).

I think that the community has not united around a standard (to my knowledge, though I'm outside the loop here) and perhaps never will given that interconversions become easier and easier nowadays. Philosophically, I tend to believe that it's up to the people who conceive the schema to devise utilities to facillitate their use and interconversion, but that's probably naive (if only because everyone is too busy).

For now, I think I'd welcome any contributions along these lines, and perhaps it is an undergraduate project to implement several of the popular schema at some point. But I feel it's relatively low priority, and can be done at the point that someone using IOData needs to implement it for their own work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants