Application-level audit category

[pkeller]

I'll start this discussion here on GitHub, since it isn't doesn't have any scientific content.

The wwPDB have said that they want exclusive use of the audit and related categories, but also were happy with the suggestion to have other category/ies recording information about the creation and manipulation of datablocks before deposition. What would be a good base name for these categories? Perhaps gphl_application_audit or gphl_application_history? (With gphl -> pdbx on acceptance of course.)

What information do we want to record?

• date
• type of change
  • we would only suggest creation of course, but if other processing/refinement software carries out additional manipulations more could be added (like addition or deletion).
• software performing change
• a general description of data added, deleted or modified by this change
  • there is some overlap with _pdbx_diffrn_data_section_contents.content_type
• details (free text)

@CV-GPhL any thoughts?

[CV-GPhL]

I think gphl_application_audit is a good base name ("history" has a kind of long term notion about it, and the various additions to such a loop could come in quick succession.

We might need something more than "date" to distinguish different records: maybe "ordinal"? If data was processed by software X (generating the first version of the mmCIF file, i.e. first gphl_application_audit record), this is then passed down to software Y (for structure solution), then software Z for refinement etc, each step can happen on the same date. And full time specification is rather ugly to read, so a nice ordinal seems a good way of ordering this.

For that reason we should also provide creation, addition, deletion, modification ... maybe even correction (to distinguish a change due to additional computation, e.g. change in R/Rfree between MR and refinement software, from a correction - or is that overkill?).

[pkeller]

I agree with ordinal, the only reason that I didn't put it in my list is because its only use is for ordering and I was just thinking of information content in the first instance.

I also think that we need to have two linked categories, so that you would have one row that corresponds to a single run of some software, which could then perform multiple operations along the lines of addition, modification etc. For our purposes, I think that all we need to do is to propose the basics, and leave extending this to the time if/when a more complex use-case is identified (either by ourselves, or others).

[pkeller]

I'm currently thinking about something like this:

loop_
_gphl_application_audit.ordinal         ## Key item
_gphl_application_audit.date
_gphl_application_audit.software_id     ## Child of _software.name
_gphl_application_audit.details

1    2021-01-27    autoPROC
;
This datablock was created by autoPROC
;

loop_
_gphl_application_audit_change.audit_ordinal  ## Key item; child of _gphl_application_audit.ordinal
_gphl_application_audit_change.ordinal        ## Key item
_gphl_application_audit_change.type           ## Enumeration, something like creation, addition, deletion, modification
_gphl_application_audit_change.details
1   1   creation
;
autoPROC aggregated mmCIF data from the output of STARANISO and AIMLESS
;

This split across two categories will allow a single run of an application to apply multiple add/delete/modify operations. We are only interested in the "creation" step just now, of course.