You could look to public soundscape archival entities for inspiration. For example, NOAA National Centers for Environmental Information (NCEI) has a Passive Acoustic Data map. If you click on points on this map, you can eventually click through to a JSON file that shows the structure of the key-values used in their database and archival system (example here).

Depending on how large and collaborative your project is, you might have different needs out of a database / organizational system. In the past, I have worked on projects where we organized the data in SQLite, which is a fairly lightweight and flexible system. Pros: you don't need a database administrator -- you can do it yourself! Cons: a lack of "concurrency" if you are going to have many contributors to the database (though not typically an issue if you or a small number of collaborators are the only ones contributing to the database).

For R users, it is possible to set up a SQLite database from R and manage your data via R packages such as RSQLite and DBI. Here is a paper on how some colleagues and I have made this work for prior acoustic monitoring projects as well as a Gitlab Wiki page on the database structure we used (all code is available at this repository). This particular software is undergoing some changes, however -- suffice to say, it is quite an undertaking to elegantly manage a large set of acoustics data, and to have the foresight to figure out all the pieces you need to track and how they should relate together.

You could look to public soundscape archival entities for inspiration. For example, NOAA National Centers for Environmental Information (NCEI) has a Passive Acoustic Data map. If you click on points on this map, you can eventually click through to a JSON file that shows the structure of the key-values used in their database and archival system (example here).

Depending on how large and collaborative your project is, you might have different needs out of a database / organizational system. In the past, I have worked on projects where we organized the data in SQLite, which is a fairly lightweight and flexible system. Pros: you don't need a database administrator -- you can do it yourself! Cons: a lack of "concurrency" if you are going to have many contributors to the database (though not typically an issue if you or a small number of collaborators are the only ones contributing to the database).

For R users, it is possible to set up a SQLite database from R and manage your data via R packages such as RSQLite and DBI. Here is a paper on how some colleagues and I have made this work for prior acoustic monitoring projects as well as a Gitlab Wiki page on the database structure we used (all code is available at this repository). This particular software is undergoing some changes, however -- suffice to say, it is quite an undertaking to elegantly manage a large set of acoustics data, and to have the foresight to figure out all the pieces you need to track and how they should relate together.