Peptide datasets, alignments and reports refer to monomers by symbol. When a monomer changes or disappears, everything built on it is affected. This article explains how the service keeps a history, what it records and what it deliberately leaves out, and why deleting a monomer is reversible.
Every monomer carries a version number
A monomer is created at version 1. The number increases each time a material change replaces its definition, and the state being replaced is archived. The Version column of the Home report shows the current number; the Version Log shows the archived states.
The version number answers a practical question: a peptide whose properties were computed against MeNle version 1 was computed with a hydrogen on the C-terminal attachment point, and one computed against version 2 with the hydroxyl that makes it an acid. Downstream tools can compare the number they recorded with the current one to know whether a recomputation is due.
What counts as a material change
A change is material when it alters what the monomer is in a sequence. Six things do:
- the symbol;
- the polymer type;
- the monomer type;
- the natural analog;
- the structure, compared on its canonical form;
- the attachment points: their labels, their kind, or their cap groups.
Everything else is cosmetic and is not versioned: the name, the author, the stored drawing, the audit dates. Redrawing the same molecule from a different SMILES, with different 2D coordinates or a different atom order, is not a change either. The service compares canonical structures, so only a different molecule counts.
This keeps the history meaningful. A log where every regenerated image is a version would bury the one edit that matters, the cap fix, under noise.
Deleting archives, it does not erase
Deleting a monomer removes it from the library and writes its full state to the archive with the reason DELETED. That archived state is the tombstone. It carries the symbol, the classification, the structure, the drawing, the author, and a copy of the organisation-specific data that the deletion cascaded away: the monomer's metadata rows and, on a forced deletion, its monomer-set memberships.
An Administrator can then revive the monomer from the Version Log. It comes back under its original identifier, so references that stored the identifier resolve again, with the next version number, its original creation date, and its metadata and memberships restored. See How to Review a Monomer's Version History.
A deletion is refused while the monomer belongs to a monomer set, unless it is forced. The refusal lists the sets, so that a curator removes the monomer from them knowingly. A forced deletion records the memberships in the tombstone so that a revive can put them back.
Two things prevent a revive:
- Its place has been taken. A live monomer now holds the same symbol, the same name or the same structure for that polymer type. The service refuses rather than create a collision; rename or remove the newer monomer first.
- It is public. Public reference data is maintained through service releases, never through deletion and revival. See Public Monomers.
A deleted monomer is remembered at registration
When you register a monomer whose symbol or structure matches a deleted one, the registration is held:
Registering 'Deg' corresponds to 1 deleted monomer (2504). Nothing was written. An administrator can revive the archived monomer under its original id, or the registration can go ahead once the correspondence has been judged.
The service does not decide for you whether this is the same monomer coming back or a new one that happens to share a name. Ask an Administrator to revive the deleted monomer, which restores it under its original identifier so that data still pointing at it resolves again.
The duplicate rules proper, which refuse rather than hold, apply between live monomers only. See Canonical SMILES and Duplicate Detection.
Who changed it
The Version Log records the account that performed the archiving. For a deletion made in the application that is the signed-in user. For an edit or a bulk import it reads System: the change is applied by the Biotoolkit service on the user's behalf. The File History of the import page is where the person behind an import is recorded.
Related
- How to Review a Monomer's Version History: reading the log and reviving.