Discussion List Archives

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

Re: CIF-JSON draft 2017-05-08



On Mon, May 8, 2017 at 1:13 PM, Bollinger, John C <John.Bollinger@stjude.org> wrote:


On Monday, May 08, 2017 11:46 AM, Robert Hanson wrote:

> 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?

There are two overlapping issues here.  I sent an example of the first to the group on May 4th, showing how the same CIF-JSON could be interpreted in two different ways.  That depends on the fact that as (still) specified, JSON arrays are used both as containers for the multiple values that a looped item takes, and also directly to represent individual values that are CIF2 lists.  That can be disambiguated under the latest draft by referring to the relevant "loop tags" to determine whether a given item is presented as part of a loop.  Of course, that disambiguation depends on the values items so identified being presented in an array, even when there is only one loop packet, and on List values that do not belong to a looped item being presented directly.  James remarked that it could also be disambiguated by the program having prior knowledge of the expected data type for a given item.  I won't repeat the whole message, but here's the ambiguous JSON:

{
  "block": {
    "_xyz": [ 0.1, 0.2, 0.3 ]
  }
}


I don't think you can have a CIF loop for a subkey. Can you? How would you represent that as a CIF loop?

As you say, the current CIF-JSON allows both of these:
"_chem_comp_atom.model_Cartn_x" : "0.000"
"_chem_comp_atom.model_Cartn_x":["-23.107","-22.157","-23.424"]

Moreover, it *also* allows this:
"_chem_comp_atom.model_Cartn_x" : ["0.000"]


You mean, specifically:

"_chem_comp_atom.model_Cartn_x" : ["0.000"]
"_chem_comp_atom.model_Cartn_y":["-23.107"]
"_chem_comp_atom.model_Cartn_z":["-23.107"]
...

as opposed to


"_chem_comp_atom.model_Cartn_x" : "0.000"
"_chem_comp_atom.model_Cartn_y": "-23.107"
"_chem_comp_atom.model_Cartn_z": "-23.107"
...

in

Yes, that's exactly what I'm suggesting.  No option for an item's values being presented outside an array.  That solves both problems: we have only one representation for item values (contained in an array), and therefore don't have to perform an array test, AND there is no longer any ambiguity about whether the outermost array is a container for values, or the value itself.

 
And you seem indeed to have gotten it, as your magCIF example is on target.  It seems clear that this:

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

is intended to be represented like so:

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

but consider this alternative CIF:

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

Since it is semantically equivalent to the preceding one, it should be acceptable to transform it to the same CIF-JSON representation.  But suppose we instead we translate it to this:

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

... then we have just the kind of ambiguity I've been going on about.  I am proposing that we allow only the first form.

I like John's elegant proposal. All items as arrays, single or not. It's very clever. Clears up the loop names issue, results in very efficient processing.

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.