Discussion List Archives

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

Re: [ddlm-group] Proposal to enhance the behaviour of a DDLm "Set"category: please consider

Dear Herbert and others,

Here are two blog posts. The first analyses in mind-numbing detail the concept of a 'Set' dataname, and the second looks at two ways we might lift the 'single-value' restriction.


I am currently working up a second proposal and pondering it from different angles before sending it out.

If imgCIF 'adds keys to categories' that could easily cause issues for software. For example, if you decide that a child key of 'scan.id' should be added to all categories that previously used only 'frame_id' as the key, any software that relies on a unique frame name to find a row will fail.  It wants 'frame 1' but there may be 10 'frame 1's.  I surmise that the only reason no problems have been encountered is that the intersection of files that include the new keys, and legacy imgCIF software that doesn't expect the keys, is exceedingly rare. If Herbert perhaps give an example of a key addition that occurred in the past that would help to confirm or refute this supposition.

all the best,

On 6 June 2016 at 20:27, Herbert J. Bernstein <yayahjb@gmail.com> wrote:

  James has said:  "While this would work prospectively, it still doesn't fix the problem of old software that doesn't know about the new child keys. Adding new keys to a category unequivocally changes the meaning of all of the non-key datanames in that category, and old software will operate using the old meanings.  If this is a point of disagreement, I will write a blog post about it as I will need to use some pictures to explain why I think this."

  One major difference between imgCIF and mmCIF is the reliance in making use of "implicit" item.mandatory_code for the values of otherwise missing keys, so we are able to deal with the issue of categories with different key structures from mmCIF without having to define different categories.  In the intervening years since the creation of imgCIF, "implicit" seems to have dropped out of sight for other dictionaries, but it is heavily used in imgCIF because we are always dealing with information that will eventually have to end up in a database (the PDB), but at a stage for which the values to use for some keys are not yet known, or which may have to change.

  So in imgCIF we add keys to categories and, in addition, we fail to give explicit values to some mmCIF keys, and, as far as I am aware, this has not caused issues for existing software, nor does it seem to have changed the meaning of the non-key datanames yet, so I very much would appreciate James' offered blog post.  It would be very helpful in a dREL conversion of imgCIF.


ddlm-group mailing list

T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148
ddlm-group mailing list

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

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

International Science Council 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.