On Mon, Jul 5, 2010 at 11:53 AM, Pantelis Sopasakis <chvng at mail.ntua.gr>
wrote:
> Dear all,
>  I'm sending you the brief list of tasks I also presented in today's
meeting
> to comment on if you like:
>
> Current State of Development:
>
> A. QPRF Editor
> * Initial design of the GUI is available at:
>  http://opentox.ntua.gr/Q-edit/launch.html
> * Source code available at:
>  http://github.com/alphaville/Q-edit

Hi Pantelis, All,

nice work, you already have been very busy. I had a look at your editor and
a discussion with Andreas Karwath, and we had the impression that your
editor might be step too far ahead. We do not have much time left, so maybe
we first should agree on the functionality of the OpenTox REACH report
service and the report editors.

That's what we had in mind (the report service api is defined accordingly):

REACH report service features:
--------------------------------------------
* create report
 - internally collect meta-information, make validations
 - leave fields that cannot be filled out automatically (need more user
input)
* provide already existing qmrf / qprf reports
* save changes to existing reports
* provide reports in the following formats:
 - MUST HAVE: format accepted by the EC (for qmrf: existing xml, for qprf:
most likely analogous format)
 - EXTENDED FEATURE: opentox internal rdf-format

QMRF/QPRF editors:
--------------------------------
MUST HAVE:
* open the report in the EC-accepted format
* edit single fields by hand
* save report in EC-accepted format
* export functions supporting document formats like PDF
* QPRF and QMRF editors should have a similar GUI and must be easy to use
EXTENDED FEATURES:
* support opentox internal rdf-format
* init creation of new report
* browse existing reports
* communicate with various opentox web services to automatically fill out
additional fields

In the last goto-meetings we agreed that we could go "rdf-first" for the
QPRF-report and -editor (because it fits into our framework), but we should
keep in mind that the format accepted by the European Commission will
probably be similar to the QMRF format.
For the QMRF, we decided to get it working with the existing qmrf-xml format
first (so that its working in Rhodes), and provide the rdf format later on.

Do people agree on the design of the service and editors? Please provide
some feedback, we could than finalize a TASK/TODO list to be assigned on
Friday.

Best regards,
Martin



>
> B. QMRF Editor
> *  Runs as a JWS application at:
>   http://ambit.sourceforge.net/qmrf/jws/qmrfeditor.jnlp
> *  Is based on XML.
>
> TASKS needed for the integration of the above editors in OpenTox:
>
> For the QPRF editor:
>
-----------------------------------------------------------------------------------
> 1. Completion of GUI design. Feedback from other partners is needed. Any
ideas are
>   welcome.
>
> 2. OpenTox ontology  needs to be extended  to describe QPRF and  QMRF
reports.
> See:
>   http://opentox.org/dev/apis/api-1.2/report
>
> 3. A web service needs to be developed for the creation/storing of QPRF
reports.
>   REST API extensions are quite straightforward yet need to be clarified
and
>   documented at http://opentox.org/dev/apis/api-1.2/report .
>
> 4. Development of a client for the QPRF reporting web service.
>
> 5. Integrate the client in the editor to allow for remote storing of QPRF
> reports,
>   remote loading and PDF creation. All application logic relies on the
service.
>
> 6. Alpha version for testing / Debugging.
>
> 7. Incorporate the QPRF editor in ToxPredict.
>
>
>
> For the QMRF Editor:
>
-----------------------------------------------------------------------------------
> Two alternative scenarios:
> A. Modification of AMBIT's QMRF Editor to work with RDF and development of
a
> QMRF reporting service (Storing of QMRF reports in RDF, Creation of PDF).
> B. Creation of a new Editor from scratch and development of a QMRF
>   reporting service (Storing of QMRF reports in RDF, Creation of PDF).
>
> [Note: Scenario A was accepted due to schedule restrictions (Deliverable
is
> due for August), so QMRF reporting services will be based on AMBIT's QMRF
> editor and the Web Services Martin presented.]
>
> TASKS:
>
> 1. Ontology extensions for QMRF reports. QPRF and QMRF reports should be
> handled in a uniform way in terms of ontology and REST API.
>
> Next steps:
> As above (QPRF Editor case).
>
>
> Best Regards,
> Pantelis
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>



-- 
Dipl-Inf. Martin Gütlein
Phone:
+49 (0)761 203 8442 (office)
+49 (0)177 623 9499 (mobile)
Email:
guetlein at informatik.uni-freiburg.de