Discussion List Archives

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

Re: mmCIF specification

Hi James,
thanks for the reply.
When writing about image-number I meant a 2D image where thereflection is detected. After talking with people who'd be interestedin using unmerged data in MX there was a consensus that it's importantto know which reflections come from which image (having image numberis a simplification because one reflection can be registered on morethan one consecutive image). This allows, for example, to discard arange of images.
I'll take this to a different forum.
Best wishes,Marcin
On Wed, 3 Jun 2020 at 08:12, James Hester via cif-developers<cif-developers@iucr.org> wrote:>> Hi Marcin,>> I can't speak to the mmCIF question, perhaps you could ask that on a wwPDB developer's forum.>> About the unmerged reflections, I think you mean something like _diffrn_refln.id? DIFFRN_REFLN was always intended to record the original measured reflections before merging (and in modern times the individual spots after integration). I think we need _diffrn_refln.id, but it would mean that diffrn_refln_[h,k,l] no longer become the unique identifier for the loop (of course it never should have been even in the days of point detectors). If anybody has written software that assumes that these datanames form a key it would cause incompatibility. However, I think almost nobody ever reads diffrn_refln_[hkl] as nobody writes it. A quick poll: do any developers on this list do anything (read/write) with _diffrn_refln_h,k,l?>> One way forward is to simply define _diffrn_refln.id as a key. Software that expects h,k,l will fail if they are missing (if any such software exists), and succeed if h,k,l are unique. If h,k,l are not unique such software would have failed anyway.  A gentler way forward is to define a DDLm extension dictionary to cif core that expands the looped categories to parallel those in mmCIF.>> James.>>> On Tue, 2 Jun 2020 at 03:54, Marcin Wojdyr via cif-developers <cif-developers@iucr.org> wrote:>>>> Dear All,>>>> my understanding is that PDBx/mmCIF dictionary is built upon the mmCIF>> dictionary which is not actively developed nowadays. So new items are>> added with the pdbx_ prefix. But what is the procedure to make a>> mandatory, but never needed mmCIF item non-mandatory?>>>> I'm thinking about _diffrn_refln.scale_group_code and>> _diffrn_refln.standard_code.>>>> By the way, do you have an image-number or a similar tag for unmerged>> reflections in small molecule CIF files?>>>> Best wishes,>> Marcin>> _______________________________________________>> cif-developers mailing list>> cif-developers@iucr.org>> http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers>>>> --> T +61 (02) 9717 9907> F +61 (02) 9717 3145> M +61 (04) 0249 4148> _______________________________________________> cif-developers mailing list> cif-developers@iucr.org> http://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers_______________________________________________cif-developers mailing listcif-developers@iucr.orghttp://mailman.iucr.org/cgi-bin/mailman/listinfo/cif-developers

Reply to: [list | sender only]
International Union of Crystallography

Scientific Union Member of the International Science Council (admitted 1947). Member of CODATA, the ISC Committee on Data. Partner with UNESCO, the United Nations Educational, Scientific and Cultural Organization in the International Year of Crystallography 2014.

International Science Council Scientific Freedom Policy

The IUCr observes the basic policy of non-discrimination and affirms the right and freedom of scientists to associate in international scientific activity without regard to such factors as ethnic origin, religion, citizenship, language, political stance, gender, sex or age, in accordance with the Statutes of the International Council for Science.

Useful links