No, the specs were quite simple, I can reel most of them off the top of my head - having spent over a month twice a year since 2012 updating the dictionary (although the last time iSpot used it was in Sept 2014).
The were:
* iSpot_SANBI_number
* Name (= taxon)
* Rank (=taxonomic rank: which is why I know that "group" in the dictionary and browser pages is just lazy programming.)
* iSpot_Group (have 16 in our database, but collapse them into invertebrates and plants, during export)
* Type (= Scientific or Vernacular (iSpot calls it common, and at one stage English Name, but we objected with 11 official languages)
* Status (= Recommended or Synonym - we dont have any recommended Vernacular names which causes a major issue with the Quiz, because despite having our dictionary for 2 years on iSpot, the developers of the quiz did not know that we did not have recommended names and so southern Africa did not have a quiz for over a year after the other communities)
* Parent_iSpot_SANBI_number (the parent taxon of the Name - e.g. a genus for a species, or a tribe or family for a genus, and for common names the taxon for that name (e.g. Thistle for Sonchus or Common Sugarbush for Protea repens).
and then there were some fields that did not make sense. To my mind they were totally redundant. They were
* Recommended Name
* Recommended Rank
* Recommended iSpot_SANBI_number
* Recommended Parent_iSpot_SANBI_number
(I just generated these from my iSpot dictionary database during export - for status = R they were the same, for status = S they were the parent)
And then at SANBI we insisted on the following being added:
* Sensitive Taxa (this is used to determine which taxa may not have their localities displayed in detail)
* Language (the Language of the Vernacular name: this was never incorporated into iSpot - so if the name was English, Afrikans, Sotho, Tsonga, Xhosa or Zulu - or any other language, is not specified in iSpot).
But there is no manual as to how the dictionary is used, and what the constraints on the fields are.
It seems to me that the following fields would be useful (yes, they can be constructed real time, but why - they are constant text fields):.
* higher taxonomy (i.e. the taxonomic list; e.g. for Recurvirostra avosetta = Animalia / Chordata / Vertebrata / Tetrapoda / Amniota / Sauropsida / Diapsida / Archosauromorpha / Archosauria / Aves / Charadriiformes / Recurvirostridae / Recurvirostra)
* the full taxonomy (i.e. the taxonomic list; e.g. for Recurvirostra avosetta = Animalia / Phylum = Chordata / Subphylum = Vertebrata / Clade = Tetrapoda / Clade = Amniota / Clade = Sauropsida / Clade = Diapsida / Clade = Archosauromorpha / Clade = Archosauria / Class = Aves / Order = Charadriiformes / Family = Recurvirostridae / Genus = Recurvirostra)
* ID box display (e.g. following a search of Name, what to show - e.g. on finding "pro mell" display "Protea mellifera - synonym of Protea repens")
* ID box save (i.e. what to store in the ID box if a name is selected - i.e. the Recommended Name for a Scientific Synonym, or the same name for Scientific-Recommended name).
What would be useful is a manual of how the dictionary is used and what the different fields are used for and any limitations of the size and type of data.
