Hi,


On Thu, Jul 15, 2010 at 3:39 PM, chung <chvng at mail.ntua.gr> wrote:

> Hi Nina,
>  Thanks for your comments.
>
>
> On Thu, 2010-07-15 at 09:30 +0300, Nina Jeliazkova wrote:
>
> > Dear Pantelis, All,
> >
> > I have several comments and suggestions:
> >
> > 1)we have so far avoided use of containers in OpenTox.owl (using
> containers
> > makes the ontology OWL full).
> > Containers can be modeled via properties , as we do for datasets.
>
>
> OK, I see.
>
> >
> > 2)Order preserving can be achieved with assigning a property, which
> > represent an order.
>
>
> Do you mean something like:
>
> /report/qprf/1
>    ot:author A:1
>    ot:author A:2
> A:1 a ot:Author
>    ot:order 1^^xsd:int
>    rdfs:comment "This is the first author"
> A:2 a ot:Author
>    ot:order 2^^xsd:int
>    rdfs:comment "This is the second author"
>
> ?
>

Yes, something like this.


>
>
> > 3)Having completely new representation for authors is not quite nice -
> could
> > we reuse these from some of ontologies, which represents publications?
>  Then
> > it will be easier to link with.   (even foaf:Person could do )
> >
>
> I'll take a look at that. Of course it will be better to reuse some
> existing ontology.
>
>

>
> > 4)Regarding compound analogues - I would prefer to represent it via
> OpenTox
> > algorithm/model objects.  Analogues can be selected by different tools
> (or
> > manually) and have different meaning - having just one proprety for
> > analogues is quite restricting.
> >
>
> Indeed, a list of analogues can be provided as a model resource by a
> similarity search algorithm but in that model there should be the list
> of these analogues. How can these be listed in the model?
>
>
My idea was the analogues (list of compounds) are given as output of  a
model - the model could return a dataset of the analogues, rather than
dataset with input compounds (as for other models) .  There could be also
some property assigned (e.g. similarity, or expert assigned weight and
comments) for each of the analogues.

I would like to use something similar for read across use case - will try to
have an example this week.


> > 5)There is not much sense in introducing new object for ot:software, we
> can
> > reuse existing objects for ot:algorithm and ot:model , with adding
> > ot:implementation property. Thus, "why something is considered analogue"
> > could be easily derived by inventing new algorithm type for "analogue
> > identification"  , and this algorithm can process a compound and assign a
> > property for another compound being analogue _because_of_this_algorithm.
> > We are going to soon need this for Read Across , not only for reporting.
>
>
> OK, I agree on that :)
>
>
> >
> > 6)Compound images, without links to a compound should be strongly
> > discouraged - there should be computer readable representation of the
> > compounds, from which the image is derived.
>
>
> An end user might need to assign some fancy image of the compound (not
> an automatically created depiction). My intention is to build an editor
> and in general a framework which will be OpenTox-dependent.
>


My point here is that allowing images only and not computer readable data,
we are not facilitating the model/prediction reproducibility anymore than
printed image in the paper.

Re: editor - there are number of editors and user preferences differ ...
better approach might be to allow copy/paste the compound from his favorite
editor.


>
> >
> > 7) ot:stereochemicalFeatures, should be a subclass of Feature, and used
> > according to existing feature/dataset API.
> >
>
>
> This is not really a feature; it is a discussion about how the
> stereochemical characteristics of the substance may affect the
> reliability of the prediction. It the keyword 'discussion' that makes me
> understand it as a comment and not as a feature of the compound.
>
>
OK, so I misunderstood.

>
> > 8)Predicted and experimental values are distinguished via representation
> of
> > Feature (and its subclass) , and more specifically, its ot:hasSource and
> > owl:sameAs  properties ( ot:hasSource  is a link to algorithm, model
> > (predicted) or an assay , owl:sameAs  can be a link to ontology of
> specific
> > assay or descriptors).
> >
>
>
> I do not really understand this! I think that the predicted feature
> corresponds to the output of the model and the dependent to what the
> model tries to predict, i.e. the experimental value. These features are
> identified by the propertied ot:dependentVariables and
> ot:predictedVariables, so it is quite straightforward to locate the
> predicted and experimental values in the report.
>

Right, my point was both are ot:Feature.  One can distinguish via inspecting
ot:hasSource, but in this case there is a model with everything defined, so
easier case.


>
> > 9) Confidence values.  There is already such construct in opentox.owl,
> which
> > was introduced to be used by Lazar algorithm.   (AFAIK confidence values
> in
> > Lazar are not confidence intervals, so even if we stay with the proposal,
> it
> > doesn't cover all cases)
> >
> >
>
> Could you give an example?
>


Yes, will try to retrieve from some previous emails.

>
> >
> > The construct in OpenTox.owl is ot:Tuple , which is allowed to be used in
> > dataset representation instead of ot:FeatureValue  .  Tuples are just
> > unordered sets of FeatureValues, thus we can have  one FeatureValue for
> the
> > predicted value and one FeatureValue for the "confidence" , and only
> define
> > one additional feature , representing the confidence. One could define
> > arbitrary feature values, describing comments, and other values, related
> to
> > the uncertainty.   IMHO, this is not only related to the report, but to
> > representation of prediction results
> >
>
> Once again, I think an example is needed. What's more we need to think
> of a uniform way to cope with confidence intervals, probability values,
> error bounds and other ways in which the uncertainty of a prediction can
> be quantified.
>

Indeed.


>
> >
> > 10) There is no need to define more objects for applicability domain
> types
> > (e.g. descriptor domain or metabolic domain).  Recall the AD in OpenTox
> are
> > models, created by algorithms  and we could just extend the
> AlgorithmTypes
> > ontology to provide entries for all these types of applicability domain.
> > Finally, one and the same AD could be of several types.
> >
> >
>
> That was my point too. Applicability Domain nodes are models that have a
> link to an algorithm which has an AD type (or subtype). We just need an
> ota:ApplicabilityDomain algorithm type.
>
>
Yes- this seems like a consensus  - so we can already extend algorithm types
ontology ?


> > These comments are focused on avoiding redundant extensions, when the
> task
> > could be done with the existing objects and properties in the ontologies
> we
> > are using.
> >
>
> Thanks for the input. I think your suggestions will help to build a
> cleaner ontology.
>

I hope so :)

Best regards,
Nina

>
> Best Regards,
> Pantelis
>
> >
> > Best regards,
> > Nina
> >
> >
> > On Wed, Jul 14, 2010 at 4:36 PM, chung <chvng at mail.ntua.gr> wrote:
> >
> > > Hi All,
> > >
> > > Find attached an updated version...
> > >
> > > On Wed, 2010-07-14 at 15:47 +0300, chung wrote:
> > >
> > > > Dear Martin, All,
> > > >  Please find attached a proposal about the structure of a data model
> for
> > > > a QPRF report. Please take a close look in comparison with the JRC
> > > > specifications and check if there are any missing properties. Note
> that
> > > > this is a first draft and probably it will need modifications. What
> we
> > > > need to do next is update the OpenTox OWL file according to the
> > > > requirements of QPRF reports. I modified a bit the GUI to resemble
> with
> > > > the structure of the QPRF report (using sections and subsections).
> > > >   I also attach a progress report of ours I had prepared for our last
> > > > meeting.
> > > >
> > > > Cheers,
> > > > Pantelis
> > > > _______________________________________________
> > > > 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
> > >
> > >
> > _______________________________________________
> > 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
>