Protein–ligand binding affinity support #9

New Issue

2026-04-12T16:37:18-04:00

aalexmmaldonado commented

2026-04-12 16:37:18 -04:00

(Migrated from github.com)

Binding affinity data — Ki, Kd, IC50, EC50 — is among the most valuable data types for ML in drug discovery. But unlike everything else in pcdigitizer, binding affinities are relational. They describe an interaction between a ligand and a protein target. A single compound identifier isn't enough; you need a target identifier too.

The current architecture assumes one compound per annotation entry. Binding affinity breaks that assumption, which means this issue may require changes to the data model itself.

Scope

Exploration and design

Use PubChemAPI.get_annotations() to find the exact heading names for binding affinity data. Fetch several pages and document the response structure, paying close attention to how target (protein) information is represented. Then propose an output schema in a comment on this issue.

The schema comment should answer three questions. Does the AnnotationEntry contain a protein accession or gene symbol, or only a compound? Do we need a different PubChem endpoint (E.g., BioAssay) to retrieve the protein target? Should the output include both cid and target_accession / target_gene columns?

implementation

Build the processor. Likely output schema: cid, sid, pclid, target_name (String), target_accession (String, nullable), target_gene_symbol (String, nullable), affinity_type (String), affinity_value (Float64), affinity_unit (String), comment (String, nullable).

If this requires extending PubChemAPI to hit additional endpoints, that new endpoint code should be a separate PR merged first.

Definition of done

Phase 1: a design document with real data samples and a proposed schema, reviewed by the maintainer. Phase 2: a working processor with tests.

Binding affinity data — Ki, Kd, IC50, EC50 — is among the most valuable data types for ML in drug discovery. But unlike everything else in pcdigitizer, binding affinities are relational. They describe an interaction between a ligand and a protein target. A single compound identifier isn't enough; you need a target identifier too. The current architecture assumes one compound per annotation entry. Binding affinity breaks that assumption, which means this issue may require changes to the data model itself. ## Scope ### Exploration and design Use `PubChemAPI.get_annotations()` to find the exact heading names for binding affinity data. Fetch several pages and document the response structure, paying close attention to how target (protein) information is represented. Then propose an output schema in a comment on this issue. The schema comment should answer three questions. Does the `AnnotationEntry` contain a protein accession or gene symbol, or only a compound? Do we need a different PubChem endpoint (E.g., BioAssay) to retrieve the protein target? Should the output include both `cid` and `target_accession` / `target_gene` columns? ### implementation Build the processor. Likely output schema: `cid`, `sid`, `pclid`, `target_name` (String), `target_accession` (String, nullable), `target_gene_symbol` (String, nullable), `affinity_type` (String), `affinity_value` (Float64), `affinity_unit` (String), `comment` (String, nullable). If this requires extending `PubChemAPI` to hit additional endpoints, that new endpoint code should be a separate PR merged first. ### Definition of done Phase 1: a design document with real data samples and a proposed schema, reviewed by the maintainer. Phase 2: a working processor with tests.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: data/pcdigitizer#9