[Owl-devel] new interface ResidueContactScoringFunction

[Henning Stehr]

I have added a class owl.core.structure.scoring.HydrophobicPotential
as an example implementation of the ResidueContactScoringFunction
interface. It defines the propensity of two residues being in contact
as the product of their hydrophobicity values. This may not be very
useful in practice but it nicely illustrates how to implement
residue-type based scoring functions using the interface.

When I have time, I will implement the CMView side, so that we can
visualize different scoring functions.

While I was writing the class I had a few questions/ideas about the
current interface definition:

- I'm still not sure about this normalization business. Thinking about
how a scoring function would be
used in CMView, the scores will have to be normalized to the [0,1]
range. Is it reasonable to expect
the scoring function to return normalized scores for individual
contacts? How about scores for the whole structure, there
normalization does not make sense, or does it? Or is it better to drop
normalization altogether and let the calling application do it if
necessary (that would require to obtain scores for all possible pairs
to get the min/max values)?

- It may sometimes be nice to pass parameters to a scoring function.
The thing is that one design goal here is that the calling application
should not need to have any knowledge about the specific scoring
function it uses. One way around this would be to pass a java
'Properties' object as an additional parameter to the constructor or
init method. A Properties object contains arbitrary key-value pairs
and very convenient methods to read/write such parameter sets from/to
text files. The convention would then be that any scoring function
would have to be accompanied by a text file whose name corresponds to
the method name returned by getMethodName(). This would allow the user
to change parameters without changing the source code, the calling
application could either just pass the parameters from the file or
intervene (if the specific properties of the function are known).
Disadvantages are the extra overhead of this and the fact that
property files are error prone because users can write arbitrary text
in such a file.

Please feel free to post other comments and suggestions about the
current interface definition. We will probably need to implement a few
more scoring functions before we can fix something which then
hopefully remains stable for a while.

Cheers,
Henning


On Fri, Apr 30, 2010 at 1:11 PM, Dan Bolser <dan.bolser at gmail.com> wrote:
> On 30 April 2010 11:34, Jose M. Duarte <jose.m.duarte at gmail.com> wrote:
>> Hi Dan
>>
>>> > Below you mention that you have two scoring functions almost ready...
>>> > which classes are they in? I'd like to work on trying to make them
>>> > implement the interface.
>>> The package owl.decoyscoring contains some scoring functions,
>>> which were implemented by Jose based on your BMCBI paper.
>>>
>>
>> You can try to run the scoreDecoys class from the default package (right
>> click and Run As Java Application). That will give you a taste of what the
>> decoys scoring does.
>>
>> Actually you will first need to compile the scoring matrices. For that you
>> need to run ResCountScorer or ResTypeScorer classes from the decoyScoring
>> package (you'll need pdbase but you can tunnel that). Once you have the
>> scoring matrices you can then run the scoreDecoys executable.
>
> When I saw that functionality I was really impressed!
>
>
>> Whenever I get some time I will try to adapt the existing code to the new
>> interface. It shouldn't be difficult.
>
>
> Thanks all for help, when I make any progress I'll get back to you ;-)
>
> Dan.
>