<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Do you have a script to create the blast db? Could we also commit that to<br>
the scripts dir? It's a pain to figure out how to do it every time.<br>
<div class="im"><br></div></blockquote><div><br>Yes no problem I was thinking about that too. I'm still in the process of rewriting it since I discovered some important bugs.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>First of all, it's really great that the Pdb class now implements HasFeatures.<br>
This will be now our reference implementation since there is no other yet :)<br>
But then, the SiftsFeature, if I understand it correctly, shouldn't<br>
that be a feature of the<br>
UniprotEntry rather than the Pdb object? A feature should be something you can<br>
completely localize in the sequence of its parent. A Uniprot protein<br>
usually has one or more subdomains<br>
for which the structure is known. Ah, now I see, because the mapping<br>
in the pdb file is also not necessarily complete.<br>
Yes, that's true, but I think usually, what's missing is only a<br>
his-tag or something. In most cases I've seen, the<br>
Pdb more or less completely maps to the Uniprot entry. So I'd make the<br>
SiftsFeature a property of the UniprotEntry (which is<br>
yet to be created, hence my previous question, see below). </blockquote><div><br>Ok I see what you mean now. Yes that sounds right. UniprotEntry should be created and then it should own the SiftsFeature.<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
In<br>
practice, as you mentioned, you will actually need to<br>
do an alignment of the pdb to the uniprot sequence. That's why in my<br>
mutanom project, I created a<br>
class Substructure which holds the alignment. Alternatives would be to<br>
add an alignment member to SiftsFeature,<br>
or even to require any feature to always contain a (possibly trivial)<br>
alignment. But maybe this would be a bit<br>
of an overkill for features like mutations which are only one amino<br>
acid long. The nice thing if you have<br>
an alignment is that you can translate between positions in Uniprot<br>
sequence space and Pdb sequence space.<br>
Then you can decide whether e.g. a scop domain or a mutation should be<br>
a feature of the Pdb or the UniprotEntry. Both<br>
is possible and the only difference is the numbering. So it depends on<br>
your application which makes more sense.<br></blockquote><div><br>I'd go for the solution of having an alignment as member of SiftsFeature. To me it sounds reasonable, but usually I can't see these things so well in advanced, maybe I'm missing something altogether. I will need to see an example to understand the issues. But anyway we can try, if it turns out it doesn't work we can always redo it.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
BTW, one cool thing about doing all this Feature stuff is that one day<br>
we can write a viewer class that can display<br>
any object implementing the Feature interface along a sequence or in a<br>
structure.<br>
I suddenly feel gravity declining, so I better stop architecture talk...<br>
<div class="im"><br></div></blockquote><div><br>:-D<br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="im"><br>
</div>Right, that's something I forgot to explain. The things in<br>
owl.core.structure.features were supposed to be<br>
something temporary. They are in fact feature-like things which are<br>
not implemented with the<br>
Feature interface but eventually should be. So SiftsFeature should<br>
really stay in owl.core.features<br>
and we should move more things there eventually. Logically, I feel<br>
there is no real difference between<br>
a structural feature and a sequence feature.<br>
<div class="im"><br></div></blockquote><div><br>Alright good to know, that makes a lot of sense.<br><br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
</div>That's what I was thinking about above. Some class which represents a<br>
full protein sequence (e.g. from Uniprot) as you will find it in the genome.<br>
It should implement HasFeatures and may reference the gene sequence<br>
as well. How should we call this? UniprotEntry? or simply 'Protein'?<br>
<br></blockquote><div><br>Yes that sounds reasonable. I'd call it UniprotEntry. Feel free to restructure all that whenever you want. It won't affect much my code and in any case refactoring just happens in eclipse without needing to worry.<br>
<br></div></div>Jose<br>