source: trunk/doc/historical/specifications/core/arraylims.html @ 4509

Last change on this file since 4509 was 4509, checked in by Jari Häkkinen, 15 years ago

Addresses #1106. Missed to change reference wherefrom retrive GPLv3 license text. And some other changes.
  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Date
File size: 9.6 KB
Line 
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
2<!--
3  $Id: arraylims.html 4509 2008-09-11 20:01:44Z jari $
4
5  Copyright (C) 2005 Jari Hakkinen, Nicklas Nordborg
6  Copyright (C) 2006 Jari Hakkinen
7
8  This file is part of BASE - BioArray Software Environment.
9  Available at http://base.thep.lu.se/
10
11  BASE is free software; you can redistribute it and/or
12  modify it under the terms of the GNU General Public License
13  as published by the Free Software Foundation; either version 3
14  of the License, or (at your option) any later version.
15
16  BASE is distributed in the hope that it will be useful,
17  but WITHOUT ANY WARRANTY; without even the implied warranty of
18  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
19  GNU General Public License for more details.
20
21  You should have received a copy of the GNU General Public License
22  along with BASE. If not, see <http://www.gnu.org/licenses/>.
23-->
24<html>
25  <head>
26    <title>BASE - Core specification - Array LIMS</title>
27  <link rel=stylesheet type="text/css" href="../../styles.css">
28  </head>
29<body>
30
31<div class="navigation">
32  <a href="../../index.html">BASE</a>
33  <img src="../../next.gif">
34  <a href="index.html">Core specification</a>
35  <img src="../../next.gif">
36  Array LIMS
37</div>
38
39  <h1>Array LIMS</h1>
40
41  <div class="abstract">
42    <p>
43    This document covers the details of how the array LIMS
44      part of BASE works.
45    </p>
46
47    <b>Contents</b><br>
48    <ol>
49    <li><a href="#probe" class="invalid">Probe</a>
50    <li><a href="#plategeometry">Plate geometry and mapping</a>
51    <li><a href="#platetype">Plate type</a>
52    <li><a href="#plate">Plate</a>
53    <li><a href="#arraydesign">Array design</a>
54    <li><a href="#affy">Affymetrix probes</a>
55    <li><a href="#arraybatch">Array batch</a>
56    <li><a href="#arrayslide">Array slide</a>
57    </ol>
58   
59    <b>See also</b><br>
60    <ul>
61    <li><a href="../../development/overview/data/plates.html">Implementation overview - plates</a>
62    <li><a href="../../development/overview/data/slides.html">Implementation overview - slides</a>
63    </ul>
64
65    <p class="authors">
66    <b>Last updated:</b> $Date: 2008-09-11 20:01:44 +0000 (Thu, 11 Sep 2008) $
67    </p>
68  </div>
69
70
71  <div class="invalid">
72  <a name="probe">
73  <h2>1. Probe</h2>
74  </a>
75
76  <ol>
77  <li>A probe represents a physical reporter. It exists only because
78    the same reporter acquired from different sources may in fact
79    be different (because of contamination or whatnot).
80  <li>It points to a reporter, and is immutable.
81  </ol>
82  </div>
83
84
85  <a name="plategeometry">
86  <h2>2. Plate geometry and mapping</h2>
87  </a>
88
89  <ol>
90  <li>A plate geometry describes how the way wells are laid out on a plate.
91  <li>The number of rows and columns is all the information stored
92    about a geometry (for now, at least).
93  <li>A plate mapping defines how wells from a list of N plates of
94    one geometry can be mapped over to a list of M plates of another
95    (or the same) geometry.
96  </ol>
97
98  <a name="platetype">
99  <h2>3. Plate type</h2>
100  </a>
101
102  <ol>
103  <li>A plate type describes a particular type or use of microtiter
104    plate, such as "PCR plate".
105  <li>A plate type has a geometry.
106  <li>For each plate type there are a number of plate event types.
107    Each event type has a name and points to a protocol type.
108  </ol>
109
110
111  <a name="plate">
112  <h2>4. Plate</h2>
113  </a>
114
115  <ol>
116  <li>A plate represents a physical microtiter plate, possibly only at
117    some stage in its existence.
118  <li>A plate is of a plate type, and may have events correspondig to
119    this type's event types. For each event, there is a protocol of
120    the event type's protocol type. Also, each event has a date and
121    a comment.
122  <li>A plate consists of wells. Each well has a row and column
123    coordinate, and these must be within the limits set by the plate
124    geometry. Wells cannot be added or removed once the plate has
125    been created.
126  <li>Each well may be associated with a <span class="invalid">probe</span>
127    reporter.
128  <li>A well may have a parent, which has to have the same
129    <span class="invalid">probe</span> reporter as
130    the well itself.
131  <li>A plate P may have an ordered list of parents. This list must
132    include all plates which contain wells which are the parents of
133    wells on the plate P.
134  <li>The position in the list of parent plates corresponds to the
135    order of N in the plate mapping discussed in the section on
136    Plate geometry.
137  <li>If a plate was created using a plate mapping, it should point
138    to that mapping and know which of the M created plates it was.
139  <li>Wells can be annotated.
140  <li class=note>[implementation note] To facilitate searches on well
141    annotations it may be necessary to maintain a table with all
142    ancestor/descendant well pairs. The trees of wells are expected
143    to be shallow enough to prevent this from being problematic.
144  <li class=note>[note] It's sometimes necessary to identify plates
145    by name, but this should be solved without requiring plate names to
146    be unique (this was a source of problems in BASE 1).
147  <li class=note>[clarification] Plates can be created from scratch, or
148    from a set of existing plates (using a plate mapping). The most
149    common case is that a plate is created from a single plate of
150    the same geometry, with wells being mapped to the same coordinates.
151  <li>A plate cannot have fewer wells than its geometry indicates.
152    <span class="invalid">If
153    wells are missing when a plate is created, the reporter whose
154    reporter id is an empty string should be used for the missing
155    wells.</span>
156  </ol>
157
158
159  <a name="arraydesign">
160  <h2>5. Array design</h2>
161  </a>
162
163  <ol>
164  <li>An array design describes a particular microarray design; what
165    sits where on what kind of substrate.
166  <li>An array design needs a number of description fields, as given
167    by MIAME.
168  <li>Array designs can be annotated. Some MIAME-mandated properties
169    have MGED ontologies, and these should be used if possible.
170  <li>A list of plates may be associated with an array design. These
171    plates are the ones that were/should be used in printing slides
172    of this array design.
173  <li>An array design will at some point get a set of features.
174    A feature maps a position on the array to a reporter, and possibly
175    also to a specific plate well. The position is most generally
176    specified as metarow/metacolumn/row/column.
177  <li>If an array design is associated with plates, its features are
178    created when a print map is added to it. A print map maps
179    plate wells to feature positions. Each feature created in this way
180    will point to the plate well it was created from, as well as to
181    the well's probe's reporter. If the print map contains enough
182    information for this, plates may be associated with the array
183    design as the print map is being added.
184  <li>An array design not associated with plates may have its features
185    created from a mapping from positions to reporters.
186  <li>Once an array design has had features added to it, it is not
187    possible to remove the features, nor to change the association
188    with plates. However, features should be removed if not used.
189  <li>It should be possible to store the print map (or other file used
190    to create the features) together with the array design.
191  <li>All coordinates in an array design must have features.
192  </ol>
193
194
195  <a name="affy">
196  <h2>6. Affymetrix data</h2>
197  </a>
198
199  <ol>
200    <li>An array design may describe an Affymetrix chip, and if it
201      does a special flag should be set.
202    <li>Affy probesets should be represented by reporters in BASE.
203    <li>An affyprobe may have a sequence, or nothing at all except
204      an internal id.
205    <li>There is a table which connects affyprobes to reporters.
206      Each row tells whether the affyprobe is a perfect match or
207      mismatch, what number it has in the list of probes for this
208      probeset (so that pm/mm pairs can be identified), and what
209      feature defines its position. <span class=question>Also, since
210      an entire reporter may be replicated, should there also be a
211      number identifying what replicate the affyprobe belongs to?</span>
212    <li>Features need to be added before the affy-specific data.
213      If a feature is only used for one reporter (which is expected
214      to always be the case), it should point to that reporter.
215      If a feature is used for more than one probeset, it may point
216      to the reporter whose reporter id is the empty string.
217  </ol>
218
219  <a name="arraybatch">
220  <h2>7. Array batch</h2>
221  </a>
222
223  <ol>
224  <li>An array batch describes a batch or single print run for one
225    array design.
226  <li>It should be possible to record factors affecting the array
227    slide quality, such as the temperature during printing.
228    This may be done through annotations.
229  <li>Array batches can be created for array designs which do not
230    yet have features, but user interfaces should warn the user
231    that the feature adding still needs to be done. As feature
232    creation cannot be undone, the array batch will need to be
233    recreated if the feature adding goes bad (if the print map
234    is wrong, for instance).
235  </ol>
236
237
238  <a name="arrayslide">
239  <h2>8. Array slide</h2>
240  </a>
241
242  <ol>
243  <li>Each array batch consists of a number of individual array
244    slides, which are identified by a barcode.
245  <li>Array slides can be added to an existing array batch at any
246    time.
247  <li>An array slide may be associated with a hybridization. Only one
248    slide may be associated with a single hybridization.
249  <li>An array slide may be dissociated from its hybridization at
250    any time.
251  <li>Array slides may be flagged as having been physically destroyed
252    without having been used, in which case they may not be connected
253    to hybridization.
254  <li>It would be useful to enforce barcode uniqueness, but it would
255    cause problems with the deleting/undeleting of array slides, and
256    so it's the users' responsibility to keep barcodes unique.
257  </ol>
258 
259
260  <!--
261  <a name="implementation">
262  <h2>9. Implementation overview</h2>
263  </a>
264
265  <h3>9.1 Database schema</h3>
266  <p>
267  <img src="images/arraylims.gif">
268  </p>
269  -->
270
271</body>
272</html>
273
Note: See TracBrowser for help on using the repository browser.