Discussion List Archives

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Draft JSON specification, round 2



On Fri, Apr 21, 2017 at 8:43 AM, Andrius Merkys <andrius.merkys@gmail.com> wrote:

We have devised our COD-JSON format for three reasons: (i) to pass
parsed CIF data to scripts in programming languages that do not have CIF
parsers, (ii) to avoid multiple CIF parsing in pipelines (JSON parsing
is somewhat faster than CIF) and (iii) to experiment with CIF data in
document-oriented databases. Applications (i) and (ii) benefit from the
syntactic approach, especially if they output CIF (we would like to have
it as similar to the original as possible). For application (iii)
semantic approach should be sufficient.


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)
 -- easy access to crystallographic structural annotations

Bob

--
Robert M. Hanson
Larson-Anderson Professor of Chemistry
St. Olaf College
Northfield, MN
http://www.stolaf.edu/people/hansonr


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Council for Science (admitted 1947). Member of CODATA, the ICSU Committee on Data. Member of ICSTI, the International Council for Scientific and Technical Information. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

ICSU Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.