Here are some comments on Jean's ideas for the new models.
First, in reply to Lisa, yes ?Map would replace ?Chromosome and
?Linkage_group.
Also, I guess that Refers_to in the ?Clone and ?YAC models should be
the same as Also in the ?Map model.
I like the 2nd level map tag idea very much (RULE 1). Very natural.
Better than any of the ideas we have discussed before.
I support Inside, Outside. Is Contains the same as Inside, or does it
refer to an interval within and interval?
You could consider:
Overlaps, Does_not_overlap for 2 intervals
Requiring more thought:
Order, taking a sequence of mappable objects left -> right
after the next tag. Each sequence would have
guaranteed order
Minor point: as we discussed, you might have some other classes than
Locus specifically in ?Map.
I also strongly support ?map_location and ?map_error, though I would
prefer to maintain upper case for models, i.e. ?Map_location and
?Map_error (a minor point since you never see them except in
models.wrm).
But I am not sure about Multi_position. What is that for, and how
will it be used?
The only area I disagree is over colours (RULE 3). I think there is
no natural link from LIGHTBLUE to LIGHTGREEN, and it is a waste of a
precious primary hue. I propose WHITE on BLUE for the object picked,
and LIGHTBLUE background for neighbours. WHITE on BLUE (inverted) is
much more striking, and I think the primary pick should be striking.
I agree entirely that neighbours should be found on the fly. This is
done a little in pmap and fmap already (e.g. the probes in pmap). The
time is negligible.
Also I disagree with the map data linked coloring scheme. We find it
VERY useful to see the Inside-related objects coloured one colour, and
Outside-related objects another colour. I liked LIGHTBLUE and
LIGHTGREEN, but I guess we have preempted LIGHTBLUE. We could use
CYAN and GREEN if you want. I would prefer to still see this primary
information if objects are unhappy. Normally that allows you to
assess why they are unhappy. What about changing the foreground
colour to RED if things are unhappy? Alternatively, it would be fine
to be able to switch on and off your proposed red colouring with a
button. I see potential for the LIGHTRED variant, though I am not
sure how it will be determined. The reason for being able to hide the
red colouring is that red objects are very arresting, and often when
working with raw data you want to be able to leave conflicting data in
place without it dominating your field of view (cf Bob's approach to
sequence editing during assembly).
I agree we definitely want a map to be able to contain another Map
(RULE 2). There are various ways this might work for display. I can
imagine (1) giving a singular linear transformation, perhaps by
defining where the endpoints of the contained map (Extent values) lie
on the containing map. (2) piecewise linear interpolation, tying all
shared loci in the contained map to their locations in the containing
map, and interpolating in between (as with the physical map in the new
worm gmap display). Note that there are likely to be conflicts when
doing this. (3) more complicated things - like specifying explicitly a
non-linear transformation (splines?).
Richard
