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.

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