Dear Christoph,

On 26 May 2011 13:40, Christoph Helma <helma at in-silico.ch> wrote:

> Dear Nina, Martin, All,
>
> It seems yesterdays reply was not delivered to the list.
>
> > What about combining both solutions?  Features could be in the dataset,
> as
> > in IST services, or as separate resources,  but additionally models
> provide
> > list of predicted variables via /model/id/predicted ?  This way there
> will
> > be still no need of a separate feature service for you.
>
> Problem is that the prediction feature URIs (of the form
> /dataset/:id/feature/prediction/:name/{value|confidence}) are built on
> top of the dataset URI, which I cannot know in advance.


I wonder, why predicted  features URIs should be dataset dependent, rather
than model dependent ?

Semantically, the same variable is predicted by a given model, regardless of
which dataset is submitted for the model.  Dataset dependent URIs for
predicted variables may introduce confusion if somebody stores triples from
several datasets in a same triple storage (which is at the end the intended
use of all the RDF serialization).  Am I wrong?


> For this reason
> new features are created for each prediction. Any ideas how to solve
> that without a dedicated feature service? Or would it be easier to
> implement a feature service (or use AMBITs) for this purpose (what about
> A+A)?
>

Actually in the AA protected version we hide features and compounds inside
models or datasets, at least this is what appears externally, internally it
is the same  service-global list of features.  In case of models , the
features are relative to the model , e.g.  /model/1/predicted  have the same
policy as /model/1  .

Best regards,
Nina



>
> Best regards,
> Christoph
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>