openMetadataInitiative / openMINDS_core

The openMINDS core metadata model includes schemas that can be used to describe the general origin, location and content of research products.
MIT License
20 stars 19 forks source link

studyTarget #165

Closed UlrikeS91 closed 3 years ago

UlrikeS91 commented 3 years ago

While working on a first dataset, we noticed that the studyTarget options aren't very extensive. I talked to @lzehl about it and we also noticed that maintenance could become challenging. In short, termSuggestions should be evaluated and grouped regularly, but then all the schemas using the property studyTarget would need to be updated as well with these new groups.

So, we wanted to ask @olinux if it would be possible replace this by a list of all terms (allowed as studyTarget) that is stored somewhere else for better maintenance?

Or, if that is not possible, we may want to consider making the studyTarget its own schema after all. Then we only need to update one place instead of several with the new controlledTerms terminology options.

UlrikeS91 commented 3 years ago

Also, perfect example for maintenance issues is controlledTerms/cellType. We made changes to the origin in tissueSamples and added this as an option (next to controlledTerms/organ), but oversaw that this should be added as option to studyTarget.

(So, in case we don't want to/can't change anything, we should at least add cellType to all studyTargets.)

lzehl commented 3 years ago

@UlrikeS91 thanks for raising and formulating the issue. For now please go ahead and include controlledTerm/CellType in all "studyTarget" properties.

@olinux I was thinking of something like the following: ... "_linkedTypes": "https://openminds.ebrains.eu/studyTargetTypes", ... With studyTargetTypes being a list of all allowed controlledTerms types and the suggestedTerm stored as a csv in either the controlledTerm Github or the main openMINDS Gihub. We could also define a specific template property / dialect for this if it would facilitate the compilation of the full schemas.

What do you think?

olinux commented 3 years ago

How about this: We specify a "_categories": ["studyTarget"] in those schemas which are actually suitable for study targets.

In the consumer, we define "_linkedCategories": ["studyTarget"]

TODO: We need to resolve the schemas based on their categories and resolve them in the generation step so the resulting json schema contains the full list of involved types.

lzehl commented 3 years ago

@olinux thanks ! that's even a better idea! I'm starting a PR for this. :)

Note for the others: This will be a PR that also needs further changes (commits) by @olinux before merging, because it requires an extension of the generator.

lzehl commented 3 years ago

@olinux as you can see above the commits for the required/discussed changes were committed in PR #168

lzehl commented 3 years ago

This issue was solved in PR #168