Discuss a possible BindingInterface object and its relationship to BindingSite and TopoMT

Open
#112 23 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
20/100
Issue type
Feature
Clarity
Clearly specified
Activity status
Active
Tech stack
python

Research direction

Start with the BindingSite design and scientific scope documents linked in the issue, then read TopoMT’s accepted conceptual contract and the referenced review threads. The work is to resolve the listed scientific and ownership questions in an agreed decision record, including representative records or API sketches. Done means the record decides whether a new BindingInterface contract is needed and defines its relationships, guarantees, ownership, and follow-up work.

Written by the indexing model from the issue text.

Description

component:molsysmt component:peptidemt component:pharmacophoremt component:topomt needs-triage proposal

Origin and discussion request

This proposal comes from the development of PeptideMT, following the BindingSite discussion in #111 and our consumer contribution.

Please discuss whether BindingMT needs a public scientific entity or result called BindingInterface, how it should relate to BindingSite, and how it should compose with TopoMT's existing interface concepts.

TopoMT should be a principal participant in this discussion. Its accepted model already includes participants, interface associations, spatial realizations and contextual evaluations. The goal is one coherent set of scientific meanings, with clear ownership and no competing definitions or independently editable interface registries.

This is a scientific and architectural discussion request, not a decision to introduce a new class or a commission to implement it. A justified conclusion that existing contracts and composed operations suffice is a valid outcome.

Scientific distinction proposed for review

Concept Proposed meaning Important qualification
BindingSite A contextual declaration of a region associated, or hypothesized to be associated, with molecular recognition The partner, pose or spatial realization may be unknown; a site may span several receptor subunits
Interface association A declared or inferred relationship between specified participants, with an explicit criterion, context and evidence Registering endpoints alone does not establish an inferred interface or biological binding
Interface realization Available localization of that association: participant-facing patches, contact boundaries, intervening regions or other supported geometry An association can be unlocalized; several realizations can belong to it; neither a cavity nor a recoverable volume is mandatory
Possible BindingInterface A binding-domain entity or characterization result composing the association, available realizations and relevant molecular observations Its additional scientific responsibilities must justify a distinct contract beyond existing owner results

A contact footprint on one participant can support a derived binding-site declaration. It does not automatically identify the complete functional site. Contact membership, buried-surface membership and topographic support retain their different definitions.

A geometric or crystal-packing interface is not automatically a biologically functional binding interaction. Hypothesis, observation, interpretation and supporting/challenging evidence remain distinguishable. A negative observation for one partner does not establish that the region cannot bind another partner.

Participant profiles, grouping and multimolecular associations

A general contract should accommodate profiles such as small molecule–peptide, small molecule–protein, peptide–protein, protein–protein, protein–protein–protein and DNA–protein, with other supported combinations admitted explicitly.

These describe participants; they should not require a separate class for every combination or imply that a particular numerical provider supports the profile. Keep molecular identity/type, contextual role and participant grouping separate. Peptide/protein labels should not silently depend on one universal length threshold. The granularity of a participant—molecule, chain, domain or explicitly selected group—also needs a declared policy using owner-supported molecular selections.

The multimolecular case needs particular care:

  • A complex A–B–C can contain separate binary interfaces A–B and B–C.
  • It may contain a localized interface involving all three participants.
  • C may recognize a composite site formed by A and B, making (A+B) | C a meaningful grouping for the binding question.

Complex composition, interface arity and the number of sides/groups in an analysis are different facts. Preserve the selected interpretation and criterion. Pairwise projections or sums of pairwise descriptors must not silently stand for a joint or cooperative association.

A site spanning receptor subunits is not automatically identical to either the subunit interface or the interface between the receptor assembly and its ligand.

Relationship between sites and interfaces

We propose composition and explicit references as the starting point:

  • A site may participate in several interface occurrences.
  • An interface may relate to several sites, candidate hypotheses or criterion-dependent footprints.
  • A site may contain views derived from an interface, retaining the originating participants, criterion, context and evidence.
  • Different partners or poses can involve the same general functional region while producing different interface observations.
  • Functional annotation identity, contextual occurrences and correspondence between them remain separate.

We would not initially model Interface as a BindingSite subclass, define it as the union of two sites, or expand BindingSite into a container for the entire complex and its characterization. The complete relationship requires more than two regional memberships.

Object-model alternatives to evaluate

  1. Reuse TopoMT interface contracts through BindingMT operations. This may suffice if the existing association/realization model expresses the binding questions and their context. Identify any actual gap before creating another entity.
  2. Introduce a BindingMT BindingInterface result by composition. This could be justified by additional responsibilities such as identifying the binding question and molecular states, associating owner-provided observations, and preserving interpretation/applicability. Reference existing TopoMT/MolSysMT results rather than duplicate their geometry, relation or analysis implementations.
  3. Extend BindingSite to represent the complete interface. We currently favor distinct concepts because their identities, dependencies and scientific questions differ. Nevertheless, review whether shared views or abstractions are useful without forcing a common inheritance hierarchy.

A new object should have a demonstrable public scientific purpose. Naming symmetry or merely collecting existing objects is insufficient justification. Conversely, a useful binding-domain result should not be excluded solely because some of its observations originate in TopoMT.

Ownership and existing work

Concern Relevant owner
Binding questions, BindingSite and binding-domain characterization BindingMT
Topographic participants/relations, interface associations/realizations, support, classification and contextual evaluations TopoMT
Molecular identity, chemistry, selections, correspondence, generic contacts/interactions and molecular surface observables MolSysMT
Pharmacophoric hypotheses and feature semantics PharmacophoreMT
Consumer scientific question, permitted information, selection and interpretation PeptideMT or another consuming researcher/component
Shared meanings, compatibility and coordinated adoption MolSysSuite

These boundaries should guide review rather than predetermine the placement of every proposed field. In particular, retain TopoMT's existing authority over its association/realization model. Agree how a possible binding-domain result references that model before introducing another canonical relation owner.

Relevant starting points:

Questions to resolve before selecting an implementation

  • What additional scientific promise would BindingInterface provide beyond TopoMT's interface contract? Which public operation needs it?
  • Which owner maintains each authoritative definition, identity and relation? Can consumers use the existing contract directly?
  • Which observations belong to the association, a particular realization or a separate characterization?
  • How are participant granularity/grouping, assembly/symmetry, pose, chemical state and coordinate context represented?
  • How are site-to-interface correspondence and criterion-dependent footprints recorded, including many-to-many relationships?
  • How do partial mapping, reduced chemistry and unavailable geometry affect individual operations while preserving useful declarations? Generated atoms and changed coordinates must not automatically inherit original membership, evidence or model confidence.
  • How do changes create new contextual results without rewriting historical evidence, and what guarantees does each application actually check?
  • How can portable, source-addressed references support interoperability without mandatory reverse dependencies or automatic engine execution?

TopoMT and MolSysMT should not need to import BindingMT to perform their native analyses. An unlocalized declaration should not require a live topographic engine merely to retain an honest binding question. Exact typed/record handoffs require owner agreement.

Interface geometry, contact counts, buried area and energetic descriptors retain their original definitions. None implicitly becomes biological binding evidence or an intrinsic binding free energy assigned to a geometric patch. Thermodynamic questions retain their full molecular/state/condition and method context.

Suggested discussion outcome and examples

Please produce an agreed decision record that:

  • Defines the distinctions and relationships between binding sites and interfaces, with counterexamples.
  • Decides whether BindingMT needs a new entity/result or composed operations over existing contracts suffice.
  • Identifies the minimum useful public contract, scientific guarantees, owner boundaries and dependency direction.
  • Provides small representative records or API sketches for a binary interface, a composite receptor site, separate pairwise interfaces in a ternary complex, a genuinely joint association and incomplete/unlocalized information.
  • Demonstrates how footprints and observations stay tied to the original participants, context, criterion and producer, without promoting geometric evidence into a stronger binding claim.
  • Routes shared meanings/adoption through MolSysSuite and links concrete follow-up work in the existing owners.

These can begin as synthetic/saved-data examples rather than a new scientific campaign. MDM2–p53 can illustrate one consumer workflow, while the public design remains applicable across molecular modalities and selects no new case chemistry, site membership or measurement cutoff.

This discussion should remain independent of the useful initial BindingSite delivery under #111 unless a concrete incompatibility is found. Implementation, qualification and scientific application would follow through separately agreed, bounded work. No new runtime class, provider, molecular calculation or release is commissioned by opening this discussion.

Dominant language
Python
Stars
1
Forks
0
PR merge metrics
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from uibcdf/dockingmt

All issues in uibcdf/dockingmt

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.