[Gusdev-gusdev] update Re: RAD3 Process Tables deprecation

[Elisabetta M. <man...@pc...>]

This is an update on my Dec 8 email attached below.
We have completed this implementation at CBIL. Here are modifications to 
the points I had made on my previous email:

Point 2. We ended up creating RAD3.AssayAnalysis (linking) table 
instead of RAD3.StudyAnalysis table.

Point 3. We have created this view.

Point 5. How to deal with the input LogicalGroup is fairly flexible and 
different instances of GUS might decide to have different policies. Here 
is a snapshot of a few initial policies we are using at CBIL to this end:

* Input LogicalGroups for DataTransformationResult analyses will not be 
nested, i.e. no input will be a LogicalGroup consisting itself of 
LogicalGroups.
* For processes which are simple normalizations of a given quantification 
(or of a pair of quantifications for 2-channel data), the input to the 
analysis will be just ONE LogicalGroup consisting of that quantification 
(resp. pair of quantifications).
* If the processing is normalization of log ratios in each of TWO 
2-channel assays, followed by dye-swap merging, the input will be TWO LogicalGroups, 
each consisting of 2 quantifications: one logical group for the two 
samples that represent the numerator in the resulting dye-swap combination 
and the other for those representing the two samples that represent the 
denominator. Note that in this scenario we won't be grouping together the 
2 quantifications (Cy5 and Cy3) that belong to the same assay.
* If the processing is normalization of log ratios in each of n 2-channel 
assays, the input will be n LogicalGroups, one for each pair of 
quantifications corresponding to the same assay.

Point 6. The AnalysisResultLoader plugin has been modified to deal with 
the new tables/view created and committed to the GUS/RAD cvs at Sanger. 
Documentation is at 
http://www.gusdb.org/documentation/plugins/GUS-RAD-Plugin-AnalysisResultLoader.html

Wishing a nice holiday and a happy New Year to everyone,
Elisabetta

---

On Wed, 8 Dec 2004, Elisabetta Manduchi wrote:

>
> Here at CBIL we have decided to deprecate the usage of the tables 
> RAD3.Process*** and to utilize instead a new view of RAD3.AnalysisResultImp 
> to store the results of a series of DataTransformation protocols. The 
> Analysis tables were created subsequently to the Process tables and have a 
> more mature layout, which should facilitate queries. They were originally 
> created to store down-stream analysis results (e.g. for differential 
> expression or clustering) but they are also suitable for pre-processing 
> result storage.
> The following describes what we are implementing:
>
> 1. We have created a RAD3.ProtocolStep table to identify protocols consisting 
> of an ordered series of (sub) protocols. Every protocol of the latter form is 
> linked through RAD3.ProtocolStep to its components. Its type will be 
> "transformation_protocol_series" (DataTransformationProtocolType).
>
> 2. We'll create a linking table RAD3.StudyAnalysis to facilitate queries.
>
> 3. We'll create a new view of RAD3.AnalysisResultImp, called 
> RAD3.DataTransformationResult, which will store all results from a series of 
> preprocessing steps obtained from protocols with type 
> DataTransformationProtocolType. This will be a simple view with just 5 
> relevant attributes: table_id, row_id (pointing to the spot or to the 
> probeset on the array; a soft link), and float_value/int_value/string_value 
> (which will be what's now currently stored in RAD3.ProcessResult.value).
>
> 4. When a series of processing steps is used, we will only store the results 
> from the *final* step and the corresponding protocol will be of type 
> "transformation_protocol_series".
>
> 5. For processes which are simple normalizations of a given quantification 
> (or of a pair of quantifications for 2-channel data), the input to the 
> analysis will be a LogicalGroup consisting just of that quantification (resp. 
> pair of quantifications). For processes which involve averaging across 
> quantifications the input LogicalGroup will contain 2 or more quantifications
>
> 6. In terms of plugins, the current AnalysisResultLoader in the GUS/RAD cvs 
> repository at Sanger will do. (Enhancements or auxiliary plugins might be 
> written for the specific case in which the analysis is an up-stream (=low 
> level=processing) one. So this plugin will do the job that the 
> ProcessResultLoader was doing for the Process tables.)
>
> Elisabetta
>