Links for _pdbx_refine_tls_group.beg_auth_asym_id

[drlemmus]

The link from _pdbx_refine_tls_group.beg_auth_asym_id to its parent _atom_site.auth_asym_id is commented out. Why? This makes it impossible to edit _atom_site.auth_asym_id without braking the TLS group descriptions.

[epeisach]

I am not sure why it is impossible to edit without breaking anything - that is a software decision to keep things in sync.

I suspect, and I would need to check, is that there were errors in this attribute relative to the parent in the data in the archive. Initially, there was very little checking of TLS records initially. Consider a depositor who created a TLS group for a ligand. This is not advisable, but we have users who do not understand TLS and have done this. The chain id of the ligand might change to match the polymer it is closest to - and now it is incorrect.

About eight years ago, there was an effort to cleanup TLS records - and this might be correct now, but I do not know.

This is why TLS records being identified by a TLS group id will be a better solution in the long run. Residue numbering, name and chain might change - but you will always know which group it is part of.

[pkeller]

I am not sure why it is impossible to edit without breaking anything - that is a software decision to keep things in sync.

That sounds to me like an argument for not having parent links defined in the dictionary at all, and delegating all the integrity checks to other software ;-) Surely it is better to have more integrity defined in the dictionary than less?

Anyway, @epeisach you explained verbally at a VC a while ago what the reason for commenting out these links was. I forget the details, but IIRC it was something to do with water _struct_asym.id values being generated in an invalid way by a specific application, so existing data in the archive couldn't support the way that the links were defined.

[drlemmus]

Anyway, @epeisach you explained verbally at a VC a while ago what the reason for commenting out these links was. I forget the details, but IIRC it was something to do with water _struct_asym.id values being generated in an invalid way by a specific application, so existing data in the archive couldn't support the way that the links were defined.

Let's hope that that application is fixed.

Anyway, the format specification should describe which records are linked otherwise there is no way you can guarantee integrity of the file. I understand that the long term solution may be more straightforward, but I still think things should be uncommented.