[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Send comment to list secretary]
[Reply to list (subscribers only)]
Re: Core CIF - revision to accommodate Acta C Notes for Authors
- To: COMCIFS@iucr
- Subject: Re: Core CIF - revision to accommodate Acta C Notes for Authors
- From: Brian McMahon <bm@iucr.org>
- Date: Mon Nov 24 15:27:23 1997
- In-Reply-To: <000000001@iucr.org>
D> A quick look through the proposed core changes raises the D> following queries and comments: D> D> *_obs D> These items are all referenced to *_gt. Since we have decided to D> go for *_gt, why are we now introducing *_obs items for the first time? D> Surely it is bad enough to build in obsolescence without actually D> introducing data names that are already obsolete before they are defined! D> (Does 'obs' stand for obsolete? :). The same comment applies to D> *_shift/esd_*. The reference is through the DDL1.4 terms "_related_item" and "_related_purpose replace". These are added to the *old* item, not the new one. Although this may seem counter-intuitive, the idea is that a CIF reader working through archival data will be pointed forward to the definition that supersedes the older one. DDL2 has a better bidirectional formalism, where the related functions are "replaces" and "replacedby", and I think this would be an improvement that one might consider for DDL version 1.5. No new 'obs' terms have been introduced. D> _refine_ls_wR_factor_gt D> We discussed the definitions of R factors some time ago and I D> thought we had decided that there was only one possible definition of wR, D> namely what here is called *_wR_factor_ref. Any omitted reflections are D> those in which w is set equal to zero, so, since w is presumably defined D> for each reflection, *_wR_factor_gt is a nonsense and should not be D> allowed into the dictionary (this would also exclude *_obs). If it is D> absolutely essential to include this definition for historical reasons, is D> there anyway we can point out its mathematical absurdity and D> inappropriateness for any valid crystallographic purpose? There are many instances of *_obs in the Acta archive. The *_gt form was introduced solely to yield a parallel translation to the other *_obs->*_gt changes. I am willing to entertain the idea that we do not introduce the *_gt form, but instead add to *_obs the entries _related_item '_refine_ls_wR_factor_ref' _related_purpose replace as a pointer to (database querying) software to consider the *_ref name as a replacement for *_obs (though the definitions are in fact slightly different). Are there any objections to this? D> _refine_ls_shift/su_mean D> The related item I assume should be *_shift/esd_mean, not D> *_shift/su_mean. I've deleted the "_related_item" entry altogether in this case. D> _reflns_number_Friedel D> The last line of the definition should read 'anomalous scattering' D> not 'inelastic scattering'. OK, I've made that change. D> _reflns_threshold_expression D> Would it be better to say 'USUALLY based on multiples of' or D> 'based on FUNCTIONS of'? I do not see any need to restrict the nature of D> the function being defined in such a drastic way, even if it does cover D> 99% of current usage. OK: _definition ; The threshold, usually based on multiples of \s(I), \s(F^2^) or \s(F), that serves to identify significantly intense reflections, the number of which is given by _reflns_number_gt. These reflections are used in the calculation of _refine_ls_R_factor_gt. ;
[Send comment to list secretary]
[Reply to list (subscribers only)]
- References:
- Core CIF - revision to accommodate Acta C Notes for Authors (Brian McMahon )
- Prev by Date: Re: Core CIF - revision to accommodate Acta C Notes for Authors
- Next by Date: Enumeration ranges
- Prev by thread: Re: Core CIF - revision to accommodate Acta C Notes for Authors
- Next by thread: Re: Core CIF - revision to accommodate Acta C Notes for Authors
- Index(es):