Gel Patterns

Richard Durbin rd at mrc-lmb.cam.ac.uk
Sat Apr 9 12:20:11 EST 1994


I am in favour of a general way to display gel patterns.  Here are
some immediate ideas to add to the discussion:

Since there may be several patterns or lanes attached to any one
object I suggest a two-level tag system:

	Fingerprint	?XXX	#Fingerprint

i.e. the display code will go one right of _Fingerprint before
bsPushObj().  

I can image it working two ways: 
	With a single object you may want to show all the columns,
each headed by name(xxx), where xxx is a key from class ?XXX.
	With a keyset of objects (as Jean uses it now approximately),
you could pass an additional key yyy, and you would get one column per
object in the keyset, given it had a key xxx that matched yyy.  So
e.g. you could show all the EcoRI digests of a set of clones.

Note that I do not specify the class ?XXX.  This might be ?Motif, for
a restriction site, or ?Probe, or ?Text (anything).  It may be
meaningful in the object, but will just be used as a label by the gel
display code.  So it can be different in different models.  Before you
rush to say that you need both a motif and probe, read the next bit.

#Fingerprint	Bands	Float UNIQUE Text
		Motif	?Motif		// not ?Motif - may be double digest
		Probe 	?Probe
		Text	?Remark
		...

Jean has essentially Bands UNIQUE Float REPEAT,  i.e. a horizontal vector.
Above I propose a vertical list of fragment lengths.  It really should
be more of a set.  This allows adding and deleting bands more easily.
It does forbid two distinct bands of exactly the same size.  Is that a
problem?  The big win is that it allows an optional label to be
attached for each band, as Sam wants, but if they are left off then
you use the same memory as Jean's original solution.   And any
automatic matching code can ignore the labels.  

I'm not quite sure what other info one might want to put in the
#Fingerprint structure, and how it will be displayed and used.
Perhaps you could double click on something at the top of the column
and see the #structure displayed as a tree (not possible with current
treedisp code).

Probably Fingerprint and #Fingerprint are not the best names.  What
about Fragment_set?  Any other ideas?

We have a direct application here for multiple fingerprints for a
single clone, because the way David Bentley makes fingerprints he gets
three per clone.

As for starting the display.  I'm not sure you should be able to start
it from the main menu.  Probably it should know how to apply the
selected keyset to itself, or a single object by displayBlock()
capture (as with probes for gridDisplay()).  I think there could be
specfic handles to start the window from menus or boxmenus in the map
display and grid display.  Actually, I guess the main menuy would also
be harmless.

Richard




More information about the Acedb mailing list