This is an archive copy of the IUCr web site dating from 2008. For current content please visit https://www.iucr.org.
[IUCr Home Page] [CIF Home Page] [mmCIF Home Page]

Re: DDL.2.x spec. ?

John Westbrook (jwest@wormhole)
Sun, 22 Jan 1995 15:04:23 -0500 

Hi Weider,

I am not sure I completely understand your query but I will try to address
part or your question.

On Jan 20,  7:22pm, Weider Chang wrote:
> Subject: DDL.2.x spec. ?
> Hi John and everyone:
>
> Here are two DDL issues that I came across when I start to work with DDL.2.x
> and the new mmCif dictionary. These issues can only be address by clearly
> spell out the new DDL's policy. May be these problems have been solved and
> someone can shade some light on that.
>
> John, how should an association between a value (or item) and its appropriate
> save frame to be identified under DDL.2.x? My point is, how does a program
> know that the "_category.id" in "_category.id    entity" should associated
with
> "save_category.id" while the "entity" is associated with "save_entity" (or
> save_ENTITY)? Is the leading "_" signifys that matching should be made after
> strip off the first character from the string? Then, how about the
> "'_category.id'" in "_category_key.name  '_category.id'"? Obviously these
> types of referencing mechanisms are NOT STAR save frame specification, which
> uses "$" to indicate reference. Should these rules be specified formally to
> prevent misinterpretation?
>
I am not entirely sure what the issue is here.   'save_' is the STAR keyword,
so any text following this is the name of an item or a category.  STAR requires
that the instance of a data name be preceded by the '_' character.  There is
no similar rule for category names.   In the current DDL, whenever a data name
is used it is preceded by the '_' character.  This is true whether it is used
as an lvalue or an rvalue.  The one exception to this usage is when the data
name follows the save frame keyword.

The current usage was part of the compromise reached with Syd and Nick.
There are two ways of making this consistent.  One is to leave off the
leading underscore when a data name occurs as an rvalue.  Then the meaning
of the underscore is just a STAR semantic.  This solution is completely
contrary to current usage where data name are always preceded by
an underscore when they occur as an rvalue.
The other possibility would be to specify data item names as
 save__category.item_id  where there should be an additional underscore
preceding the category name.   In my view this would be the easiest
way to obtain consistency.  This would  only be necessary for item name
definitions and would provide on additional way to differentiate
categories definitions from item definitions.  Nick and Syd may wish to comment
on this.

>
> Should there be rules that specify how dependent information should be
> declared. For example, "_struct_conn.conn_type_id" was declared as the
> "_item_linked.parent_name" of "_struct_conn_type.id" in mmCif dictionary. The
> enumeration range of the value was declared in "save_struct_conn_type.id" and
> the "struct_conn_type" category is NOT a mandatory information in a Cif. So,
> how can one check the integrity of the "_struct_conn.conn_type_id"? How can
> one  sure a "hydrog" in one Cif is the same "hydrog" in another file at the
> "_struct_conn.conn_type_id" level? Is this mean enumeration range is
> automatically transferable through the parent relationship? I don't think it
> should. A restriction that state the declaration of enumeration range must be
> at the APPLICABLE root parent node is needed to prevent problem like this.
>
As I see it this is a dictionary developers issue rather than a DDL issue.
The question of where to place the enumeration in the parent child hierarchy
is a policy decision that should be set in the dictionary.  Clearly, one
should be cautious and consistent in the dictionary design to avoid the
situation that you raise.  I do not think that there need to be any
additional rules in this regard.

> Is there any plan or solution to address these issues? Thanks.
>
I think we should seriously consider implementing a fix to the inconsistent
use of the underscore in the item save frame definitions.


Regards,

John


-- 
****************************************************************************
*  John Westbrook                       Ph:  (908) 445-5156                *
*  Department of Chemistry              Fax: (908) 445-5958                *
*  Rutgers University                                                      *
*  PO Box 939                        e-mail: jwest@rutchem.rutgers.edu     *
*  Piscataway, NJ 08855-0939                                               *
****************************************************************************