update for ed

doc/Design_notes/notes/featureset_col.html

-<!-- $Id: featureset_col.html,v 1.6 2010-04-29 14:15:56 mh17 Exp $ -->
+<!-- $Id: featureset_col.html,v 1.7 2010-04-30 12:17:59 mh17 Exp $ -->
 <h2>Columns Featuresets and Data Sources</h2>
 <fieldset><legend>Definitions</legend>
 <p><a href="Design_notes/modules/zmapFeature.shtml#terminology">zmapFeature.shtml</a> has some notes about the words used for various data items in the ZMap code (which cannot be changed without a lot of work) and this section aims to define terms to be used to describe things that can be configured by the user/ otterlace or presented to the user/ annotators, or used in an external interface eg data servers and X-remote.  This may seem pedantic, but there is some confusion caused by the re-use of words to refer to different objects.</p>
@@ -128,19 +128,19 @@ mRNA = vertebrate_mRNA ; polyA_site ; polyA_signal
 </p>
 <p>Each featureset may be given a style:
 <pre>
-[featureset_styles]
+[featureset-styles]
 EST_rat = EST_rat_style
 </pre>
-and by analogy the GFF source for a featureset will be defined as:
+Each featureset may be mapped to a (case sensitive) GFF source name:
 <pre>
-[GFF_source]
+[GFF-source]
 vertebrate_mRNA = vertrna
 </pre>
 </p>
 
 <p>Column styles may be defined as follows:
 <pre>
-[column_styles]
+[column-styles]
 EST_rat = align_col_style
 </pre>
 </p>
@@ -148,15 +148,15 @@ EST_rat = align_col_style
 <p>
 For GFF sources we also need a description text (which was supplied by ACEDB) and corresponds to the description in the load column dialog in Otterlace. This will appear in yet another stanza:
 <pre>
-[GFF_description]
-vertna = Vertebrate messenger RNA
+[GFF-description]
+vertebrate_mRNA = Vertebrate messenger RNA
 </pre>
-Note that the source key here is the internal GFF source name as defined for each featureset in the [GFF_source] stanza, which defaults to be the same as the featureset name.
+Note that the source key here is the featureset name, not the internal name defined in the [GFF_source] stanza.
 </p>
 
 <p>Each column may also be given a description:
 <pre>
-[Column_description]
+[Column-description]
 vertebrate_mRNA = Vertebrate messenger RNA
 </pre>
 </p>
@@ -169,7 +169,7 @@ vertebrate_mRNA = Vertebrate messenger RNA
 <p>The alternative stanza format above will be used, as it is probably easier to read.
 </p>
 <h3>Legacy issues with GFF and ACEDB etc</h3>
-<p>In the ZMap code there are a few mappings, originally derived from ACEDB and we need to used these (from ACEDB) and provide similar data for pipeServers.  Or rathe that we need to implement the above configuration data in ZMap and either patch the ACEDB data into the same data structures or replace it with our own. <b>ZMapView</b> holds the following mappings:
+<p>In the ZMap code there are a few mappings, originally derived from ACEDB and we need to used these (from ACEDB) and provide similar data for pipeServers.  Or rather that we need to implement the above configuration data in ZMap and either patch the ACEDB data into the same data structures or replace it with our own. <b>ZMapView</b> holds the following mappings:
 <ul>
 <li> <b>source_2_featureset</b> GFF source id (quark) to ZMapGFFSet, which contains a feature_set_id, which is really a display column
 <li> <b>source_2_sourcedata</b> GFF source id (quark) to ZMapGFFSource, which contains the source id (duplicated) an the id of the style (quark) to use to display it.