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.

2)Order preserving can be achieved with assigning a property, which
represent an order.

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 )

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.

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.

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.

7) ot:stereochemicalFeatures, should be a subclass of Feature, and used
according to existing feature/dataset API.

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

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)

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


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.


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.


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