On Thu, 2010-07-15 at 15:52 +0300, Nina Jeliazkova wrote:
> 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.
> 

Yes, this is true: The image link (if any) will force the editor to
override depiction and use that image while letting the user that loaded
the report to choose the automatic depiction once again. Of this will
not affect the computer-readable part of the compound (e.g. its SMILES)
and its value has more to do with the printable version rather than with
anything else.

> 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 ?
> 
> 
It seems we need to.

Best Regards,
Pantelis

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