Open mjaquiery opened 1 year ago
This issue supersedes #117
broadly agree with all of this, galv should be encouraging the entry of metadata, and the UI should relect this.
"Individual dashboard of tasks": how are these assigned? new datasets currently are ownerless until an owner is assigned. Or is it the admins on a MP that are tasked with this?
- Tasks would be assigned on a write-access basis. If a task needs doing, and you have the necessary permissions to do it, it appears on your dashboard.
- When a monitored path is created, it will be assigned at least one person with write access. This will no longer automatically be the person who creates it.
"Move to a more page-by-page view with links between". I can't picture this, perhaps one to discuss
Currently we have a couple of main pages: Datasets, Harvesters, etc. and we dive into details by expanding within those pages (using the inspect button). We'd be looking to use a setup where you'd have discrete pages for each dataset, and navigate between them using page links rather than expanding/collapsing a view. Not completely decided yet; any ideas appreciated!
"Build monitored paths a directories on landing page with the ability to "subscribe" to read only access & request write access". What does write access mean in this context? write metadata (for all datasets in MP)?
- Write access means you get to alter metadata for all datasets in the MP. It also means those metadata are treated as your responsibility in terms of the dashboard view.
- Read access is granted more liberally, and used to allow others to see metadata completion status.
- We will also have 'admin' access, which will allow you to change user permissions and delete the MP
- Harvesters will have similar user groups, with write access granting you the ability to create and delete MPs
A major result of this change is that Monitored Paths, rather than Harvesters, become the main grouping mechanism for most users. Only lab managers need worry much about Harvesters.
Discussion with @davidhowey and @BradyPlanden resulted in the conclusion that the primary component of Galv should be a single 'step' in a battery testing protocol. This will combine:
Cell
information
Equipment
used for measuring/simulatingData
time
, volts
, amps
Files
on a filesystemProtcol
informationExperiment
Protocols
into a coherent investigation strategyProjects
?The backend/API will be primarily organised around these Cycler Data
nodes.
The frontend could be organised around Cycler Data
nodes, Files
, or Experiments
/Projects
. @BradyPlanden originally suggested Files
, but this may not make sense if Experiments
are the preferred way of interacting with these data from a metadata entry perspective.
Outcomes of the meeting to discuss this on July 12th: :bearded_person: Brady Planden :bearded_person: Matt Jaquiery
We discussed what Galv should be, and what the benefits of using it will be. We envision Galv as a "Metadata Secretary", i.e. a (meta)data platform that prompts users to enter high-quality metadata which can then be provided to users at analysis time. It should serve the needs of both individual researchers and lab managers.