[IUCr Home Page]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: Meaning of _category.mandatory_code



Hi John,

On Fri, 2006-01-27 at 09:39 -0500, Bollinger, John Clayton wrote:

> 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).

Just to clarify what STAR is supposed to do, Volume G section 2.1.3.6 on
STAR save frames and 2.1.3.9 on STAR scopes state that the scope of a
save frame is all data items contained within the frame, but a save
frame may reference other save frames (!).   The scope of a data block
includes any save frames, "and all specifications [of a data item] will
be recognised when accessing the data block".  I confess to not
understanding what recognising all specifications might actually mean.

> 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.

I find this eminently reasonable logic, and this was my own starting
position.  Where I am now, after trying to write a generic validator for
CIF/DDL, is to view the object to be validated as the combination of the
enclosing datablock and the specific save frame (so the enclosing data
block acts as a global block).  The only exception to this rule is
parent-child validation, which requires access to the entire data block:
e.g. as _item.category_id is a child of _category.id, you have to access
all category definition save frames in order to check that a given
_item.category_id corresponds to a category which has been defined in
the dictionary. 

A further exception would be _category.mandatory_id if it were to mean
"this category appears somewhere in the datablock proper or in at least
one save frame", which is one possibility you raise.

> 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.

Discussion of these issues is very helpful, as it is just me and Volume
G at the moment.

Best wishes,
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

Reply to: [list | sender only]


Copyright © International Union of Crystallography

IUCr Webmaster