First of all - Thanks Ivelina for your inputs !

You are right about the RatTD50 being a individual - I was a little confused
there. I have made the correction. The rest of the ontology follows from our
work flow which is :

a) We generate a dictionary of overlaps found from a dataset of molecules.
(Basically we run a pairwise graph comparison of all the molecules in a
dataset and collect all the overlaps found in all the comparisons.)

b) This dictionary is then used to generate a fingerprint of a test molecule
(for the endpoint of the particular dataset which generated the
dictionary).

c) In the back end we have modeled the fingerprints of the molecules ( of
the dataset) against the dictionary generated from the dataset. For our
internal testing and validation - we then use it in a RandomForest model to
predict toxicity of future molecules.

The question I am thinking about is how does this ontology fits in with the
API. Since the API has a dataset class - but what about the dictionary we
generate - would it be a dataset also - or a dataset derived object of some
sort ?

Thanks
Surajit

On Wed, Feb 3, 2010 at 7:36 PM, Ivelina Nikolova <iva at lml.bas.bg> wrote:

> Dear Surajit,
>
> I'm looking at the MaxTox.owl you've attached earlier this week. The
> reasoner classifies it well, so technically it is correct, but I'm
> lacking some additional knowledge about the problem you wish to solve
> with this ontology, may you give me some more explanations so that i  so
> that I can get your point while creating it.
>
> It is surprising for me to see that you have chosen to create a class
> called RatTD50 as a Dataset subclass. Normally the concrete datasets or
> features are individuals and they are not part of the ontology, but of
> some external resource and they have their URL. What is your reason to
> design it this way?
>
> Best,
> ivelina
>
>
>
>
>
>
> surajit ray wrote:
> > Hi Nina,
> >
> > I have created a basic ontology for the Maxtox model. Could please go
> > through it briefly when you have the time - and suggest improvements as
> well
> > as how we can fit this into the existing Ontology of Opentox. Just
> > indications will do (I understand you are already under a deadline
> > pressure...)
> >
> > I have just started learning protege so a few concepts may have gone
> awry. I
> > have tried my best to get the gist of our prediction system into the
> > attached ontology.
> >
> > Thanks in advance
> >
> > Cheers
> > Surajit
> >
> > On Tue, Feb 2, 2010 at 11:45 AM, Nina Jeliazkova <nina at acad.bg> wrote:
> >
> >
> >>  Hi Surajit,
> >>
> >>
> >> surajit ray wrote:
> >>
> >> Hi Nina,
> >>
> >>  Are we officially supposed to use the restlet2 m7 ?
> >>
> >>  The library and particular release are choice of the developer, so the
> >> answer is - it is up to you.
> >>
> >>  At this point I have few questions about this interaction
> >> a) Once a time consuming calculation is over - should the server notify
> an
> >> attached client about the result OR just sit with the data at a
> specified
> >> URL till it is fetched by the client ?
> >>
> >> The client sends GET requests and verifies if the result is ready (200
> OK).
> >> Have a look at the API  at
> http://opentox.org/dev/apis/api-1.1/AsyncTask
> >>
> >> When returning 303 (redirect) for an uncomplete task and making use of
> >> Refresh field, it is very easy to implement browser -like client to
> >> periodically check the task status. Browsers will automatically try to
> fetch
> >> the content after time interval, specified in Refresh:
> >>
> >>  (In the REST interface is it allowable for the server to contact a
> >> connected client ?)
> >>
> >> No.  REST is using HTTP protocol for communication and there is no any
> >> notion of an "attached" client.  The client sends GET/PUT/POST/DELETE
> >> request, receives an answer and there is no permanent between them after
> the
> >> response is sent.
> >> Unless you implement your client to behave as server as well, there is
> no
> >> way of server to tell the client anything, besides answering client
> request.
> >>
> >>  b) Should the server identify the client requesting the computation and
> >> authenticate before delivering the data OR give it to any client
> requesting
> >> the URI of the predicted/computed values ?
> >>
> >> We've decided to postpone everything, concerning authentication and
> >> authorization after the end of February, and currently all the services
> are
> >> open to everybody (I know it sounds scary :)
> >>
> >>  c) How long should the computed values be retained on the server OR
> >> should there be REST interface for destroying (and hence freeing up
> >> resources) a set of computed values ?
> >>
> >> It depends on your implementation.
> >>
> >> For example ambit services store everything in a database and keep the
> >> results forever, unless a delete operation is performed on specific
> >> resource.  REST way of deleting a resource is sending DELETE request
> >> (instead of POST or PUT, which are generaly for create/update).  For
> most of
> >> OpenTox resources DELETE operation is defined in the API (see wiki), but
> not
> >> everybody has implemented the full set of the API.
> >>
> >> d) Should there be an "account" like system for every client on the
> server
> >>
> >> See answer in (b).
> >>
> >> ? If yes - should the data generated by a client be attached to that
> >> "account" or available to all ?
> >>
> >> There might be public and private data, but at this moment we consider
> >> everything is public and will decide on details after finalizing
> >> deliverables at the end of this month.
> >>
> >>  Should the computed data persist indefinitely in each of these
> "accounts"
> >> ?
> >>
> >>  Again, it depends on your implementation.
> >>
> >> Best regards,
> >> Nina
> >>
> >>  Cheers
> >> Surajit
> >>
> >> On Tue, Feb 2, 2010 at 3:31 AM, Nina Jeliazkova <nina at acad.bg> wrote:
> >>
> >>
> >>> Hi Pantelis,
> >>>
> >>> There is a standard Java class java.util.concurrent.ExecutorService ;
> it
> >>> could be configured to work as a pool of fixed or variable number of
> >>> threads.
> >>>
> >>> There is a Restlet TaskService , which is wraps the ExecutorService.
> >>> I've found it behaved weird and switched to the standard Java class.
> >>>
> >>> You might look at ambit code at
> >>>
> >>>
> >>>
> https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/ambit2-all/ambit2-www/src/main/java/ambit2/rest/AmbitApplication.java
> >>>
> >>>
> https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/ambit2-all/ambit2-www/src/main/java/ambit2/rest/task
> >>>
> >>> For each asynchronous task, it creates a Callable class, which returns
> >>> Reference. Each tasks has an unique identifier (UUID) and the set of
> >>> tasks is stored in a ConcurrentMap. There is a timer, which removes
> >>> completed tasks few hours after completion.
> >>>
> >>> Hope this helps,
> >>> Nina
> >>>
> >>>
> >>> chung wrote:
> >>>
> >>>> Hi Nina,
> >>>>  I'm trying to make some improvements on the services so except for
> the
> >>>> migration from restlet2 m3 to m7 I was thinking of introducing some
> >>>> execution pool (e.g. an ExecutorService or -why not- something
> >>>> 'homemade') and establish a queue for the incoming requests
> (especially
> >>>> those characterized as time-consuming and memory-consuming ones). This
> >>>> way I will be able to manage all running tasks on the server and make
> >>>> some performance improvements I hope. Is there some standard way of
> >>>> doing this? Could you suggest some executor or some utility to manage
> >>>> the running threads and do you know if there is some way to specify
> the
> >>>> maximum number of running threads for Restlet?
> >>>>
> >>>> Best Regards,
> >>>> Pantelis
> >>>>
> >>>>
> >>>> On Tue, 2010-01-26 at 14:21 +0200, Nina Jeliazkova wrote:
> >>>>
> >>>>
> >>>>> Hello All,
> >>>>>
> >>>>> Following the data type discussions and proposal earlier this month,
> >>>>>
> >>> now
> >>>
> >>>>> support for NumericFeature and NominalFeature are implemented in IDEA
> >>>>> services.
> >>>>>
> >>>>> Please note all features are explicitly declared to be subclass of
> >>>>> ot:Feature as well. While this is redundant and can be derived from
> the
> >>>>> ontology with a help of a reasoner, it does make the client
> >>>>> implementation somewhat easier.
> >>>>>
> >>>>> Examples from CPDBAS dataset at
> >>>>> http://ambit.uni-plovdiv.bg:8080/ambit2/dataset/9
> >>>>>
> >>>>> <http://ambit.uni-plovdiv.bg:8080/ambit2/feature/12122>
> >>>>>       a       ot:Feature , ot:NominalFeature ;
> >>>>>       dc:identifier
> >>>>> "http://ambit.uni-plovdiv.bg:8080/ambit2/feature/12122"^^xsd:anyURI
> ;
> >>>>>       dc:title "ActivityOutcome_CPDBAS_SingleCellCall" ;
> >>>>>       ot:acceptValue "inactive" , "active" ;
> >>>>>       ot:hasSource
> >>>>> <http://ambit.uni-plovdiv.bg:8080/ambit2/reference/11847> ;
> >>>>>       ot:units "" ;
> >>>>>       =       ot:ActivityOutcome_CPDBAS_SingleCellCall .
> >>>>>
> >>>>>
> >>>>> <http://ambit.uni-plovdiv.bg:8080/ambit2/feature/12124>
> >>>>>       a       ot:Feature , ot:NumericFeature ;
> >>>>>       dc:identifier
> >>>>> "http://ambit.uni-plovdiv.bg:8080/ambit2/feature/12124"^^xsd:anyURI
> ;
> >>>>>       dc:title "STRUCTURE_MolecularWeight" ;
> >>>>>       ot:hasSource
> >>>>> <http://ambit.uni-plovdiv.bg:8080/ambit2/reference/11847> ;
> >>>>>       ot:units "" ;
> >>>>>       =       ot:STRUCTURE_MolecularWeight .
> >>>>>
> >>>>>
> >>>>> Bug reports are of course welcome at the usual place
> >>>>>
> >>>>> http://sourceforge.net/tracker/?group_id=191756
> >>>>>
> >>>>> Best regards,
> >>>>> Nina
> >>>>>
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>> 1) Feature data types:
> >>>>>> Proposal (based on Pantelis suggestions and Protege guide) at
> >>>>>> http://opentox.org/data/documents/development/RDF%20files/Datatypes
> .
> >>>>>> Updated opentox.owl at
> >>>>>>
> >>>>>>
> >>>
> http://opentox.org/data/documents/development/RDF%20files/OpenToxOntology/view
> >>>
> >>>>>>
> >>>>>>
> >>>>> _______________________________________________
> >>>>> 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
> >>>>
> >>>>
> >>> _______________________________________________
> >>> Development mailing list
> >>> Development at opentox.org
> >>> http://www.opentox.org/mailman/listinfo/development
> >>>
> >>>
> >>
> >> --
> >> Surajit Ray
> >> Partner
> >> www.rareindianart.com
> >>
> >>
> >>
> >>
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > 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
>



-- 
Surajit Ray
Partner
www.rareindianart.com