BASE Core specification Array LIMS

Array LIMS

1. A plate geometry describes how the way wells are laid out on a plate.
2. The number of rows and columns is all the information stored about a geometry (for now, at least).
3. A plate mapping defines how wells from a list of N plates of one geometry can be mapped over to a list of M plates of another (or the same) geometry.

1. A plate type describes a particular type or use of microtiter plate, such as "PCR plate".
2. A plate type has a geometry.
3. For each plate type there are a number of plate event types. Each event type has a name and points to a protocol type.

1. A plate represents a physical microtiter plate, possibly only at some stage in its existence.
2. A plate is of a plate type, and may have events correspondig to this type's event types. For each event, there is a protocol of the event type's protocol type. Also, each event has a date and a comment.
3. A plate consists of wells. Each well has a row and column coordinate, and these must be within the limits set by the plate geometry. Wells cannot be added or removed once the plate has been created.
4. Each well may be associated with a probe reporter.
5. A well may have a parent, which has to have the same probe reporter as the well itself.
6. A plate P may have an ordered list of parents. This list must include all plates which contain wells which are the parents of wells on the plate P.
7. The position in the list of parent plates corresponds to the order of N in the plate mapping discussed in the section on Plate geometry.
8. If a plate was created using a plate mapping, it should point to that mapping and know which of the M created plates it was.
9. Wells can be annotated.
10. [implementation note] To facilitate searches on well annotations it may be necessary to maintain a table with all ancestor/descendant well pairs. The trees of wells are expected to be shallow enough to prevent this from being problematic.
11. [note] It's sometimes necessary to identify plates by name, but this should be solved without requiring plate names to be unique (this was a source of problems in BASE 1).
12. [clarification] Plates can be created from scratch, or from a set of existing plates (using a plate mapping). The most common case is that a plate is created from a single plate of the same geometry, with wells being mapped to the same coordinates.
13. A plate cannot have fewer wells than its geometry indicates. If wells are missing when a plate is created, the reporter whose reporter id is an empty string should be used for the missing wells.

1. An array design describes a particular microarray design; what sits where on what kind of substrate.
2. An array design needs a number of description fields, as given by MIAME.
3. Array designs can be annotated. Some MIAME-mandated properties have MGED ontologies, and these should be used if possible.
4. A list of plates may be associated with an array design. These plates are the ones that were/should be used in printing slides of this array design.
5. An array design will at some point get a set of features. A feature maps a position on the array to a reporter, and possibly also to a specific plate well. The position is most generally specified as metarow/metacolumn/row/column.
6. If an array design is associated with plates, its features are created when a print map is added to it. A print map maps plate wells to feature positions. Each feature created in this way will point to the plate well it was created from, as well as to the well's probe's reporter. If the print map contains enough information for this, plates may be associated with the array design as the print map is being added.
7. An array design not associated with plates may have its features created from a mapping from positions to reporters.
8. Once an array design has had features added to it, it is not possible to remove the features, nor to change the association with plates. However, features should be removed if not used.
9. It should be possible to store the print map (or other file used to create the features) together with the array design.
10. All coordinates in an array design must have features.

1. An array design may describe an Affymetrix chip, and if it does a special flag should be set.
2. Affy probesets should be represented by reporters in BASE.
3. An affyprobe may have a sequence, or nothing at all except an internal id.
4. There is a table which connects affyprobes to reporters. Each row tells whether the affyprobe is a perfect match or mismatch, what number it has in the list of probes for this probeset (so that pm/mm pairs can be identified), and what feature defines its position. Also, since an entire reporter may be replicated, should there also be a number identifying what replicate the affyprobe belongs to?
5. Features need to be added before the affy-specific data. If a feature is only used for one reporter (which is expected to always be the case), it should point to that reporter. If a feature is used for more than one probeset, it may point to the reporter whose reporter id is the empty string.

1. An array batch describes a batch or single print run for one array design.
2. It should be possible to record factors affecting the array slide quality, such as the temperature during printing. This may be done through annotations.
3. Array batches can be created for array designs which do not yet have features, but user interfaces should warn the user that the feature adding still needs to be done. As feature creation cannot be undone, the array batch will need to be recreated if the feature adding goes bad (if the print map is wrong, for instance).

1. Each array batch consists of a number of individual array slides, which are identified by a barcode.
2. Array slides can be added to an existing array batch at any time.
3. An array slide may be associated with a hybridization. Only one slide may be associated with a single hybridization.
4. An array slide may be dissociated from its hybridization at any time.
5. Array slides may be flagged as having been physically destroyed without having been used, in which case they may not be connected to hybridization.
6. It would be useful to enforce barcode uniqueness, but it would cause problems with the deleting/undeleting of array slides, and so it's the users' responsibility to keep barcodes unique.