Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for toxic/nontoxic categories #1

Open
vedina opened this issue Oct 5, 2013 · 2 comments
Open

Support for toxic/nontoxic categories #1

vedina opened this issue Oct 5, 2013 · 2 comments

Comments

@vedina
Copy link
Contributor

vedina commented Oct 5, 2013

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
Copy link
Member

egonw commented Oct 6, 2013

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
Copy link
Contributor Author

vedina commented Oct 6, 2013

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants