Re: [ddlm-group] (no subject)

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