> 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  .

Stupid me! I can save the predicted feature in the model and reference
that from the prediction dataset, not the other way round. This is how I
have implemented it now in the development branch (you can see it in the
last models at ot-dev.in-silico.ch).

@Martin: Can you adjust the validation service - I get 2 errors from the 
tests where validation expects the old representation.

@Micha, Andi: Nightly validation tests at the integration server will
fail for this reason.

Best regards,
Christoph