Discussion List Archives

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

(7): private restraints descriptors, etc

Dear Colleagues

Just when you thought you had heard the last from me for a while...

David Brown has sent in some comments that I wanted to pass on just before
I leave. His remarks on D4.1, I think, especially merit some thought.

D> D5.1  Procedural matters:  I agree with Paula's interpretation that we
D> prefix the D5.1 with the number of the circular, when this is not the
D> number following the D.

I don't think there's any contest on this, eh? Let's elevate it to the
status of an Agreement.

A5.1: Internal cross-references to discussion threads should take the form
      (r)Xm.n, where n is the point numbered n in circular m, specifically
      referenced in (optional) circular r; and X is D or A according as the
      topic is currently under Discussion or Agreed.

Remember, you have one month to complain!

D> D4.1 Restraints:  I am beginning to get the hang of this discussion. 
D> Paula's compromise seems a good one.  Maybe some of the names used in the
D> *_type character strings could be expanded to make them clearer.  Are
D> units assumed to be Angstroms and degrees unless otherwise declared?
D> 
D> An alternative would be to define CIF-like terms that could be embedded in
D> a character string.  This string could then be read as a CIF (or part of a
D> CIF) outside of the main CIFreading routine.  That is, to the program
D> reading the CIF it would look just like a character string, but when
D> opened up, inside would be a mini-embedded CIF using data names that were
D> specific to the program being used.  When the program becomes obsolete, so
D> do these CIF-type names, since they do not appear in any cifdic.
D> 
D> Here is another possibility.  In Beijing we discussed the possibility of
D> each program system having field names that were specific to, and chosen
D> by, the manager of the program, names that might begin 'xtal_' or
D> 'shelx_'.  In this case the program manager might devise a set of fields
D> that would  represent the restraints in an appropriate way for both the
D> program and the community.  One would need then to consult the appropriate
D> program dictionary as well as the core and mm dictionaries.  In this way,
D> if a program becomes obsolete, the whole of its dictionary dies
D> automatically without cluttering up the core dictionary.  When the method
D> of quoting restraints becomes standardized, an appropriate set of fields
D> can be added to the mm or core dictionary.

D> D4.2 Dictionary introductions:  I am not too worried about the lack of
D> aesthetics in 'pd_calc_[pd]'.  If anything it helps to emphasise that this
D> name is not like other names and should not be used in a regular CIF.  I
D> agree with Paula that she should drop fields such as _chemical_[mm].

I'm nearly ready to cave in on this (i.e. accept _name '_entity_[mm]' etc),
but I'll hang fire just in case someone at Tarrytown is able to convince me
that my idea of leaving trailing underscores is correct, after all. Doubt it,
though.

Back in November,
Brian