TAG Meeting 2016-02-03
- Eric Jansson (inactive account)
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).