🚀 go-pugleaf

I am very glad to see Jean's proposal for making map representation more
general in ACEDB. I have a few questions and comments, as indicated below,
interspersed among the lines from Jean's proposal (which are indented and
preceded by ">").
I also will follow up with a separate message (not thread) about map
display. 

+=====================================================================+
|  John L. McCarthy.               . | Internet:..JLMcCarthy@lbl.gov  |
|  Computer Science R&D  MS 50B-3238 | Bitnet: ...JLMCCARTHY@LBL      |
|  Lawrence Berkeley Laboratory     .| telephone: (510) 486-5307      |
|  1 Cyclotron Road                . |                                |
|  BERKELEY, CA 94720, U.S.A.      . | FAX:       (510) 486-4004      |
+=====================================================================+

  >?Map    Type UNIQUE Genetic  // this flag can be used to define
subclasses
  >                    Cytogenetic // Chromosome could be Map, filtered
Cytogenetic
Please clarify the comment -- perhaps with an example
  >
  >                    Physical
  >        Contains Locus ?Locus XREF Map  // to look tidy
  >                 Also  ANY XREF Map  // Anything else
Should "Also" be "Refers_to"?  compare ?YAC/Location/Map/?Map XREF
Refers_to
  >                 
  >        
  >?map_location UNIQUE Position UNIQUE Float #map_error
  >                     Multi_Position  Float #map_error
  >                     Ends Left UNIQUE Float #map_error
  >                          Right UNIQUE Float #map_error
  >
  >?map_error Error UNIQUE Float
Why is this a separate object, rather than using Float Float in each above?
Is it in order to have an explicit tag, or because of UNIQUE?
Does this imply that postions can have multiple Errors?
  >
  >
  >?Locus  Map ?Map XREF Locus #map_location
  >        Main_Marker ?Map XREF Main_Marker
  >        Inside  Inside_YAC  ?YAC XREF Contains
  >                Inside_Fragment ?Fragment XREF Locus
  >                Chrom_Band ?Chrom_Band XREF Locus
  >
  >?Clone  Position  Map ?Map XREF Refers_to #map_location  // position on
vertical maps
Should be position on either vertical or horizontal (or other?) maps
  >        Inside    Links ?Fragment XREF Link
Please explain what the ?Fragment object is supposed to be (not a clone?)
  >
  >?YAC    Location        Map ?Map XREF Refers_to #map_location
Could you alternatively make ?YAC (P1, etc.) simply a sub-class of clone?
  >        Contains        Locus ?Locus XREF Inside_YAC
  >
  >
  >************************************************************
Suggest you add a heading here "MAP DISPLAY MODULE BEHAVIOR"
  >
  >RULE 1:
  >MappingTags, governing the Map package behaviour are always 2 up
  >from the actual objects.
  >
  >So far, i have defined this way: Contains, Inside, Outside
  >          i would consider Between, Does_Not_Contain
  >
  >RULE2:
  >As far as the map display is concerned, anything in the Contains
  >paragraph will appear on the map. In particular a Map may well
  >contain another map.
  >
  >Its display will be specialised if it belongs to a class with a
  >specialised display code (i.e.: Gene, Chrom_Band, Rearrangement,
  >later submaps).
  >
  >Otherwise, any object containing the construction
  >Map xxx Position 3.2 Error .3
  >will be displayed as a point locus (gMapDisplayAnyLocus)
  >
  >any with
  >Map xxx Ends Left 4.2 Error .1
  >             Right 4.8 Error .2
  >will be displeaed as a segment (gMapDisplayAnyInterval)
  >
  >RULE3: 
  >On firstpick (gMapSelect):
  >a) The selected box, and all boxes refreeing to the same key turn
  >lighblue.
When will multiple boxes refer to the same key? (loci with multiple
positons?)

  >b) All neighbours (i.e. keys referred to in the selected obj) turn
  >LIGHTGREEN
  >c) All tags referred to via mappingTag (Inside, Outside etc) as
  >obtained via a bsFlatten(mappingTag,2) recolor according to their
Please explain what bsFlatten does
  >relative position: GREEN if happy, RED if Problem, LIGHTRED if marginal.
  >
  >************************************************************
  >
  >Interesting properties:
  >
  >a) Every box on the map will be recolored according to the Inside,
  >Outside etc mapping tags irrespective of their class, irrespective
  >of their class and peculiar displays.
  >
  >b) I do not prerregister friends any more, i.e. sets of objetc
  >coloring lightgreen in advance. This enormously simplifis the code.
  >It also behaves much better because "friends" are not transitive.
  >The overhead of accessing the object rather tahn a preregistered
  >table is negligeable. It anticipates on the second pick(display) and
  >is in fact faster than preregistering all sets of friends.
  >
  >c) Any new class will appear on the map if it XREF to a tag to the
  >right of the Contains tag. In particular, in the runnig prototype i
  >have a well behaved YAC/STS map, when the code was compiled before
  >including these classes in the model files. This completely solves
  >the problem of the Bentley database who had to call his YACs
  >deficiencies and the like.
  >
  >d) The generic map making algorithms depend only on the mappingTags
  >and thus run on arbitrary maps.
It would be good to have a separate discussion of these algorithms
  >
  >e) As a side effect, you will note that the mappingTags are part of
  >the models but will not appear in the ace files. Furthermore, a YAC
  >say can be said to Contains other yacs, clones, STS, genes, i.e. any
  >etherogeneous set you want, since you can define one level of tags
HETEROGENEOUS?   This is really good!
  >under the mappingTag contains.
  >
  >f) As required by John McCarthy and others, the numbers defining the
  >map position are now explicitelly qualified.
   
+=====================================================================+
|  John L. McCarthy.               . | Internet:..JLMcCarthy@lbl.gov  |
|  Computer Science R&D  MS 50B-3238 | Bitnet: ...JLMCCARTHY@LBL      |
|  Lawrence Berkeley Laboratory     .| telephone: (510) 486-5307      |
|  1 Cyclotron Road                . |                                |
|  BERKELEY, CA 94720, U.S.A.      . | FAX:       (510) 486-4004      |
+=====================================================================+