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.

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