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).