Hi everyone,

I am working with Ensembles stable IDs for transcripts (ENSTs) and thought the idea of a stable ID was to point to identical transcripts on different versions of the database in terms of sequence (DNA and protein).

Now I found some ENSTs containing major changes in the sequence on different versions:

**Examples**:

SYNGAP1  ENST00000418600 - lost coding Exon, -58aa, -88bp, based on different Vega transcript:

[ENST00000418600 Ensembl release **78**][1]

[ENST00000418600 Ensembl release **81**][2]

CTDP1 ENST00000299543 - lost coding Exon, -119 aa, -373bp, different annotation method

[ENST00000299543 Ensembl release **75**][3]

[ENST00000299543 Ensembl release **81**][4]

So I have some **questions** arising from this:

1\. What is guaranteed to stay stable for ensembles "stable" IDs (mainly ENSTs)?

All information I could find on this is:

> [Ensembl's stable identifiers are mapped between re-annotation processes using a combination of location based mappings and those generated by Exonerate. The process performs exon based mapping and deriving subsequent identifier mappings based upon these findings][5].

2\. Why is the community using ENSTs without version numbers (which exist), which would guarantee sequence stability (according to [the documentation][6]), while refseq NM_s are usually used with version? Examples:

[CCDS][7], [HGVS][8] (recommending Variant annotation on ENST without version), [Uniprot][9], ...

3\. What stability do refseq stable IDs guarantee? Could you point me to any document defining the stable features I can assume for NM_ respectively versioned NM_?

Thanks for any help!

**Edit**: Reformatted the links and picked better database versions

 [1]: http://Dec2014.archive.ensembl.org/Homo_sapiens/Transcript/Summary?db=core;g=ENSG00000197283;r=6:33420265-33453689;t=ENST00000418600
 [2]: http://Jul2015.archive.ensembl.org/Homo_sapiens/Transcript/Summary?db=core;g=ENSG00000197283;r=6:33420265-33453689;t=ENST00000418600
 [3]: http://Feb2014.archive.ensembl.org/Homo_sapiens/Transcript/Summary?db=core;g=ENSG00000060069;r=18:78077248-78077248;t=ENST00000299543
 [4]: http://Jul2015.archive.ensembl.org/Homo_sapiens/Transcript/Summary?db=core;g=ENSG00000060069;r=18:79681430-79754510;t=ENST00000299543
 [5]: http://www.ensembl.org/info/genome/stable_ids/index.html
 [6]: http://www.ensembl.org/info/genome/stable_ids/versions.html
 [7]: http://www.ncbi.nlm.nih.gov/CCDS/CcdsBrowse.cgi?REQUEST=CCDS&DATA=CCDS34434
 [8]: http://www.hgvs.org/mutnomen/refseq.html
 [9]: http://www.uniprot.org/uniprot/Q96PV0
<p>In the meantime I got a reply from the ensembl helpdesk (there were some problems with reopening the question):</p>

<p><strong>Summarised answer to question 1:</strong></p>

<p>-they consider maintaining the IDs for my two examples wrong, but they never change IDs retrospectively</p>

<p>-they try to be conservative in their mapping in the sense that they try to keep their IDs alive</p>

<p>-I did not get a precise answer on the general question what stability is guaranteed, so i guess you have to expect any kind of change.</p>

<p>So take home message for me is, to never use ENSTs without the version of Ensembl I refer to, or at least the ENST with version number (which should guaratee sequence stability at exon level: <a href="http://www.ensembl.org/info/genome/stable_ids/versions.html">documentation</a>).</p>

<p>Regarding <strong>question 2 </strong>they told me they would discuss making the Version number more prominent on their website, which would make their importance more obvious for the community.(edit: they did in ensembl 85)</p>

<p>Answer to <strong>question 3</strong> from  <a href="http://www.ncbi.nlm.nih.gov/books/NBK50679/#RefSeqFAQ.what_causes_the_version_number">RefSeq FAQ</a></p>

> *What updates to RefSeq records need a simple version number change and which require a new accession number?*

>  The following cases require a simple version change:

 >- the RefSeq record is updated to make minor corrections (e.g., fix mismatches or indels)
 >- the RefSeq record is updated by an end extension or trim in the UTRs but does not add or remove exons or change any splice sites
 >- the RefSeq record is updated by an end extension or trim in the 5’ or 3’ end of the coding sequence and/or UTRs and DOES add or remove terminal exons. In this case, the replaced or updated RefSeq must be completely contained within the other version (i.e., no addition or removal of internal exons or changes to any splice sites).

>    All other cases require the old record to be suppressed rather than updated, and a new record with a new accession number to be created. In addition, RefSeqGene records cannot be updated when the exon definition or protein length is changed.

edit: added answer to question 3 and updated answer 2
