When is an entry considered missing?

[jonblack]

Currently an entry is considered missing if it doesn't exist in a databank but does exist in its parent. For example, if there is no entry in HSSP for 1crn but there is an entry for 1crn in its parent, DSSP, then 1crn is missing from HSSP

This is, however, only one level deep. What happens if the entry exists in MMCIF but in neither DSSP nor HSSP? The above definition labels it missing in DSSP but says nothing about HSSP. I assume it inherits the missing state from the parent in this case?

It can get even more complicated. What happens if an entry is in MMCIF but annotated in DSSP? I assume in this case the HSSP entry inherits the annotation of the entry in DSSP?

@drlemmus, @cbaakman

[drlemmus]

I think we should strive for:

Case1 mmCIF && DSSP && !HSSP
HSSP status: missing (annotated "." || unannotated)
Case2 mmCIF && !DSSP && !HSSP
DSSP status: missing (annotated "." || unannotated)
HSSP status: missing annotated "No DSSP"

In Case2 the key reason that there is no HSSP, is that there is no DSSP so that can be annotated automatically. Here it is important that if the DSSP entry is added at some stage, the HSSP status goes to "missing unannotated". I.e. we move to Case1.

Something that was not supported is cases where the is more than one parent. So far this is only true for PDB_REDO. Here, I propose:

Case1 mmCIF && PDB && STRUCTUREFACTORS && !PDB_REDO
PDB_REDO status: missing (annotated "." || unannotated)
Case2 mmCIF && PDB && !STRUCTUREFACTORS && !PDB_REDO
STRUCTUREFACTORS status: missing (annotated "." || unannotated)
PDB_REDO status: missing annotated "No STRUCTUREFACTORS"
Case3 mmCIF && !PDB && STRUCTUREFACTORS && !PDB_REDO
PDB status: missing (annotated "." || unannotated)
PDB_REDO status: missing annotated "No PDB"
Case3 mmCIF && !PDB && !STRUCTUREFACTORS && !PDB_REDO
PDB status: missing (annotated "." || unannotated)
STRUCTUREFACTORS status: missing (annotated ".*" || unannotated)
PDB_REDO status: missing annotated "No PDB" "No STRUCTUREFACTORS"

In Case2, Case3, and Case4 we could go to another case in the next update cycle.