Update softwareVersion.schema.tpl.json

[lzehl]

this change is overdue and the result of an old discussion. Idea: some software versions specifically support certain constructs (e.g. siibra only supports a certain set of common coordinate spaces which varies across versions of the software.)

note: I'm not fixed on the property name or definition. If you have a better idea please make a suggestion.

[UlrikeS91]

"supportedConstruct" is not optimal, but I also cannot come up with anything that is better. If it should be a bit more explicit, we could call it "supportedResearchProduct" since all the links are in fact research product versions (and maybe more should be added later?). But I am ok with "supportedConstruct".

[apdavison]

In what sense does the software version "support" these "constructs"? Input/output data formats, or...? Could this be handled through content types?

[UlrikeS91]

Based on @lzehl example, I assume that this is a constraint of the software in some way. In her example, a user wouldn't be able to replace the used coordinate space with whichever other space they want to. It can only be one that is supported by the software. So, the user can choose from a specific set, but that is it.

It is obviously limiting the input and output data in most cases (not sure if it would always limit them, though), but not enough so that it could be handled via the content types. Similar example is QuickNII. It has a specific atlas version and the version cannot be changed within the software. But the input data are "normal" png files. This is a spatial registration software for histological sections, so obviously the content of the images is important for the usefulness of the software, but in principle any png files can be used as input.

I also considered if an existing property could deal with this, but I don't think that any of the existing ones are suitable.

• hasPart (links to software version): These are in a way a part of the software, but they are more like the underlaying data/content of the software.
• feature (links to software features): It might be a distinguishing characteristics in some cases, but not always. But it should be possible to add this information regardless.
• requirement (free text): I guess this is a well defined property in software development and should remain as is?

[apdavison]

In the case of QuickNII it would be the output data files that depend on the atlas version, I guess.

What is the use case for adding such information to the metadata?

[UlrikeS91]

In the case of QuickNII it would be the output data files that depend on the atlas version, I guess.

Partly, yes. The coordinate space is more important, the registration would still be compatible with other versions of the atlas that use the same coordinate space but it may not be accurate in those other versions.

What is the use case for adding such information to the metadata?

Not sure. @lzehl will have to answer this once she is back from vacation.

[lzehl]

@UlrikeS91 @apdavison thanks for picking this PR / issue up again.

@apdavison this cannot be handled through content types, because it goes deeper and put's a restriction on the actual data of those constructs. The software depends on these data to be in place and most likely provides them as part of the software package (or if not requires them to be in place online or with installation instructions for the user).

In principle these constructs are required input data for a software which are automatically assumed / set by the software (with the user only to be able to choose from the supported collection, not to be able to change the collection). Without them the software would not run. Moreover, it restricts the usage of the software. Example: voluba is an image registration tool which does not allow a user to register their data to any brain atlas / common coordinate space, but only a specific supported set.

[lzehl]

@apdavison @UlrikeS91 we should discuss this to come to a solution

[lzehl]

@apdavison I'd like to get this in before PR #512 reading through our discussion above and considering that we probably want to keep this more flexible I wonder if we should just define this as "inputData" as for DatasetVersion and ModelVersion?

[apdavison]

I think the cleanest approach would be to add these types (plus DatasetVersion) to hasPart, since if I understand correctly the software does not work correctly without these research products, just as if a software dependency was missing.

[lzehl]

Sounds good to me

[lzehl]

@Raphael-Gazzotti can you double check and merge if correct?