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! :-).

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 :-(





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