THIS PAGE DOCUMENTS AN ARCTOS RELEASE SCHEDULED FOR JULY 9 2012. IT WILL NOT MAKE SENSE FROM PRODUCTION UNTIL THEN. TEST IS http://login.corral.tacc.utexas.edu/.
This document supercedes all other locality documentation.
Major changes to the model (and, partially, their implications) are summarized here.
Specimens lose their (singular) pointer to place information; cataloged_item.collecting_event_id is no more.
Geography (geog_auth_rec) exists as a parent to locality, as before.
Geology (geology_attributes) exists as a child of locality, as before.
Table lat_long is gone. Coordinates are now a part of Locality data (and recorded verbatim in collecting_event). Note that nothing suggests coordinates are determined from locality data; in this model, coordinates can stand as the primary or only place information.
One implication of this change is that there is no longer a 1specimen–>1acceptedCoordiate relationship: Any specimen can have lots of (or no) coordinates which could be considered accepted for various purposes. The FLAT data objects (which are used for specimen search and results, among other things) deal with this (kinda…) by grabbing a random set of coordinates from a random “accepted place of collection” specimen_event. Better ideas for representing the actual complexity are as always welcome.
Reports that use lat_long will no longer work. Feel free to use the data from FLAT for reports and such, but do please be aware that our world is no longer necessarily so flat and that it is possible to link a specimen to multiple events of various types. (Handy for things that spend some time in captivity, biopsies, mark-recapture data, etc.) I’m happy to help resurrect your reports – just let me know what no longer works and how it should work under the new model.
Along the same lines, the specimen_event_type vocabulary could use some help. There are currently two options, representing accepted (or NULL) versus unaccepted coordinate determinations.
Unless someone yells vigorously and soon, this will deprecate catalog.cfm – I simply don’t think it’s possible to make people aware of the complexity of the data from that form under this model.
Table Locality is now
|LOCALITY_ID||NOT NULL||NUMBER||primary key|
|GEOG_AUTH_REC_ID||NOT NULL||NUMBER||foreign key to table geog_auth_rec|
|DEC_LAT||NULL||NUMBER(12,10)||Decimal latitude; eventually to be calculated WGS84 decimal latitude|
|DEC_LONG||NULL||NUMBER(13,10)||Decimal longitude; eventually to be calculated WGS84 decimal longitude|
|MINIMUM_ELEVATION||NULL||NUMBER||minimum numeric elevation|
|MAXIMUM_ELEVATION||NULL||NUMBER||maximum numeric elevation|
|LOCALITY_NAME||Assigned unique name for the locality; useful in grouping specimens and data entry.|
New table specimen_event links specimens to places.
|SPECIMEN_EVENT_ID||NOT NULL||NUMBER||primary key|
|COLLECTING_EVENT_ID||NOT NULL||NUMBER||foreign key to collecting_event|
|COLLECTION_OBJECT_ID||NOT NULL||NUMBER||foreign key to cataloged_item|
|ASSIGNED_BY_AGENT_ID||NOT NULL||NUMBER||Person who made the specimen/event linkage|
|ASSIGNED_DATE||NOT NULL||DATE||date on which the linkage was established|
|VERIFICATIONSTATUS||NULL||VARCHAR2(255)||ctverification_status; “verified by %” values lock events and places.|
There may be zero or many specimen_events of any type for any specimen.
All habitat information is centralized in specimen_event.