Re: [ddlm-group] Further discussion of proposal #2

Dear James and Colleagues,

I’m going to respond to several aspects of this discussion in separate messages to (I hope) make the individual threads easier to follow.  This first response is directed to these comments of James's:

> I don't actually think default values for keys are necessary until multiple-packet loops are set up. Also, I would need to see a clear formulation of how you would propose to convert Set to Loop in order to comment sensibly in light of all of the other constraints we are operating under. I do appreciate that I am favouring a particular application by giving 'Set' categories such significance. Apart from being bound to do this to keep compatibility with legacy applications, there are non-trivial efficiencies available by being able to make certain values 'global', and the DDL1, DDL2 entry.id, and 'Set' behaviour provides a neat way to do this.

With respect to efficiency, it is not clear to me how a Set with a category key would be any more efficient than a Loop, and it is also not clear whether any efficiency gain that did accrue would be sufficient to justify the required change to DDLm.  I would be interested in hearing a fuller explanation.

In any case, whether it is classified as a Set or a Loop, if a category has a category key, then surely it is necessary for every instance / packet / row of that category to have a value for that key.  If one does not want to oblige data files to provide an *explicit* value for the category key, then the only alternative is to permit them to rely on a default value.  If we are going to do that -- as we must do to avoid changes such as we are discussing from invalidating existing data files -- then I don't see what is gained by making a special rule allowing the key to be defaulted in certain cases, as opposed to simply defining default values for keys where that is warranted, so that existing dictionary semantics provide for data files that present only one packet to omit the key.  In particular, that does not interfere with requiring the key to be presented explicitly when multiple packets are presented, for if a file that presents multiple packets allows them to all take the key's default value then the resulting duplicate keys make the file invalid.

Let's consider the SPACE_GROUP category, since it sparked this whole discussion.  I append a cut at what I think we should do with it (only frames containing modifications are presented); I think I have marked all the changes and additions within via CIF comments.  I rarely wrangle dictionaries, so I apologize for any errors I have committed.  The key defaulting presented within formalizes how, when, and why SPACE_GROUP's category key and the associated child key in SPACE_GROUP_SYMOP can be omitted from data files.  To the best of my knowledge, nothing within relies on any DDLm changes.

Note, by the way, that I think the particular changes presented, or something very like them, are needed regardless of what we choose for the general case, because the DDL1 core and mmCIF are already structured this way.

Best regards,

John

----

save_SPACE_GROUP

_definition.id                          SPACE_GROUP
_definition.scope                       Category
_definition.class                       Loop        # CHANGED
_definition.update                      2016-06-16  # CHANGED
_description.text
;
     The CATEGORY of data items used to specify space group
     information about the crystal used in the diffraction measurements.
;
_name.category_id                       EXPTL
_name.object_id                         SPACE_GROUP

####
# ADDED:

_category.key_id                        '_space_group.key'
loop_
  _category_key.name
         '_space_group.id'

# ... end of additions
####

save_

save__space_group.id

_definition.id                          '_space_group.id'
loop_
  _alias.definition_id
         '_space_group.id'
         '_space_group_id'
_definition.update                      2016-06-16  # CHANGED
_description.text
;
     Code identifying a space group if multiple symmetries.
     See _exptl_crystals.key.
;
_name.category_id                       space_group
_name.object_id                         id
_type.purpose                           Encode
_type.source                            Assigned
_type.container                         Single
_type.contents                          Code

# Take note of this (ADDED):
_enumeration.default                    ''

save_

####
# ADDED:

save__space_group.key

_definition.id                          '_space_group.key'
loop_
  _alias.definition_id
         '_space_group.key'
_definition.update                      2016-06-16
_description.text
;
     Value is a unique key to a set of space_group items
     in a looped list.
;
_name.category_id                       space_group
_name.object_id                         key
_type.purpose                           Key
_type.source                            Related
_type.container                         Single
_type.contents                          Code
loop_
  _method.purpose
  _method.expression
         Evaluation          '_space_group.key = _space_group.id'

save_

# ... end of additions
####

save_SPACE_GROUP_SYMOP

_definition.id                          SPACE_GROUP_SYMOP
_definition.scope                       Category
_definition.class                       Loop
_definition.update                      2013-09-08
_description.text
;
     The CATEGORY of data items used to describe symmetry equivalent sites
     in the crystal unit cell.
;
_name.category_id                       SPACE_GROUP
_name.object_id                         SPACE_GROUP_SYMOP
_category.key_id                        '_space_group_symop.key'
loop_
  _category_key.name
         '_space_group_symop.sg_id'     # ADDED
         '_space_group_symop.id'

save_

save__space_group_symop.key

_definition.id                          '_space_group_symop.key'
loop_
  _alias.definition_id
         '_space_group_symop.key'
_definition.update                      2016-06-16    # CHANGED
_description.text
;
     Value is a unique key to a set of space_group_symop items
     in a looped list.
;
_name.category_id                       space_group_symop
_name.object_id                         key
_type.purpose                           Key
_type.source                            Related
_type.container                         List          # CHANGED
_type.contents                          'Code,Index'  # CHANGED
loop_
  _method.purpose
  _method.expression
         # CHANGED:
         Evaluation          '_space_group_symop.key = [_space_group_symop.sg_id, _space_group_symop.id]'

save_

####
# ADDED:
# Note: this item is needed in any case because mmCIF and
# the DDL1 core define it

save__space_group_symop.sg_id

_definition.id                          '_space_group_symop.sg_id'
loop_
  _alias.definition_id
         '_space_group_symop.sg_id'
         '_space_group_symop_sg_id'
_definition.update                      2016-06-16
_description.text
# copied from mmCIF:
;
   This must match a particular value of _space_group.id, allowing
   the symmetry operation to be identified with a particular space
   group.
;
_name.category_id                       space_group_symop
_name.object_id                         sg_id
_name.linked_item_id                    '_space_group.id'
_type.purpose                           Link
_type.source                            Related
_type.container                         Single
_type.contents                          Code

# Take note of this:
_enumeration.default                    ''

save_

# ... end of additions
####

________________________________

Email Disclaimer: www.stjude.org/emaildisclaimer
Consultation Disclaimer: www.stjude.org/consultationdisclaimer
_______________________________________________
ddlm-group mailing list
ddlm-group@iucr.org
http://mailman.iucr.org/cgi-bin/mailman/listinfo/ddlm-group