Link to this post | posted 18 Mar, 2021 03:09

lhughes

Just to add from the perspective of a BE1 phage (looking at Cross, which we annotated last semester), the CCCGGAA that lines up with the CCCAAAT in the BK1 examples is preceded by a stop codon in the potential second reading frame (and looks to be that way in the majority of the BE1 examples in Chris's chart), so that is exactly the longest position where a frameshift could take place between those two reading frames in those phages. That's interesting (whether or not it really means anything). Lee

Link to this post | posted 18 Mar, 2021 02:55

lhughes

Looking at the referenced paper, I do find that the CCCAAAT appears very much like the GGGAAAT in the Lambda example. If we can follow that example, then the shift would be a -1 giving Proline (from a Proline in the original frame). The new frame had a stop codon a few codons previously, so this is about the earliest the frameshift could happen. This looks very good to me for the BK1 phages (though still begs the question about where a shift would be in the BE1 phage genes that are in the same pham). The first nucleotide of the slippery sequence in Sham would be 23985 (this is the phage I had open to check). Lee

Link to this post | posted 17 Mar, 2021 21:12

lhughes

Joyce, We've annotated several BK1 at UNT (and are annotating 2 right now). The last line of your post hits at the crux of the matter. Without a clear slippery sequence, we cannot bioinformatically identify a frameshift even if it seems likely that there could be a frameshift in this area. That is the reason none of the annotations I've been involved in for this subcluster have a frameshift in the final annotation. Lee

Link to this post | posted 09 Mar, 2020 18:52
lhughes	I *think* we've been trying to use "endolysin" unless it was specifically the Lysin A and B situation, so hopefully most of our more recent ones are already correct. Good to have the clarification.

Link to this post | posted 24 Feb, 2020 14:50

lhughes

We see a similar region in the Cluster BI1 phages. When we look more closely at the Phamerator map, we also see the criss-crossing lines of short regions of homology that I see in the map of the Cluster DJ phages. There appear to be some short areas of conserved sequences between those genes (that is what we find in the BI1 phages). I would consider that these conserved sequences probably serve some purpose and are likely intergenic, so extending to LO just to do so might not be the best approach without further analysis of what is in those gaps. I have a graduate student who is doing that for BI1 phages right now to try to understand what is going on there better. Lee

Link to this post | posted 02 Oct, 2019 19:05
lhughes	welkin Hi All, Aragorn is back up and working. Best, Welkin We are having trouble accessing Aragorn today. Anyone else having the same problem? Lee

Link to this post | posted 17 Aug, 2019 20:12

lhughes

DrHHNZ Thanks Claire, That is helpful and we had seen some hints in the HHpred. The students had suggested that the only matches were all "integrases" without any further designation. I will have to take a closer look when we are back in class again. Thanks again for your time! Best, Heather Hi Heather - I think that is an NCBI issue. The hits used to say which they were, but I think more recently NCBI decided to use the generic "integrase" for everything so that information doesn't pop out like it used to. Lee

Link to this post | posted 26 May, 2019 19:47
lhughes	Steven Caruso These are big phages. S. Yep! At least the large terminal repeats actually bring the total down a little bit (since both ends should be identical, you only have to annotate one end and then just match the other one), but still large. And the massive number of tRNA's increases the workload too. Lee

Link to this post | posted 24 May, 2019 21:03
lhughes	Steve, I would just note that any tRNA calls for most of the BE1 phages already in GenBank were called using the rules AS THEY EXISTED AT THE TIME of their annotation. That could be part of the discrepancy. Keep in mind that some rules also overrule other rules, so that could also be part of the difference. Lee

Link to this post | posted 10 Apr, 2019 13:54

lhughes

My best guess is that the field isn't actually empty, but has something in it (a space perhaps, or a hard return), which is why it isn't being labeled. You probably need to make sure those fields are actually empty in order to get them to write. If you are copying and pasting into the Function field at some point in the process, you might have an extra hard return in the data (this can happen when copying from other programs) that is still in the field and causing the problem. Lee