Hi Martin, All,
    I more or less agree that we should restrict ourselves into
providing 
  only some absolutely necessary functionalities for the time and
extend 
  the editor(s) later. I'd like to outline my perception about the GUI
design 
  and the use case behind that.

--> First of all the GUI is not much more than a decorated 
      user-friendly web client that exploits the QPRF reporting 
      web service to create/store a QPRF report according to 
      the JRC specifications.

 I'd like to go into some further detail about the use case and
user requirements about the editor so I summarize a list of 
must-have and should-have functionalities for the first version 
of the editor:

MUST-HAVE FEATURES:
1. Create an empty report (This is the easiest thing to do...). 
    The user fills out all fields needed for the QPRF report 
    (see JRC specifications). 
    Once the user has completed report editing he can:
  i.  Store it locally (in RDF format)
  ii. Store it on a remote server and acquire a report URI.
  ii. Export it as PDF (The pdf creation is done using the QPRF
reporting service)

2. User can load a report from the remote server providing the report's
URI. 
    The report is downloaded in RDF format and it's content is
displayed 
    in a user-friendly manner. In no way does the user interact with
RDFs.

3. Once the user has completed editing a report he can either store it
locally 
    or in a remote server. In the latter case, a report URI is returned
to the 
    user. The report is stored in RDF. 

EXTENSIONS:

1. User creates a report providing a compound and/or a model. 
    The compound can be identified by its name, smiles or even 
    its URI. The user can choose a model from a list (using the
ontology 
    service) or provide the model URI manually. Credentials might 
    need to be provided. User credentials are stored in the current 
    session so that the user won't have to re-enter them.


On Mon, 2010-07-05 at 17:33 +0200, Martin Guetlein wrote:

> 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, 

By 'internally' you mean information retrieval from remote servers?

> make validations

You mean by model validations?

>  - leave fields that cannot be filled out automatically (need more user
> input)

Indded, there are quite a lot such meta information (e.g. Comments on
the uncertainty of the prediction).

> * provide already existing qmrf / qprf reports

Are there any existing QPRF reports in a format different from PDF?

> * 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)


As I mentioned in our previous virtual meeting, it might seem more
difficult to work with RDF rather that with some XML of ours but it is
both easier and also better practice than XML. Existing RDF
representations will be easily embedded into the RDF representation of
the QPRF report. The parsing will be carried out using Jena. Also, using
RDF uniformness is retained.


>  - 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

I think creation of a new report is something quite easy and
straightforward so it could be a must-have one.

> * browse existing reports
> * communicate with various opentox web services to automatically fill out
> additional fields

Such as?

> 
> 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.


We could have a draft todo list by tomorrow to be discussed and
finalized on Friday.

> 
> Best regards,
> Martin
> 
> 
> 

Best Regards,
Pantelis