TAG Meeting 2021-09-16

Attendees

Agenda

1. Summit update and questions re TAG attendance
2. Multi-year data management strategies
   1. In the August meeting, we had a very spirited conversation in which TAG members recommended against the current practice of using a single database ODS to manage multiple years of data in a single database (see notes from https://edfi.atlassian.net/wiki/display/GOV/TAG+Meeting+2021-08-19)
   2. The Alliance has a follow-up request for TAG members, but we also welcome any further thoughts TAG members may have on the subject.
3. Data out supports and tools
   1. This was a priority raised by TAG members (see https://edfi.atlassian.net/wiki/display/GOV/TAG+Meeting+2021-06-17), but we have not had a chance to discuss it yet.
   2. Candidly, the Alliance staff is a bit “in the dark” as to what these might be, so please be willing to share your thoughts! If you would like to share materials in advance and/or present ideas at the meeting to help lead this, please let me know.
4. Re-anchoring certification
   1. Improving certification is a consistent theme in the community, and often what is meant is that an organization is not receiving the data it expects. But what data should be the expectation?

Materials

Ed-Fi Technical Advisory Group - Sept 2021.pptx

Notes

Multi-year data management 

On the multi-year data management issue, the main suggestion was to survey the community to gather info on the extent of various kinds of installs of the ODS and data management practice.

Unless there was way more work on the data model it is currently not great for multi year, also not advisable because the DB grows too unmanageable and the general best practice is to shovel data into a longitudinal store.

Currently year by year management of ODS databases is serviceable but not a ton of tools available.

The issue of breaking changes was raised as well - consuming those with a multi-year model seems harder.

It was noted that – while a survey will tells us the extent to which various parties may be affected by roadmap changes – it does not actually define the best long-term options.

(Note: this action was completed - see https://docs.google.com/forms/d/19WF4DMRGCyr-9thKFU8Hqq9BdO3pnrYBWCHkmJwOh98/ that went out to a community LEA list)

Data out supports and tools

A few points were covered in this discussion:

• The RVWG will be collecting these artifacts
• API to API synchronization (via API publisher) seems to be materializing as a main use case in the community
• API performance for data out generally  also seems very important, as the norm for many is to move data off the ODS
• the call for  a GraphQL interface has died down recently as the concept of the ODS as a datastore that is queried directly seems to be waning in favor of movement of data off the ODS
• API composites were discussed
  • Generally there was regarded to be some potential need to get formatted data out to reduce the number of API calls
  • However,  it was noted that the number of use cases for this has been very low (rostering and student transcripts)
  • The complexity of the current implementation was raised - maybe this should not be part of the ODS directly? The loss would be authorization support currently provided by the ODS
• Streaming data was also discussed
  • Actual use cases that need this in K12 are rare: teachers and staff don't generally have the time

Actions

• survey of multi-year ODS models (Eric)
• summarize the outcomes of the TAG data model work