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

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

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