Define categories for the MONAI bundle properties

[Nic-Ma]

Hi All,

Currently, we defined all the required bundle properties in 1 file: https://github.com/Project-MONAI/MONAI/blob/dev/monai/bundle/properties.py, which were collected from our MONAI Label, MONAI deploy, NVFlare projects.
But actually, it may not be necessary to require every bundle to provide all these properties. I would like to define different property categories for different applications, then the bundle developer can declare the supported applications in the metadata.json. It can help reduce the development effort and limitation for a bundle, and provide more flexibility.

Detailed implementation steps:

1. Referring to the existing property list, MONAI Label, MONAI Deploy, NVFlare and even other apps define its own required properties in its repo.
2. We maintain a small mapping list in the model-zoo repo:

   [
       "monai-label": {"0.4": "<URL to the properties>", "0.5": "URL to the properties"},
       "monai-deploy": {...},
       "nvflare": {...},
       "other-app": {...}
   ]

3. A bundle developer decides which apps he wants to support for this bundle, then list the apps name in the metadata.json, for example:
   "supported_apps": ["monai-label", "nvflare"]
4. The CICD of MONAI model-zoo repo can check the declared properties and we can also try to show the supported apps as labels in the bundle list.

@ericspod @KumoLiu welcome your discussion here.

Thanks.

[Nic-Ma]

Hi @ericspod , @KumoLiu ,

@mingxueg-nv will start the development based on this proposal.
If you have any concerns, please feel free to discuss them here.

Thanks.

[mingxueg-nv]

A suggestion, supported_apps also provide a version, like "support_apps": {"monai-label": 0.0.5, "nvflare": 0.1.4}, it’s easier to maintain.

[ericspod]

I'm good with adding more optional properties to the metadata for bundles. This is the place I feel we can put a lot of configuration and meta information which the model zoo and other tools can use to better understand how to use a bundle. If supported_apps is optional this lets users ignore it if they don't want to consider compatibility with applications, this way we don't have to make it any harder to make a bundle. For the actual value supported_apps, it may be that it is a dictionary relating app names and a description of supported versions along the lines of what we use in requirements.txt files, eg. "support_apps": {"app1": "1.0.5", "app2": ">0.2", "app3": "1.1,1.2", "app4": ">=1.2,!=1.3.22"}.

Also related on the changes to the schema which can incorporate what we want to add to the metadata format: #7409

[yiheng-wang-nv]

Hi @ericspod , thanks for the suggestions. I agree that we can push the schema changes PR (#7409 ) forward, and then enable the supported_apps (add into #7409 or submit a new PR).
BTW, I prepared a CI tests change PR in model zoo: https://github.com/Project-MONAI/model-zoo/pull/602 I can modify it to support new schema.

[ericspod]

I have modified #7409 to include supported_apps now, please check wording of description and documentation.

[yiheng-wang-nv]

Updates: we already have a new schema in MONAI, and MONAI model zoo enables properties check if a bundle uses the new schema and provide the corresponding properties list. So far, the default setting is still to check MONAI's default properties.

For each app: monai-label, monai-deploy and nvflare, I think we should invite their maintainers to prepare the properties.

[yiheng-wang-nv]

Updates: we already have a new schema in MONAI, and MONAI model zoo enables properties check if a bundle uses the new schema and provide the corresponding properties list. So far, the default setting is still to check MONAI's default properties.

For each app: monai-label, monai-deploy and nvflare, I think we should invite their maintainers to prepare the properties.

Hi @SachidanandAlle @tangy5 , for monai label, could you provide some information here? Thanks!
Hi @YuanTingHsieh , for NVFLARE, do you know which properies are necessary? Cou you give some information here? Thanks!