ocefpaf
commented
1 month ago As it stands we have to do row wise iteration to split out the GBIF and obis download information and that seems overburdening.
Do you mean after the table is created? Or to create the table? If the former I believe the GBIF and OBIS are in different columns and no looping over rows is necessary. If I'm mistaken, maybe we need to create two tables instead of one in the function.
A generic question I have is how much do you have the function do vs how much do you do data wrangling in the use case notebook?
That is a good question! Hard to answer without knowing what people will be doing with that table. I like to keep the functions doing a bare minimum and leave the data wrangling part to the end user, b/c that will change more often. In order to implement that we need to identify this minimum table that would empower users to get what they want more easily. (That may lead to the create of multiple functions, easier to maintain, like fetch_obis, fetch_gbif, merge_tables, summary_table, etc).
@ocefpaf, @laurabrenskelle and I added an mbon_stats function, during the code sprint, to go out and grab statistics about dataset usage from two APIs. The response is a big data frame with some nested dictionaries. I think we're collecting all the data we need, but now it's a matter of being able to parse and use the response.
I'm curious if you could take a look at the function and see what we can do to make it easier to work with the data. As it stands we have to do row wise iteration to split out the GBIF and obis download information and that seems overburdening.
A generic question I have is how much do you have the function do vs how much do you do data wrangling in the use case notebook?
Any advice is appreciated!