Hi Martin,
  Here is what I suggest to have a service that will allow querying in
the future and will be easy to implement:

1. The service receives an RDF representation of a QPRF report
2. Parse it and get the following information:
     i. Compound URI + Title
     ii. Model URI + Title
     iii. Algorithm URI + TItle
     iv. Applicability Domain URI + Title
   (Do not parse any other information)
3. Store the above in a Relational Database (in a single table) using
the report's URI as the Primary Key
4. Append a table column in that table pointing to a file on the server
where the complete POSTed representation of the report is found.

If one asks for a certain QPRF report, search for it in the database,
locate the file and return it as is. Later you can add querying services
allowing the clients to have a URI list of all QPRF reports that refer
to some compound or applicability domain etc...

Best Regards,
Pantelis

On Thu, 2010-07-15 at 08:39 +0200, Martin Guetlein wrote:

> Hi Pantelis, All,
> 
> I have a general question considering the Reach report formats
> (QMRF/QPRF). I am wondering whether I should store each field of the
> report (like e.g. qprf_report_xy/substance/structure_codes/SMILES), or
> whether it is enough to only store links to the OpenTox-Resources like
> compound_uri (further information could be retrieved from the compound
> service).
> (This was not totally clear from your suggestion, on slide 9 you wrote
> that the compound identifiers like Smiles should be available in the
> report, without more detailed specification.)


All these information will be contained in the RDF of the report which
you can store as is.

Here, a reasonable question raises: Why store these information (e.g.
SMILES) since it can be retrieved from the compound URI by a HTTP URI.
1. There might be no compound URI: Users must be allowed to create and
store reports about compounds of their own that cannot be found in any
OpenTox database service.
2. The user might have added additional information that are not found
in the representation of the compound URI or may have added meta
information about the compound (comments, description etc) that might be
useful in the report.

After all I think it will be easier to store it as is and not parse all
of it. 

Regards,
Pantelis

> 
> The first approach, storing mainly links to resources, would assure
> that the report is consistent, and that there is no redundant
> information. However the user can make changes only to certain fields,
> and the report depends on other services.(This would require many
> changes to the QMRF editor).
> 
> The other approach, storing each field, would lead to some redundant
> information, but it would leave it to the user to make comments, and
> add additional info to all fields (This is how it is implemented in
> the QMRF editor). We of course could guide the user in the editors,
> still the report could be inconsistent.
> 
> I prefer the second approach. What do you think?
> 
> Regards,
> Martin
> 
> On Wed, Jul 14, 2010 at 3:36 PM, chung <chvng at mail.ntua.gr> wrote:
> > Hi All,
> >
> > Find attached an updated version...
> >
> > On Wed, 2010-07-14 at 15:47 +0300, chung wrote:
> >
> >> Dear Martin, All,
> >>  Please find attached a proposal about the structure of a data model for
> >> a QPRF report. Please take a close look in comparison with the JRC
> >> specifications and check if there are any missing properties. Note that
> >> this is a first draft and probably it will need modifications. What we
> >> need to do next is update the OpenTox OWL file according to the
> >> requirements of QPRF reports. I modified a bit the GUI to resemble with
> >> the structure of the QPRF report (using sections and subsections).
> >>   I also attach a progress report of ours I had prepared for our last
> >> meeting.
> >>
> >> Cheers,
> >> Pantelis
> >> _______________________________________________
> >> 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
> >
> >
> 
> 
>