[ensembl-dev] GRCh37 Protein sequence has asterisks

Tue Dec 5 14:27:46 GMT 2017

Hi Will,

I understand why the output sequence might differ, but it’s currently giving nonsensical output such as:

>NP_002417.2
MKFLLILLLQATASGALPLNSSTSLEKNNVLFGERYLEKFYGLEINKLPVTKMKYSGNLMKEKIQEMQHFLGLKVTGQLDTSTLEMMHAPRCGVPDVHHFREMPGGPVWRKHYITYRINNYTPDMNREDVDYAIRKAFQVWSNVTPLKFSKINTGMADILVVFARGAHGDFHAFDGKGGILAHAFGPGSGIGGDAHFDEDEFWTTHSGGTTCSSLLFTRLAIP*VLAILVIQRP*CSPPTNMLTSTHFASLLMTYVAFSPCMETQKRTNACQILTIQNQLSVTPI*VLMLSLPWEIRSFSSKTGSSG*RFLRDQRPVLI*FLPYGQPCHLALKLLMKLKPEIKFFFLKMTNTG*LAI*DQSQIIPRAYILLVFLTL*KKLMQLFLTHVFIGPTSL*ITSIGGMMKGDR*WTLVIPN*LPRTSKESGLKLMQSSTLKTNTTISSKDLTNLNMTSYSNVSPKH*KAIAGLVV

I didn’t realise there was a problem until some time later when downstream tools complained about asterisks in the protein sequences. As a user of the API, I expected to get the RefSeq sequence, though I now understand that is more complex. Instead, a warning that I was retrieving a sequence that was dubious, or at the very least that I have stop codons in my sequence would have been very helpful. In hindsight I should have checked that the sequence only consisted of expected one letter code characters, but it’d be prudent to warn users in cases like this.

Thank you to you and Alessandro for your help. I don’t mean to sound ungrateful; these are just some suggestions for how the API could be made more useful and/or less prone to misuse.

Kind regards,
Luke

From: William McLaren <wm2 at ebi.ac.uk>
Date: Tuesday, 5 December 2017 at 14:09
To: Ensembl developers list <dev at ensembl.org>, Alessandro Vullo <avullo at ebi.ac.uk>, Luke Goodsell <l.goodsell at achillestx.com>
Subject: Re: [ensembl-dev] GRCh37 Protein sequence has asterisks

The otherfeatures DB contains a direct import of the GFF gene model files distributed by NCBI, i.e. the coordinates only.

When you request a RefSeq transcript object from the otherfeatures DB as you did in your API code, the API uses sequence from the mapped region of the reference genome to construct the transcript model. This is then translated to produce the protein sequence.

If there are differences between the RefSeq model and the genome, then this translation process may give rise to invalid sequences.

VEP accounts for this by modifying those extracted regions of reference sequence so that they match the original RefSeq model; this accounts for both equal length substitutions and insertions and deletions that might introduce frameshift changes.

Will

On 5 December 2017 at 1:13:25 pm, Luke Goodsell (l.goodsell at achillestx.com<mailto:l.goodsell at achillestx.com>) wrote:
Thanks, Will, those look like very useful tools.

I still think it’d be good to make sure the otherfeatures DB is accurate, but those tools address our immediate needs.

Kind regards,
Luke

From: William McLaren <wm2 at ebi.ac.uk>
Date: Tuesday, 5 December 2017 at 12:23
To: Alessandro Vullo <avullo at ebi.ac.uk>, Ensembl developers list <dev at ensembl.org>, Luke Goodsell <l.goodsell at achillestx.com>
Subject: Re: [ensembl-dev] GRCh37 Protein sequence has asterisks

VEP can do this for you with the ProteinSeqs plugin [1]. I did not recommend it initially as I supposed you might be extracting sequences genome-wide.

The plugin generates two files, reference.fa and mutated.fa, containing one mutated sequence *per variant*. The sequences should be accurate WRT to the modifications made via the BAM files. I can’t say from experience how well this plugin will perform on a genome-wide analysis; you could expect that the resultant FASTA files would be very large at least.

The plugin does not currently support outputting cDNAs or CDS, but it would be fairly straightforward to add this functionality to the plugin.

Note that if you wish to incorporate the effects of multiple variants together, you can look into using VEP’s sister tool Haplosaurus [2]; this can output CDS and protein sequences in its JSON format output.

Cheers

Will

[1] https://github.com/Ensembl/VEP_plugins/blob/release/90/ProteinSeqs.pm
[2] https://github.com/Ensembl/ensembl-vep#haplo

On 5 December 2017 at 12:05:41 pm, Luke Goodsell (l.goodsell at achillestx.com<mailto:l.goodsell at achillestx.com>) wrote:
Thanks, Will,

Unfortunately, I cannot find cDNA from RefSeq – their sequences contain UTRs. Is there an easy way to identify the start and stop codons? The longest ORF is not always the correct one, unfortunately.

Incidentally, being able to get the sequences used by VEP is very important for us; we’re trying to construct the new protein sequences that result from variants using consequence information annotated by VEP. We’d very much appreciate the corrected sequences being incorporated into the otherfeatures database as soon as possible.

Kind regards,
Luke

From: William McLaren <wm2 at ebi.ac.uk>
Date: Tuesday, 5 December 2017 at 09:15
To: Luke Goodsell <l.goodsell at achillestx.com>, Ensembl developers list <dev at ensembl.org>, Alessandro Vullo <avullo at ebi.ac.uk>
Subject: Re: [ensembl-dev] GRCh37 Protein sequence has asterisks

Hi Luke,

There is no straightforward way to do this via Ensembl at the moment; I’d suggest you download the relevant files from NCBI.

The BAM files we use are obtained from ftp://ftp.ncbi.nlm.nih.gov/refseq/H_sapiens/H_sapiens/GRCh37.p13_interim_annotation/; it seems there’s a protein and rna FASTA file in there which may have what you need.

Otherwise you may find what you need in the parent directory ftp://ftp.ncbi.nlm.nih.gov/refseq/H_sapiens/H_sapiens. I’m not familiar with NCBI’s FASTA layout so you’d have to investigate yourself!

Regards

Will McLaren
Ensembl Variation

On 4 December 2017 at 5:55:38 pm, Luke Goodsell (l.goodsell at achillestx.com<mailto:l.goodsell at achillestx.com>) wrote:
Hi Allessandro,
Is there a way to extract the BAM-edited sequences? I'd simply like to get FASTA files of the RefSeq cDNA and proteins as used by VEP.
Kind regards,
Luke

From: Alessandro Vullo
Sent: Monday, 4 December, 17:44
Subject: Re: [ensembl-dev] GRCh37 Protein sequence has asterisks
To: Ensembl developers list, Luke Goodsell

Hi Luke, The problem is likely to depend on RefSeq differing from the reference. Are you using VEP and then retrieving the sequence as annotated by it? Quoting the relevant people (VEP): "VEP uses BAMs to correct RefSeqs that differ from the reference, and without those the API can give incorrect translations. This will hopefully be fixed in future when the SeqEdit objects that VEP creates from the BAMs are incorporated directly into the otherfeatures DB." Hope that helps, Alessandro
This e-mail message contains confidential information intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail and then delete and discard all copies of the e-mail. We have taken all reasonable precautions to check this e-mail and any attachments for viruses, but we cannot accept any liability for any damage sustained as a result of any virus, worm or other malicious software. Achilles Therapeutics Limited (10167668) is registered in England and Wales. The registered office is at 215 Euston Road, London, NW1 2BE, UK. _______________________________________________
Dev mailing list Dev at ensembl.org
Posting guidelines and subscribe/unsubscribe info: http://lists.ensembl.org/mailman/listinfo/dev
Ensembl Blog: http://www.ensembl.info/
This e-mail message contains confidential information intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail and then delete and discard all copies of the e-mail. We have taken all reasonable precautions to check this e-mail and any attachments for viruses, but we cannot accept any liability for any damage sustained as a result of any virus, worm or other malicious software. Achilles Therapeutics Limited (10167668) is registered in England and Wales. The registered office is at 215 Euston Road, London, NW1 2BE, UK.
This e-mail message contains confidential information intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail and then delete and discard all copies of the e-mail. We have taken all reasonable precautions to check this e-mail and any attachments for viruses, but we cannot accept any liability for any damage sustained as a result of any virus, worm or other malicious software. Achilles Therapeutics Limited (10167668) is registered in England and Wales. The registered office is at 215 Euston Road, London, NW1 2BE, UK.
This e-mail message contains confidential information intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail and then delete and discard all copies of the e-mail. We have taken all reasonable precautions to check this e-mail and any attachments for viruses, but we cannot accept any liability for any damage sustained as a result of any virus, worm or other malicious software. Achilles Therapeutics Limited (10167668) is registered in England and Wales. The registered office is at 215 Euston Road, London, NW1 2BE, UK.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20171205/a8481e51/attachment.html>