On Thu, May 26, 2011 at 11:26 PM, Christoph Helma <helma at in-silico.ch>wrote:

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

Great, I adjusted the validation, the tests are running and things are a bit
easier.

Best regards,
Martin

P.S.:
The validation service has become a bit more strict on determining weather a
model performs prediction or regression: The rdf-type of the predicted
feature has to be set to numeric or nominal (nominal preferred if both are
set).


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



-- 
Dipl-Inf. Martin Gütlein
Phone:
+49 (0)761 203 8442 (office)
+49 (0)177 623 9499 (mobile)
Email:
guetlein at informatik.uni-freiburg.de