| 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 |
|
|
|
|
|
|
|
|
|
|
|