[Date Prev][Date Next][Date Index]
(74) Working practices, abbreviations in data names
- To: COMCIFS@iucr.ac.uk
- Subject: (74) Working practices, abbreviations in data names
- From: bm
- Date: Thu, 9 Oct 1997 15:24:52 +0100
Dear Colleagues There has been little correspondence following the last circular; I circulate below David's responses. Note that the absence of any objections to the various proposals on the table for reorganising our mode of working will be construed as tacit approval. I remind all interested parties that there are two workshops of some importance in the next couple of weeks: an mmCIF software developers workshop at Rutgers University, October 17-19, and a workshop on image data formats at Brookhaven, October 19-22. D70.1 Review of Comcifs ------------------------ D> I will be submitting to the Executive Committee of the IUCr a D> report on Comcifs work and a proposal for future terms of D> reference. The report comprises sections 1-6 of the report that D> appeared in Circular 70, and the proposed terms of reference will D> be those that appeared in Circular 72 modified in the light of D> comments received. I will present the final document to Comcifs D> for approval before submitting it to the Executive. D> D> Since the proposals in Circular 72 will, when suitably D> modified and approved by the Executive Committee, serve as our D> terms of reference, we should keep them as simple as possible and D> restrict them to important matters. They should describe the D> membership of Comcifs and the procedures for establishing formal D> working parties, particularly those charged with creating and D> maintaining dictionaries that are important to the functioning of D> other organisations, e.g, Acta Cryst., PDF, PDB. D> D> Other matters, such as the way in which routine business is D> carried out, terms of reference of working groups and how we D> exercise our mandate to publicise the results, are not part of our D> terms of reference, though we may wish to spell them out for our D> own better understanding. These modi operandi are likely to evolve D> given the rapid changes occuring in electronic communication, and D> they should be kept under the control of Comcifs. Thus Brian's D> proposed terms of reference for informal working groups belong to D> the modi operandi and are not part of the terms of reference that D> need to be approved by the Executive Committee. D> D> However, I question the need for terms of reference for D> Informal Working Groups. (Are these the same as the Working D> Parties mentioned in Circ.72?) Comcifs needs to remain flexible in D> the way it undertakes its tasks and needs to be able to establish D> working groups (or parties) in a way that best suits the problem. D> Some will need to be formally established, such as the group that D> maintains mmCIF, since this group will need to have representatives D> from several user organisations. In these cases explicit terms of D> reference that all the constituencies can work with are probably D> needed. On the other hand, the informal dictionary relationships D> group that Brian describes in Circ.73 hardly needs terms of D> reference because, at the moment, it has not even been acknowledged D> by Comcifs, let alone been given any authority. There is nothing D> to stop such groups of people getting together to make proposals to D> Comcifs, and, while Comcifs would like to know about them, they do D> not need the permission of Comcifs or specific terms of reference D> unless they feel that it would give more legitimacy to their work. D> Their contribution is no less valuable for being informal (see D> D73.3 below). Lets keep the organisation as simple as is D> consistent with everyone understanding their role. I have no quibble with this overall philosophy. However, we did find it useful to draw up some guidelines to establish a basis for our approach to the problem (to begin with, we had not even defined what the problem was). Such guidelines (which, as suggested, need not form part of the official terms of reference) may be suitable for other groups also. I don't know whether one should distinguish formally between our dictionary maintenance group and the aforementioned Working Parties, but I do see some difference between efforts to construct a new dictionary for a particular sub-discipline, and efforts to ensure a complete and unambiguous implementation of CIF (and perhaps its evolution) across all relevant sub-disciplines. It's clear to me that (for good or ill) COMCIFS has a role to play in such topics as choice and specification of DDL, dictionary evolution and software coordination, and there are good reasons why COMCIFS should identify the problems and commission studies to resolve them, rather than leave the initiative to the general public. D73.1 Modulated structure dictionary ------------------------------------ D> I will see about establishing a subcommittee to review this D> draft, but see my comments under D73.2 below about the importance D> of not making a dictionary publicly accessible until it has been D> given provisional approval by Comcifs. Although the draft is visible through the Web on the URL I posted last time, it is not copied to the IUCr mirror servers nor referenced from any other public web document. It might, however, be prudent for me to add a disclaimer to the files in case they are stumbled upon inadvertently. D73.2 Community review ----------------------- D> Helen is correct to point out the importance of the community D> review stage in the approval of a dictionary, and such a review is D> built into our procedures, as Brian points out. Now that we have D> had some experience with these procedures, it may be time to review D> them. Below I suggest a procedure for dictionary creation and D> updating. D> D> Dictionaries are produced by working parties (or groups) which D> are given a mandate by Comcifs. The initiative for new D> dictionaries usually comes from workers in the field many of whom D> have limited experience with cifs. When I am approached by a D> person interested in establishing a new dictionary, I appoint that D> person as an observer to Comcifs and encouraged him or her to D> establish a group of like-minded people to prepare a draft D> dictionary. The first draft, through the inexperience of the D> members of the group, is likely to contain many violations of the D> cif standard and, in the past, Brian and I have had to work with D> the group before a cif-compliant draft is prepared. In the future D> I will ask Comcifs to appoint a subcommittee to check these drafts. D> It is essential that these early drafts are NOT made widely D> available as the premature publication of a dictionary that is not D> properly cif compliant could do far more harm than good. Because D> checking a draft for cif compliance is tedious and time consuming, D> it is best if this is initially undertaken by a small subcommittee D> of Comcifs. Only when the subcommittee is satisfied that the draft D> dictionary represents a reasonable working model should it be D> presented to the full membership of Comcifs. At this stage, D> Comcifs would be asked to give provisional approval in a formal D> vote. Only then should the draft be publicly posted and given D> maximum possible exposure, though with the caveat that there could D> still be major changes. After adequate public input, the D> subcommittee would undertake a detailed review, and recommend that D> Comcifs give final approval, once again in formal vote. D> D> A less formal process may be adequate for incremental changes D> in an existing dictionary. These would be proposed by the working D> group formally established to maintain the dictionary and would be D> reviewed by the corresponding subcommittee. The subcommittee would D> have authority to approve minor extensions such as new datanames or D> clarified definitions, but would bring back to Comcifs any changes D> that have implications for the development of the cif standard. D> D> This proposal follows the spirit of our present procedures but D> streamlines them in the light of experience. Comments are welcome. D> Lack of comments will be taken as tacit approval. D73.3 Dictionary maintenance (would 'dictionary relationships' be a better name?) ----------------------------------------------------------------- D> It is good to know there are people working on the problem of D> relating dictionaries and that they have constituted themselves as an D> informal working group. I look forward to hearing the proposals D> that come out of these discussions. I do not think it is necessary D> to formalise this group unless they request it. See my comments D> above (D70.1) We have made progress on layering static DDL1 dictionaries (by which I mean validating a data file against more than one dictionary - public or private - in a way designed to resolve possible conflicts between competing definitions). I hope to look at the parallel issues for DDL2 dictionaries, and hope that we can have some useful discussions at Rutgers next week. There are also some incipient proposals for a revision control system, for mapping protocols between namespaces and for extending DDL to allow dynamic editing of dictionary-based attributes. If we explore these in detail, we shall in effect be specifying a toolkit for dictionary evolution and maintenance, so I think the terminology is the right one. I remind you that these discussions may be reviewed by COMCIFS members only (at present) at the URL http://www.iucr.org/iucr-top/cif/comcifs/wg1. D73.4 Non-CIF standards ----------------------- D> We will need to formalise the relationships with groups D> developing cognate standards. I am in favour of Comcifs D> establishing some ground rules whereby we would give our D> endorsement to standards that can be converted to compliant cifs. D> I shall be meeting with the imageNCIF group (Hammersley and Co) D> next month and will discuss with them the best way of ensuring that D> their binary image files can be convertible into a proper cifs. D> D> As Brian M suggests, working with these groups might provide D> a means by which CIF can work towards introducing nested loops. D> Although these create additional problems for the programmer, D> unnested loops create considerable complexity in the dictionaries D> and we ought to explore the trade offs. This type of extension is the sort of thing I have in mind when I say (above) that COMCIFS should take an active lead in commissioning new working groups. I am surprised not to have received more response to the suggestion that COMCIFS should for the present request the quasi-CIF standards groups to provide conversion libraries to pure CIF format. Can we take it that everyone is entirely happy with this approach? ======================================================================== D74.1 Abbreviations used in CIF names ------------------------------------- D> For information (and possible posting on the web) I enclose below a D> list of the abbreviations that we have used in the data names in the D> current core and pd dictionaries. The idea is that we should not D> proliferate these, but stay with the same D> abbreviation for the same word. For example, difference, diffraction and D> diffractometer each have different abbreviations so we should stick with D> these in future dictionaries. There are several cases (marked) where D> different abbreviations are used for the same word and we should try to D> standardise on one. Fortunately there do not seem to be any cases where D> the same abbreviation is used for different words. D> I have not yet checked the names in the msCIF dictionary but will D> do this. Nor have I tried working through the mmCIF dictionary though D> there is no reason why all the cif dictionaries should not use the same D> convention on abbreviations. I shall tackle this one when the spirit D> moves me. This is an extremely useful exercise, and thanks are due to David. I shall indeed post this list on the web; for now, at a more or less arbitrary location (http://www.iucr.org/iucr-top/cif/spec/abbrev.html), though in time it might usefully be referenced by documentation issuing from the dictionary maintenance working group! ABBREVIATIONS USED IN CIF NAMES Appear in coreCIF unless otherwise labelled abbrev abbreviation abs absolute absorpt absorption AN accession number anal analyser (pd) aniso anisotropic atten attenuation av average ax axial (pd) backgd *background bg *background bkg *background (pd) calc calculated calib calibration (pd) cartn cartesian char characterisation (pd) coef coefficient conn connectivity cons constant defn definition detc detector (pd) dict dictionary diff difference diffr diffractometer diffrn diffraction displace displacement dist distance (pd) divg divergence (pd) dtime dead time eq *equatorial (pd) equat *equatorial equiv equivalent eqn equation (pd) esd standard uncertainty (estimated standard deviation) exptl experimental fract fractional Fsqd F squared geom geometric H-M Hermann-Mauguin hbond hydrogen bond horiz horizontal I intensity id identifier illum illumination inc increment (pd) incl include info information (pd) instr instrument (pd) Int international iso isotropic len length (pd) ls least squares max maximum meanI mean intensity meas measured mid middle (between max and min) min minimum monochr *monochromator (pd) mono *monochromator (pd) NCA number of connected atoms netI net intensity NH number of connected hydrogen atoms norm normal obs observed orient orientation pd powder diffraction (pd) perp perpendicular pk peak (pd) polarisn polarisation pos position prep preparation (pd) proc processed (pd) prof profile (pd) publ publication R agreement index rad radius recd received recip reciprocal (pd) refine refinement refln reflection reflns reflections res resolution Rmerge agreement index of merging rms root mean square S goodness of fit samp sample (pd) scat scattering factor sigI *sigma(I) sigmaI *sigma(I) sint sin theta sint/lambda *sin(theta)/lambda spec specimen (pd) src source (pd) std standard (pd) stol *sin(theta)/lambda tbar mean path length tran *transformation transf *transformation transform *transformation vert vertical wR weighted agreement index wt weight * terms with multiple definitions terms for which abbreviations are defined are sometimes found unabbreviated D74.2 New URLs for IUCr web locations ------------------------------------- The eagle-eyed may have spotted occasional references to URLs of the form http://www.iucr.org/ (cf the more familiar http://www.iucr.ac.uk/). The new form represents essentially an alias (technically these are A records in a zone file for the second-level domain iucr.org) that is more compact, more memorable, and more indicative of the Union's nature as an international non-profit organisation. For so long as the UK academic network JANET acts as our Internet Services Provider (and there are no plans to change that), the older .iucr.ac.uk addresses will remain valid. However, we shall progressively move to using the .iucr.org addresses in our stationery and publications, and you should modify any references you make in future publications accordingly. Regards Brian
- Prev by Date: (73) msCIF, Community Review, Dictionary Working Group, data exchange
- Next by Date: (75) mmCIF Workshop; imgCIF/CBF Workshop; review of COMCIFS
- Index(es):