Support for toxic/nontoxic categories

vedina commented 11 years ago

A proposal to annotate OpenTox features by custom RDF data types, in order to avoids custom hacks (e.g. regexp) to identify which values mean toxic or nontoxic compounds.

Example of the RDF for toxicity categories with custom RDF data types (proposal by @egonw)

<http://localhost:8080/ambit2/feature/180>
a ot:Feature ;
        ot:acceptValue 
       "Whatever"^^ot:InconclusiveCategory ,    
       "Nonmutagen"^^ot:NontoxicCategory , 
       "Mutagen"^^ot:ToxicCategory .

ot:ToxicityCategory
         rdfs:subClassOf xsd:string .
ot:InconclusiveCategory
         a rdfs:Datatype ;
         rdfs:subClassOf ot:ToxicityCategory.
ot:NontoxicCategory
         a rdfs:Datatype ;
         rdfs:subClassOf ot:ToxicityCategory .
ot:ToxicCategory
         a rdfs:Datatype ;
         rdfs:subClassOf ot:ToxicityCategory .

Previous discussions at http://sourceforge.net/p/ambit/feature-requests/58/

Example implementations: http://tinyurl.com/ambit58n3 http://tinyurl.com/ambit58json

egonw commented 11 years ago

What I originally had in mind, was slightly different. I did not spot that, when this got implemented. I like the output to be typed, not the enumeration of values for a feature, or not alone that anyway.

What I think the next OpenTox API should allow, is the return values of actual calculations to be semantic.

vedina commented 11 years ago

Both can be used together.

By specifying the enumeration one can quickly spot what are the allowed values from a given model.

By just assigning a type to the values, this is not possible. The current predicted values are of string type and it is straightforward to be replaces by typed values. However, it will break the compatibility with older clients, which do not understand the new typing and expect strings.

opentox-api / api-specification

Support for toxic/nontoxic categories #1