After last week's meeting, and a sync with Markus, we are going to move ahead with more of an organised structure with work streams to enable more concrete progress with better defined deliverables.

The working group will be split into three workstreams with the following goals:

1. Topology / graph model workstream

   • End deliverable: The topological graph model that will be used for the data. The model is an abstract description of a grid and can be applied across any grid configuration (market + location agnostic model).
   • Questions to answer:
     • What and how many levels of abstraction should we use?
     • How does it map to CIM/CGMES?
     • ...
   • Relevant issues:
     • How to specify zones / geographic granularity #4
     • How to include topological information #24

2. Data types + specifications workstream

   • End deliverable: A comprehensive list of all data types/kinds needed in the model, as well as the respective properties (dynamic/static, etc.).
   • Questions to answer:
     • How many data types should we specify?
     • How do we split up and define the data types?
     • What is the right level of granularity?
     • When / how should we include carbon data (if any)?
     • ...
   • Relevant issues:
     • structure of the specification #21
     • Include generation capacity? #18
     • Split imports and exports #8
     • Granularity of production and consumption #7
     • What datasets are still missing #6
     • Limit items in the spec to model inputs #5

3. Data interfacing workstream

   • End deliverable: A fully-defined API (interface) spec that describes how to get data from the data, and what data should be served by each request.
   • Questions to answer:
     • Is it flexible / intuitive enough for adopters e.g. TSOs?
     • How many endpoints should we specify?
     • What is the best interface (Rest API, GraphQL...)?
     • How do we aggregate?
     • How does the interface deal with missing values?
     • ...
   • Relevant issues:
     • structure of the specification #21
     • Handling missing data and anomalous data #25
     • Defining rules for aggregation #19
     • definition of compliance with the specification #22

Working principles

• Each group will have a main driver, who will be responsible for:
  1. Ensuring progress and getting others in the workstream to provide input and contribute
  2. Coordinating with the other workstream where relevant
  3. Keep their issues cleaned up in GitHub
  4. Presenting updates from the workstream at the biweekly sync
• Someone from each workstream familiar with GitHub will be responsible for creating the relevant pull requests. The main driver will make sure everyone can contribute to progress, including those unfamiliar with GitHub (best through GitHub issues, if not at the very least documents linked back to a GitHub issue).
• The biweekly meeting will focus solely on agreeing on pull request scopes and content (having gathered all the input). Little focus should be given to the issues themselves (discussion should ideally happen async/outside of biweekly meeting).