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 James,

  The most extensive example of adding keys has been the entire variant category and all the tags that point to it.    This allows for multiple versions of the same row in a wide range of categories.  It is very
much like alternate conformers.  You are absolutely right that this would cause unusual behavior in software that expects just one such row.  If the software is dictionary driven and working from a dictionary
prior to the introduction of variants, then the "right" thing for it to do is to declare and error, which should tip off the user that it is time for a dictionary update, or, perhaps a manual cleanup of the file to pick the desired variant.  If the application is not dictionary-driven, then it probably will accidentally pick up the first variant it finds and never be aware that this was a problem.

  If the data file declares the dictionary to which it is supposed to conform, this should be a minimal problem.  If we are going to work with data files that make no such declaration, and somebody provides a file that conforms to the latest dictionary to an application that expects files conforming to an older dictionary but does not bother to check for conformance, we might see strange behavior, but isn't this more of an argument for both applications and files to clearly identify the dictionaries they expect, rather than an argument to freeze further dictionary development. 

  I would suggest that the tests to apply are:

  1.  Given a new dictionary, will every file that conformed to the old dictionary be treated as conforming to the new dictionary by applications designed to conform to the new dictionary?
  2.  Given a new file conforming to a new dictionary, but not to an old one, but which explicitly declares the dictionary version to which it conforms, will any dictionary-aware application written for the old dictionary and unable to handle the features of the new one provide reasonable and clear indications of the issue?

  Regards,
    Herbert
  

On Mon, Jun 6, 2016 at 7:37 PM, James Hester <jamesrhester@gmail.com> wrote:
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.

https://cifmusings.wordpress.com/2016/06/03/understanding-single-valued-cif-datanames/
https://cifmusings.wordpress.com/2016/06/06/can-we-safely-loop-an-unlooped-category/

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,
James.

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.

  Regards,
    Herbert

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group




--
T +61 (02) 9717 9907
F +61 (02) 9717 3145
M +61 (04) 0249 4148

_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group


_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group

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.

Useful links