Label Swapping - Label Merging - Renaming and more

This page explains how label swapping and miscellaneous options work

Label Swap

Label swapping is a technique where at least one replicate has its labels swapped so that 2 labels are matched to other conditions. Label Swapping is defined in the divLabelSwap - a dialog box shown when the corresponding link is pressed in Step 3 (s3showdivLabelSwap). When the aforementioned link is pressed, the function showLabelSwapDialogBox is executed that shows the div and initializes LS using the InitializeLS function. This function itterates the rawfiles_structure array and gets all biological replicates and technical replicates of the experiment. Then it populates the LSbrep and LStrep with the corresponding values and adds a header to each one (Bio Reps and Tech Reps respectively). It also gets all conditions from the conditions list andd populates the LSfirstlabel and LSsecondlabel with them. In order to add a Label Swap one should choose two different labels from LSfirstlabel and LSsecondlabel and the replicate coordinate where the swap applies (that is the bio and tech rep from LSbrep and LStrep). When the value of LSbrep or LStrep changes, onLSrepchange is executed that iterates rawfiles_structure and gets all rawfiles that correspond to the specific replicate coordinate. These are all added as elements in the LSRawFilesList list which is located on the top right corner of the dialog and shows all raw files that will be affected by the label swap. They are also added to the global array LSselected_raws. The concept is that when PS gets quantitative data from these rawfiles it will simply match two label to two other conditions. When LSfirstlabel or LSsecondlabel change values, onLSlabelchange is executed for a validity check and draws the border of the lists red un case the two labels are the same. Hitting the add button finishes the procedure. onLSAddclick is executed where after making sure that at least one raw file will be affected and that the two labels to be swapped are not the same, PS edits the LabelSwapArray and LS_counters_per_Add that are the two global variables that describe the label swaps. LabelSwapArray is a 2dimensional array that has 4 columns: rawfile, firstlabel, secondlabel and counter (a key). Each raw corresponds to a different raw file where a label swap of firstlabel and secondlabel occur. An example of its structure is seen below:

// +-------------------------------+-------------+--------------+---------------+
// |		   Raw File			   | First Label | Second Label | Counter (key) |
// +-------------------------------+-------------+--------------+---------------+
// | OT2_Terhune(...)DMC-HLNF01_02 | L		     | H			|			 0  |
// | OT2_Terhune(...)DMC-HLNF02_02 | L		     | H			|			 1  |
// | OT2_Terhune(...)DMC-HLNF03_02 | L		     | H			|			 2  |
// | OT2_Terhune(...)DMC-HLNF04_02 | L		     | H			|			 3  |
// | (...)						   |		     |			    |			    |
// | OT2_Terhune(...)DMC-HLNF12_02 | L		     | H			|			11  |
// +-------------------------------+-------------+--------------+---------------+

LS_counters_per_Add has a slightly more complicated structure. Each row has three elements, a string containing a description of the label swap we are currently adding, an array of all counters (keys) of this label swap and an array of the two labels that are swapped:

// +---------------+-------+--------+
// | Description   | Keys  | Labels |
// +---------------+-------+--------+
// | L - H in b1t2 | 1	   | L	    |
// |			   +-------+--------+
// |			   | 2	   | H	    |
// |			   +-------+--------+
// |			   | 3	   |		|
// |			   +-------+		|
// |			   | 4	   |		|
// |			   +-------+		|
// |			   | 5	   |		|
// |			   +-------+		|
// |			   | (...) |		|
// |			   +-------+		|
// |			   | 11	   |		|
// +---------------+-------+--------+

This will make removing a label swap correctly from the LabelSwapArray easy in the next step. LSLabelSwaps is a list that contains all descriptions of all LabelSwaps that are asigned and is populated at the end of onLSAddclick. To Remove a Label Swap one should choose it (one or more of them) from this list and hit the remove button. This executes the onLSRemoveclick function that iterates the LS_counters_per_Add array to find all label swaps with the descriptions selected in LSLabelSwaps adds these description to the local array options_to_erase. It also gets all counters from the second column of LS_counters_per_Add that correspond to these swaps and store them in another array called my_keys. After that it simply erases all elements of LS_counters_per_Add that have the descriptions to be erased (and are contained in options_to_erase) and all label swaps in LabelSwapArray that have a key in my_keys. This way the LabelSwapArray is refreshed correctly in a few steps. Finally the LSLabelSwaps list is repopulated. When tne analysis is going to be sent to the server, the LabelSwapArray will be sent that contains all necessary information for Label Swapping.

Miscellaneous options

Hitting the Miscellaneous button in step 3 shows the divAdvancedOptions container that has the three options concerning protein disqualification from the protein analysis based on whether a protein was quantified in a specific amount of replicates and from a specific amount of peptides and the p-value cut-off of statistical significance. The fist two options can be changed using lists of possible values. When the miscellaneous button is hit, InitializeAdvParam is executed to populate AdvParamLPep that is the first list that shows the least amount of peptides matched to a protein in order for it not to be disqualified. AdvParamLBRep is the second list that shows how many Biological replicates should a protein be contained in, in order for it not to be disqualified. This is populated in InitializeAdvParam with all possible values from 1 to the amount of bio reps of the experiment. The last option, the p threshold is a text box (PThreshold) that has input limitations so that one can enter only digits, commas and dots in order to type a decimal value. Hitting the OK button executes the onADVoptionsOK_click function that performs a simple input validation in PThreshold's value and sets its value in the Pthreshold global variable. The values of the list boxes are stored in the global variables LeastPep and LeastBRep respectively.

Label merging - renaming

There are some experiments where all quantified proteins from many labels must be considered as if they are from the same condition. For example if one has an 8-plex tagged experiment and has 4 conditions they could mark one condition with the first two tags, the 2nd with the 3rd and the fourth tag and so on. In PS it is easy to merge 2 or more labels to one condition. This is done by selecting the conditions to merge in the conditions list and right clicking and selecting same conditions. The context menu bound to the conditions list is initialized in PS’s initialization with conditionsMergeCMenuInit. It has 2 options “Same Condition” that merges 2 or more coditions to one and “Restore Condition” that restores an already merged condition. The same condition option is matched to a function that first creates an array with all selected options on the conditions list called itemsToRename. I then shows the condsadvancedDlg container that has a text box where the user writes the name of the merged condition. conditionsMergeCMenuInit also binds a function to the OK button of the merge condition dialog box. Its role is to refresh the RenameArray global array. RenameArray is a simple array that matches all authentic conditions to their merged ones. If no conditions are merged the first and the second column of it are the same. An example is:

// L	Lung_Ca
// M	M
// H	Lung_Ca

This array merges L and H to Lung_Ca. The same labels when no merging is done would be:

// L	L
// M	M
// H	H

Hitting the OK button will itterate through all RenameArray and search for the selected conditions in the first column. When PS finds the condition it will change the respective value in the second column to the provided merged condition name:

if($.inArray(my_row[0], itemsToRename) != -1)
{
	RenameArray[idx][1] = $("#s3AdvNewCondition").val();
}

Restoring conditions is the opposite procedure. Having selected some merged conditions, the Restore Conditions option in the context menu will perform an itteration like the one above and when it finds a value in the second column that matches the selected merged condition it will replace it with the respective value of the first column:

if($.inArray(my_row[1], itemsToRename) != -1)
{
	RenameArray[idx][1] = RenameArray[idx][0];
}

After merging or restoring conditions, Refresh_conds_list is always executed that has been explained before and gets all unique conditions from the second column of RenameArray and populates the conditions list with them. AuthenticItemsinRename is a variable that contains all the authentic conditions and is used to distinguish the authentic and the merged conditions in this function. All merged conditions are displayed in bold. expquantfiltlbl is also refreshed so that it contains always only valid condition names. eraseInvalidLabelSwaps will erase all invalid Label swaps, a procedure necessary since we just changed the valid conditions. InitializeRename is a function that is executed when conditions are parsed from the experiment files (or when they are entered by teh user in Step 2 in LFQ experiments). It is a simple function that initializes RenameArray as seen above and populates AuthenticItemsinRename with the authentic labels (that is the first column of RenameArray). Refresh_conds_list_cmenu_items is the last function that has to do with Renaming labels and it is executed every time the conditions of the experiment change and when the user clicks on the condition list. It iterates through all the selected conditions in condition list and chooses whether to display the “Same Condition”, the “Restore Conditions” option or none of the above. First, if the function finds at least one selected condition not being in AuthenticItemsinRename, i.e. a merged condition is selected, it hides the option “Same Condition”. The same happens if only one (or not even one) conditions are selected. Then it iterates through the selected conditions again and if it finds at least one condition being part of AuthenticItemsinRename then it hides the “Restore Conditions” since an authentic condition can not be restored back to itself. The “Restore Conditions” is also hidden if no conditions were selected. If the context menu ends up with no options, it is temporarily unbound from conditions list right click - otherwise a blank square would be shown - with the line below:

$('#conds_list_container').contextmenu("option", "autoTrigger", false);