[cmview-devel] Scoring functions

[Jose Duarte]

The interface is definitely a good idea, agreed.

I did some work already in that direction. Basically I implemented 
residue type and residue count scoring following Dan's ideas. I also 
implemented an all atom based scoring scheme but that one doesn't play 
so well with CMView which is purely residue based.

Anyway the code for residue scoring is in owl in package 
owl.decoyScoring in case anyone feels like having a look. It should be 
possible to adapt to the standard interface proposed below quite easily.

Jose



Henning Stehr 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
>