Dear All,
    I just deployed the new version of Jaqpot3 at
http://opentox.ntua.gr:8080 (source code at
https://github.com/alphaville/jaqpot3 ). Certain things need to be
optimized (JVM options, MySQL server, etc). On /monitoring you can find
a monitoring facility powered by JavaMelody while on /dbstats an XML is
retrurned with statistics about the database. I will soon circulate some
instructions and cURL commands we have used for testing. Please send me
if you notice any inconsistencies. 

Best Regards
Pantelis


On Mon, 2011-04-11 at 15:57 +0300, chung wrote:

> Dear all,
>     Soon our services will be up and running so I'd like to share with
> you some extensions as well as some ideas.
> 
> 1. Rescue Service
>     When one applies a DELETE on a resource (such as a model, a task or
> a bibtex resource) it is not really deleted from the database but it's
> deactivated. The deleted resource will return a status code 404 (not
> found) accompanied by an Error Report (in RDF). The deactivated
> resources however are still on the server and will remain there for one
> month (we have a lot of disk space, so we think we can cope with it...).
> Now, if the user wants to recover a resource that was deleter by mistake
> he can apply a get on /rescue?id={resource-id} or /rescue?uri={uri of
> previously deleted resource}. I was thinking that this can be a
> interface with access restricted to system admins only so it remains
> easy for the end-user to send an email to us and we can recover the
> deleted resource unless one month has passed and it has been deleted
> automatically. This can of remain out of specification.
> 
> 2. BibTeX service
>     The BibTeX service the runs under jaqpot is tested however it will
> remain inactive or even useless if we don't find a way to associate
> BibTeX entries with other resources. I was thinking of a REST API that
> would look like the following...
> 
> resource  /bibtex/{id}
> method   POST
> POSTed Parameters 
>   1. resource_uri  [ The uri of the resource we want to associate with
> the bibtex entry. ]
> Header Parameters
>   1. subjectid [The authentication token. Specified by the underlying
> policy]
> 
> This way we establish 1-to-many relationships between bibtex entries and
> other resources. Each BibTeX entry will provide a list of the resources
> that cite it. Inversely every algorithm and every model will potentially
> point to bibtex entry. Algorithms for example will carry a pointer to a
> bibliographic reference which the user will be able to download in
> various supported formats (such as the standard JSON-based BibTeX
> format). From the ontological point of view we need to introduce a new
> property, let's say ot:bibtex with domain ot:OpenToxResource and range
> knouf:Entry. 
> 
> 
> 3. Fast RBF Neural Networks
>     An initial implementation of a high-performance RBF-NN training
> algorithm will be available. It has been tested on a variety of
> datasets. 
> 
> 4. Consensus Modeling
> 
>     We currently work on the design of a simple consensus modeling
> algorithm. The algorithm accepts as input a series of model URIs and one
> of DoA models of the same length (For example, the user has to provide 2
> predictive models and 2 corresponding DoA "models" that were trained
> using the same dataset. The consensus model that is trained outputs the
> average of the predictions that are obtained by the sub-models that
> include the submitted instances in their DoA. A cURL request is expected
> to look like that:
> 
> 
> curl -X POST 
> -d model_uri[]={model1}    -d model_uri[]={model2} 
> -d doa[]={doa1 for model1} -d doa[]={doa2 for model2} 
> host:port/algorithm/consensus 
> -H subjectid:{token}
> 
> As soon as the services are up again we'll ask from Vedrin to start
> smokeping tests and we expect better performance and stability.
> 
> Best Regards,
> Pantelis
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>