Where should the development home be for the ML Model Extension?

[rbavery]

The new MLM model extension is now released as version 1.0! It includes a validation package, JSON schema, and updated schema definitions to handle the complexity of how to run and deploy models in 2024. @fmigneault and I are excited to use and maintain this extension and we welcome folks to use the extension, provide contributions, and provide feedback in issues. The old ML Model extension is going to be deprecated in favor of this new MLM extension: stac-extensions/ml-model#16

On this note, where should the development home for the extension be? Currently it is in a fork within the CRIM org: https://github.com/crim-ca/mlm-extension

I think it'd be better for industry adoption, visibility, and community stewardship if the development home was instead within the stac org: https://github.com/stac-extensions

@fmigneault raised a concern that CRIM would like to maintain contribution visibility. One option is that we fork https://github.com/crim-ca/mlm-extension into https://github.com/stac-extensions and have the fork be the central hub of development. This would show clearly that the stac-extensions repo is derived form the CRIM repo.

I'm alright with this as long as the stac-extensions fork is the hub for development and hosts the identifier for the JSON schema. Curious what others think!

[gadomski]

maintain contribution visibility

Can you clarify what you mean by this? If we transfer the extension to the stac-extensions organization, the version control history comes along with it, so all contributions will still be attributed to the authors. Any other attribution could then be handled in the README or license information?

[rbavery]

I'm also of the opinion that attribution could be handled in the README with logos and text references to CRIM (and other contributors like Wherobots). There could be a full transfer to simplify the ownership. Some folks might get confused that a fork is where main development takes place.

If I understand correctly, CRIM would like to maintain a reference in the repo to the original repo with a fork. The link and message included in forked repos forked from https://github.com/crim-ca/dlm-extension might be important to them. @fmigneault do you have any new thoughts on this setup? Is a fork necessary?

[fmigneault]

I think that it would be acceptable if the contributions/logos are visible in the README (not just CRIM's but Wherobtos' ones also).
As long as it is not only the Git history. Most people do not bother to look deeper than the landing page.
I'll come back with more updates, I'll have to refer with others in the company.

[rbavery]

Thanks for checking in on this possibility Francis! I'm down to discuss in person at the next STAC Community meeting.

[m-mohr]

I was under the impression that actually mlm would be a v2 of ml-model, but that doesn't seem to be the case. (Why not?)

I don't think we should have forks in stac-extensions as it would water down where the main source would be. Why would we want to have a fork there? External repos can be added to the list of extensions on stac-extensions.github.io.
I'm relatively neutral on whether ml-model lives under stac-extensions or crim-ca. I don't think there is any major difference.

[rbavery]

I was under the impression that actually mlm would be a v2 of ml-model, but that doesn't seem to be the case. (Why not?)

I also was under this impression. thoughts @fmigneault ? While working on this PR, I thought we would transfer the DLM repo to stac-extensions/ml-model as version 2.

I'm relatively neutral on whether ml-model lives under stac-extensions or crim-ca. I don't think there is any major difference.

We (at Wherobots) would prefer the extension to live under a neutral org, similar to projects like geoparquet and the stac-spec itself. I think it's a helpful signal that the extension is owned and managed by the community and not any one company. I think it increases visibility and other ML related extensions (ml-aoi, ml-label) that are in use are under stac-extensions as well.

[fmigneault]

I'm open to discuss a merge of mlm as a ml-model v2, though there is not really any logic in the history between the two.
I'm not sure if that would cause more or less confusion in the end? This is partly why a different prefix was used.
Another issue is that I do not plan to spend time on offering "migration" scripts between v1 and v2.

[rbavery]

I'm supportive of not offering migration scripts and also don't plan on it. There's not enough active users of v1 for it to matter and the MLM offers many new necessary fields so automatic migration might not be possible.

I do think there's an advantage to discovery and encouraging community maintainership/contribution. Even though DLM didn't directly fork ml-model, I think it would make sense for users that the MLM is the newest progression of efforts to describe geospatial models and version 2 wouldn't look weird. As long as it is a non-fork repo and other past repos are archived or point to it, I think users will understand this is the extension to use today.

[m-mohr]

Bye the way, my question was just out of curiousity. I'm pretty neutral on whether it's a ml-model v2 or mlm.
If it's a v2, we don't necessarily need any migration scripts, but a documented migration path / a mapping would be good to have.

[emmanuelmathot]

IMO, this is not a ml-model v2 but a new extension addressing larger machine learning capabilities in STAC. We should keep ml-model as it is and deprecate it eventually when the mlm extension maturity will reach Candidate level.

[fmigneault]

I agree to keep them separate to help make thing clearer about the larger scope.

I think marking ml-model as deprecated earlier is better. Otherwise, users might be guided toward using it, which will lead to frustration later for migration, since the intention is to not maintain it anymore. Note that, if needed, a deprecated extension schema can still be used. It would just clearly state that one should not expect any fixes and development from it in the future.

[languith]

As we are the original maintainer of the stac-mlm extension, we would like to keep the repository within our organization at CRIM.
We understand the community’s preference for a neutral organization to enhance visibility and stewardship. However, CRIM, being a non-profit dedicated to applied research, aligns closely with these community values. Our continued management of the repository not only allows us to leverage our specialized expertise and dedicated resources for the evolution of the extension but also ensures rigorous maintenance and quality control.
We are committed to open collaboration and invite contributions from the community to ensure diverse input.
Furthermore, while we recognize the advantages of centralizing extensions under the stac-extensions organization, without a concerted effort to consolidate all extensions, maintaining this particular extension under CRIM allows us to demonstrate our active role in the geospatial domain and our commitment to the open-source.
We are open to discussions on how best to implement a governance model that ensures broad community involvement while keeping the development home at CRIM.

[jiayuasu]

Hi @languith

This is Jia from (https://wherobots.com/), and I want to express my appreciation for CRIM’s contributions to our collaborative projects.

I understand your concerns, but I believe transitioning the dlm-extension to a vendor-neutral GitHub repository under @stac-extensions is crucial for nurturing the growth of this open-source initiative. Experience has shown that few commercial organizations commit seriously to a repository that is not perceived as neutral, especially one aimed at establishing specifications rather than merely hosting software artifacts.

The stagnation observed in the development of https://github.com/crim-ca/dlm-extension over the past three years underscores the need for enhanced visibility and community collaboration, which can be achieved under the @stac-extensions umbrella.

As an active maintainer of Apache Sedona and participant in several open standards, including GeoParquet (https://github.com/opengeospatial/geoparquet), our commitment to open, collaborative development is profound. When Sedona transitioned to the Apache Software Foundation in 2020, all original git commit histories were preserved, dating back to its inception in 2015, as can be seen at https://github.com/apache/sedona.

Most importantly, according to stac-extensions/ml-model#13 , @rbavery and the community was expecting to move the dlm-extension to the stac-extensions based on @fmigneault-crim 's original communication with us in December last year.

While CRIM may continue development independently, uniting under @stac-extensions would avoid fragmentation and strengthen the project. I encourage CRIM to reconsider its position. Otherwise, we may need to reassess our commitment of time and resources to this project, given the potential for limited progress without broader collaborative support.