Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic support for additional metadata #23

Open
6 tasks
jefferis opened this issue Sep 3, 2024 · 0 comments
Open
6 tasks

Generic support for additional metadata #23

jefferis opened this issue Sep 3, 2024 · 0 comments

Comments

@jefferis
Copy link
Contributor

jefferis commented Sep 3, 2024

The PR for additional fanc_meta (#22) gives one pattern, where we just return accept a path to a file on disk (tsv/feather) or a dataframe. I think more generically we could provide the option to register a metadata function (possibly even more than one) for a dataset.

cf_register_meta<-function(dataset, FUN, add = TRUE, after = TRUE) {

}

Where FUN would look like

FUN<-function(ids=NULL, ...) {
  # fetch metadata
  return(df)
}

using cf_register_meta would allow the actual method of storing the metadata FUN to evolve as we change coconatfly. Furthermore it would be a step on the way to actually using the coconat::register_dataset function (which could perhaps use this under the hood?).

Questions/todos

  • how do we handle registering of duplicate functions?
  • What does add=FALSE mean (does it completely replace the built-in function)?
  • What does after mean (does it take priority over the functions that precede it (probably, yes)?
  • Do we allow both dataframe or file input?
  • Who handles updates for CAVE type data? Probably coconatfly since this is quite generic, but then we should provide a supervoxel_id column to signal this.
    • coconatfly would also need to figure out how to do this update for the specified dataset.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant