You are here: Home » Development » Testing » Test Case Development » ToxPredict


— filed under: , , , ,

Graphical User Interface (GUI) for predicting toxicity

ToxPredictBased on Use Case 3.A.1 Given a chemical structure, predict an endpoint (version B)

Try ToxPredict Demo application at


3.A.ToxPredict operations


This page lists low level details on OpenTox services, used by ToxPredict. For end user tutorial , please consult the slides .


3.A.1.1 User input

3.A.1.1.1 Chemical structure as

  • Chemical structure (SMILES , MOL, SDF from structure editor or as text string){identifier}/all



3.A.1.1.2 Endpoint from selection list


(1) Ontology service in order to search for available endpoints & models.  Available since Jan 11 2010. 

(2) Friendly user interface, able to handle long list of endpoints and models.


  • RDF representation of OpenTox models (ot:Model instances) to provide user-friendly name in dc:title
  • RDF representation of ot:Model objects with sufficient detail (e.g. making use of relevant model properties like ot:algorithm, dc:title, ot:predictedVars, ot:dependentVars, etc.)
  • If creating new features for dependent or predicted variables, please assign owl:sameAs from ECHA endpoints ontology (e.g.  otee:Carcinogenicity , or at least otee:Endpoint, if specific endpoint is not available in the ontology).  This is necessary in order to retrieve models by an endpoint, otherwise the models will not be visible in ToxPredict. 
  • Extend OpenTox ontology with a property of ot:Model, describing its status - e.g. published, under_development, etc.  Implement in services (ALL) , to allow presenting to the user

3.A.1.2 Retrieve chemical structure and identifiers


(1) Dataset service, providing query facilities for structure and identifiers.  Since identifiers can be regarded as instances of OpenTox Feature object, an ontology of identifiers (IUPAC name, synonyms, CAS, EINECS, etc.) is necessary as well as their mapping to features.  An initial ontology of identifiers is available in the latest opentox.owl

  • Query service<compoundURI> returns all available identifiers



3.A.1.3 Check chemical correctness

Prerequisite: Service for verifying chemical correctness or same on the client side? Structure editors and data services lookup are likely to return correct structures.

  • Structures , obtained from AMBIT dataset service have quality labels assigned, based on comparison with structures from different sources, having the same identifiers. 
  • Optional: Additional algorithm service, verifying chemical correctness.

Input:  URI of the chemical compound, or Dataset, consisting of compound URI and all relevant information of compound identifier and properties.

Output: same

3.A.1.4 User input: Remove ambiguities

(e.g. from non-unique names,CAS) and errors (e.g. wrong Smiles syntax) if necessary

Input:  URI of the chemical compound, or better a Dataset, consisting of compound URI and all relevant information of compound identifier and properties.

Output: same

Prerequisite: None (user interface). 

  • with :
    • selected
    • recommended
    • validated
    • reviewed 
  • models for the selected endpoints


(1)Model service(s).  Several available.

  • Prediction is made by POST-ing dataset URL, obtained previously to the Model(s) URL
  • Models need to be registered into the ontology service, in order to be visible to the application

(2)Ontology service for retrieving models for selected endpoints.

(3) Extension of Model RDF representation to incorporate information about model status (recommended, validated, reviewed). 


(4) Ability to find out which Descriptor calculation service has to be used, if selected models require descriptors.  This can be found by retrieving model ot:independentVariables and looking at ot:hasSource property for description calculation Algorithms.  The lookup, launch of descriptor calculation and POST to the model is performed by the superservice

Input:  Dataset URI, Models URI

Output: new Dataset URI


3.A.1.6 Display predictions and confidences (applicability domains) together with experimental data (if available)


(1) Validation  service (for retrieving statistics) and applicability domain service. 

(2)  Data service for retrieving experimental data. (Shouldn't experimental data be retrieved and displayed already on step 3.A.1.2 ? )

  • The query is based on features having owl:sameAs as entries from ECHA endpoint ontology.


3.A.1.7 User input: Select a model to display prediction details


(1) Dataset service, to retrieve compound and prediction results from.[]=

(2) Reporting service to generate user friendly reports. is used to POST the same query as above, but without restriction on URI length

Document Actions