I would also recommend Arbimon. It is well set up to handle Audiomoth recordings. Being cloud based, you will need a good internet connection for sound file upload. I'm just starting to investigate its use for Song Scope recordings. Setting up the call recognisers will be a slow process, but they can be made available to all users once done.

You could try using a video editor like DaVinci for looking at your video and audio together. I don't think DaVinci displays sonograms by default (just waveform) but I think it will open your selected audio in an external editor which would allow you to see the sonograms and make measurements with something like Audacity or Kaleidoscope.

The open-source program Audacity can show the spectrograms and histograms and has quite a lot of other useful features, e.g. playing ultrasound calls slower, so it can be heard by people. 

Hi Akiba, [not sure if I'm on the right thread]

The Open-Source Tech Toolkit would need a repository for designs & specifcations. Regarding the latter, I'm a Technical Editor for a specification company. The format we use for the architecture & construction industry is suitable for any discipline [e.g. teaching students how to write a spec using our format/proforma they're given a task to write "how to tie their shoe laces"].

A specification defines qualities & standards (e.g. ISO, IEC). Drawings illustrate locations & quantity. Drawings are normally referenced back to the specification clauses.

I'd like to write an example of a specification for the Wildlogger, which will cover the many options for sensors, including references to approved/tested sensors and [if necessary] how they should be calibrated.

Looking over the horizon, what is the best repository for such Toolkit drawings and specifications?

If demand was large enough, and funding available, the company I work for could host the specifications and I'd maintain them full-time: There would be many advantages using our database over MS Word-based system.

Best Regards,

Nigel 

As someone who has practiced in information technology standards groups and actively worked on data schema standards to facilitate data sharing and even legally valid business transactions (https://www.oasis-open.org/committees/download.php/31222/ENML-1.0-Specification.pdf), my experience indicates it is important that you do the following:

1) Create a small workgroup of the right stakeholders who are committed to the process and results;

2) Pick a schema definition language - JSON or XML - to create the standard (JSON is the flavor of the day, but it is possible to do both with the right commitment);

3) Get people trained on the methodology and grammar for creating the schema;

4) Build the right semantic model up to a level of detail that is feasible for implementation within one year - if you go deeper than that the people who need to get things done in the field will move on while the workgroup will still be arguing details;

5) Build the schema; and

6) Build at least reference tools and applications in at least 2 different programming languages that show the model and schema working.

Without this process, it will be easy to miss the forest by getting lost in the trees (apologies for that).

Arshad

I don't know that it would be possible to create one scheme across all fields and collection tools. I'm involved in a project trying to define shared data standards with 10 private companies in one sector and that's a multi-year discussion. KDEs for seafood traceability (not even a full schema) took 5 years. If by standards you mean general agreements in principles, then maybe working with the ODI would be a good approach (see the work they did on engineering). if you want to get to schemas, maybe check with Matt Jones at NCEAS, bc data science for ecology is his career's work.

Hi skatewing,

I'm not a domain expert like most people in this forum, but I have created XML schemas using object oriented (OO) principles in the past; the same capability exists with JSON schemas.

The important thing is to create a heirarchy of schemas, starting with a generalized schema definition that applies to all participants at the upper layer, and inherit that schema as one starts diving deeper. This permits specialized schemas at lower layers that meets the needs of smaller groups, but as one moves up the schema hierarchy, one finds common parent objects that can be shared with other groups.

If it is impossible to create it in a hierarchy for all group participants, it is possible to start with a smaller general schema that meets everyone's needs and then each specialized group can create independent hierarchies, which can then be linked as necessary (https://json-schema.org/learn/getting-started-step-by-step.html#references)

This capability of inheriting parent schemas, and linking to external schemas, allows simultaneous - yet separate - development by many groups without having to involve everyone all the time. You do need to bring together many people for a short while for the more general parts of the schema at higher levels; but once defined, it can segment out to smaller groups as specialized schema branches/hierarchies are defined.

Arshad