Re: CIF-JSON draft 2017-05-08

On Tuesday, May 09, 2017 5:42 AM, Marcin Wojdyr wrote:
> On 8 May 2017 at 21:47, Bollinger, John C <John.Bollinger@stjude.org> wrote:
>
>> Interpreting that as a backward step depends on asserting some kind of inherent significance to whether an item or category is presented looped.  There isn't any.  The important characteristic is not the *presentation* of the category but its *multiplicity* and key structure.
>
> Well, "_list no" guarantees multiplicity 1. I cannot see another multiplicity control in DDL1/2.

I do not dispute that DDL1 can require one syntactic form vs. the other.  I am saying that the syntactic distinction has no bona fide semantic significance.  The underlying point of DDL1's "_list no" option is to specify that the item with that attribute shall take at most one value in any given data block.  Requiring that it not be looped is the mechanism, not the objective.  We don't need that in CIF-JSON (nor is it needed more generally in CIF), because we have the option of simply limiting ourselves to presenting at most one value for the item, or even of lifting the restriction altogether.

> But if DDL2 was designed to be like RDMB schema then unlimited number of entries in block indeed fits this design.
>
> Regarding "loop tags": the original motivation was to keep track which columns are in the same loop, so that JSON can be converted back to valid CIF without knowing the context. Both:
>
> loop_ _x _y 1 2 3 4
>
> and:
>
> loop_ _x 1 3
> loop_ _y 2 4
>
> will have the same JSON representation, but a dictionary may allow only one of the two.

I am not at all concerned with full-fidelity round-tripping of CIF data from its native serialization format through CIF-JSON and back.  Nor am I particularly concerned with conveying the "in the same loop" property via CIF-JSON, though I do not object to providing "loop tags" for the purpose. The primary reason to require items to be presented in the same loop is to ensure that within the group of items presented in that loop, each value of each item can be associated with a corresponding value of each of the other items.  There are additional reasons related to convenience of processing and maybe of human reading, but we've already thrown those out by providing looped items' values in separate JSON arrays instead of in a single array of packets.

If one wanted to perform validation of CIF data presented in CIF-JSON format then one would have to reconstitute the data into logical loops anyway.  Though one could use the "loop tags" for that purpose, I see little advantage to that relative to going by items' categories as defined in their dictionary (and we are already assuming a dictionary if we propose to validate).  If one does not care to validate, on the other hand, then it makes no difference whether associated items are presented in the same loop or in different ones, as long as we can make the needed associations between corresponding item values.  CIF-JSON provides only one way to do that (by matching index in items' value arrays), and it depends on the loop tags only for discovering associations about which we have no foreknowledge.  I anticipate that many applications of CIF-JSON will not need that, and those that do might be better off with COD-JSON.

If we really wanted to convey the original loop structure then we would be better off with a JSON structure that reflected it directly.  I don't see a need for that, and if we indeed reject that idea, as our current draft does, then let's agree that it's because conveying the loop structure is not always essential.


John


________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer

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