EdFi Calendar Model Proposed changes for Data Standard

  • Slides: 9
Download presentation
Ed-Fi Calendar Model Proposed changes for Data Standard 2. 1

Ed-Fi Calendar Model Proposed changes for Data Standard 2. 1

Background - Calendar in Ed-Fi UDM v 2. 0 • Ed-Fi UDM 2. 0

Background - Calendar in Ed-Fi UDM v 2. 0 • Ed-Fi UDM 2. 0 has no strong concept of a “calendar. ” Rather, dates that apply to educational entities (like Schools, Students and Staff) are derived from aggregating dates attached to other entities in the model: – Session (most close proxy to “calendar”) – Grading. Period – Calendar. Date (with associated Calendar. Events for that Calendar. Date) • The model assumes that the School is the entity that defines dates relating to instruction. Each of the entities above has a School. ID (School. Reference) in the entity key.

Limitations of Calendar in Ed-Fi UDM v 2. 0 • Model cannot capture scenarios

Limitations of Calendar in Ed-Fi UDM v 2. 0 • Model cannot capture scenarios where Calendar. Events differ within a School – Examples: • Pre. K has a half day on the last Friday of every month • Grade 12 will be dismissed from school a week early, etc. – Causes problems in accurate calculations of instructional time (SEA use case; would affect operational scenarios for LEAs) – Useful to note that if a School has multiple Grading. Periods or Sessions, the model can’t consistently capture how those would be applied to different grade levels or individuals • To take the Grade 12 early dismissal example above, does Grade 12 have differing Calendar. Events or does it have a different Session and Grading. Period? • If Session explicitly pointed to Calendar. Date (as in UDM), could use Session as calendar

Limitations of Calendar in Ed-Fi UDM v 2. 0 • Model assumes that all

Limitations of Calendar in Ed-Fi UDM v 2. 0 • Model assumes that all Students in a School share the same calendar. – Similar to the first problem, but not exactly the same. The first limitation is just the ability to have multiple set of relevant instructional dates within a School. This limitation is how they are applied to Students. • Staff has not come up yet, but it’s easy to imagine it will – We can envision multiple ways to make this association. A student might get different instructional dates dependent on: • Grade. Level • Program • IEP

TN Field Work • Add a School. Calendar entity and a School. Calendar. Date

TN Field Work • Add a School. Calendar entity and a School. Calendar. Date entity • Associate each Student with a School. Calendar

Nebraska Proposed Solution • • • Add a Calendar. Entity entity Associate that entity

Nebraska Proposed Solution • • • Add a Calendar. Entity entity Associate that entity with Sessions and Sessions with that entity • Proposed association is many-to-many Associate Calendar. Events direction with a Session © 2016 Ed-Fi Alliance 7

AZ Implementation • AZ implementation assumes that a school shares Sessions and Grading. Periods,

AZ Implementation • AZ implementation assumes that a school shares Sessions and Grading. Periods, and captures calendar differences via a Track entity • • Unlike other designs, Sessions and Grading. Periods are common to a whole school (as in current Ed-Fi model) As with other models, the association of a Track is via Student. School. Association © 2016 Ed-Fi Alliance 8

School Calendar - Proposed • • Calendar is a sub-concept to a session Calendar

School Calendar - Proposed • • Calendar is a sub-concept to a session Calendar is optional to accommodate multiple calendars; if none, there is only one using existing model Calendar explicitly links to students and staff Deprecate Academic. Week © 2016 Ed-Fi Alliance 9