Hi ,

Would the target of a ot:hasMessage be an object defined in the ontology ?
OR would it be just text literal ?

Just a suggestion .....
It would be helpful to have an class on the lines of a "logfile" (in opentox
owl). Coupled with a ot:hasLogreport (on the dataset,data-entry etc)  we
could potentially use this construct for various levels of structured log
reports for any task.
The log could cover everything from errors,warnings,messages to suggestion
for next steps etc.

Cheers
Surajit

On 12 October 2010 13:31, Nina Jeliazkova <jeliazkova.nina at gmail.com> wrote:

> 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
> >
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>