<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&#39;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&#39;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&#39;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&#39;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&#39;s true, but I think usually, what&#39;s missing is only a<br>
his-tag or something. In most cases I&#39;ve seen, the<br>
Pdb more or less completely maps to the Uniprot entry. So I&#39;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&#39;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&#39;d go for the solution of having an alignment as member of SiftsFeature. To me it sounds reasonable, but usually I can&#39;t see these things so well in advanced, maybe I&#39;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&#39;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&#39;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&#39;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 &#39;Protein&#39;?<br>
<br></blockquote><div><br>Yes that sounds reasonable. I&#39;d call it UniprotEntry. Feel free to restructure all that whenever you want. It won&#39;t affect much my code and in any case refactoring just happens in eclipse without needing to worry.<br>
<br></div></div>Jose<br>