[cmview-devel] Scoring functions

[Henning Stehr]

> If you implement this, I'll volunteer to plug in some of the
> residue-residue pairwise potentials from the literature. I'd really
> love to compare my scores to some of those described previously.

Here you go:
owl.core.structure.scoring.ResidueContactScoringFunction

Still in request-for-comments stage but when we have implemented
the first couple of scoring functions, it should become apparent whether
the design works well or we need to refine.

When I'm bored I will add the functionality to CMView that any scoring
function can be visualized and used as a basis for modelling.

I havn't looked too much into Jose's package owl.decoyscoring yet but it is
probably easy to adapt his benchmarking framework to quantitatively
compare any scoring functions which implement the interface.

>
> Without the impediment of any knowledge of the existing architecture,
> I'd like to ask the following...
>
> * Can we (in theory) easily add scores based on arbitrary
> residue-residue interaction criteria?
>
> * How about scores based on explicit distance potentials? i.e. when
> the score is an explicit function of the distance of two particular
> groups?
>
> * Can we ... add scores based on reduced amino acid or atom alphabets?
>
> * Can we ... add scores based on NCI [1] for example?
>
>
> I'm starting to guess that the answer to all these questions is, "Yes,
> it's up to the method that supports the interface as to how the actual
> calculation is done". Is that correct?
>
>
> Thanks for starting this project, and thanks for creating open source software!
>
> All the best,
> Dan.
>
> [1] http://www.ncbi.nlm.nih.gov/pmc/articles/PMC168935/
>
> On 21 April 2010 16:48, Henning Stehr <stehr at molgen.mpg.de> wrote:
>> Matthias had the idea to define an interface for contact based scoring
>> functions such that new scoring functions can easily be added to
>> CMView. This would be very useful for ab-initio modelling and
>> refinement and to standardize things already implemented.
>>
>> Below you can see what I (in my role as architecture astronaut) think
>> such an interface ScoringFunction should look like.
>>
>> A scoring function could be based on the sequence (like a contact type
>> potential), contact map (like a contact count potential) or 3D
>> structure (like a geometric potential).
>>
>> In CMView, the score would be displayed as an overlay similar to the
>> way distance map or contact density are currently shown. One could
>> also add functions for refinement/editing based on the scores. Some
>> similar functionality is already implemented for DeltaRank scoring.
>>
>> For a start, it should be relatively easy to implement the scoring
>> functions described in:
>>
>> Dan M Bolser, Ioannis Filippis, Henning Stehr, Jose Duarte and Michael Lappe.
>> Residue contact-count potentials are as effective as residue-residue
>> contact-type potentials for ranking protein decoys (2008).
>> BMC Structural Biology 2008, 8:53: doi:10.1186/1472-6807-8-53
>>
>> In addition, we are currently working on two novel scoring functions
>> DeltaRank and GMBP which are still unpublished. It will still take
>> some time until they can be incorporated in such a way that they can
>> be used by external users.
>>
>> As said before, these are only ideas so far but it seems to make sense
>> to still include this in CMView 2.0.
>>
>> I'm posting this here for different reasons:
>> - as my online notebook so I won't forget
>> - to put this out for discussion and get feedback from other astronauts
>> - so that someone who feels the urge can start implementing something
>> - to promote the open source spirit of the project
>>
>> Happy hacking,
>> Henning
>>
>> --------------------
>>
>> interface ScoringFunction {
>>
>> /**
>> * Initializes the ScoringFunction object with the data that the
>> scoring can potentially be based on.
>> */
>> public void init(sequence, contacts, coordinates);
>>
>> /**
>> * Notifies the ScoringFunction object that the underlying data has
>> changed and scores have to be recalculated
>> */
>> public void updateData(sequence, contacts, coordinates);
>>
>> /**
>> * Returns the normalized score for contact (i,j). If (i,j) is not
>> really a contact, should
>> * returns the score assuming that it was a contact.
>> */
>> public double getScore(i,j);
>>
>> /**
>> * Returns a score for the whole contact map, as it would be used for
>> decoy scoring.
>> * This can be simply the sum of individual scores or something more complex.
>> */
>> public double getOverallScore();
>>
>> /**
>> * Returns a summed score for the current set of selected contacts.
>> Similar to above.
>> * Not sure if this is very useful but could be used to find good/bad regions.
>> */
>> public double getScoreForSelection(selected_contacts);
>>
>> }
>>
>> _______________________________________________
>> cmview-devel mailing list
>> cmview-devel at bioinformatics.org
>> http://www.bioinformatics.org/mailman/listinfo/cmview-devel
>>
>