Hi Martin,

Both approaches have pros and cons. With RDF one could have both in one
place actually - we could have a link-only approach where in RDF uses only
pointers to resources, and a "full" version, where RDF representations of
these resources are included in the report.

e.g. one could have only compound URI, but also in the "full" version SMILES
and any other properties of the compound (SMILES included), via same
opentox.owl representation.

As a background, you might already be aware QMRF deals with compounds and
descriptor data via "attachments" , which are actually links to the files,
uploaded at JRC site (qsardb.jrc.it)  - real embedding of not XML-data into
QMRF XML is something we have played with, but it is not really convenient.
And if you download the QMRF XML, then download attachments separately and
store in a local folder, the links in the XML will point back to the JRC
site , which might not be exactly what is expected.

Best regards,
Nina

On Thu, Jul 15, 2010 at 9:39 AM, Martin Guetlein <
martin.guetlein at googlemail.com> 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.)
>
> 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
> >
> >
>
>
>
> --
> 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
> _______________________________________________
> Development mailing list
> Development at opentox.org
> http://www.opentox.org/mailman/listinfo/development
>