On Thu, 2010-07-15 at 15:39 +0300, chung 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"
> 
> ?
> 
> 
> > 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?
> 
> 
> > 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.


Sorry... That was a bad typo.. I meant NOT OpenTox-dependent!
Regards,
Pantelis

> 
> > 
> > 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.
> 
> 
> > 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.
> 
> > 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?
> 
> > 
> > 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.
> 
> > 
> > 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.
> 
> > 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.
> 
> 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
>