On Mon, Jul 12, 2010 at 1:04 PM, Nina Jeliazkova
<jeliazkova.nina at gmail.com> wrote:
> On Mon, Jul 12, 2010 at 1:16 PM, chung <chvng at mail.ntua.gr> wrote:
>
>> Hi Martin,
>>
>>
>> On Mon, 2010-07-12 at 10:40 +0200, Martin Guetlein wrote:
>>
>> > 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.
>>
>> Why should the web service create  an empty report? I mean this is more
>> or less some
>> static information. I don't see any obvious reasons for having it
>> deployed on the web.
>>
>
> It make sense to have web service functionality to
> 1)create empty report
> 2)have different sections of the report exposed by URIs
> 3)update different sections of the report (by PUT / POST to the sections
> URIs)

This sounds sensible, and should work rather straightforward, just
following the report-(xml)-structure.

For example the title for qmrf could be accessed via:
http://<report-service>/qmrf/<report-id>/QMRF_chapters/1/QSAR_title

This should work as soon as rdf is supported as well.

Regards,
Martin

>
>
>
> Just my 2 cents.
>
> Nina
>
>>
>> > Again, I do not think RDF is a must have feature (rather than the
>> > 'official' no yet defined format).
>>
>> OK, then let's use the existing XML for the QPRF report.
>>
>> Best regards,
>> Pantelis
>>
>> >
>> > >
>> > > 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)
>> > _______________________________________________
>> > 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
>



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