You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As we discussed, I was thinking it might be helpful to add a more formal description of the soundevent schema to the docs, and maybe a schema for the Acoustic Objects Exchange format you mention here
The descriptions you have in the data schemas section and the user guide are very well written, intuitive, and helpful for understanding the package.
But adding a more formal description of the schema would be good as well, to:
help understand the mapping/hierarchy from pydantic classes to schema (e.g., not clear to me right now if Dataset is the top-level object that I should interact with "first"?)
open up a broader conversation in the bioacoustics community about what kind of schemas + standards we need so that file formats are more portable and tools are interoperable
If it were me I would put this more formal description in the "Reference" section of the docs, following the Diataxis framework (and maybe move the API docs to their own separate section "API" or a sub-section within "reference")?
Hope that feedback is helpful and that we can keep talking!
The text was updated successfully, but these errors were encountered:
Hi @mbsantiago, good talking with you today.
As we discussed, I was thinking it might be helpful to add a more formal description of the soundevent schema to the docs, and maybe a schema for the Acoustic Objects Exchange format you mention here
The descriptions you have in the data schemas section and the user guide are very well written, intuitive, and helpful for understanding the package.
But adding a more formal description of the schema would be good as well, to:
Dataset
is the top-level object that I should interact with "first"?)If it were me I would put this more formal description in the "Reference" section of the docs, following the Diataxis framework (and maybe move the API docs to their own separate section "API" or a sub-section within "reference")?
Hope that feedback is helpful and that we can keep talking!
The text was updated successfully, but these errors were encountered: