Christoph,

On 12 October 2010 10:20, Christoph Helma <helma at in-silico.ch> wrote:

> Excerpts from Nina Jeliazkova's message of Mon Oct 11 19:44:01 +0200 2010:
> > On 11 October 2010 19:51, Christoph Helma <helma at in-silico.ch> wrote:
> >
> > > Excerpts from Nina Jeliazkova's message of Mon Oct 11 17:27:14 +0200
> 2010:
> > > > Christoph,
> > > >
> > > > Could you tell what kind of errors (parsing of SMILES ?) would you
> like
> > > to
> > > > store into metadata?  Is it possible to provide examples?
> > >
> > > It will be a mixed bag of SMILES errors, duplicated structures,
> > > incorrect activity entries, .... Examples can be found e.g. at
> > > http://toxcreate.org/models under "Warnings:  show".  Simple string
> > > annotation for concatenated error/warning messages could be sufficient.
> > >
> >
> > Ah, ok - agree such information would be very useful.
> >
> > What do you think about storing these somehow linked to the compounds ?
>  As
> > a start could be simple string annotation , but linked to the compounds
> and
> > not datasets.   Thus one should be able to point to the exact compound
> where
> > the error is.
> >
> > Perhaps introduce "metadata" for compounds as well?
> >
>
> I think parsing errors are dataset related, not properties of
> compounds


Well, if it is a SMILES parsing error , I would say it is compound related


> - and I am reporting also parsing errors for feature values
> and formatting errors which are not compound related.
>

OK.  Then we need metadata/errors for features as well.


> Maybe metadata for data entries would be more consistent, but I fear
> that could make things too complicated/slow (take e.g. the display of
> dataset summaries: it would require to iterate over all dataset entries
> just to show error messages - obtaining them directly from dataset
> metadata would be far more efficient).
>

I see. But if one needs to show an error for specific data entry, then the
client/user is on its own.   For a dataset with more than few errors it
might not be easy task.

It seems like we need a compromise - errors on both dataset level and
dataset entry /compound level . It could be a summary on the dataset level
for quick display and at the dataset entry /compound or feature level
(optional?) if details for specific entry is needed.

In this line of thinking,  does it make sense to assign a generic container
for errors/warnings to every OpenTox object . It could be applicable for
models as well (e.g. warning: "default parameters used to derive this model"
).

Then  the client code will choose what to use based on its preferences /
information available.

We'll need to add a single property to opentox.owl :

<ot> ot:hasMessage/Errors/Warning/find-the-best-word  <Literal>.

What do you think?

Nina

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