Prefix for MLMD DB entities of Model Registry

[tarilabs]

As noted in the Model Registry document: https://github.com/kubeflow/community/pull/682/files#diff-aaf54745ecb36016135c83a5a41a03025574ecb492aec56ef6d2c7c902abfe17R116

we're wrapping MLMD as the underlying stack.

Similarly to KFP, we are storing in the MLMD's DB some domain specific entities: https://github.com/kubeflow/model-registry/blob/main/docs/logical_model.md

We are looking for a "common prefix" nomenclature we should use for these entities, currently these are set to:

• kfmr.RegisteredModel
• kfmr.ModelVersion
• kfmr.ModelArtifact
• etc.

We're wondering before Alpha release of KF 1.9 we should adopt a more Kubeflow-common prefix such as kf. or kubeflow..

See also slack: https://kubeflow.slack.com/archives/C06JLC34PD0/p1708618535159289

[StefanoFioravanzo]

+1 for a generic prefix such as kubeflow of kf. If our goal is to build a generic metadata substrate to interconnect all Kubeflow components and potentially interoperate with third-party tools as well, then a kubeflow-wide prefix is preferable.

[tarilabs]

generic metadata substrate to interconnect all Kubeflow components and potentially interoperate with third-party tools as well

Thanks @StefanoFioravanzo for the feedback, all good with a generic prefix if makes our life easier for a standardized way to define namespace/prefixes/... across components!

My only remarks is in quoted part, I would refrain in making interconnection on internal implementation layer (ie have 3rd party tools interoperate at this layer) and rather have components integrate via exposed APIs.

Wdyt?

[StefanoFioravanzo]

Yes in principle I agree, I didn't mean that third-party software should be able to tap into backend systems. But if metadata structure becomes an open spec that can be consumed and produced by other libraries then we facilitate interoperation. Think of something like MLFlow having a Kubeflow module or extension to produce Kubeflow-compliant artifacts

[tarilabs]

Yes in principle I agree, I didn't mean that third-party software should be able to tap into backend systems. But if metadata structure becomes an open spec that can be consumed and produced by other libraries then we facilitate interoperation.

Yes @StefanoFioravanzo !
We have an (in-progress!) open-spec kind of document, here: https://github.com/kubeflow/model-registry/blob/main/docs/logical_model.md

Think of something like MLFlow having a Kubeflow module or extension to produce Kubeflow-compliant artifacts

Indeed and (at least partially! for the scope of MR) a subject or our gsoc here: https://www.kubeflow.org/events/gsoc-2024/#project-10-enhancing-kf-model-registry-python-client-for-seamless-ml-imports-from-alternative-registries :)