source: trunk/doc/historical/specifications/features.html @ 4889

Last change on this file since 4889 was 4889, checked in by Nicklas Nordborg, 14 years ago

References #1290: Change source files to UTF-8

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