WebAlign and VoluBA allow submission of registration results to EBRAINS curation

[xgui3783]

per roadmap https://ebrains.eu/services/atlases/#services

[fsdavid]

Can we elaborate?

[xgui3783]

this is probably what @JThoennissen and Lyuba & co were discussing: how to integrate the output of voluba (registration of volume to template) back to ebrains

[dickscheid]

There is a detailed documentation of the proposed workflow under this internal link

[JThoennissen]

According to discussion with @dickscheid @xgui3783, the following needs to be done by end of month:

• [ ] change all HBP texts/logos to EBRAINS
• [ ] let the user optionally paste a KG-URL to link the DataAnalysis to an existing dataset
• [x] ask the user for a description (“Description” in DataAnalysis)
• [ ] use the image hash everywhere (also in the JSON files) –> ideally same hash that is computed by the KG
• [ ] keep track of different submitted versions somehow (I’m also fine with renaming the JSON files in the Bucket)
• [x] store the user's name (“Performed by” in DataAnalysis)
• [ ] store the type of transformation ("Technique" or "Description" in DataAnalysis)
• [x] fix: "Start time"
• [x] fix: “Environment”

[xgui3783]

fix: "Start time"

does not seem to be broken, so not modified

store the type of transformation ("Technique" or "Description" in DataAnalysis)

since user can add custom description, this can be considered met. Otherwise, we probably should add the relevant analysis technique in controlled/voluba space

let the user optionally paste a KG-URL to link the DataAnalysis to an existing dataset

since user can add custom description, this can be considered met. Otherwise, datanalysis schema does not seem to support dataset version

[JThoennissen]

let the user optionally paste a KG-URL to link the DataAnalysis to an existing dataset

This should be rather done together with the possibility to choose datasets for anchoring directly from the KG. This means: At the beginning, query for all DatasetVersion instances available in the KG and let the user choose a Dataset. Then for this dataset, query all File instances and let the user choose the actual file. This way, we can explicitly link the file to the DataAnalysis.

[xgui3783]

let the user optionally paste a KG-URL to link the DataAnalysis to an existing dataset

This should be rather done together with the possibility to choose datasets for anchoring directly from the KG. This means: At the beginning, query for all DatasetVersion instances available in the KG and let the user choose a Dataset. Then for this dataset, query all File instances and let the user choose the actual file. This way, we can explicitly link the file to the DataAnalysis.

This makes sense.

To achieve this we will need to:

• [ ] create an endpoint which queries / filters dataset versions (input could be uuid or name)
• [ ] create an endpoint which queries / filters files, based on dataset uuid provided
• [ ] implement frontend which implements these two queries

[xgui3783]

I have some bad news.

The proposed workflow:

1/ User searches (with string or uuid) dataset version

2/ User confirms the dataset version they would like to use

3/ User searches File by uuid or name

4/ User selects File

Between 2/ and 3/ , to get from DatasetVersion to File the traversal appears to be the following:

DatasetVersion -> FileRepository -> File

DatasetVersion -> FileRepository is already plenty slow, but FileRepository -> File is ... very very slow (see https://github.com/HumanBrainProject/fairgraph/issues/57) With the tests I did just now, it took 30 seconds to fetch two files from https://search.kg.ebrains.eu/?category=Dataset#87c6dea7-bdf7-4049-9975-6a9925df393f , as an example.

This would not be a very user friendly work flow.

[JThoennissen]

Lyuba said that we could ask Oliver Schmid, maybe he has a solution ... I will write an email today.

[xgui3783]

There is a known issue at https://github.com/HumanBrainProject/fairgraph/issues/57 which describes the same issue.