TAG Meeting 2019-07-10

Owned by Eric Jansson
Last updated: Jul 15, 2019

Agenda

  1. Update on Data Out SIG: update on the progress of the SIG plus Q&A
  2. Survey domain (action from June meeting): whether to have an independent survey domain or re-use the assessment domain model
  3. Level 1 error discussion (continuation from June meeting):
    1. Update from Open Source Rules Engine and Validation API SIG work: as we have a SIG exploring a related area, I would like to get a brief update on that work
    2. June discussion, continued
  4. Extensions Registry concept (holdover from May meeting)

Participants

  • Andrew
  • Jen
  • Jim
  • Veronica
  • Molly (INSITE, proxy for Rosh)
  • Tom
  • Marcos
  • Britto
  • Sayee S, Ed-Fi Alliance
  • Shannon K, Ed-Fi Alliance
  • Vinaya Mayya, Ed-Fi Alliance
  • Steven Arnold, Ed-Fi Alliance
  • Eric J.

Materials

Notes

Data Out SIG

SIG progress was presented - see slides

  • Gap to getting vendor input was noted.
  • It was suggested that LEA collaboratives might be something of a proxy for vendors, as they often behave in similar ways (they are aggregating LEA needs)
  • The absence of bulk JSON scenarios was noted. It was felt that this was likely due to bulk JSON being seen mostly as useful for data import.
  • There was a question about if webhooks/notifications API had come up as an option. Answer: not prominently
  • There was a question on if the Graph QL option might employ dynamic profiles. Answer: not discussed directly, but API profiles as a security mechanism had been well represented in discussions of needs.

Survey and Assessment domain

The key questions for feedback was if the Ed-Fi data model should re-use the assessment domain, have  a survey doing, or both. The question was discussed at some length; while not all points from the discussion were recorded, the main TAG feedback seemed to be:

  • Move forward with both a survey domain and an assessment domain that could capture survey data (e.g. make the small additions called for by the AWG). Primary reasons to do this:
    • This helps leave the assessment domain alone and focused on student assessments. To try to capture surveys in that system would cause a number of data elements extraneous to that use case (but important for others – say parent surveys) to be added. 
    • This separation likely makes logical sense to the market as it support current vernacular around "surveys". To force a survey provider to submit "assessments" would likely seem illogical and cause issues. Likewise, if a survey provider sees their survey as an "assessment" (e.g. a SEL provider who creates scores from it) then they can use the assessment domain.
  • However, we need to control for diverge of the two models. If/when survey enters the core data model, it should explain how it maps to the assessment model and any gaps created, so that data could (if needed) move between the two models)

Level 1 Errors

There was no time for discussion, so the item is deferred to the next month's meeting.