What Are ELM Classes and ELM Instances in the ELM Database?

An ELM class is the reusable definition of a eukaryotic linear motif — a pattern describing a functional site in proteins. An ELM instance is a concrete, documented occurrence of that class in a specific protein. In short: the class is the rule, the instance is a verified example of the rule being used. You need both concepts to search the ELM resource effectively, because the database is organized around them and lets you browse either level.

The class: a motif definition

A class captures what the motif looks like and what it does. It is the abstract entry — the pattern, the functional site type, and the associated annotation — rather than any single protein.

Classes are named with a structured prefix that signals the motif's role. From the ELM release notes, you can see prefixes such as:

• LIG_ — ligand-binding motifs (for example LIG_SH3_PxxxRxxKP_6)
• DOC_ — docking motifs (for example DOC_PP2B_LxvP_1)
• DEG_ — degradation motifs (for example DEG_Cend_DCAF12_1)
• MOD_ — modification motifs (for example MOD_AAK1BIKe_LxxQxTG_1)
• TRG_ — targeting motifs (for example TRG_NESrev_CRM1_2)

The suffix encodes the interacting partner and a version number, so LIG_SH3_PxxxRxxKP_6 is the sixth defined class of an SH3-binding ligand motif with that pattern.

The instance: a documented occurrence

An instance is where a class meets a real protein. It records that a specific protein contains a match to the class pattern, together with the evidence supporting it. When the ELM release notes say a class was "revised with ~70 new instances," that means 70 additional protein occurrences were added to the evidence base for that motif definition.

This distinction matters because a class can exist with many instances, few instances, or be newly defined and still accumulating them. Instance counts are therefore a rough signal of how well-characterized a motif type is.

How the two levels relate

The homepage illustrates the link directly: it highlights "PDB-Structure 2IWP showing a peptide from ELM class LIG_PDZ_Class_1" — the class is the definition, and the structure is a specific instance of it.

Why the database separates them

Separating definitions from occurrences lets you ask two different questions:

• "What kinds of linear motifs exist?" — browse or search ELM classes.
• "Which proteins actually contain this motif, and what's the evidence?" — look at ELM instances.

It also keeps the resource maintainable. A single class can be updated once and gain many instances, as in the release notes where MOD_PIKK_1 was updated with 18 new instances, or where nine new classes were released alongside roughly 70 new instances across five revised classes.

Practical implications when you use ELM

• If you are scanning a protein of interest for known motifs, you are working at the instance level — matching your sequence against class definitions.
• If you want to understand a motif's consensus pattern, interacting domain, or pathway context, you are working at the class level.
• Class names change over time. The release notes record renamings, such as LIG_TRAF2_1 becoming LIG_TRAF2like_MATH_shPxQ_1, so cite the current class name when referencing a motif.
• The database also maintains candidate classes and candidate instances separately from validated ones, so check which category an entry belongs to before treating it as established.

For large-scale work, the ELM resource points to gget elm for running queries locally rather than through the web interface.