Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direct link between atlases and tools/services that use them? #139

Open
UlrikeS91 opened this issue Oct 15, 2021 · 6 comments
Open

Direct link between atlases and tools/services that use them? #139

UlrikeS91 opened this issue Oct 15, 2021 · 6 comments
Assignees
Labels
question further information is requested request any request or update for schemas

Comments

@UlrikeS91
Copy link
Collaborator

This is just an idea, but it might be worthwhile thinking about it. Atlases are obviously research outputs themselves, but (one of) their main purpose is to be used somehow, e.g. as a visual reference or within tools/services.

So, wouldn't it make sense to capture this somehow?

Example: QuickNII
It's a tool used to register data to a reference atlas. Right now it supports the Allen mouse brain atlas and the Waxholm rat brain atlas (and many more to come).
QuickNII is/will be registered as a Software(Version) and both atlases will be/are registered as BrainAtlas(Versions), but there is no connection between the two...

@lzehl
Copy link
Member

lzehl commented Jan 4, 2022

@bweyers and @jagru20 any idea how this linkage could be established in a Software? (it is a rather specific case, but maybe you know about similar cases for e.g., software that only supports certain models?)

@bweyers
Copy link
Collaborator

bweyers commented Jan 4, 2022

Isn't it the case that atlases are (from a software point of view) just a specific type of data to be read and written on? Thus, a linkage similar to datasets could be thought...

@lzehl
Copy link
Member

lzehl commented Jan 4, 2022

@bweyers generally speaking atlases can match a single dataset, but could also be composed of multiple datasets. Datasets and software are currently linked through contentTypes. I think contentTypes are not sufficient to state the support of a particular atlas or model within a software, because their original contentType is often irrelevant in these cases. They are neither input nor output format, but integrated (typically hard-coded) within the software directly, no? For example, QuickNII supports two atlases and allows datasets with certain contentTypes to be registered to these software-integrated atlases. The contentTypes of the atlases do not play a role in this context, and other atlases with the same contentTypes are not supported by the software. I think the atlases are more to be seen as implementation aspect of the software itself. What do you think?

@lzehl
Copy link
Member

lzehl commented Mar 31, 2022

@bweyers and @jagru20 did you have the time to think about this a bit?

@lzehl
Copy link
Member

lzehl commented Jan 19, 2023

@bweyers and @jagru20 Could you comment on this issue? I could imagine the following:

Adding an additional optional property to SoftwareVersion schema "supported construct" (feel free suggest a different name) which can get as input (type array (0-N)) a BrainAtlasVersion, a ModelVersion, a MetaDataModelVersion, a CommonCoordinateSpace (for now).

@jagru20
Copy link
Collaborator

jagru20 commented Feb 9, 2023

Hey Lyuba, please apologize the delay from our side. Introducing a property like the one you proposed sounds like a good idea for this purpose. If it is an Array I would rather suggest naming it "supportedConstructs" but that is nitpicking.

@UlrikeS91 UlrikeS91 added question further information is requested request any request or update for schemas labels May 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question further information is requested request any request or update for schemas
Projects
None yet
Development

No branches or pull requests

4 participants