TAG Meeting 2022-01-20

Attendees

Agenda

1. Data Out via API

   1. TAG inputs (from Nov/Dec)

   2. proposed architecture / direction - see https://github.com/K12-Analytics-Engineering/dagster-edfi-api-to-bq-amt/releases (Marcos)

   3. Update on RVWG

2. Certification and SEA/LEA data collision poll to TAG

   1. See summary attached to this page: TAG Meeting -2022-01-20 - Summary of SEA-LEA Data Collision

3. Managed provider support

   1. SSO and multi-tenancy for Ed-Fi tools

   2. How to further understand needs and priorities?

Materials

Open

Notes

Data Out

A demonstration of the Exchange project linked above was shown as a means to propose the ideas: would a system like this meet community use cases. Some comments reaffirmed the point that we collectively need to consider solutions using such "off-the-shelf" toolkits as we prioritize data out feature development, as maybe such tools can supplant demand for complex new ODS API features.

In subsequent discussion, there were comments pointing out that the use case here is more around analytics interoperability: movement of the data to an analytics infrastructure, and less for system-interoperability, the need to provide for more narrow, generally current-year data to "hydrate" collaborating systems.

Considerable further discussion took on the topic of if the Alliance should be publishing an "analytics specification" AMT was pointed out as an obvious starting point. The TAG discussion was generally favorable on the Alliance taking a stronger approach in this area. We agreed that a session at the Tech Congress was at a minimum needed.

SEA/LEA data collision

The results of the poll were presented and discussed. In general, cases 1 and 3 – as presented in the summary linked – were not controversial and most discussion centered on case 2. Several points were made:

• Both state and local identifiers for elements like Course Codes are important and likely need to be captured

• The possibility of sourcing local data from SIS → LEA → and then to SEA was raised as a architecture to consider (TEA, SC).  This concept was debated: it would result in LEAs "losing some control" over how their data was presented, but it was seen as a way of simplifying SIS integrations (no more profiles or variations)

• The local context must be seen as the primary context for data out from a SIS, as that is the data most closely connected to educating students and the district operations.

  • Some comments about "whose data is this - the states or the districts?" seemed to reaffirm this position.

  • Some comments also pointed out that you can move from local/granular to state/aggregate, but not the other way

• The possibility of a resource/page that displays a SIS capability more precisely was raised (shows what a SIS is capable of in terms of sending data in each geography)