This guide covers importing a peptide dataset from a HELM file (CSV/Excel) or an SDF, supplying a monomer library, and configuring peptide-specific options.
The Peptide dataset type is only available when the peptide plugin is enabled for your organization. If you do not see it, contact your administrator.
Step 1: Open the New Dataset wizard
From the Home page, click the Create Dataset card (or New → Create Dataset in the left navigation). The New Dataset wizard opens with three steps: Dataset Information, Properties Configuration, and Import Status.
Step 2: Choose the Peptide dataset type
Under Dataset Type, select Peptide.
Then choose the target Project and the Dataset File.
Accepted file formats for peptides:
| Format | Notes |
|---|---|
CSV / Excel (.csv, .csv.gz, .xlsx) |
Tabular files with an identifier column and a HELM column; every other column becomes a property. HELM references monomers by symbol only, so a monomer library is needed for any monomer not already in the Biotoolkit Monomer Service. |
SDF (.sdf, .sd, .sdf.gz, .sd.gz) |
A V3000 SDF that carries the peptides and a monomer template for each monomer. The embedded templates are used to register any missing monomers on the Biotoolkit Monomer Service, so no separate monomer library is needed. |
Use the Download peptide dataset templates links (CSV / Excel) in the dialog to start from a correctly formatted file. The template's columns are ID, HELM and three example property columns, so a minimal row looks like PEP001,PEPTIDE1{A.G.K.L}$$$$.
Step 3: Supply a monomer library (CSV/Excel imports only)
A Monomer Library File maps each monomer symbol to its chemical structure so Ideation can register monomers that are not yet in the Biotoolkit Monomer Service. It is needed only for CSV/Excel (HELM) imports — HELM references monomers by symbol without carrying their structures — and the picker appears only for those files.
The notice above the picker sums up how the upload relates to the Biotoolkit Monomer Service:
- Monomers live in the Biotoolkit Monomer Service. If every monomer of your dataset is already registered there, you do not need a library file at all.
- Only the monomers your dataset actually uses are registered from the file. A shared library of thousands of monomers is fine: the rows your HELM sequences never reference are skipped, and skipping them is not reported as a problem.
- You can also upload the same file directly in the Biotoolkit Monomer Service app — the notice links to it — instead of attaching it here.
It can be a CSV, Excel, or SDF file, and it uses the same field names as the Biotoolkit Monomer Service import template — so a library file written for the Biotoolkit Monomer Service imports into Ideation unchanged, and vice versa.
| Field | Required | What it holds |
|---|---|---|
symbol |
yes | The symbol the HELM sequences use. |
smiles |
one of | The structure as SMILES, with numbered attachment points — C[C@H](N[*:1])C([*:2])=O. |
ctab |
one of | The structure as a connection table. For an SDF, the molfile itself is the structure and no ctab field is needed. |
name |
no | Falls back to the symbol. |
polymer_type |
no | PEPTIDE or CHEM. Inferred from how the dataset's HELM uses the monomer when absent. |
monomer_type |
no | Backbone or Undefined. |
natural_analog |
no | The natural amino acid the monomer stands in for. |
rgroups |
no | The attachment points and their cap groups, as R1:H;R2:OH. Derived from the structure when absent. |
R1, R2, … |
no | The same declaration spread over one column per attachment point, each holding its cap group (H or OH) — the way some registration systems export it. Ignored when rgroups is also stated. |
author |
no | Accepted for compatibility with the Biotoolkit Monomer Service template; not stored. |
Each row needs a symbol and a structure — either smiles or ctab. Columns Ideation does not know are ignored, so extra columns are never a reason for a file to fail.
Field names are matched on their letters only: natural_analog, Natural Analog and NaturalAnalog all name the same field, whatever the casing or the separator. Exports from a registration system that writes CamelCase headers therefore import as they are.
A row Ideation cannot read — an unknown polymer type, a row with neither smiles nor ctab, a SMILES whose attachment point carries no R-number when no ctab is there to fall back on — is skipped and reported, while every other row imports. Skipped rows appear in the dataset's import issues dialog, under Monomers not registered, as Monomer "X" (library row N) with the reason, but only when a peptide of the dataset actually uses that monomer; the peptides built from it are listed under Peptides imported with missing data as missing that monomer. A row that reads fine but that the Monomer Service refuses — invalid chemistry, a structure already registered under another symbol — is reported the same way, with the service's reason. Two smaller problems cost less than the row: an unreadable rgroups or R1… declaration is ignored and the cap groups are derived from the structure instead, and an unusable smiles is dropped when the row also carries a ctab, which then provides the structure. Both are recorded in the server log only.
polymer_type, monomer_type and rgroups are the fields Ideation can work out on its own — but when your file states them, your values win over what Ideation would have derived from the structure. That is what lets you register a monomer whose structure carries no usable attachment-point labels; it also means an incorrect value registers an incorrect monomer, so state them only when you mean to.
Files written against the previous Ideation template keep working: the old spaced Natural Analog header is still accepted (see the matching rule above), CTAB still matches, and the now-obsolete Short Name column is simply ignored.
For SDF dataset imports you do not provide a monomer library. A V3000 SDF already embeds a monomer template for every monomer, and those templates are used to register any missing monomers on the Biotoolkit Monomer Service automatically — which is why the picker does not appear for SDF files.
Step 4: Configure peptide-specific options
Click Next. On the Properties Configuration step, a Peptide Specific Configuration section appears:
- HELM Column — the column that holds the HELM sequence notation (tabular imports only; auto-detected when named
HELM). - Reference Peptide — the peptide used by default as the basis for SAR slides created from this dataset. You can change it later per report.
Select and configure at least one main property, then submit.
Step 5: Watch the import
The final Import Status step shows the peptide import timeline:
Initializing → Registering Monomers → Parsing Peptide Sequences → Generating Alignment → Ready
- Registering Monomers runs when a monomer library was supplied, or when the dataset is a V3000 SDF (whose embedded monomer templates are registered on the Biotoolkit Monomer Service).
- Generating Alignment computes a position-by-position alignment from the dataset's own sequences, so the dataset arrives ready to build a SAR Slide from — no alignment file needed. It is saved as an alignment named Default alignment.
When the dataset reaches Ready, it opens on the dataset page.
Registration only adds monomers that are new to the Biotoolkit Monomer Service. Monomers whose symbol already exists there are used as-is and are never overwritten or updated — so a library or SDF cannot change a monomer that other datasets already rely on. The service also runs a duplication check on structure: if the same monomer is already registered under a different symbol, it is matched to that existing entry (as an alias) rather than registered again.
If it cannot run, the import still succeeds and the dataset simply has no default alignment. It is skipped for datasets with no HELM sequences and for datasets above 5,000 peptides. See How to Align Peptides.
If some peptides reference monomers that could not be resolved, they are imported with their HELM sequence preserved but without full structure or properties, and the dataset is flagged with an amber import issues warning that lists them under Peptides imported with missing data. See How to Resolve Missing Monomers.
Step 6: Read the dataset table
The dataset page lists one row per peptide. Besides your own properties, a peptide dataset carries these common columns:
| Column | Shown by default | What it holds |
|---|---|---|
| ID | yes | The primary identifier. |
| Backbone Sequence | yes | The peptide drawn as its sequence of monomers. |
| Num Monomers | yes | How many monomers the HELM declares. |
| Num Atoms | yes | Atom count of the converted structure. |
| Molecular Weight | yes | Computed from the converted structure. |
| HELM | yes | The HELM notation as imported. |
| Canonical SMILES | no | Canonical SMILES of the whole peptide, computed from the converted structure. |
| Inchi Key | no | InChIKey of the whole peptide, computed from the converted structure. |
| Missing Monomers | when needed | The unresolved symbols of a peptide imported without its structure; the column exists only while something is unresolved. |
Tick Canonical SMILES and Inchi Key in Table settings › Columns to show them; they start unticked because they are long identifiers you copy rather than read. Both are empty for a peptide whose structure could not be converted, and for peptides imported before this release until you run Sync monomers (see How to Resolve Missing Monomers).
The row menu (the list icon in the Actions column of a row) offers Create SAR Slide with that peptide as reference, and copies to the clipboard: Copy HELM, Copy CTAB v2000, Copy CTAB v3000, Copy Canonical SMILES and Copy InChIKey. A copy is disabled when the peptide has no such value.