RE: Meaning of _category.mandatory_code

["Bollinger, John Clayton" <jobollin@xxxxxxxxxxx>]

James,

I can't authoritatively interpret the _category.mandatory_code for you, but I can point you to http://www.crystal.uwa.edu.au/star/StarSpecs.pdf for a formal description of save frame semantics, including scoping.  I don't know whether it is specific enough to help, but it does say that the data in a save frame are "insulated from" those in the surrounding data block.  I also observe that neither CIF nor STAR defines a mechanism to reference save frame contents, though STAR does have a syntax for referencing an entire save frame as a data value (which, I'm sure you know, is specifically disallowed by CIF).

My take on all of this differs from yours.  In the absence of clearer semantic specifications, I have looked at save frames as self-contained data objects, independent of their data block except inasmuch as the block scopes their *names* and hence all references to them.  I may be reading too much into it, but I take the "insulation" bit in the STAR docs to mean that the inside of a save frame doesn't have a view of the surrounding data block at all.  When it comes to validation, then, I'll offer the possibility that you are misapplying the DDL rule: Vol G apparently requires a mandatory category to appear in a *data block* based on the relevant dictionary, but a save frame is not a data block, so this requirement is irrelevant to individual save frames.  It is unclear whether a data block that contains a mandatory item within a save frame thereby satisfies the mmcif requirement, but the intent seems to be that it should do.

After all that, I'm not sure whether I have addressed your core concern about whether _item_description and _category_description are appropriately defined.  My apologies if I have not.

Regards,

John

-- 

John C. Bollinger, Ph.D.
Indiana University
Molecular Structure Center

jobollin@indiana.edu 

> -----Original Message-----
> From: cif-developers-bounces@iucr.org 
> [mailto:cif-developers-bounces@iucr.org] On Behalf Of James Hester
> Sent: Friday, January 27, 2006 1:08 AM
> To: Forum for CIF software developers
> Subject: Meaning of _category.mandatory_code
> 
> _category.mandatory_code is discussed in Volume G p 473 and 
> in mmcif_ddl_2.1.6.dic, which simply state "Whether or not 
> the category must be specified in a dictionary".  Vol G page 
> 64 is more explicit and partially contradictory: "whether or 
> not this category must appear in a data block based on this 
> dictionary."
> 
> So the interpretation is clear for e.g. the space_group 
> category of the cif_sym dictionary: any CIF data block 
> claiming to conform with this dictionary must have at least 
> one data item belonging to the space_group category.  
> Likewise, the dictionary category in the core ddl2 dictionary 
> must appear, and it does, in the datablock outside the 
> dictionary save frames.
> 
> However, what about the _item_description category in the 
> core ddl2 dictionary?  It has _category.mandatory_code set to 
> 'yes'.  Taking the
> p64 description, this is saying no more than that an 
> attribute from the _item_description category must appear 
> somewhere in a DDL2 dictionary.
> I'm not aware of any explicit description of save frame 
> scoping in CIF dictionaries, but I deduce that we are 
> supposed to adopt a model whereby, from the perspective of a 
> single dictionary save frame, the datablock consists 
> precisely of the save frame plus the enclosing datablock, 
> that is, the enclosing datablock is to a save frame what a 
> global block is to subsequent datablocks in a STAR file.  In 
> this scoping model, we deduce that all save frame definitions 
> must at the very least include an _item_description 
> attribute.  Unfortunately, this cannot be the case, as some 
> save frames are category definitions and so an 
> item_description is absent.  Either we should drop the 
> mandatory specification for _item_description, or improve the 
> wording to allow e.g. _category_description to substitute for 
> _item_description.  
> 
> Comments? 
> 
> James.
> --
> ______________________________________________________________
> _________
> James Hester, ANBF                             KEK
> e-mail: jrh@anbf2.kek.jp                       Oho 1-1
> Phone: +81 298 64 7959                         Tsukuba, Ibaraki 305
>   Fax: +81 298 64 7967                         Japan
> ______________________________________________________________
> __________
> _______________________________________________
> cif-developers mailing list
> cif-developers@iucr.org
> http://scripts.iucr.org/mailman/listinfo/cif-developers
> 
_______________________________________________
cif-developers mailing list
cif-developers@iucr.org
http://scripts.iucr.org/mailman/listinfo/cif-developers