On Wed, Jul 7, 2010 at 12:24 PM, chung <chvng at mail.ntua.gr> wrote:
> Hi Martin, All,

Hi Pantelis,

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

You are actually right, that a user could start with a blank report in
the editor. From my point of view, the normal use case would be that a
report is created via report webservice, and can be viewed/edited with
the editor.
Again, I do not think RDF is a must have feature (rather than the
'official' no yet defined format).

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

Same comments as for point 1.


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

I agree, we should provide a nice GUI-supported way to search and
browse the existing reports.

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

right

>
>> make validations
>
> You mean by model validations?

right

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

I meant that the reports are stored on the server (in an internal
format, supported formats for the user are 'official'-xml format,
probably rdf. conversion to pdf/other formats will be done in the
editors).

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

I know the advantages of rdf, however what we must have at the end is
the official EC format, rdf would be nice to have for OpenTox internal
usage.
However, as stated before, we decided that we will start with rdf as
format for QPRF.

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

What I meant, was that it should be possible to initialize the
creation of new report at the webservice (by selecting a model /
compound, and sending the post command to the web services).

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

For example, the Applicability domain section in the QPRF report is
quite detailed (3.3-a-ii, what if the model doesn't use any structural
fragments?).
We could leave those sections empty by default, but give the user some
guidance if he wants to make more experiments.

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

As we already have decided on todo list some time ago, maybe we could
adjust this list to the new requirements (and shift partner
responsibilities if necessary), instead of coming up with a totally
new one?
I added the old list to the end of the mail.

Best regards,
Martin

P.S.: Sorry for answering late, I was away last week for few days.


* by 07.05.2010:
 Definition of the API
   This has already be done by Nina (thanks a lot for that!) and can
be found here (http://www.opentox.org/dev/apis/api-1.1/Validation) -
and Martin and I concur. Probably, others might want to comment (it
still depends on future work regarding automatic filling of parameters
- see below).
   The API would allow as parameters a Model URI, a List of
(cross-)validation URIs (for the same model) and additional parameters
(which cannot be filled automatically, as well as manually constructed
reports in qmrf-xml and a to be defined qprf format. That would mean,
that complete reports can be stored on the OpenTox servers.

* by 01.06.2010:
 ALU-FR:  QMRF: Identify possible attributes for automatic preconstruction
 TUM: QPRF: Identify possible attributes for automatic preconstruction
(in close collaboration with NTUA)

* by 22.06.2010:
 ALU-FR: QMRF: Derive data from web services automatically, construct
XML for Editor
  NTUA and SL: QMRF :Adapt QMRF Editor (Java Webstart, OpenTox design)
from https://ambit.svn.sourceforge.net/svnroot/ambit/trunk/ambit1/src/ambit/data/qmrf
(in collaboration with IBMC)
  NTUA and SL: QPRF : Define (most likely a XML schemata) format for
QPRF (in close collaboration with TUM and Ex-ECB (Andrew needs to be
contacted))

* by 13.07.2010:
 IBMC:  QMRF:  Integrate QMRF-Editor into OpenTox Web services (Get
user input, initialize model building and validation, Start QMRF
editor)
 ALU-FR: QPRF : Derive data from web service automatically, construct
XML for Editor

* by 03.08.2010:
  NTUA and SL: QPRF:  Based on Nina’s QMRF implementation, implement a
QPRF editor (including Java-Webstart and OpenTox design)
  IBMC:   Integrate QPRF-Editor into OpenTox Webservices (Get user
input, initialize model building and validation, Start QPRF editor)