Protocols

The protocol model is designed to be simple. In essence, it is just a formatted text description of experimental steps.

As for other model, each protocol is assigned a unique ID, their description can embed tables and images, and they can of course be shared to other user or groups, cross-referenced, and exported as PDF. In addition, to overcome the fact that most public repositories do not accept formatted text, pictures or table, a short free-text summary must be written. This summary will be used upon submitting data to public repositories.

The Protocol summary field is used upon sunmission to public repositories

Most (if not all?) public repositories require protocol description in as a plain, single line (no carriage return), non-formatted text (no lists, tables, styling...). The summary field should be used to provide such a protocol summary compatible with data submission (few sentences summarizing the main aspects of the protocol).

Protocol immutability is not enforced

Protocol immutability is not enforced

The system does not enforce immutability of protocols text, and does not currently automatically generate versions. In a context where cross-referencing is possible, and even encouraged, it is very important to understand what ensues:

• Many user can cross-reference a given protocol (using its UUID)
• As there is currently no versioning, cross-referencing links will always point to the latest and only version
• There is no way for users to know a protocol was modified. Nor to retrieve the past versions of it

In case of protocol modification, cross-referencing links made prior to the modification will now point to the "wrong" protocol

A protocol should be handled as "frozen"

To avoid problems and keep the cross-referenced information correct, it is not advisable to edit the content of a protocol after it is been made available. To achieve this:

Do not share protocols with edit permissions to prevent others from changing the procedure. Instead, keep it read only.

Manually create a new version of protocol when steps are modified, added or removed. The same apply when e.g. different reagents quantities or incubation times are used.

The only exceptions to the above include fixing typos or unclear directions (adding details, a picture, etc...).

A protocol can derive from a parent protocol

Protocol lineage is available. One protocol can derive from another. When deriving a protocol from another, parent-child relationship is automatically captured. This lineage information links the different versions together and make it easy to trace the different modifications. We also advise embedding the version number in the name to easily filter and display all versions of a protocol.

A lab note can derive from a protocol

When you need to perform an experiment following a specific protocol, simply locate the right protocol and click the Derive lab note button. This will clone the protocol into a new experiment: all you need to do is add your notes and gel pictures!

Protocols can be assembled into ordered lists

Protocols can be assembled into protocol lists i.e. a protocol list is the ordered sequence of protocols. Samples accept either a protocol or a list of protocols.