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)



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
>