[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
- Subject: Re: _item_related.function_code
- From: David Brown <idbrown@xxxxxxxxxxx>
- Date: Mon, 14 Jun 2010 14:35:22 -0400
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54165DF33819@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTimGcuFIw1s8V-PPW5hrjOvxGPvPIIrxnOHnrEKp@mail.gmail.com><8F77913624F7524AACD2A92EAF3BFA54165DF33819@SJMEMXMBS11.stjude.sjcrh.local>
For the record, the defintions in DDL1 are not very helpful.|
In the case of the refinement flags, the original item (_*_refinement_flags) has a definition that lists _*_flags_adp etc as related_items with the related_function 'replace'. 'replace' is defined in the DDL1 dictionary as
'new definition replaces the current one'
with a further explanation in the text that "'replace' signals that the item referred to in _related_item may be used identically to replace the defined item." Thus it appears that the original intention is not that one item replaces (or is replaced by) the other, but the two are on an equal footing. The sense that one item is deprecated does not seem to be present. However, the value seems to be correctly used in that _*_refinement_flags_adp etc. replace _*_refinement_flags, which is the item being defined. However, I interpreted the first definition as having the opposite meaning so there is some ambiguity.
The items _*_refinement_flag_adp etc. in core CIF have the _related_function value 'alternate' which is defined in DDL1 as
'used alternatively for validation tests'
which is not very helpful and seems to duplicate the value 'replace'. Why should something be allowed to pass a validation test if it does not function indentically to 'replace'?
I cannot see that DDL1 has the ability to give the sense of one item being replaced by another (rather than both being equally acceptable). Given the rather loose structure of DDL1 it probably is not worth attempting a correction in coreCIF dictionaries (though some clarification in DDL1 would be useful).
Bollinger, John C wrote:
Dear Richard, I read DDL2 and the mmCIF dictionary the same way you do. In the scope of the definition of _atom_site.refinement_flags, the defined item is _atom_site.refinement_flags, so the dictionary fragment you presented says that _atom_site.refinement_flags replaces each of _atom_site.refinement_flags_adp, _atom_site.refinement_flags_occupancy, and _atom_site.refinement_flags_posn, which is inconsistent with the definitions of the corresponding Core dictionary items. One cannot simply argue that we are reading DDL2 wrongly, for the current mmCIF dictionary uses the related item feature inconsistently. Items _diffrn_reflns_class.av_sgI/I and _reflns_shell.meanI_over_sigI_gt use the 'replaces' code in the same sense that _atom_site.refinement_flags does, but items _database_2.database_id and _database_2.database_code use it in the opposite sense (consistent with the DDL2 bit you cited). There are no uses of "replacedby" and no other uses of "replaces" in the current mmCIF dictionar y . One group of definitions or the other must be erroneous. Inasmuch as mmCIF attempts to be consistent with the Core dictionary, I think it is safe to assume that it is the definitions of _atom_site.refinement_flags, _diffrn_reflns_class.av_sgI/I, and _reflns_shell.meanI_over_sigI_gt that are wrong. The corresponding DDL1 feature for related items uses code 'replace' for what DDL2 calls 'replacedby': "'replace' signals that the item referred to in _related_item may be used identically to replace the defined item." All of the erroneous mmCIF definitions are drawn from the Core, so perhaps the errors arise from faulty machine translation of the Core dictionary ('replace' --> 'replaces' instead of 'replace' --> 'replacedby'). I'm not sure who is responsible for mmCIF dictionary maintenance, but there are others listening to this list who do. That's where this needs to go. Best Regards, John -- John C. Bollinger, Ph.D. Department of Structural Biology St. Jude Children's Research Hospital On Monday, June 14, 2010 7:07 AM, Richard Gildea wrote:I have query regarding the _item_related.function_code definitions and their use in item definitions. The descriptions for the 'replaces' and 'replacedby' value for _item_related.function_code are: "REPLACES indicates that the defined item replaces the item identified in _item_related.related_name." and "REPLACEDBY indicates that the defined item is replaced by the item identified in _item_related.related_name.">From the _atom_site.refinement_flags definition in cif_mm.dic these items are defined as follows:loop_ _item_related.related_name _item_related.function_code '_atom_site.refinement_flags_posn' replaces '_atom_site.refinement_flags_adp' replaces '_atom_site.refinement_flags_occupancy' replaces>From the above definitions, I would take this to mean that _atom_site.refinement_flags ("the defined item") replaces the three items *_posn, *_adp, *_occupancy ("the items identified in _item_related.related_name").This interpretation is clearly at odds with the associated description which says "It has been replaced by _atom_site.refinement_flags_posn, *_adp and *_occupancy". Either my interpretation of the DDL2 definitions is wrong, or I suspect that it is "replacedby" which should be used here, and not "replaces". In fact the only occurrences of "replacedby" in cif_mm.dic are in commented out definitions.Email Disclaimer: www.stjude.org/emaildisclaimer _______________________________________________ cif-developers mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/cif-developers
begin:vcard fn:I.David Brown n:Brown;I.David org:McMaster University;Brockhouse Institute for Materials Research adr:;;King St. W;Hamilton;Ontario;L8S 4M1;Canada email;internet:email@example.com title:Professor Emeritus tel;work:+905 525 9140 x 24710 tel;fax:+905 521 2773 version:2.1 end:vcard
_______________________________________________ cif-developers mailing list firstname.lastname@example.org http://scripts.iucr.org/mailman/listinfo/cif-developers
Reply to: [list | sender only]