Frank van der Most, Phd.
Originally published on 24 November 2020. Moved to Rubber Boots Data on 2 September 2021.
Summary
The currently available database software for sea turtles and their nests is about ten years old or limited in their possibilities. I am considering developing new database software. In this text, I am calling for input from sea turtle NGOs and individual experts about their work practices and for feedback on the outline that comprises the bulk of this text.
Introduction
In May 2020, I published an overview of databases and software for the collection of data about sea turtles and their nests during beach patrols. It covers SWOT, TREDS, Turtle tracker, TURT and Sea turtle DB.
In short, the conclusion is that the existing software is over a decade old and not updated, limited in scope or aimed at a different purpose. Recently, I had a long conversation with an employee of a sea turtle NGO who agreed that the available options to replace their home-built database were not very appealing. They also reported that most of the attempts to develop a database application that they were aware of, were not flexible enough to fit the user wishes of more than one NGO.
I am considering taking up the challenge of developing a system that is flexible enough to support different practices of data collection and management. For doing so, I would welcome feedback and input from sea turtle NGO’s and individual experts to expand my knowledge of the existing practices and user wishes. (See the very last section of this text, or contact me immediately at frank_drv@icloud.com )
I have a background in research, a PhD., and skills and experience with the design of databases for research purposes. For more information, please see my CV and blog about research databases. However, my experience and knowledge about sea turtle work are limited to the volunteer work that I did in 2020 on the turtle data management of Osa Conservation in Costa Rica and the discussion with the sea turtle NGO mentioned earlier.
In the remainder of this text, I will provide an outline of a design as a starting point. The outline is based on my experience with the NGOs that I have been in contact with, the review of the software that I found on-line, and my own ideas and experience with database design. The feedback and input hopefully lead to a revision, expansion and further detailing of this outline. They hopefully also result in a feature priority list.
Please note that it is merely an outline, not a plan or road map. Particular features may prove too difficult, costly or time consuming to implement. Finally, the feedback will hopefully give me an idea of the economic viability of developing a new system.
1 Aim of sea turtle nesting data collection system
The Sea Turtle Research Database system (hereafter simply ‘turtle data system’ or ‘system’) aims at
supporting the collection, management and standardization of data about nesting sea turtles, their nests, hatchlings and other related things such as patrols, and hatcheries.
Below, I will use the phrase ‘turtle project’, which, for the purposes of this text, is an ongoing activity of an organization or an individual person, of collecting data as mentioned in the aim, through patrolling one or more beaches in specific area.
2 Diversity of work practices
The turtle data system will support a variety of work practices in areas such as
– the size and organization of patrols
– the organization of the collection of data into beach sectors or zones
– the ways of marking and numbering of nests and tagging of turtles
– the initial collection and further processing of data (For example pen and paper on patrols plus entering data behind the computer, or, entering data in on-line or off-line mobile devices)
– the use of hatcheries
– …
3 Flexibility
The diversity of work practices will be addressed through a system of standard and flexible data modules, and standard and flexible fields and flexibility in the navigation of the database.
Standard and flexible data modules
A data module holds the data regarding one particular type of thing, such as turtles, nests, patrols etc. Based on current practices (as hopefully established through talks and consultations ) there will be a set of standard modules that relatively many turtle projects use. Each project can then select which ones they want to use. For example, a project that does not make use of a hatchery can switch off the hatchery data module.
Flexible data modules can be defined per project for data that is less frequently collected or perhaps by only one project in the entire world. This could be, for example, about the quality of the sand layers of a beach, the water quality or the tidal flows.
Standard and flexible fields.
Fields are parts of a data module which describe the thing that the data module is about. For example, the turtles data module holds data about turtles. Fields in that data module could contain data on the species, the weight or the curved carapace length of a turtle. Usually, a field contains only one characteristic or only one data point. For example, curved carapace length and width would be stored in separate fields.
Based on current practices, standard data modules will be filled with a number of standard fields, that is, fields used by relatively many turtle projects. Each project can then select which fields they want to use from the selected standard modules.
Besides these, each turtle project can also define its own fields, both for the standard and the flexible data modules. It follows that flexible data modules only contain flexible data fields.
Navigation
The diversity in work practices can also be addressed through a variety of ways of navigating through the data. Different work practices may also mean that data is entered in a different order, after all. The structure of the data modules and fields does not necessarily dictate how the fields are presented in the user interface.
Limits to flexibility
Although different work practices will be supported, the flexibility of the data modules, fields and navigation will not be endless. For example, the number of flexible data modules may be limited.
The reason that the flexibility cannot be endless is that any economies of scale of a single system will be lost to the complexities of the programming of endless flexibility. In other words endless flexibility would mean custom development for individual turtle projects, which would make the price go up to levels that most turtle projects probably cannot afford.
4 Standardization
In the previous section, standard data modules and standard fields ideally will be derived from the talks and perhaps further interactions with NGOs and individuals. However, there is an additional possibility of standardization, after the initial launch of the turtle data system. In the course of the system’s lifetime, occasional but regular review of the definitions of flexible fields and data modules as set by the different turtle projects may reveal candidates for standardization. Such candidates could then be added as standard data modules and fields.
5 Off-line or on-line / patrol interface and field station interface
A major problem for sea turtle projects is the unavailability of good internet connections, either on the beach or in an office, or both. Off-line work comprises entering data with pen and paper, but also with tablets or smart phones. The following constellations can be identified.
- pen and paper on patrol. Pen and paper in the field station
- pen and paper on patrol. Off-line database (pc) in the field station
- pen and paper on patrol. On-line database (pc or tablet) in the field station
- off-line mobile device (phone or tablet) on patrol. Off-line database (pc) in the field station
- off-line mobile device (phone or tablet) on patrol. On-line database (pc or tablet) in the field station
- on-line mobile device (phone or tablet) on patrol. On-line database (pc or tablet) in the field station
I tried to visualize these constellations in the drawing below.
On-line work on the database (both for pc and mobile device) would mean working through a web browser. The difference between working on patrol and in the field station is that the patrol interface is geared towards entering new data, while the field station interface supports entering data but also the definition of modules, fields and navigation, data management, setting up user accounts, etc.
The turtle data system could support all the constellations mentioned above, except the first one. However, because of the programming complexities involved and the likely regular updating of the system, not all constellations might be available from the start. Also, not all constellations can be expected to support all features outlined in this text. The feedback might hopefully provide an indication of what most turtle projects need or would like to have.
6 User roles
The turtle data system supports at least four different user roles: the client, the database managers, the data editors and guests. The client is the one who owns the license and is allowed full access. The database managers also have full access, except that they cannot delete or restrict access of the client account. The data editors are the ones that are allowed to enter and edit data. Guests can only see data. For some of the roles it is perhaps needed to specify more detailed rights. For example, some data editors can only add and edit new or recent data, i.e. while on patrol, whereas others could be allowed to also edit older data.
7 Multi-language support
The turtle data system could support multiple languages. Initially the interfaces will work only in English and perhaps Spanish. Flexible data modules and fields are being defined by the turtle project and can be in languages that are written from left to right and from top to bottom.
Standard fields will initially be provided in English (and perhaps Spanish) as well, but projects will be able to add their own translations of field labels, descriptions, instructions and error messages.
8 Multi units and format support
Turtle projects occur in many different countries and besides language, units, calendars, date and time formats will differ. Although this should be supported, the complexities are enormous. For the time being, standard fields will be in scientific units (meters and grams), the calendar will be Gregorian, dates will be in separate fields fo day, month and year (the order could be different though), and time in 24 hour format (hours and minutes also in separate fields).
Those projects that cannot wait for other or additional units, calendars and formats can use flexible fields to construct their own.
9 Export and sharing of data
When it comes to ownership of the data, projects own their own data. Any on-line version of the database will keep a project’s data invisible to other projects. If a project wants to share data with others, then that will require positive action.
All projects (but not necessarily all user roles) will be able to export all their data (the actual data and the meta data).
These exports can serve multiple purposes: to analyze the data in other software, to share the data with actors outside the project, to make back-ups and to allow clients to switch to other sea turtle databases or software.
Initially, the export possibilities may be limited to ‘export all’.
10 Tag sharing
Tagged turtles may show up in places where another turtle project is active. Or turtles may be participating in a tracking project. Where possible, an on-line version of the turtle data system could connect to external databases to enhance data about individual turtles.
Internally, for those project that agree to participate and to the extent that they want to, there could be a sharing of tag numbers and basic data about individual turtles. This would allow synergy between the different projects and a geographically more expanded study of turtle behaviour.
11 Back-ups
Clients are responsible for making their own back-ups.
In case of an on-line database, there may be a generic back-up of the entire system for cases that the server crashes or other disasters, but there will be no guarantee that there will be no data loss.
The reason for this rather strict – and for the users perhaps brutal – approach is that back-up and restore systems would need to be programmed and these are very costly and time consuming. If there would be any guarantee, the project would come to a grinding halt from the start.
12 Price model and setting
The price model and setting is not decided yet and I am open to suggestions. The feedback will hopefully make clear what clients would be willing and able to pay.
Because turtle projects also occur in relatively poor countries or are being done by poor NGOs and individuals, I aim to set up a system that differentiates prices accordingly.
Perhaps it is needless to say but just in case, I am happy to take some risk, but I do eventually want to earn a reasonable income from this project.
13 What will the system not do ( or do only at a later point in time )
– As mentioned in the section on flexibility, there will be limits to the flexibility.
– The system will not perform a lot analysis on the data since this may be quite a drain on the server. Some overviews will be possible, but beyond that the idea is to make an export and to analyze the data using other software.
– Tracking of individual sea turtles. Through GPS devices, one can now track the movements of individual sea turtles. The sea turtles may be registered in the database, but the tracking data will not soon be part of it. I assume that the producers of the devices also deliver software to handle the data. What might be possible – depending on the devices’ producers – is to have links from the turtle data system to tracking data on the internet (See also the section on tag sharing).
Your feedback is more than welcome
If you or your NGO is interested in replacing an existing system (which currently could consist of pen and paper) I would love to hear from you! Please do contact me ( frank_drv@icloud.com ) for a telephone call, Skype or Zoom meeting, or an email exchange – whatever you prefer. My aim would be to talk about how you currently collect data, which kinds of data you collect, and how you would like to proceed with this in the near future. I will only publish the information that you provide in anonymous form and aggregated with the information provided by others. Please note that my aim with the talk is not to sell you anything. I also would not be able to compensate you for your time, other then through feedback and suggestions during the exchange.
Rubber Boots Data 
Leave a Reply