Is it necessary to have the model name in <model name>.model.yaml?

[frauzufall]

Hi all,

Is the intention behind naming the specification file <model name>.model.yaml that there might be multiple of them in the same ZIP?

In our case the ZIP content is cached somewhere (imagine it's located remotely) which makes it a bit difficult to scan the whole content for a *.model.yaml file, I'd rather like to know exactly for which file name to ask.

This is a problem with the API on our side, but I want to make sure I don't misunderstand the use case as well. Therefore my question - why is the file not simply named model.yaml or if there is the possibility for multiple YAML files, should there be something like an index file listing the available model files in this ZIP?

Thanks for pointers!
Deborah

[oeway]

Hi,

How about allowing only one model in the zip package and rename the file name as model.yaml?

For the naming of the yaml file in a github repo, we have basically two choices:

1. force each model yaml to be contained in a folder so we have the model:

+-- my-awesome-model-1
|   +-- model.yaml
|   +-- my-other-files.xyz
+-- my-awesome-model-2
|   +-- model.yaml
|   +-- my-other-files.xyz

The drawback of this is that if you want to share files (e.g. source code) between models, you will need to copy them (resolving relative path ../ won't be a good option for packaging).

2. use any name ends with .model.yaml, and only rename them into model.yaml when they are packaged into a zip file. And this process can be automised from the bioimage.io website with packaging bioengine app. Then we can have this type of structure:

+-- my-awesome-models
|   +-- my-awesome-model-1.model.yaml
|   +-- my-awesome-model-2.model.yaml
|   +-- my-other-files.xyz

After packaging, one of the zip package will become:

+-- my-awesome-model-1.zip
|   +-- model.yaml
|   +-- my-other-files.xyz

I think we should perhaps go for option 2, would that work for you?

[FynnBe]

Yep, I was basically about to post the exact same thing.. github issues should have a <user> writing.. feature 👍

Only one addendum:
Should the .zip file have the .model.zip extension (to avoid future clashes with other packages we might want to publish, e.g. .dataset.zip/ .notebook.zip or whatever? Otherwise we again are in the position of having to look into the zip to determine what kind of package it is.

[oeway]

Should the .zip file have the .model.zip extension (to avoid future clashes with other packages we might want to publish, e.g. .dataset.zip/ .notebook.zip or whatever? Otherwise we again are in the position of having to look into the zip to determine what kind of package it is.

I think using .model.zip is a good idea!

[frauzufall]

Yes, option 2 would work, because this would mean from consumer side I can assume that a ZIP has a model.yaml file, correct? About the ZIP naming - yes that's actually important - we once said we could call them myname.bioimage.io.zip.. I think we discussed this on gitter? I don't remember, but that's what our training currently exports and what our consumer is using to identify which kind of ZIP packages it is able to open. Would that become myname.model.bioimage.io.zip or are we abandoning the bioimage.io?

[FynnBe]

right, to be less generic... Trusting our past selves, we should maybe keep it.
How about mymodel.bioimage.io.model.zip, I think it reads better.

[oeway]

right, to be less generic... Trusting our past selves, we should maybe keep it.
How about mymodel.bioimage.io.model.zip, I think it reads better.

I am fine with both, we can also make the .bioimage.io as recommended part, but the .model.zip part will be used for detecting package types.

[FynnBe]

I vaguely remember us mentioning this issue briefly in last week's meeting. Noting that we didn't comment here, I suppose we landed on mymodel.bioimage.io.model.zip with model.yaml in it.

Please confirm/object 👍 👎

[frauzufall]

Sorry for changing my mind... But I would prefer using myname.model.bioimage.io.zip instead of myname.bioimage.io.model.zip - because this is in sync with how subdomains work (e.g. https://model.bioimage.io could point to all the models) and it would make it easier in other cases as well - currently we have a menu entry called import bioimage.io.zip and this could stay the same, no matter what you import, if it's a model or something else from our bioimage.io universe.

[FynnBe]

Good point myname.model.bioimage.io.zip with model.yaml in it then?! Let's collect som more 👍 to just settle this. @oeway , @m-novikov , @constantinpape , @esgomezm , ok?