Hello all once again,
   Some issues have to be clarified before proceeding with the
implementation of the QPRF-editor. We have carried out some initial
design on it but the fact that we throw away source code due to API
modification and so on is quite frequent in OpenTox... So finalization
of OpenTox ontology and API specifications is absolutely necessary if we
want this editor implemented in deterministic polynomial time (P), i.e.
before the deadline.

Best regards,
NTUA development group

P.S. 
 This http://translate.google.com/# will help you understand the text
below.

On Tue, 2010-06-15 at 16:41 +0300, chung wrote:
> Dear all, 
>  As it is substantial for the implementation of QPRF reporting services
> to extend the ontology API (taking into account the specification of the
> JRC at http://ecb.jrc.it/qsar/qsar-tools/qrf/QPRF_version_1.02.pdf , I
> think that the following are needed:
> 
> 1. The class 'ot:Report' is subclassed by 'ot:QPRFReport' and
> 'ot:QMRFReport'. Question: Are there any other reports needed there?
> Maybe 'ot:ValidationReport'?
> 
> 2. As you read in the updated version of the ontology I sent yesterday,
> a new ontological class called 'ot:AdequacyInfo' is needed to include
> the information of section 4.x of the QPRF specifications (see link
> above). Four dartatype properties are related with this class. These are
> 'ot:adequacyConclusion', 'ot:adequacyOutcome', 'ot:regulatoryPurpose'
> and 'ot:regulatoryInterpretation'. 
> 
> 3. I don't think that any modification is needed for section 1 of the
> specifications. We just extend the domain of the object property
> 'ot:dataEntry', to contain 'ot:QPRFReport' as well. Then, for example,
> we may have triples like:
> http://<server>/report/qprf/1 ot:dataEntry X
> X ot:compound http://<server>/compound/1
> Note: Only one compound should be related to a QPRF report (JRC
> specifications).
> 
> 4. Section 3.1. : What I suggest here is the the endpoint/predicted
> variable is correlated to the QPRFreport using the property
> ot:predictedVariables. For example:
> http://<server>/report/qprf/1 ot:predictedVariables
> http://<server>/feature/1
> 
> 5. Section 3.2.a. Make use of ot:algorithm
> 
> 6. Section 3.2.b. Introduce the property ot:qmrfReport which may
> correlate a Model with a QMRFReport. For example:
> http://<server>/report/qprf/1 ot:model http://<sever>/model/1
> http://<sever>/model/1 ot:qmrfReport http://<server>/report/qmrf/1
> http://<sever>/model/1 ot:qmrfReport http://<server>/report/qmrf/2
> http://<sever>/model/1 ot:qmrfReport http://<server>/report/qmrf/3
> ...
> 
> 7. About section 3.3. : In every model, one can find a link to an
> applicability domain model (or at least an AD algorithm). So in the RDF
> representation of the qprf report one finds the model used to make the
> prediction and the AD model/algorithm for that model. Now we need to
> handle sections 3.3.a (domains) and 3.3.c (3.3 Considerations on
> structural analogues) [We'll discuss 3.3.b later]. So I suggest to
> introduce the class ot:DomainInfo for 3.3.a. Once ot:domainInfo is
> introduce we can have the properties:
> * ot:descriptorDomain : Model U algorithm --> String
> * ot:structFragmentDomain : Model U algorithm --> String
> * ot:MechanismDomain : Model U algorithm --> String
> * ot:MetabolicDomain : Model U algorithm --> String
> 
> 8. Section 3.3.b. (Structural Analogues): This is a specific n-ary
> transitive relation between compounds. For that reason (thinking
> SQL-wise) we introduce the generic class ot:Relation which is subclassed
> by ot:CompoundRelation which is subclassed by ot:StructuralRelation. A
> membership in a relation is declared using the property
> ot:relationElement (see updated ontology). As far as 3.3.c. is concerned
> we can use rdfs:comment for it, which is something like a comment on the
> applicability domain. For example:
> X rdf:type ot:StructuralRelation
> X rdfs:comment "the user provides a discussion on structural analogues".
> 
> 9. About 3.2.c. : I suggest that the predicted value is contained in the
> RDf representation of the QPRF report explicitly to avoid posting a
> compound to the descriptor calculation proxy service and then to model
> service. 3.2.d. can be handled using rdfs:comment.
> 
> Any comments or ideas?
> Best regards,
> Pantelis
> 
> 
> On Mon, 2010-06-14 at 17:18 +0300, chung wrote:
> > Dear all,
> >  I send you again an updated version of the OpenTox ontology. Please
> > check out if the attached file opens with Protege because there have
> > been some problems (possible Protege version compatibility problems). I
> > think we should finalize the error reporting part of the ontology, so
> > please take a look at ot:ErrorReport and ot:errorReportProperty.
> > 
> > Best regards,
> > 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
>