source: trunk/doc/specifications/features.html @ 2304

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

Changed copyright statement.

  • Property svn:eol-style set to native
  • Property svn:keywords set to Id Date
File size: 11.8 KB
1<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "">
3  $Id: features.html 2304 2006-05-22 09:37:00Z jari $
5  Copyright (C) Authors contributing to this file.
7  This file is part of BASE - BioArray Software Environment.
8  Available at
10  BASE is free software; you can redistribute it and/or
11  modify it under the terms of the GNU General Public License
12  as published by the Free Software Foundation; either version 2
13  of the License, or (at your option) any later version.
15  BASE is distributed in the hope that it will be useful,
16  but WITHOUT ANY WARRANTY; without even the implied warranty of
18  GNU General Public License for more details.
20  You should have received a copy of the GNU General Public License
21  along with this program; if not, write to the Free Software
22  Foundation, Inc., 59 Temple Place - Suite 330,
23  Boston, MA  02111-1307, USA.
26  <head>
27    <title>BASE - Preliminary list of features</title>
28  <link rel=stylesheet type="text/css" href="../styles.css">
29  </head>
32<div class="navigation">
33  <a href="../index.html">BASE</a>
34  <img src="../next.gif">
35  Preliminary list of features
38  <h1>Preliminary list of features</h1>
40  <div class="abstract">
41    <p>
42    This is the list of features we would like to see in the <b>core</b>
43    of BASE 2, as seen somewhat from a user's perspective. There will be a
44    separate document describing the more technical aspects of these
45    features, and yet another document detailing features that do not need
46    to go into the core.
47    </p>
49    <p class="authors">
50    <b>Created by:</b> Carl<br>
51    <b>Contributions by:</b> Nicklas, Johan<br>
52    <b>Last updated:</b> $Date: 2006-05-22 09:37:00 +0000 (Mon, 22 May 2006) $
53    </p>
54  </div>
55  <br>
59<li>User system
61  <li>User accounts
62  <li>Groups
63  <li>Roles for global access rights
64    <div class=sub>A role is a set of global access rights. Assigning
65    users roles makes it easier to update the rights for a whole set of
66    users.</div>
67  <li>Authentication system with multiple sessions per user
68  <li>Anonymous guest accounts
69  <li>Tracking of disk usage, with quotas
74  <li>Logging system for easy troubleshooting
75  <li>Powerful external API
76    <div class=sub>For use by web interface, external applications,
77    analysis tools.</div>
78  <li>Queueing system for resource-intensive tasks
81<li>Item class
83  <li>Access levels: read, reference, use, alter, remove
84    <div class=sub>The difference between 'reference' and 'use' is that
85    with the 'use' right the user may e.g. decrease the remaining quantity
86    of a biomaterial.</div>
87  <li>Sharing of Items with multiple users/groups
88    <div class=sub>A key is a set of users/groups with access levels.
89    An Item can be shared with an anonymous key, so that all one sees
90    is that it's shared with a specified set of users/groups, and
91    if this set is changed nothing happens to other Items.
92    Alternatively, it can be shared with a named key, e.g. "my friends",
93    consisting of a set of users/groups that can be changed. This way
94    one can share multiple items with collaborators and easily change
95    the collaborator list without having to alter actual groups.</div>
96  <li>Recursive sharing/unsharing of items
97  <li>Almost everything is an Item
98  <li>All modifications are logged to the database
101<li>Annotation system
103  <li>Almost all Items can be annotated
104  <li>An Item may have one Annotation of each applicable AnnotationType.
105  <li>Each AnnotationType has a value type.
106  <li>Value types: Ontologies (GO, MGED, etc), numbers, text, sets, files, ...
107  <li>An AnnotationType is defined on one Item class
108    <div class=sub>For instance: 'Sample age' is not the same thing
109    as 'Extract age'.</div>
110  <li>Annotations on items are inherited between classes
111    <div class=sub>E.g.: An extract has sample annotations, because it's
112    created from a sample. These annotations are not merely copied on
113    extract creation, but instead follow the sample's annotations at all
114    times.</div>
115  <li>On pooling of Items, consensus Annotations are created
116    <div class=sub>When several Items (such as extracts or wells) pooled
117    into one, their annotations need to be combined in a meaningful way.
118    Ideally, a consensus annotation would be created in a type-dependent
119    way. A complication is that this should be done dynamically, so that
120    downstream annotations are kept current. This is a technical problem
121    which needs to be solved.</div>
122  <li>Channels need to be considered
123    <div class=sub>For Hybridizations and downstream Items, the
124    biomaterial annotations are associated with a channel. Also see the
125    dye-swap issues below (in the raw data section).</div>
126  <li>Annotations are fully searchable
127    <div class=sub>One could e.g. filter RawBioAssays on their channel 1
128    sample disease status.</div>
133  <li>Different types of protocols
134  <li><s>Protocol subtypes for plate events
135    <div class=sub>Users may define new subtypes.</div></s>
140  <li>Personal file upload area
141  <li>The upload area may be structured ??
142    <div class=sub>Directories in the upload area?</div>
147  <li>Grouping of some items into Projects
148    <div class=sub>For instance: Biomaterials, Experiments, Protocols and
149    Uploads.</div>
154  <li>SampleSource -&gt; Sample -&gt; Extract -&gt; LabeledExtract
155    &lt;- Label
156  <li>Pooling (Samples -&gt; Sample etc.)
157    <div class=sub>E.g.: Five samples are pooled to make one sample. From
158    the samples and pool six extracts are created. Five extracts
159    are pooled, levaing the user with seven extracts...</div>
160  <li>Resource tracking
161    <div class=sub>Rather than just keeping track of the remaining
162    quantity, we should remember all withdrawals of material.</div>
167  <li>Annotatable
168  <li>Admin-defined columns
169  <li>Connection to external databases
170    <div class=sub>Admin defines external databases, tables, columns and
171    how to pull data from them (e.g. what type of join).</div>
172  <li>Store the type of the reporter ID.
173    <div class=sub>Only allow well-defined types.</div>
174  <li>Easy redefinition of web links
175    <div class=sub>Even though these are somewhat interface-specific, the
176    data-dependent links corresponding to different columns should be part
177    of the core.</div>
180<li>Array LIMS: Plates
182  <li>Geometries (columns / rows)
183    <div class=sub>Generalization of the 96 well / 384 well stuff in BASE
184    1.</div>
185  <li>Plate types with different geometries, event types and annotation
186  types
187    <div class=sub>An event is date/protocol/comment (should this be a
188    general annotation value type?).</div>
189  <li>Plates, each of a plate type and containing a number of wells
190  <li>Fully annotatable wells on plates
191    <div class=sub>Do we allow pooling of wells? In either case,
192    annotations will be tricky to inherit. Consider a tree of wells. If
193    one is annotated as being contaminated, the rest may also be. There
194    will have to be different ways to search well annotations (annotations
195    on the same well, annotations on all related wells, etc.).</div>
196  <li>Plate import from files with user-defined file formats
197  <li>Hitpicking
198    <div class=sub>Creating plates with material from other plates in an
199    arbitrary (acyclic) way.</div>
200  <li>Plate merging
201    <div class=sub>E.g. from 96w to 384w, with definable well mapping.
202    Mappings should be defined for different geometries. Maybe maintain a
203    list of possible source and destination plate types for merging, as
204    well as for the simpler action of 1-to-1 plate creation.</div>
207<li>Array LIMS: Arrays
209  <li>ArrayDesign -&gt; ArrayBatch -&gt; ArraySlide
210  <li>Feature specified on ArrayDesign by block/column/row.
211    <div class=sub>A Feature maps a position to a well or a reporter.</div>
212  <li>Meta-row/meta-column should map to block number
213  <li>Association of Plates and ArrayDesign
214    <div class=sub>It should be possible to dissociate, but only if
215    Features don't exist (yet).</div>
216  <li>Features can be created by print maps or 'reporter maps'.
217    <div class=sub>A 'reporter map' maps block/column/row to a reporter.
218    Maybe we should rename it to 'feature map'? A print map maps
219    plate-number/column-in-plate/row-in-plate to a position on the array
220    design, so that Features can be created given the list of
221    plates.</div>
222  <li>Possible to destroy Features if unreferenced
223    <div class=sub>Needed to redo plate association.</div>
224  <li>Add new print map formats easily
229  <li>LabeledExtract(s) -&gt; Hybridization -&gt; Scan -&gt;
230    ImageAcquisition -&gt; Image
231  <li>Arbitrary number of channels
232  <li>Allow the removal of image files without losing image information
235<li>Raw data
237  <li>(ImageAcquisition -&gt;) RawBioAssay
238    <div class=sub>The RawBioAssay may be the starting point for data
239    input.</div>
240  <li>User-definable formats for raw data
241  <li>Consistency with ArrayDesign
242    <div class=sub>Raw data must be verified against ArrayDesign.</div>
243  <li>Each spot has a position, a Reporter, and a Feature.
244  <li>Admin-defined RawBioAssayData table
245    <div class=sub>Because of the sheer number of spots, this seems like a
246    reasonable way to handle the problem of platform differences.</div>
247  <li>Spot image creation for 1 - 3 channels
248    <div class=sub>Spot images are extracted from TIFFs belonging to the
249    ImageAcquisition and JPEG-compressed after rescaling and gamma
250    correction.</div>
253<li>Experiment and analysis
255  <li>The channel count is fixed within an Experiment
256  <li>An Experiment has BioAssaySets consisting of BioAssays
257  <li>BioAssays have parent BioAssays and RawBioAssays
258    <div class=sub>Each may have multiple parents.</div>
259  <li>Each spot has position, intensities, reporter in BioAssay.
260  <li>Flexible tracking of spot origin
261    <div class=sub>Spots usually point back to spots with the same
262    position on the parent BioAssay(s), but may be mapped in an arbitrary
263    way. The same applies to parent RawBioAssays.</div>
264  <li>Extra values may be attached to spots
265    <div class=sub>The value type must be defined (at the very least
266    named), and values must be attached to all spots within the
267    BioAssaySet.</div>
268  <li>Values may be attached to positions within a BioAssaySet.
269  <li>Possibility to keep attached values through subsequent
270    analysis steps
271  <li>Possibility to retain positions / Reporters for which all
272    spots have been lost
273  <li>Allow raw channels to be mapped to channels in any way (dye-swap)
274    <div class=sub>Ratios in the raw data need to be handled.</div>
275  <li>Store and use info about experimental design
276    <div class=sub>For experiments without a common reference sample, but
277    maybe also as a general way of handling dye-swaps.</div>
278  <li>Advanced filtering without external applications
279    <div class=sub>For instance, "keep spots whose reporters are up
280    twofold on at least 3 slides annotated as 'disease'" or "((Ch1 FG med
281    / Ch1 BG med &gt; 5) in Raw Data Set 1) OR ((Ch1 FG med / Ch1 BG med
282    &gt; 5) in Raw Data Set 2)".</div>
283  <li>Files and other data attached to transformations/jobs
284    <div class=sub>For use by externals tools.</div>
287<li>General search interface <div class=sub>External programs / user
288  interfaces need to know what can be filtered on and what information can
289  be retrieved.</div>
291  <li>Specification of what can be searched on
292  <li>Specification of possible operators
293  <li>Specification of possible values
294  <li>Specification of what can be returned
295  <li>Specification of sortability
296  <li>What about grouping, discretization, histograms?
297    <div class=sub>These are useful for generating plots, and leave a lot
298    of number crunching to the database.</div>
299  <li>Filtering presets (core feature or not?)
300  <li>Presets transferrable between search types ??
301  <li>Retrieval of statistics on RawBioAssays and BioAssays
302    <div class=sub>E.g., the percentage of flagged spots. This is useful
303    when combined with annotations and other upstream data (such as the
304    name of the experimenter).</div>
Note: See TracBrowser for help on using the repository browser.