Re: mmCIF specification

Hi Marcin,

Images would be the province of imgCIF. I often find it hard to pin down the exact key in some imgCIF categories, but I *think* what you need is a pointer to _diffrn_data_frame.id, which is according to Vol G a unique identifier for each frame of data (a frame is the complete image formed by all modules of the detector at a single scan step).  As far as I am aware there is not yet a facility in PDBx/mmCIF to link unmerged h,k,l spots and the frame that they came from, but as PDBx is so large it is probably worth asking on the developers' forum what the situation is.  Let us know back here what answer you get.  Herbert Bernstein is probably also on our cif-developers list and may have something to suggest.

As far as core CIF is concerned, a way to map imgCIF into core CIF has been sketched out, but the machinery is not yet in place. The concept is that a DDLm core CIF extension dictionary would take core CIF to the same category structure as imgCIF (which is mmCIF + a few extra key data names in a few diffrn categories), after which it would be simple to add columns to diffrn_refln indicating which frame the data come from.  If you would be interested in contributing to this effort let me know and I'll provide more information.

all the best,

James.

On Wed, 3 Jun 2020 at 21:53, Marcin Wojdyr <wojdyr@gmail.com> wrote:

Hi James,

thanks for the reply.

When writing about image-number I meant a 2D image where the
reflection is detected. After talking with people who'd be interested
in using unmerged data in MX there was a consensus that it's important
to know which reflections come from which image (having image number
is a simplification because one reflection can be registered on more
than one consecutive image). This allows, for example, to discard a
range 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

--

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