TAG Meeting 2016-02-03

Owned by Eric Jansson (inactive account)
Last updated: Mar 31, 2016
2 min read

Feb 3, 2016

Attending

  • Matt Warden
  • Don Dailey
  • Duy Nguyen
  • Ron Engels (Denver Public Schools)
  • Erik Gomez
  • Mark Walls
  • Neal Schuh
  • Josh Allen
  • Douglas Loyo
  • Geoff McElhanon
  • Chris Moffatt
  • Itzel Torres

Notes

The meeting goal was to review proposed items for Data Standard 2.1, and the meeting reviewed items in the attached PowerPoint deck. The main points of discussion:

API extensions and standardization. One topic that was included was a carry-over from the previous January meeting, and involved how the current Ed-Fi Data Collection API integrates extensions into API resources, as “first-class” elements, which can cause confusion in consumers of the API as to what the actual “standard” interface is. Some alternatives to current practice were suggested

  • offering extended elements at endpoints on a defined URL path extension (as in “/extension”)
  • creating separate resources that contain these properties
  • possibly maintaining a central registry of these extensions, in order to allow them to be consumed elsewhere

Natural key issues. It was noted that some Ed-Fi natural keys are cumbersome and result in the issues described in the deck. Members agreed that some enterprise keys are often tricky: one example provided was where a staff was identified in a vendor system by a pseudo id plus location, another was the practice of using email addresses as a “good enough” id. There were no objections to the data model’s use of natural keys (listed in the Powerpoint), but one member noted that a missing benefit was that natural keys allow the Ed-Fi model follow the “key unification” pattern.  [Editorial note: key unification refers to what happens as natural key fields are propagated in a model, which is to enforce absolute referential integrity. With a surrogate key model, relations can't flow past the next table. Please feel free to correct if this is inaccurate.]

A particular pain point for IDs in the current model is Section. One member suggested that student information systems have a unique section code and that the Ed-Fi model should use that one instead of the current natural key. Another possible direction (not necessarily different from the first idea) on the issue was iterative: seek stable more natural values vs unstable ones (example: “location” in the Ed-Fi Section key is likley unstable - find a way to remove it).