Discussion List Archives

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

Re: CIF-JSON draft 2017-05-08

I am in total agreement with John's two points:

On Mon, May 8, 2017 at 9:23 AM, Bollinger, John C <John.Bollinger@stjude.org> wrote:
 

From my perspective, the paramount issues are

 

1. to make CIF-JSON simple to both encode and decode (where "simple" implies lowest knowledge, not necessarily lowest effort)

2. to ensure that a CIF-JSON instance carries all the semantic information of the corresponding CIF


I am happy with anything that accomplishes this unambiguously and with reasonable economy.

John, I'm still not clear what you mean by this:
 

It is in service to both points that I raised the issue of the ambiguity between CIF lists as values on one hand and multiple values in a loop on the other. 

I am satisfied to have loop tags be required so as to enable that to be disambiguated, but the more I think about it, the more convinced I become that the best solution would be to present every item’s values, whether one or many, in a JSON array. 


Could you give an example? I'm guessing that it might have to do with this issue, which definitely threw me for a loop (pun intended) when I had to recraft my CIF decoder upon finding that the RCSB CIF ligand encoding for Ca2+ is:

_chem_comp_atom.comp_id                    CA 
_chem_comp_atom.atom_id                    CA 
_chem_comp_atom.alt_atom_id                CA 
_chem_comp_atom.type_symbol                CA 
_chem_comp_atom.charge                     2 
_chem_comp_atom.pdbx_align                 0 
_chem_comp_atom.pdbx_aromatic_flag         N 
_chem_comp_atom.pdbx_leaving_atom_flag     N 
_chem_comp_atom.pdbx_stereo_config         N 
_chem_comp_atom.model_Cartn_x              0.000 
...

Jmol had always expected these as a loop. But here is a one-atom system, so no loop. I found it 5 years after I wrote the CIF parser. So it required substantial reworking to get this right. With the JSON format, we must always be prepared to have

"_chem_comp_atom.model_Cartn_x" : "0.000" 

in one case and

"_chem_comp_atom.model_Cartn_x":["-23.107","-22.157","-23.424"]
in others. Right?

John, are you suggesting that perhaps every JSON entry should be an array so that no array test has to be made? So, for example,

_chem_comp.id                                    HOH 
_chem_comp.name WATER
_chem_comp.type NON-POLYMER
_chem_comp.pdbx_type HETAS
_chem_comp.formula "H2 O"

would become:
"_chem_comp.id":["HOH"],
"_chem_comp.name":["WATER"],
"_chem_comp.type":["NON-POLYMER"],
"_chem_comp.pdbx_type":["HETAS"],
"_chem_comp.formula":["H2 O"],
equivalence in CIF between scalars and items in single-packet loops.  If that were accepted then "loop tags" could remain optional, and perhaps the constraints on it could even be loosened relative to the original proposal.

 

I am inclined to agree with Marcin, however, that the second null representation in the present proposal constitutes an ugly wart (and I acknowledge my contribution to the present state of the proposal in that area). 


I don't care at all about this, as long as CIF . and ? are distinguished from CIF "." and "?".

(3) Made loop tags compulsory

You lost me on this one. What's an example of what we are after here? Is it as in this example, from a magnetic CIF file:

loop_
  _parent_propagation_vector.id
  _parent_propagation_vector.kxkykz
  k1 [-0.75 0.75 -0.75]

becoming:

  "_parent_propagation_vector.id": ["k1"]
  "_parent_propagation_vector.kxkykz": [[-0.75 0.75 -0.75]]

or equivalently:

  "_parent_propagation_vector.id": "k1"
  "_parent_propagation_vector.kxkykz": [-0.75 0.75 -0.75]

?

Thus, if we happened upon the kxkykz entry first, we might presume we had a loop in the second case. We would have to know the context -- that kxkykz is always an array. But how/why would we know that context? And in some imaginable case, we might have:

  "_parent_propagation_vector.kxkykz": [-0.75 0.75 -0.75]
  "_parent_propagation_vector.gxgygz": [-0.75 0.75 -0.75]

In which case without any context, we would decode these as loops.

?

Bob

_______________________________________________
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.