Excerpts from Nina Jeliazkova's message of Tue Oct 12 10:01:33 +0200 2010:
> 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 about ot:Info/Warning/Error for each OpenTox object? 

ot:Info: informative messages, eg. about default parameters used
ot:Warning: informative messages about inconsistencies, potential errors.. (e.g. duplicated measurements)
ot:Error: Errors, e.g. syntactically incorrect compound structures

Best regards,
Christoph