[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Reply to: [list | sender only]
Re: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains.
- To: "Discussion list of the IUCr Committee for the Maintenance of the CIFStandard (COMCIFS)" <comcifs@iucr.org>
- Subject: Re: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains.
- From: Brian McMahon <bm@iucr.org>
- Date: Sat, 5 Mar 2011 12:53:00 +0000
- In-Reply-To: <8F77913624F7524AACD2A92EAF3BFA54168ECD35D9@SJMEMXMBS11.stjude.sjcrh.local>
- References: <AANLkTikfLNd6mQB9hB9haGek_52ceO3GjXrtAR5tbsnj@mail.gmail.com><AANLkTin+DsXM58+gQ=H4vXGyuRS7xcDHcmAKKYMztvDL@mail.gmail.com><AANLkTimzgzLHrAg_pKHv82Qjzsz6ME1NPFsfZ87P2tQ8@mail.gmail.com><AANLkTi=pQoaya+9eyChCzn5HnkGkcOcbZxL=rQEN=jDL@mail.gmail.com><a06240800c996972c073b@[149.72.35.130]><8F77913624F7524AACD2A92EAF3BFA54168ECD35D9@SJMEMXMBS11.stjude.sjcrh.local>
I should like to make a number of comments to explain my perspective on the choices we face in continuing to develop CIF in the direction of greater functionality. (Think of me in this context as an Editor of International Tables G, with a specific desire to document a coherent and consistent standard sponsored by the IUCr.) (1) "Stakeholder buy-in" is not something we'll be able to guarantee, whatever approach we take. Herbert makes the well-established point that demonstrably "better" solutions are not always those that flourish. Peter's experiences with CML are also illuminating. On the face of it, one would expect CML to attract a huge number of stakeholders based on the potential returns from an information exchange standard in chemistry, and the adoption of a standard data format (XML) that is common currency. And yet, the uptake of CML still seems to me modest - I would go so far as to say disappointing. (2) There is a real danger that a poor choice for a novel syntactic feature could lead to some confusion. But (a) there are relatively few available constructs with the necessary aesthetic appeal (if we want to keep files reasonably human readable), and any one choice may conflict in some way with some other existing convention; and (b) people can learn to cope with potential ambiguities when they have to. Who are such "people" and when will they "have to"? That will depend in part on how the results are used in the real world. If all CIF input/output is through computerised pipelines, the onus is on the developers writing the standard parsers. If it's envisaged that general cut and paste will frequently be involved, then the incidence of mistakes is likely to be higher. There's going to be considerable scope for judgement in trying to assess the impact of a syntactic change in the real world. (3) That's related to Peter's notion of toolchains, which is well made. The CIF data format is idiosyncratic (a turn-off for many), but well specified and relatively lightweight. On the other hand, it is supported by a rather small set of tools. Building new bespoke tools will be burdensome, because it must be undertaken by a small community. In my view, extending that toolchain within a small group, if that is what needs to be done, is helped by applying Occam's razor ("entities should not be unnecessarily multiplied") to new syntactic elements - they should contain the smallest amount of complexity needed to achieve the purpose for which they have been introduced. (4) Then the question arises of whether - and what - we gain by introducing syntactic features, not strictly necessary but familiar to a larger constituency, in the hope of encouraging greater direct involvement in extending the toolchain. Frankly, I am sceptical that by itself this would attract many new active programmers, but I'd be interested in hearing counter-views, especially from this wider circle of COMCIFS advisers with all your experience of your respective communities. I think it *might* be more appealing to groups that decline to engage directly with CIF as it now stands if there were widespread traffic of CIFs expressed in a less idiosyncratic format (e.g. XML). But only "might" - there's nothing actually preventing people from developing XML files based on CIF tokens and dictionary attributes within the "Crystallographic Information Framework". Indeed, there are already instances of this: PDBML, the crystal structure content within CML files, the symmetry database of the Bilbao group. But none have really taken off, and I'm not aware of any community demand for delivery of CIF data in XML format, certainly among the people who interact with the IUCr journals. My conclusion is that it is not primarily the format that is inhibiting greater stakeholder buy-in, certainly to CIF as it now exists. There might be greater interest from people external to this group if and when we have functioning dictionary-based methods evaluation through dREL, but on past experience I wouldn't automatically expect that to happen. However, we do have within this CIF developer community significant experience in implementing dictionary-based methods. Doing this properly over the complex objects described by related dictionary categories is not at all an easy task. This is why we have needed to develop dREL, not as yet another general-purpose language, but as one specifically tuned to the data structures expressible in CIF. If the consequence of this is the need to continue extending our own toolchain, that argues against putting additional obstacles in the path of doing so. Regards Brian _________________________________________________________________________ Brian McMahon tel: +44 1244 342878 Research and Development Officer fax: +44 1244 314888 International Union of Crystallography e-mail: bm@iucr.org 5 Abbey Square, Chester CH1 2HU, England
Reply to: [list | sender only]
- Follow-Ups:
- Re: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains. (Herbert J. Bernstein)
- References:
- Advice on COMCIFS policy regarding compatibility of CIF syntax withother domains (James Hester)
- Re: Advice on COMCIFS policy regarding compatibility of CIF syntaxwith other domains (James Hester)
- Re: Advice on COMCIFS policy regarding compatibility of CIF syntaxwith other domains (Peter Murray-Rust)
- Re: Advice on COMCIFS policy regarding compatibility of CIF syntaxwith other domains (James Hester)
- Re: Advice on COMCIFS policy regarding compatibility of CIFsyntax with other domains (Herbert J. Bernstein)
- RE: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains. . (Bollinger, John C)
- Prev by Date: RE: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains. .
- Next by Date: Re: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains.
- Prev by thread: RE: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains. .
- Next by thread: Re: Advice on COMCIFS policy regarding compatibility of CIFsyntaxwith other domains.
- Index(es):