Andreas,

See my last reply to Christoph, as well as the API description at
http://opentox.org/dev/apis/api-1.1/Algorithm  - this has been developed
jointly with TUM and included in their fminer implementation.

Best regards,
Nina
Andreas Maunz wrote:
> Christoph Helma wrote on 04/29/2010 11:33 PM:
>>>> According to our API the model knows about ot.Algorithm and
>>>> ot.IndependentVariables, but it would need to know the service to
>>>> calculate independent variables.
>>> It does actually - every feature (variable) has ot:hasSource, which
>>> points to the service it has been generated from (e.g. descriptor
>>> calculation one) - and this is what we use in ToxPredict.
>>
>> True, but that makes sense only for "simple" descriptor calculation
>> algorithms (i.e. descriptors that are independent of the training
>> activities, like phys-chem properties, substructures). If we use e.g.
>> supervised graph mining techiques we need
>>
>> (i) an algorithm (model because it is algorithm applied to data?) that
>> mines features in the training dataset and creates a feature dataset
>> (e.g. fminer)
>>
>> (ii) a simple substructure matching algorithm that determines if the
>> mined features are present in the compound to be predicted (e.g.
>> OpenBabel Smarts matcher)
>
> We need this not just for crossvalidation, but also for single
> predictions.
> The feature set is not fixed, but depends on properties inherent to
> the (training) data set.
> However, once the features are calculated for the training dataset,
> the matching service (ii) may be seen as an ordinary feature
> calculation service:
>
> f_i(mol) = 1   if feature i occurs in mol,
> f_i(mol) = 0   else.
>
> I.e. it takes the same role as any other feature calculation service.
>
>> My interpretation was, that ot:hasSource should point to the graph
>> mining algorithm, but the model would need the substructure matcher for
>> predictions. How should we handle this?
>
> Set ot:hasSource to service (ii)?
>
> Regards
> Andreas
>
>