1. Extending the biogeographical model Africamuseum 6 (7?) June 2013

2. Workplan  Continue with database constructed so far  Add fields for Authority (name of the author, date, parentheses) Classification Fields for different ranks Synonymy Sources

3. Fields for classification  Add fields to ‘species’ table for the main ranks: Kingdom Phylum (=division) Class Order Family  Alternative: separate table Split taxonomy in genus/species, and family and above  Problem: not properly normalised, not good solution for long-term management of taxonomic register

4. Add field for authority  Add field for authority in the species table One text field, not structured further Too complex to be split up in separate fields  Optionally, add field for reference to original description Ideally as a link to the sources table

5. Add table sources  Fields ID (=primary key, autonumber) Author Year Reference

6. Relations with sources table  Add ‘SourcesID’ link in Species table  Add ‘SourcesID’ link in Distribution table  Create relations between Sources and Species table Sources and distribution table

7. Add synonymy  ‘Self-referential’ table Record in table refers to other record in same table Needs status of the taxon described in the record  Create new fields: AcceptedID TaxonStatus (optionally link to separate table)  Create relation: AcceptedID link to ID of taxon table

8. Relations diagram - synonyms

9. One-to-many relationships  E.g. species in family: each species belongs to one, and only one family  Implement by listing the Primary Key of the ‘one’ side as a field in the table of the ‘many’ side  ‘Foreign Key’ points at the right record in the ‘one’ side of the relationship

10. One-to-many relationships (Many) species in (one) family (Many) places/localities in (one) country

11. Many-to-many relationships?  Problem: we don’t have a ‘one’ side, there is no single record to refer to  Can not be implemented directly in SQL  Needs extra table To split up many-to-many in two one-to- many relations Extra table takes pointers to both sides of the relationship

12. Many-to-many relationship  Example: ‘sources’ versus ‘species’ Source = literature, report, database…  One source refers to several species  A species is referred to in many sources  Create many-to-many table Split the one many-to-many relationship in two one-to-many relationships

13. Many-to-many relationship

14. Relations diagram - complete

15. Present structure: Philosophy  Structure has to be as simple as possible  But not any simpler!!  Present structure is good short-term solution, but not long-term Needs better alternative to represent classification and hierarchy

16. Hierarchy: flat table  Every rank in the hierarchy is represented by a field in the table  Simplest solution Easy to create Easy to query

17. Hierarchy: flat table

18.  Problems not normalised! Not a real problem if a quick-and-dirty solution is all that is needed Difficult to maintain hierarchy in the long term ‘Standard’ problems with non-normalised database  Possible conflicting information, inefficient storage… Cfr MASDEA; too simple

19. Hierarchy: normalised tables  Every rank is represented by a separate table  Not very difficult to write a query to regenerate flat table  Every taxon can have additional information Extra fields with description…

20. Hierarchy: cascading tables

23. Hierarchy: normalised tables  Avantages Easy to maintain and query Normailised, possible to add information at any level of the hierarchy  Drawbacks Ranks are hard-wired on the structure of the database New rank would require change of the structure of the database And probably of the user interface, web interface… Number of tables Lot of functionality duplicated

24. Taxonomic reality  Ranks used depend on the taxonomic group Botany: mainly infra-specific; zoology: mainly on higher levels Many of the ranks are only sparsely used  Needs for a more flexible system  Much of the functionality is the same across all ranks ‘parent’, synonymy Authority, description…

25. ‘Open Hierarchy’  Possible to define new ranks without having to rewrite the structure of the database  All taxonomic names are stored in a field in a single table; other fields indicate parent and rank  Many-to-one relation: a single parent, several descendants Include ID of parent in the record of the descendant

28. Open Hierarchy  Avantages Completely normalised Flexible  Drawbacks Difficult to query classification Queries of the type ‘all species of the Echinodermata’… Solution: Recursive query ‘calculated field’ program

29. Synonymy  Every taxon can have several synonyms; in principle, only one valid name for any synonym Many-to-one relation: one valid name, many synonymous names Include ID of the valid name in the record of the synonymous name Other fields for the type of synonymy…

31. Rest of the taxonomic model  Ranks should be in a separate table Information on the level of the rank can be added Possibility of extra quality control Rank of a parent as compared to rank of descendants Rank of siblings should be same

33. Combine with rest  Previous work on geography and sources