Dear Pantelis, All,

chung wrote:
> Dear Tobias, Nina, All,
>
> According to the OpenTox API 1.0 about algorithms, a training algorithm
> service accepts as POSTed parameters the dataset_uri and some algorithm
> specific parameters. The dataset_uri itself contains a list of compounds
> and a corresponding list of feature definitions in a sense that if
> "/coumpound/100" and "/feature_definition/2535" belong to a dataset with
> uri "/dataset/37" then the value of the feature is available at
> "/feature/compound/100/feature_definition/2535". For example see
> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature/compound/aldosterone/feature_definition/CDK_LipinskiFailures 
> .
>
> So, the dataset contains feature definitions that correspond either to
> molecular descriptors or toxicological endpoints without being able to
> tell which is which. However this piece of information is very important
> for a learning algorithm. So I propose that the target feature
> definition should be an extra posted parameters. This modification of
> the API is of high importance for algorithm related web services and
> should be taken into account in API 2.0 (or 1.1 maybe! :-).
>   
This was discussed couple of times, but hasn't yet included in the API,
which we should definitely do for 1.1. 

The proposed marking in the feature definition is not quite generic. 
This metainfo should be done on the level of dataset or model.  An
example that has been considered already is that LogP can be both a
target variable, descriptor in a QSAR model, or a measured value.
> Furthermore about the previous post of Tobias about the Ids of features
> and feature definition, I think that the following problem arises (Let
> me give an example). Suppose that we (NTUA service) are given a data set
> URI: http://www.server1.com/dataset/1 (i) and we choose the compound
> http://www.server2.com/compound/100 (ii) and the feature definition
> http://www.server1.com/feature_definition/1234 (iii). Where can we find
> the value of the feature defined by the URI (iii) for the compound (ii).
> Note that these two are in the same dataset (i) and the URI
> http://www.server1.com/feature/compound/100/feature_definition/1234
> might return a status code 404 (not found). The same holds for 
> http://www.server2.com/feature/compound/100/feature_definition/1234 . 
> The problem arises when compounds and feature definitions from different
> servers meet in the same dataset. ...that's all greek to me :-(
>   
Let's first analyze  - what would one expect in this case? What would be
the meaning of  having feature value  for the feature (iii) and compound
(ii) ?

Best regards,
Nina

>
>
>
>
> On Tue, 2009-09-29 at 18:37 +0300, Nina Jeliazkova wrote: 
>   
>> Hi Tobias,
>>
>>     * Straightforward answer: 
>>
>>
>> In the XML (or whatever format) introduce two types of identifiers :
>> local ID ( e.g. CDK_topoShape) and global URI 
>> (http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature_definition/CDK_topoShape)
>>
>>
>> example (not synchronized with API)
>>
>> <compound id="XXX">
>>     <link href="http://opentox.org/compound/XXX">
>>     <feature_definition id="YYY">
>>         <link href="http://opentox.org/feature_definition/YYY">
>>         <feature>3.14</feature>
>>     </feature_definition>
>> </compound>
>>
>> URI like this one 
>> /feature/compound/{cid}/feature_definition/{f_def_id}  will assume to be
>> expanded by local ID only. This should happen only server side, e.g. the
>> client itself should not construct URI, they should be returned by the
>> server (this is what /Hypermedia as the Engine of Application State
>> /means, isn't it).
>>
>> That said, localID is most probably redundant, but sometimes might be
>> useful. 
>>
>> An interesting example is below. Do you see any issues with mixing
>> references from different sites?
>>
>> <compound id="XXX">
>>     <link href="http://opentox.org/compound/XXX">
>>     <feature_definition id="ZZZ">
>>         <link href="http://yoursite.org/feature_definition/ZZZ">
>>         <feature>3.14</feature>
>>     </feature_definition>
>> </compound>
>>
>>     * More complex answer :
>>
>> We are exploring the space of distributed REST applications (many
>> services, running on different servers) and naming of distributed
>> objects, which is far from trivial.  Most of the REST hype is only about
>> single REST application, running on a single machines (or a cluster of
>> machines) under single administrative authority.  This is not the case
>> with OpenTox.
>>
>> One way is to make use of RDF in order to define that two (or more) URI
>> point to the same object  e.g. http://opentox.org/compound/benzene and
>> http://myservice.org:9999/compound/c1ccccc1  mean the same chemical
>> compound.   RDF and ontologies  (descriptor ,endpoints, etc.) can help
>> to ensure the services are talking about the same objects , but there
>> are still caveats. 
>>
>> Best regards,
>> Nina
>>
>> Tobias Girschick wrote:
>>     
>>> Hi,
>>>
>>> While revising the API 1.0 there arose some controversy about IDs for
>>> features, feature definitions, references and so on.
>>>
>>> As far as we I know there has been no definitive decision made up to
>>> now. Please correct me if I am wrong here.
>>>
>>> What we are using at the moment as IDs for feature definitions and
>>> references is full URIs, e.g. something like this:
>>>
>>> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/feature_definition/CDK_topoShape
>>> http://lxkramer13.informatik.tu-muenchen.de:8180/OpenTox/reference/CDK_topoShape
>>>
>>> This seems to be very nice and useful. But there arises one conflict
>>> with feature IDs as the API specifies the following URI to GET a
>>> specific feature:
>>> /feature/compound/{cid}/feature_definition/{f_def_id}
>>>
>>> The URI won't work if I just blindly insert the compound or feature
>>> definition ID here, as they both are fully qualified URIs. 
>>>
>>> If we use just something like CDK_topoShape as ID instead of a URI, we
>>> have the problem that this would have to be unique over the whole
>>> OpenTox system to prevent mix ups.
>>>
>>> Is there a clever way to solve this?
>>>
>>> Regards,
>>> Tobias
>>>
>>>   
>>>       
>> _______________________________________________
>> Development mailing list
>> Development at opentox.org
>> http://www.opentox.org/mailman/listinfo/development
>>     
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>