Curent Situation OPTION A: no model changes: comments here OPTION B field changes only B comments OPTION C changes comments about field MTL's thoughts on option C
TableName FieldName   TableName FieldName see bugs 786 and 1079  
stemCount STEMCOUNT_ID split into 2 tables is not necessary     stem STEM_ID consolidated to one stem table  
stemCount TAXONOBSERVATION_ID       stem TAXONOBSERVATION_ID    
stemCount stemDiameter       stem stemDiameter    
stemCount stemDiameterAccuracy       stem stemDiameterAccuracy    
stemCount stemHeight       stem stemHeight    
stemCount stemHeightAccuracy       stem stemHeightAccuracy    
stemCount stemCount       stem stemCount    
stemCount stemTaxonArea       stem stemTaxonArea    
stemLocation STEMLOCATION_ID              
stemLocation STEMCOUNT_ID              
stemLocation stemCode       stem stemCode author's code  
stemLocation stemXPosition       stem stemXPosition    
stemLocation stemYPosition       stem stemYPosition    
    previous stem accessible via stemCode and obs.previousObservation_ID     stem PREVIOUSSTEM_ID recursive key back to previous observation of same stem unnecessary or minimally an implementation field. Previous observation, same stem code should suffice.
taxonInterpretation TAXONINTERPRETATION_ID   TAXONINTERPRETATION_ID   taxonClass TAXONCLASS_ID    
taxonInterpretation TAXONOBSERVATION_ID   TAXONOBSERVATION_ID   taxonClass TAXONOBSERVATION_ID    
taxonInterpretation interpretationDate   interpretationDate   taxonClass interpretationDate    
taxonInterpretation PARTY_ID   PARTY_ID   taxonClass PARTY_ID    
taxonInterpretation ROLE_ID   ROLE_ID   taxonClass ROLE_ID    
taxonInterpretation interpretationType add values 'author, less precise, but absolutely certain' AND 'author, more precise, but less certain' interpretationType leave values alone taxonClass interpretationType Author, Computer, Correction…  
taxonInterpretation reference_ID   reference_ID   taxonClass reference_ID    
taxonInterpretation originalInterpretation   originalInterpretation   taxonClass originalInterpretation boolean  
taxonInterpretation currentInterpretation   currentInterpretation   taxonClass currentInterpretation boolean  
taxonInterpretation notes   notes   taxonClass notes    
taxonInterpretation notesPublic   notesPublic   taxonClass notesPublic implementation field  
taxonInterpretation notesMgt   notesMgt   taxonClass notesMgt implementation field  
taxonInterpretation revisions   revisions   taxonClass revisions implementation field  
          taxonClass taxonClassType exact, aggregate, one-of, subset I suggested this in new comment on bug 1079
          taxonInterpretation TAXONINTERPRETATION_ID    
          taxonInterpretation TAXONCLASS_ID    
taxonInterpretation PLANTCONCEPT_ID   PLANTCONCEPT_ID   taxonInterpretation PLANTCONCEPT_ID    
taxonInterpretation PLANTNAME_ID   PLANTNAME_ID   taxonInterpretation PLANTNAME_ID   keep this as PLANTNAME_ID or just a text field, as in TaxonObservation?
      classFit values? taxonInterpretation classFit absolutely right, good answer, understandable but wrong, …  
      classConfidence H-M-low taxonInterpretation classConfidence high, medium, low  
taxonObservation TAXONOBSERVATION_ID   TAXONOBSERVATION_ID   taxonObservation TAXONOBSERVATION_ID    
taxonObservation OBSERVATION_ID   OBSERVATION_ID   taxonObservation OBSERVATION_ID    
taxonObservation PLANTNAME_ID nulls allowed for weird taxa PLANTNAME_ID nulls allowed for weird taxa taxonObservation plantName text field now  
taxonObservation reference_ID   reference_ID   taxonObservation reference_ID    
taxonObservation taxonCollection treat voucher as separate issue taxonCollection treat voucher as separate issue     collection handled in voucher table  
taxonObservation taxonCover   taxonCover   taxonObservation taxonCover    
taxonObservation taxonBasalArea   taxonBasalArea   taxonObservation taxonBasalArea    
taxonObservation taxonInferenceArea   taxonInferenceArea   taxonObservation taxonInferenceArea    
taxonObservation cheatPlantName   cheatPlantName     cheatPlantName no longer needed  
    deal with this idea with business rules: if a 'cheatplantname' occurs on a plot more than once, any records that have a stemCount record are considered 'individual', those without would be considered 'collective' (new BusRule: only one 'collective' taxonObs per cheatplantName per observation should be allowed.  For option A, that would mean that only one taxonObs is allowed without stemCount record(s) referencing it. taxonObservationType add field taxonObservation taxonObservationType individual, collective perhaps new terms are needed - 'entire taxon' or 'partial taxon' might be better terms as someone might have a taxonObservation and voucher for multiple individuals, but still just a subset of the taxon on a plot
          voucher VOUCHER_ID new table to attach to taxonObs (and, by reference, stem) voucher could be very easily added, regardless of option A,B,C being chosen.  I feel that this is a separate issue.
          voucher TaxonObservation_ID    
          voucher Party_ID collector  
          voucher CollectionNumber    
          voucher Museum    
          voucher AccessionNumber    
voucher CollectionDate