1 |
|
---|
2 | BioPlate events
|
---|
3 | ===============
|
---|
4 |
|
---|
5 | The attached diagram shows new and modified things in the Biomaterial LIMS.
|
---|
6 | There are three new classes:
|
---|
7 |
|
---|
8 | * BioPlateTypeData
|
---|
9 | * BioPlateEventData
|
---|
10 | * BioPlateEventDefinitionData
|
---|
11 |
|
---|
12 | In addition there is a new link from BioMaterialEventData to BioPlateEventData
|
---|
13 | and the BioPlateData class has several new properties and links.
|
---|
14 |
|
---|
15 |
|
---|
16 | BioPlateTypeData
|
---|
17 | ----------------
|
---|
18 |
|
---|
19 | This class is used to group bio plates into different types. A type can:
|
---|
20 |
|
---|
21 | * be locked to a specific biomaterial type which means that it is not
|
---|
22 | possible to mix, for example, samples and extracts on bioplates that
|
---|
23 | uses the type.
|
---|
24 | * lock the wells on the bioplates that uses the type. This means that once
|
---|
25 | a biomaterial has been put in a well, it can't be moved to a different
|
---|
26 | plate/well, nor can it be replaced with another biomaterial
|
---|
27 |
|
---|
28 | The plate type is also used to "root" event definitions, which means that
|
---|
29 | an event is only possible for bioplates of a specific plate type.
|
---|
30 |
|
---|
31 | The installation will (at least) create four generic plate types:
|
---|
32 |
|
---|
33 | * Generic storage plate: mixing is allowed, wells are not locked
|
---|
34 | * Sample reaction plate: only samples, wells are locked
|
---|
35 | * Extract reaction plate: only extracts, wells are locked
|
---|
36 | * Labeled extract reaction plate: only labeled extracts, wells are locked
|
---|
37 |
|
---|
38 | Already existing bioplates will be assigned to the "Generic storage plate"
|
---|
39 | type. Plate types are global resources, which means that they don't have an
|
---|
40 | owner, and everyone has at least read permission to them. Create and edit
|
---|
41 | permissions are only granted to administrators (or power users?).
|
---|
42 |
|
---|
43 | Q: I am thinking that it might be a good idea to define one plate type for
|
---|
44 | each step in the lab procedures. Or at least those steps that are important to
|
---|
45 | be registered in BASE. This way it will be easy to select the next event. For
|
---|
46 | example, when I have a plate of type X the next event must be Y or Z. However,
|
---|
47 | I assume that lab procedures vary a lot between labs and even between projects,
|
---|
48 | so this is probably something that has to be setup by an admin. Maybe we should
|
---|
49 | think of some kind of import/export functionality that can be used to setup
|
---|
50 | plate types and event definitions.
|
---|
51 |
|
---|
52 |
|
---|
53 | BioPlateEventDefinitionData
|
---|
54 | ---------------------------
|
---|
55 |
|
---|
56 | This class is used to define an event that is re-occurring in the lab. It is
|
---|
57 | linked to a specific source plate type and, if the event generate new plates,
|
---|
58 | also to a destination plate type. A default protocol, hardware (eg. some kind
|
---|
59 | of robot), label and mapping can be selected. It is possible to lock this or
|
---|
60 | allow it to be changed at the time of the event.
|
---|
61 |
|
---|
62 | An event definition can define three types of event (the same type that are
|
---|
63 | currently possible for biomaterials):
|
---|
64 |
|
---|
65 | * Creation event: An event that creates a new bio plate
|
---|
66 | * Hybridization event: An event that creates new hybridization(s)
|
---|
67 | * Other: An event that doesn't create anything. It is merely registered as
|
---|
68 | something that happened to some plate.
|
---|
69 |
|
---|
70 | Event definitions are personal resources. Eg. there is an owner and they need
|
---|
71 | to be shared to the proper user/groups/projects before other user can use them.
|
---|
72 | This makes it possible to define different workflows in different projects.
|
---|
73 | Create permission is granted to power users (or users?).
|
---|
74 |
|
---|
75 |
|
---|
76 | BioPlateEventData
|
---|
77 | -----------------
|
---|
78 |
|
---|
79 | This is the registration of an actual event that has happened to a plate. The
|
---|
80 | information is similar to what is registered in a BioMaterialEventData object
|
---|
81 | (date/time, user, a comment, etc.) There is a link to the source plate. If the
|
---|
82 | event is a creation event the destination plates are also registered. The new
|
---|
83 | biomaterial that is created in the destination plates are linked back to the
|
---|
84 | biomaterial in the source plates using individual BioMaterialEvent objects.
|
---|
85 | The selected mapping is used to determine how the coordinates are related
|
---|
86 | between the source and destination plates. Here we need a way to allow users to
|
---|
87 | override the default mapping for a specific event. It is not yet fully
|
---|
88 | investigated how to do this.
|
---|
89 |
|
---|
90 | The new biomaterial will have individual BioMaterialEvent:s attached to them
|
---|
91 | which is more or less copies of the plate event. This is needed to maintain
|
---|
92 | backwards compatibility. Editing of the individual event is disabled, but they
|
---|
93 | are synchronized with the plate event and any changes made to the plate event
|
---|
94 | are also copied to the individual events.
|
---|
95 |
|
---|
96 | Q: What about quantities? We never discussed it. Should this also be a property
|
---|
97 | of the plate event and the same amount is applied to all biomaterials on the
|
---|
98 | plate?
|
---|
99 |
|
---|
100 | Q: Pooling events are not possible with the current design. The plate mapping is
|
---|
101 | re-used from the Array LIMS and a destination well can only have a single source
|
---|
102 | well linked to it. Is this too limiting?
|
---|
103 |
|
---|
104 | Q: Permission-wise I am not sure how plate events should be handled. The
|
---|
105 | permission system can either handle it is a standalone item, or as a child
|
---|
106 | item. The most natural would be to handle events as a child item to some plate.
|
---|
107 | The problem with this is that multiple plates may be created by the same event
|
---|
108 | and there is no natural parent item. The drawback with a standalone permission
|
---|
109 | system is that users must manage the permissions also for events and not just
|
---|
110 | for the plates. A similar problem arises if we start to delete plates. Do we
|
---|
111 | handle the events as child items and delete them also, or is the user required
|
---|
112 | to delete the events as well? What should happen to the biomaterials on a plate
|
---|
113 | that is deleted?
|
---|
114 |
|
---|