Clarifying Galv's role

[mjaquiery]

Outcomes of the meeting to discuss this on July 12th:
🧔 Brady Planden
🧔 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.

• Frontend updates
  • Tiered directory setup that mimics a cycler or standard PC directory
    • Decompose monitored paths into subdirectories
  • Individual dashboard of tasks (metadata entry) awaiting completion
    • New datasets
    • Completed/total
      • Completed to a particular standard defined by various JSON schemas
  • Group dashboard to show Harvester operators (lab manager/PI) how stuff is going
  • Final data inspection page that displays the dataset (i.e. how the current inspect element works)
  • Move to a more page-by-page view with links between
    • Closer functionally to the django-rest-framework frontend but React pretty
  • Build monitored paths a directories on landing page with the ability to "subscribe" to read only access & request write access
• Backend updates
  • Monitored Paths for gating access
    • Created by Harvester users
    • Path is non-editable (destroy/create new if necessary)
    • MPs have admin/write/read permissions
    • At least one admin chosen at creation time
    • Userset modifiable by Harvester admin and MP admin
  • Orphan file/dataset views for Harvester users/admins
• Benefits to users who do their homework
  - Lots of work to be done making Harvester parsers work to collect this
  - Join together different data sources
  - experiment schedule
  - equipment details
  - cell info
  - (see Battery Intelligence Lab examples)
  - Scrape several data sources automatically/parse files
  - Example scripts that pull this together
  - Example datasets with example workflows
• Benefits to labs whose members do their homework
  • Quick oversight of historical data
  • Metaanalysis opportunities
  • Ability to track differences in e.g. cell parameters over time
• Benefits to wider community
  • Improve collaboration
  • Improve data sharing
  • Allow large-scale analysis
  • Improve adherence to standards e.g. EMMO JSON-LD

[BradyPlanden]

This issue supersedes #117

[martinjrobins]

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?
• "Move to a more page-by-page view with links between". I can't picture this, perhaps one to discuss
• "Group dashboard to show Harvester operators (lab manager/PI) how stuff is going" love it!
• "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)?

[mjaquiery]

"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.

[mjaquiery]

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
  • Electrochemical data (probably via link)
  • Measured/simulated?
    • Equipment used for measuring/simulating
• Data
  • At least a minimum set of columns, e.g. time, volts, amps
  • Could come from mulitple harvested Files on a filesystem
• Protcol information
• Experiment
  • Broader description/purpose
  • Unifies several Protocols into a coherent investigation strategy
  • May in turn be unified into larger Projects?

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.