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

load/save_model for ML models #300

Closed
m-mohr opened this issue Nov 12, 2021 · 6 comments · Fixed by #304
Closed

load/save_model for ML models #300

m-mohr opened this issue Nov 12, 2021 · 6 comments · Fixed by #304

Comments

@m-mohr
Copy link
Member

m-mohr commented Nov 12, 2021

Propose two processes load_model and save_model to load and store ML models. Should be similar to load_results with loading from job id and URL. The input could be STAC items described with the (upcoming) ml-model extension: https://github.com/stac-extensions/ml-model

@jdries
Copy link
Contributor

jdries commented Nov 12, 2021

I guess this is the metadata spec that we're referring to:
https://github.com/radiantearth/geo-ml-model-catalog
?

@m-mohr
Copy link
Member Author

m-mohr commented Nov 12, 2021

The Geo-ML-Model-Catalog was the first attempt from Radiant to write this specification not based on STAC, but this evolved somehow into a work-in-progress STAC extension: https://github.com/stac-extensions/ml-model
I'll check with Jon what the long-term plan is with the Geo-ML-Model-Catalog repo.

@m-mohr
Copy link
Member Author

m-mohr commented Nov 12, 2021

The STAC extension one is now the main repo. The GMLMC one will be archived after we [have] transfer[ed] everything.

This is very much work in progress and if there's anything missing or you see issues, please report them so that we can make proper use of it for our use case.

Our plan is to release the draft version pretty soon, and have a model repository on MLHub before the end of the year.

@m-mohr
Copy link
Member Author

m-mohr commented Nov 12, 2021

@jdries @aljacob Do you have an idea what metadata would be minimally required for our use case?

@jdries
Copy link
Contributor

jdries commented Nov 15, 2021

Really minimally, the model just needs a name. But we'll probably also specify the type of model file, so we can determine if it's compatible with our software.

@m-mohr
Copy link
Member Author

m-mohr commented Nov 15, 2021

Thanks and good to know, but I guess I should have asked what you need minimally (so that I can ensure this is at least available) and what other information would be useful in addition? @jdries

From what you have listed right now, we may not really need a model extension yet.

  • The name is either the STAC id and/or title.
  • The generating software could be exposed via the processing extension although you'd run into issues if the software can generate multiple types so maybe a model file type would need to be part of a new extension. Looking at standardization: How could we ensure that model types match between implementations? Like is there a common name for each model type that we could refer to? Otherwise, implementations may choose different type names although they refer to the same thing. Could you give an example for software where this issue of model types occur? You could also directly add it here so that we can get the discussion started: Model "file type"? stac-extensions/ml-model#5

@m-mohr m-mohr linked a pull request Nov 16, 2021 that will close this issue
@m-mohr m-mohr modified the milestones: 1.2.0, 1.3.0 Nov 29, 2021
@m-mohr m-mohr added the ML label Dec 13, 2021
m-mohr added a commit that referenced this issue Mar 9, 2022
@m-mohr m-mohr closed this as completed Mar 9, 2022
@m-mohr m-mohr modified the milestones: 1.3.0, 2.0.0 Feb 1, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants