RE: enumeration values
- Subject: RE: enumeration values
- From: "Bollinger, John C" <John.Bollinger@xxxxxxxxxx>
- Date: Mon, 7 Jun 2010 08:59:32 -0500
- Accept-Language: en-US
- acceptlanguage: en-US
- In-Reply-To: <AANLkTiloQRcimB7gC1w5dZjZIqZ1sBtRBBRUIYu48yks@mail.gmail.com>
- References: <AANLkTil-uCJIT-Rg_07zc3FTtY3ln8FMiOvAhcsGWAPq@mail.gmail.com><AANLkTikX0ngj8MfE7vAQ9gfN59oILZGtAgaNS1mLwR9M@mail.gmail.com><8F77913624F7524AACD2A92EAF3BFA54165DF33805@SJMEMXMBS11.stjude.sjcrh.local><AANLkTiloQRcimB7gC1w5dZjZIqZ1sBtRBBRUIYu48yks@mail.gmail.com>
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 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]
- Follow-Ups:
- Re: enumeration values (Richard Gildea)
- References:
- enumeration values (Richard Gildea)
- RE: enumeration values (Bollinger, John C)
- Re: enumeration values (Richard Gildea)
- Prev by Date: Re: enumeration values
- Next by Date: Re: enumeration values
- Prev by thread: Re: enumeration values
- Next by thread: Re: enumeration values
- Index(es):