Discussion List Archives

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

Re: mmCIF specification

Dear Colleagues,
  James has stated the approach to identifying frames correctly.  The original question

"But what is the procedure to make a mandatory, but never needed mmCIF item 

suggests a difference in views about how this all fits together.  Information is what it is.
If all we need at a particular time is some particular subset of columns and rows in the
information available to us, and do not wish to see anything else, there are no CIF
police to arrest you for hiding the information you don't want.  The only thing constraining
what you need to keep is that you need enough information to let you make sense of
the information you are looking at.  So if you want, you can take any subset you want and
stick it into a Mongo NOSQL database and do whatever science you wish.

However, if you are the maintainer of a large, complex evolving body of data, and want some
reasonable chance of maintaining the ability to search for and retrieve various subsets of
columns and rows at the same time as other subsets of columns and rows are being updated
without it getting garbled, then I would urge you to a strictly follow a relational model and be sure
to keep careful track of the keys needed for the relevant schema, and to be very careful to
include information for the columns that are mandatory for the schema holding it all together.

That is why mmcif, pdbx, imgCIF all work within a relational model using DDL2, rather than
DDLm, and why James, John Westbrook and I are all interested in seeing a clean interoperable
mapping created between DDL2 and a relational view of a subset of DDLm.   For coreCIF image
handling, I would suggest adopting the same approach.


On Wed, Jun 3, 2020 at 8:41 AM James Hester via cif-developers <cif-developers@iucr.org> wrote:
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,

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,

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 mailing list

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.