Structural Classification of Proteins — extended (SCOPe) is a database of protein structural relationships that extends the SCOP database. SCOP is a (mostly) manually curated ordering of domains from the majority of proteins of known structure in a hierarchy according to structural and evolutionary relationships. Development of SCOP (version 1) concluded with SCOP 1.75, released in June 2009. SCOPe extends the SCOP database, using a combination of manual curation and rigorously validated automated methods to classify many newer PDB structures. Our goal in implementing automation is to extend SCOPe to include structures that can be classified in the SCOP hierarchy, without sacrificing the reliability of the database that was developed through years of expert curation.
SCOPe also incorporates and updates the Astral compendium. Astral provides several databases and tools to aid in the analysis of the protein structures classified in SCOP, particularly through the use of their sequences. Here is a link to more info about Astral. New releases of Astral are derived from SCOPe.
We have rigorously benchmarked our automated methods to ensure that they are as accurate as manual curation, though there are many proteins to which our methods cannot be applied. SCOPe also corrects some errors in SCOP. SCOPe aims to be backward compatible with SCOP, providing the same parseable files and a history of changes between all stable SCOP and SCOPe releases (available on the Stats & History page).
The SCOPe website provides integrated access to data found in all releases of the SCOP and Astral databases that feature stable identifiers.
For backward compatibility, SCOPe entries are arranged in the same hierarchy as SCOP (version 1) entries.
By analogy with taxonomy, SCOP was created as a hierarchy of several levels where the fundamental unit of classification is a domain in the experimentally determined protein structure. Starting at the bottom, the hierarchy of SCOP domains comprises the following levels:
Only the first seven classes are true classes. Because traditionally the aim of SCOP has been to classify every residue in the PDB, the remaining classes were maintained as placeholders to keep track of portions of a PDB structure that were not appropriate to include in SCOP. The SCOPe automated classification methods do not currently add entries to classes other than the first seven.
The multi-domain class is a special class. It contains chains with multiple domains that haven't been observed in a different context.
The figure below shows the number of structures in the PDB and SCOP(e) at the time of each SCOP(e) release. Extended horizontal lines start at the freeze date for each SCOP(e) release and show the number of PDB entries available on that date. (The "freeze date" is the last date for PDB entries to be released and still classified in a given SCOP(e) release. Prior to SCOP 1.73, all protein structures available on the freeze date were manually classified.)
The figure below illustrates how SCOP(e) has changed over the years. The length of the vertical line for each release is proportional to the number of entries classified. The angle of the blue baseline between releases reflects the degree of divergence from comprehensive and fully manually curated releases. The angle is based on the percentage of PDB entries on the freeze date that were not classified in the release, and the extent to which entries were manually classified. The SCOP2 prototype introduces radical changes to the classification scheme, indicated on the figure by reversing the angle [PubMed].
Note that since releases beyond SCOP 1.71 are not comprehensive, not all structurally characterized protein families and folds from the PDB are classified in these releases. Therefore, we caution against using later releases to (for example) analyze the rate at which new folds are being discovered.
SCOP (version 1) is a database that originated in 1994 for protein structure classification [PubMed]. The last version of this database, 1.75, was released in June 2009 and is still available both in Cambridge UK and on the SCOPe website. SCOP 1.75 classifies 38,221 PDB entries.
SCOPe continues the development and maintenance of the classic SCOP hierarchy and may be seen as a continuation of the SCOP database, with ongoing updates and new classifications [PubMed]. SCOPe is completely backward compatible with SCOP (version 1), including all the same parseable files that we previously released separately in SCOP and Astral releases. As of Februrary 2016, SCOPe 2.06-stable classifies 77,439 PDB entries.
SCOP2 represents a marked change from the SCOP classification structure and is currently available as a prototype with only a small number of classified families. SCOP2 replaces the tree-like SCOP hierarchy with a directed acyclic graph, allowing curators to represent structural and evolutionary relationships between proteins in more precise detail. There is no division of proteins into domains with fixed boundaries; instead, node-specific bounaries define the protein regions for each particular relationship [PubMed]. As of February 2016, the SCOP2 prototype classifies 995 PDB entries.
The SCOPe database continues to support the same style of stable identifiers in use since SCOP 1.55. Identifiers are provided as an unambiguous way to link to each a SCOP or SCOPe entry and are stable across releases. See the sections on citing and linking to SCOPe and SCOP using stable identifiers.
sccs. SCOP(e) concise classification string. This is a dot notation used to concisely describe a SCOP(e) class, fold, superfamily, and family. For example, a.39.1.1 references the "Calbindin D9K" family, where "a" represents the class, "39" represents the fold, "1" represents the superfamily, and the last "1" represents the family.
sunid. SCOP(e) unique identifier. This is simply a number that may be used to reference any entry in the SCOP(e) hierarchy, from root to leaves (Fold, Superfamily, Family, etc.).
sid. Stable domain identifier. A 7-character sid consists of "d" followed by the 4-character PDB ID of the file of origin, the PDB chain ID ('_' if none, '.' if multiple as is the case in genetic domains), and a single character (usually an integer) if needed to specify the domain uniquely ('_' if not). Sids are currently all lower case, even when the chain letter is upper case. Example sids include d4akea1, d9hvpa_, and d1cph.1.
Both sunids and sccs identifiers are expected to remain stable across releases, except in cases where the classification changes substantially. For example, when nodes in the hierarchy (e.g. Superfamilies) are merged or split due to new evidence of evolutionary relationships, corresponding identifiers become obsolete and new sunids are introduced. If a domain is split, or the boundaries change substantially, new sid(s) and sunid(s) are assigned.
A history of changes between all consecutive SCOP(e) releases is available under the Stats & History tab, and a history of changes to each individual entry is shown at the bottom of the page describing that entry.
The primary sources of Astral documention are the three references cited above and listed on the Help > References page. The Astral compendium is a collection of software and databases, partially derived from SCOP(e), that aid research into protein structure and evolution. span class="dbsc">Astral provides sequences and coordinate files for all SCOP(e) domains, as well as sequences for all PDB chains that are classified in SCOP(e). Chemically modified amino acids are translated back to the original sequence, and sequences are curated to eliminate errors resulting from the automated parsing of PDB files. Because the majority of sequences in the PDB are very similar to others, Astral provides representative subsets of proteins that span the set of classified protein structures or domains while alleviating bias toward well-studied proteins. The highest quality representative in each subset is chosen using AEROSPACI scores, which provide a numeric estimate of the quality and precision of crystallographically determined structures.
The figure below, taken from the 2004 NAR paper, gives a brief overview of how Astral is created. New releases of Astral are derived from SCOPe domain definitions.
Data flow in Astral: Primary data sources are shown in green. Primary Astral databases are shown in light yellow. Less commonly used resources are shown in darker yellow. Resources added more recently are outlined in light blue/grey. Using the RAF maps, four complete sequence sets are created for every domain in the first seven classes of the SCOP(e) database. Two sets (the genetic domain sets) include the genetic domain sequences described in the 2002 NAR paper, and the other two (the original-style sequence sets) use the prior method of splitting each multi-chain domain into multiple sequences. For each of these methodologies, one complete sequence set is derived from sequences in the PDB ATOM records, and another from sequences in the SEQRES records. The SEQRES sets (for both genetic domain and original-style methods) are used to derive representative subsets. Each set is fully compared against itself using BLAST, and subsets are created using three similarity criteria and various thresholds. Representatives are chosen according to AEROSPACI scores. PDB chain sequence sets are derived from the SEQRES records of every PDB chain in SCOP(e); selected subsets are created at 90-100% ID thresholds. PDB-style files are derived from the RAF maps and SCOP(e) domain definitions. At each new release of Astral, all non-redundant sequences from each SCOP(e) family and superfamily are aligned using MAFFT. A hidden Markov model (HMM) is created from the multiple sequence alignment for each family and superfamily using HMMER. These HMMs, and BLAST, are used to predict domains in the sequences of newly released PDB entries on a weekly basis. HMMs from the Pfam-A database are also used to predict domains in regions of the sequences not identified by HMMs derived from Astral. Unassigned regions of at least 20 consecutive residues are also predicted to be potential domains.
Documentation describing more recent updates (since the 2004 paper) can be found in the release notes, which are linked from the Downloads > Astral Sequences & Subsets page.
The website search bar at the top of each page supports keyword search, as well as searches by a number of different SCOP(e) identifiers.
View the Search examples page for further details on the syntax, as well as many examples.
Thumbnails were generated for each domain using PyMOL, based on a viewing angle for each protein calculated using OVOP (Sverud O, MacCallum RM. 2003. Towards optimal views of proteins. Bioinformatics 19(7): 882-888 [PubMed]).
On the SCOPe website page showing information about each domain, thumbnails are displayed showing the domain in isolation, in the context of its chain, and in the context of its PDB structure. Links to other domains in the same chain, and in the same PDB structure, are below the corresponding thumbnail. To preview thumbnails from these other domains and get tool tip text with a short description, mouse over the links to the other domains. The figure to the right shows the thumbnails generated for the domain d4akea1.
In the interest of scientific reproducibility, when you publish a manuscript or give a talk about data you obtained from SCOP or SCOPe, it's crucial to unambiguously refer to the data you used. Using these citation conventions will provide all the information needed for other researchers to accurately download the same data that you are working with. For related help, see sections on backward compatibility with SCOP, stable releases and updates, and stable identifiers.
When citing a particular SCOPe or SCOP entry, we recommend the following conventions, depending on the level of the entry cited:
Publications using SCOP, Astral or SCOPe data should also cite the appropriate references given under the Help > References menu rather than just referring to the website.
Parseable files have been provided for each SCOP(e) release, available from the Downloads > Parseable Files & Software page. Each of these files has a header, starting with the '#' character, which includes release, version, and copyright information.
The list below shows the four parseable formats for SCOP(e) data. For information on downloading and parsing Astral subsets and RAF sequence maps, see the Astral help.
dir.des.scop(e).txt. - Descriptions for each node in the SCOP(e) hierarchy.
46457 cf a.1 - Globin-like 113449 px a.1.1.1 d1ux8a_ 1ux8 A: ^1 ^2 ^3 ^4 ^5
Five tab-delimited columns:
dir.cla.scop(e).txt - Full classification for each domain.
d1ux8a_ 1ux8 A: a.1.1.1 113449 cl=46456,cf=46457,sf=46458,fa=46459,dm=46460,sp=116748,px=113449 2gtld1 2gtl D:8-147 a.1.1.2 135658 cl=46456,cf=46457,sf=46458,fa=46463,dm=116758,sp=116759,px=135658 d1cph.1 1cph B:,A: g.1.1.1 43831 cl=56992,cf=56993,sf=56994,fa=56995,dm=56996,sp=56997,px=43831 ^1 ^2 ^3 ^4 ^5 ^6
Six tab-delimited columns:
dir.hie.scop(e).txt - Children and parents for each node
0 - 46456,48724,51349,53931,56572,56835,56992,57942,58117,58231,58788 46457 46456 46458,46548 ^1 ^2 ^3
Three tab-delimited columns:
dir.com.scop(e).txt - Human and machine-annotated comments
100067 ! complexed with cyn, hem, xe 63437 ! SQ Q10784 164742 ! automated match to d1s56b_ ! complexed with cyn, hem, na; mutant ^1 ^2 ^3
Two or more "!"-delimited columns:
In order to facilitate use of SCOPe data by SCOP and Astral users, we provide SCOPe data in parseable files in the same formats as the SCOP and Astral databases. SCOPe uses the same stable identifiers (e.g., sunid, sid, sccs) as were used for prior releases of SCOP and Astral, and the same protocols previously used to assign new SCOP and Astral identifiers are also used in SCOPe. A history of all changes between consecutive releases of SCOP and SCOPe is available on the Stats & History page.
Like all previous SCOP and SCOPe releases, SCOPe 2.06 is "stable," meaning the data will not change until the next release (although we will continue to make improvements or bug fixes to the interface).
Our current infrastructure imports and classifies new PDB files on a weekly basis.
Starting with SCOPe 2.02, we are also producing periodic updates that add newly released PDB entries the classification (approximately monthly). These periodic updates add new entries to the current release, without affecting older domains. Sequences for the newly added chains and domains will not be included in the Astral subsets until the subsequent stable release. Periodic releases are named by appending the stable version number with the release date of the periodic release (e.g., "SCOPe version 2.02-2013-06-20"). Stable releases are explicitly labeled stable on the website and downloadable files, (e.g., "SCOPe version 2.02-stable") to avoid confusion in cases where different files representing either a stable release or a periodic update are available.
In addition to making new domains and PDB entries visible through the web interface, the periodic updates also include updated versions of:
Note that these periodic updates will not replace stable releases or the files we make available with each stable version. Because stable releases of SCOPe (and the Astral subsets) are commonly used for benchmarking, we plan to continue producing stable releases as well as periodic updates to those releases. The stable releases will include any changes (such as merging or splitting clades, moving clades, or changes and corrections to domain boundaries) that curators make to the classification.
The most recent periodic release corresponding to each version of SCOPe will be available on the website, in addition to the stable releases. Parseable files corresponding to previous periodic releases are available on request. It is also fairly trivial to reconstruct earlier periodic releases using subsequent ones from the same stable release, since the date when each node was added to SCOPe is shown on the Stats & History page) and also stored in the MySQL database. More recently added nodes never affect earlier ones (all changes are made in the subsequent stable release).
In order to move toward our goal of complete coverage of the PDB, we have re-introduced manual curation of new Folds, Superfamilies, and Families in SCOPe 2.04. We examined and classified structures from the largest Pfam families that were not included in SCOP 1.75. In curating members of the 34 largest unrepresented Pfam families (each with at least 20 structures not previously in SCOP), we added 18 new Folds, 25 new Superfamilies, and 47 new Families to SCOPe 2.04. Aided by improvements to our automated curation method, we increased the fraction of classified PDB structures from 65% in SCOPe 2.03 to 68% in SCOPe 2.04.
Manual curation in SCOPe is performed by John-Marc Chandonia. Dr. Chandonia has reviewed Alexey Murzin's annotations since 2001 as part of the Astral build process, including dialog regarding manual classification errors. He has followed the same conservative principles as Dr. Murzin in deciding whether to annotate newly structurally characterized proteins as homologous to prior structures. We also invite collaborations with experts in particular superfamilies; if you would like to help us update part of the SCOPe hierarchy, please contact us at firstname.lastname@example.org.
The figure below shows four examples of new Superfamilies and Families added in SCOPe 2.04:
The vast majority of new protein structures solved represent a new experiment on a protein that was already structurally characterized (Chandonia and Brenner, 2006, available under the Help > References menu). Our goal in implementing automation is classify structures that can be reliably classified in the existing SCOP hierarchy, without sacrificing the reliability of the database, which has been maintained through years of expert curation.
We introduced a new automated assigment protocol in SCOPe 2.01 (described here), which classified only single-domain chains, and extended it in SCOPe 2.03 (described here) to classify some multi-domain chains.
Starting with SCOPe 2.04, we modified some of the parameters in the 2.03 method in order to classify more chains. The list of changes from the previous version is:
To ensure that these changes would not increase our error rate, we applied the same tests described in the Benchmarking section, below.
The updated procedure is described next. The figure below, taken from , shows an example application of the method:
Description of Method:
We first create a BLAST database containing the SEQRES-based sequences for each domain in SCOPe. Then, for each newly released PDB chain, we BLAST its SEQRES sequence against the domain sequence database. BLAST performs local alignment, returning the start and end of the alignment (the hit) for the query sequence and the target sequence, as well as the E-value. We collect only the BLAST alignments where the E-value is at least as significant as 10-4 and the alignment covers most of the target domain (defined as missing at most 10 residues from each end). We group the alignments by the PDB chain to which the targets belong and rank the groups by the total number of residues covered by the hits on the query chain. We then use the top-ranking group of BLAST-based alignments to annotate domains in the query sequence. If the BLAST boundaries are outside the observed residues in the query chain, the assigned SCOPe domain is shortened to include only observed residues.
The boundaries are then extended by applying two methods. If the nearest PDB chain end or gap in ATOM records is within 15 residues of an alignment end, we extend the domain to include these residues. If a region between two alignment ends is 10 residues or shorter, we extend the two domain boundaries to fill the region. The purpose of extending the BLAST hit is to classify every observed residue (i.e., one with ATOM records) in the chain; the 15-residue limitation makes it very unlikely that the extension will include a new domain. Any longer gap between BLAST alignments or chain ends results in the chain being put on hold to await manual classification.
After making predictions for each chain, we apply some criteria to determine whether each domain prediction was high-confidence (i.e., sufficiently accurate to be included in SCOPe without further manual inspection). We first verify that each chain contains no domains that are homologous to genetic domains classified in SCOP (due to the difficulty of correctly automating predictions that include multiple PDB chains). In cases where an entire PDB chain was predicted to be a single SCOPe domain, we verify that the target domain also comprised its entire PDB chain. In cases where a PDB chain was divided into multiple domains, we verify that there are no regions in the ATOM records of the chain that are both longer than 10 residues and not assigned to any domain.
To fully classify domain predictions in the SCOPe hierarchy, we also had to assign levels below Superfamily. In our benchmarking, we found that the following rules could be used to reliably assign those levels:
In cases where the protein or family could not be reliably matched to an existing SCOP clade, we created a new group called "automated matches" at the Family or Protein level. These are not true families or proteins, because the domains within each one are not as similar to each other as members of manually curated families and proteins. For example, assignment to an "automated matches" family means the domain could reliably be assigned to the parent superfamily, but could not be automatically assigned to one of the existing families with 100% confidence. Manual curation or future improvements in automation may allow us to re-assign these domains with greater specificity. New SCOPe Species nodes were created if the PDB species annotation did not match any existing SCOP species.
To facilitate the mapping of SCOPe Species nodes to PDB species annotations, we attempted to make the descriptions of SCOPe species-level nodes more consistent, e.g., by always using the same common name for a species, and by updating NCBI taxonomy ids that have changed. This resulted in 1,520 species nodes being updated between SCOP 1.75 and SCOPe 2.01. The sunids for these nodes did NOT change, since each refers to the same species as before.
To validate the automatic classification method, we performed benchmarking against all SCOP releases with stable identifiers (i.e. releases 1.55-1.75). All PDB entries that were added between each pair of consecutive releases were automatically classified based on the earlier release and compared with the manually curated domains in the subsequent release. A predicted domain was considered identified and classified correctly if:
We have taken a very conservative approach to applying automated classification, in order to ensure that our methods are as accurate as manual curation, even though there are many proteins to which our methods cannot be applied. This means that our automated methods were tuned until they produced zero errors relative to manual curation. In fact, benchmarking revealed some previous errors in manual curation, which we corrected in SCOPe.
Over the course of benchmarking, we uncovered a number of errors in domains in SCOP. These were then manually corrected. We detected errors in 70 manually curated domains by running benchmarking and manually inspecting predicted domains that did not sufficiently match the manually annotated domains. These errors in domain boundaries in multi-domain chains were manually fixed in SCOPe 2.03. We also detected and fixed inconsistencies in 5,054 domains that had been predicted and classified with the SCOP 1.73 automated method. We review some of the types of errors detected.
The figure below, taken from , shows four examples of domains with incorrect boundaries that were corrected in SCOPe releases:
We are continuing to upgrade the website. Planned features include more sophisticated search functionality (including searches by sequence and by structure), use of AJAX to avoid full page reloads, and a SCOPe tree browser for more efficient display of results. We also plan to allow downloads of additional derived data (e.g., sequence sets and HMMs) for different clades in the tree.
Please report bugs and usability issues to us at email@example.com.