Invert. database... what important inclusions?

[eucera]

I maintain a bee database which has 193k lines of data; 29k described localities and some 3.5k species. The database is maintained in FileMaker and is fully relational.

My work has included upkeep and maintenance of the Species database and there are absolutely dozens of fields. Effectively I have created species information pages covering taxonomy, traits, distribution, biometrics and threat statuses. Needless to say it is backed up in numerous sites!

[Jason Green]

Thanks Stuart. Distribution-wise I have two related fields now; Grid Refs, and because I don't want the width of the box to go from the start of one grid ref. to the end of the fourth - imagine how long the box would the become - I have a second one next to it simply giving the number of grid refs for that species. To see all the grid refs, just click the box of the given species and it appears in the Input Line on the toolbar. I'll be adding one for Life Stages too, you know, Adult, Nymph, Copula, Eggs, Pupa, etc.

[bugwoman]

Hi Jason,

Just to add a very belated point of clarification - it's best to have both a collector/recorder field AND a determiner/identifier field, as you may have collected or photographed a specimen and then had help in identifying it (as on these boards). The addition of a determiner's name with known expertise helps enormously in verification for data quality purposes. So if Stuart has confirmed that a bee is definitely one particular species, then put his name in the determiner column and a note in a comments section to this effect (eg. identification conf. S. Roberts from photograph posted on internet). If you have a voucher specimen that can be sent to someone for later confirmation, all the better - and add in a note to this effect. This is particularly important when you start submitting records, as the person processing and examining the records can see that you have been in contact with the appropriate people and haven't just been making wild guesses based on photos out of Chinnery or incorrectly labelled images from Google!

Also, please don't submit records identified to a higher level of accuracy than can reasonably be expected, so if someone says a particular insect is probably Xxxxxx. yyyyyyy, then it can only be recorded as Xxxxxx sp. with a note in the comments section that it might be X. yyyyyyy.

Thanks,

Claudia

[Jason Green]

Thanks Claudia! Yes, my databases have these fields.

Originally Posted by bugwoman

This is particularly important when you start submitting records, as the person processing and examining the records can see that you have been in contact with the appropriate people and haven't just been making wild guesses based on photos out of Chinnery or incorrectly labelled images from Google!

I shudder at the thought! Most of my material for records is nowadays collected, keyed, fully-labelled then safely boxed. I was going through old folders on my computer the other day of fully-resolved photographs. It must have been approaching half that I had to roll-back to just Genus - funny what you realise after a while of diligent collecting/keying!

[Matt Smith]

If you are going to put a lot of work / records into your database, I would suggest getting a proper database package. Using a spreadsheet means a lot of duplication of work - eg all the order / family data - threat status etc has to be entered for each record. With a proper database you only have to do this once per species.

The other danger of using a spreadsheet is the sorting aspect. All it needs you to do is forget to include 1 column in your sort and your database can be horrible messed up as records get broken.

If you are recording grid refs, use the format AB123456 - do not split the grid ref up into sections along the lines of AB 123 456. Most mapping programs and record centre databases can only use grid refs in the AB123456 format - I have spent hours massaging grid refs back into the proper format for the Tachinid Recording Scheme, but still a lot of people seem to write them in blocks.

I use a range of stuff here. I have the "old" Recorder 3.3 and still use that. Tried Mapmate and didn't like it, Recorder 2000 / Recorder 6 is an abysmal package and has been from the word go. For most of my recording I use a combination of Recorder 3.3 and my own databases built using Lotus Approach.