Discussion List Archives

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

RE: enumeration values

Dear Richard,

 

You are right that it is possible to construct a DDL2 definition that suffers from the same problem.  In fact, the mmCIF versions of the items we have been discussing are direct translations of their CIF Core equivalents, so you wouldn’t realize any advantage by translating to mmCIF data names (which I never intended to suggest as a solution). My point was that the current official DDL2 dictionaries, especially the mmCIF dictionary, were constructed more carefully and intentionally than the (DDL1) CIF Core dictionary originally was, even though the mmCIF dictionary has inherited some of the Core dictionary’s problems through implementation of Core-compatibility definitions.  In retrospect, my previous comments about DDL1 vs. DDL2 were a bit of a red herring, for which I now apologize.

 

I am not a member of COMCIFS, and I do not represent IUCr, so I cannot speak with any authority about to the likelihood of COMCIFS accepting DDL additions and dictionary changes such as you suggest.  As a totally non-authoritative guess, however, I think the chances are slim, especially because COMCIFS has already implemented a different solution (deprecating _atom_site_refinement_flags in favor of the trio of data names we already discussed).  The chosen solution did not change the validity of any CIFs that use the deprecated name, but I believe that was by design.  Nevertheless, If you are intent on petitioning for additional changes then do not let me dissuade you.

 

At this (late) point, I am compelled to ask what problem you actually want solved.  If it is simply to process existing CIFs without validation errors / warnings, then I have already made two suggestions.  Of those, easiest is probably to add the flag combinations to your local copy of the Core dictionary.  If the problem is to ensure that CIFs you distribute are valid with respect to the official dictionaries, then the only currently available option is to translate your CIFs to replace the deprecated name with the replacement trio.  If the problem is philosophical dissatisfaction with the facts that the dictionary is internally inconsistent and that there are therefore many formally invalid CIFs in circulation, then your only option is to ask COMCIFS for changes such as you have described, or for additions to the enumeration of allowed values for _atom_site_refinement_flags (such as I have described).  Because you raised the issue on this list, I inferred that your problem was one of the first two.  If it is in fact the third, then you will need to address it to COMCIFS to have any hope of resolution.

 

 

Best Regards,

John

--

John C. Bollinger, Ph.D.

Department of Structural Biology

St. Jude Children's Research Hospital

 

 

 

From: cif-developers-bounces@iucr.org [mailto:cif-developers-bounces@iucr.org] On Behalf Of Richard Gildea
Sent: Monday, June 07, 2010 6:16 AM
To: cif-developers@iucr.org
Subject: Re: enumeration values. .

 

Dear John,

 

I'm not sure that the problem is restricted only to DDL1 dictionaries, it looks like the same problem would exist with a DDL2 dictionary also.

 

It seems to me that this could be resolved relatively simply by the addition of an extra item added to the DDL to indicate whether the given enumeration choices can be combined in *any order*.  Obviously for this to be the case it should only apply to one character codes.  It should be easy for a validator to then loop through every character in the value to be validated, and check that each character is a valid choice.  It should also check that each code is used only once.

 

Such a DDL item could be something such as _enumeration_combine or _enumeration_permute (or DDL2 equivalent), which itself has permitted values of 'yes' and 'no' (the default).  Adding an extra item like this shouldn't break, or change the behaviour of, older validators, whilst allowing up to date validators to validate these concatenated values correctly.

 

I think you are probably correct regarding the case sensitivity issue - it would probably be best to (or at least have an option to) treat case sensitive mismatches as warnings instead of errors.

 

Thanks,

 

Richard


Email Disclaimer: www.stjude.org/emaildisclaimer
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/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.