Re: Draft JSON specification, round 2

This makes total sense to me. Clearly any program that utilizes CIF data to extract structural information has to be able to decipher the data source, be it CIF, PDB, MMTF, or JSON, and transform the data into its own internal form of data structures. Fundamentally, these formats are no different from each other. They all encode string and numeric data in the form of bits. Well, MMTF is binary, but the others are character-based formats. Numbers aren't really "numbers" - even they are just strings of characters.

OK, that said, what Jmol does is to stream the CIF data into temporary internal Java/JavaScript data formats that can be used efficiently for further processing. It doesn't care about block order (mostly; can't be 100% sure of that in complex CIF subsystem files); it just streams the data in. In addition, though, it can read the entire CIF data structure into an internal "Jmol math" data structure (which is basically a superset of JSON, allowing additional data types such as Point3F, Point4F, and BitSet). This internal structure, though not used by Jmol itself, can be read out using script commands into JSON string format for quick display or for saving to a file or for transmitting to another program or platform.

So one of my interests would be to add a CIF-JSON generator to Jmol so that Jmol could be used to create this data format if desired.

But more importantly, the Jmol/JSmol user can tap into this "local database" of structural information to, say, query the symmetry operators, or check the modulation vector, or look at the unit cell information. This, effectively, is what people call structural annotations. And I suggest this is another use of CIF-JSON not mentioned above. The JSON-based data provide easy access to annotations to a structure that are in an array-based format that is familiar to JavaScript and Java programmers. In Jmol it's not quite JSON, but it is just as good (better?), and its use is Java/JavaScript transparent.

Since Jmol has both CIF1 and CIF2 parsers, Jmol has no need of a JSON equivalent for file reading. A web page using JSmol would never, for example, need to request that COD deliver a CIF-JSON file. However, I or someone with more of an interest in this, could certainly write a CIF-JSON file reader adapter for Jmol. I probably would not do it myself, because "CIF" in Jmol is a lot more than "CIF" for many programs. We have standard small-molecule CIF, macromolecular CIF, incommensurately and commensurately modulated CIF, magnetic CIF, modulated magnetic CIF, and CIF2. These subclasses, of course, are all built on top of a basic CIF parser, but they have a lot of nuances, and those would all have to be processed differently from a CIF-JSON format.

Jmol, by the way, already has a JSON format reader, but it is a simple, rather idiosyncratic format developed specifically for ChemDoodle. As far as I know, it's never used.

So, there are two use cases involving Jmol:

 -- outputting CIF data as some official JSON format (relatively trivial)

Bob