Discussion List Archives

[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]
International Union of Crystallography

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

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