[Owl-devel] Uniprot entries and mapping to Pdb structures

[Jose M. Duarte]

> Do you have a script to create the blast db? Could we also commit that to
> the scripts dir? It's a pain to figure out how to do it every time.
>
>
Yes no problem I was thinking about that too. I'm still in the process of
rewriting it since I discovered some important bugs.



>
> First of all, it's really great that the Pdb class now implements
> HasFeatures.
> This will be now our reference implementation since there is no other yet
> :)
> But then, the SiftsFeature, if I understand it correctly, shouldn't
> that be a feature of the
> UniprotEntry rather than the Pdb object? A feature should be something you
> can
> completely localize in the sequence of its parent. A Uniprot protein
> usually has one or more subdomains
> for which the structure is known. Ah, now I see, because the mapping
> in the pdb file is also not necessarily complete.
> Yes, that's true, but I think usually, what's missing is only a
> his-tag or something. In most cases I've seen, the
> Pdb more or less completely maps to the Uniprot entry. So I'd make the
> SiftsFeature a property of the UniprotEntry (which is
> yet to be created, hence my previous question, see below).


Ok I see what you mean now. Yes that sounds right. UniprotEntry should be
created and then it should own the SiftsFeature.



> In
> practice, as you mentioned, you will actually need to
> do an alignment of the pdb to the uniprot sequence. That's why in my
> mutanom project, I created a
> class Substructure which holds the alignment. Alternatives would be to
> add an alignment member to SiftsFeature,
> or even to require any feature to always contain a (possibly trivial)
> alignment. But maybe this would be a bit
> of an overkill for features like mutations which are only one amino
> acid long. The nice thing if you have
> an alignment is that you can translate between positions in Uniprot
> sequence space and Pdb sequence space.
> Then you can decide whether e.g. a scop domain or a mutation should be
> a feature of the Pdb or the UniprotEntry. Both
> is possible and the only difference is the numbering. So it depends on
> your application which makes more sense.
>

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.



> BTW, one cool thing about doing all this Feature stuff is that one day
> we can write a viewer class that can display
> any object implementing the Feature interface along a sequence or in a
> structure.
> I suddenly feel gravity declining, so I better stop architecture talk...
>
>
:-D



>
> Right, that's something I forgot to explain. The things in
> owl.core.structure.features were supposed to be
> something temporary. They are in fact feature-like things which are
> not implemented with the
> Feature interface but eventually should be. So SiftsFeature should
> really stay in owl.core.features
> and we should move more things there eventually. Logically, I feel
> there is no real difference between
> a structural feature and a sequence feature.
>
>
Alright good to know, that makes a lot of sense.



> That's what I was thinking about above. Some class which represents a
> full protein sequence (e.g. from Uniprot) as you will find it in the
> genome.
> It should implement HasFeatures and may reference the gene sequence
> as well. How should we call this? UniprotEntry? or simply 'Protein'?
>
>
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.

Jose
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.bioinformatics.org/pipermail/owl-devel/attachments/20100427/622ba1ee/attachment-0001.html>