Consider more flexible structure for StudentAttendanceSummary

[mattharris5]

Per the conversation on the NATB call on August 10, we may want to consider a more flexible data structure for reporting an attendance summary for a student. The current proposed model for 3.4 only satisfies the use case of reporting daily attendance. As education becomes less focused on daily attendance and more flexible learning environments emerge, the SIF data model should accommodate flexible summary reports with a resolution at the day, period, hour, or even minute level.

Possible Structure

This is very similar to the existing StudentAttendanceSummary structure.

• StudentAttendanceSummary
  • studentRefId
  • schoolRefId
  • schoolYear
  • resident
  • fte
  • resolution [ enumeration of Day, Period, Activity, Hour, Minute ]
  • timeTablePeriod (for resolutions below 'Day' this could be used for limiting to a specific period)
  • timeSpan
  • startDate
  • endDate
  • startDay (for migration compatibility)
  • endDay (for migration compatibility)
  • length (total length of this period - this can be used as the denominator for calculations)
  • counts
  • count
    • metric [enumeration of Presents, Absences, ExcusedAbsences, UnexcusedAbsences, Tardies ]
    • value [xs:decimal]
    • rate [xs:decimal] - (not necessarily needed if length has been provided above, but nice for the provider to do the math)

      Examples

      Summarize daily attendance for Semester 1

• resolution: Day
• timeSpan:
  • startDate: Sept 1, 2016
  • endDate: December 15, 2016
  • length: 65 (i.e., 65 days)
• counts
  • count
  • metric: Presents (many use cases may value the ability to provide both the count of presents and the count of absences separately)
  • value: 58 (i.e., present for 58 of the 65 days)
  • rate: 0.892 (89.2% present)
  • count
  • metric: Absences
  • value: 5 (absent for 5 of the 65 days)
  • rate: 0.118 (11.8% absence)

You could also include the excused vs. unexcused breakdown in there too, if your use case demanded that level of detail.

Summarize period attendance for all periods for the month of September

• resolution: Period
• timeSpan:
  • startDate: Sept 1, 2016
  • endDate: Sept 30, 2016
  • length: 160 (i.e., 160 periods in that 30 day period)
• counts:
  • count
  • metric: Absences
  • value: 23 (missed 23 periods of the 160 total)

    Summarize period attendance for this student's Period 3 for the entire year

• resolution: Period
• timeTablePeriod: 3
• timeSpan:
  • startDate: Sept 1, 2016
  • endDate: June 5, 2017
  • length: 180 (180 period 3's in the year)
• counts:
  • count:
  • metric: Absences
  • value: 13 (missed 13 period 3's in the year)
  • count:
  • metric: Tardies
  • values: 74 (this student is late to period 3 a lot!)

    Summarize minute attendance for a single day

• resolution: Minute
• timeSpan:
  • startDate: October 7, 2016
  • endDate: October 7, 2016
  • length: 360 (360 minutes of school that day)
• counts:
  • count:
  • metric: Presents
  • value: 348 (was present for 348 minutes that day)

Using these flexible structures, providers can choose to summarize attendance at nearly any level to fit the needs of the use case. These summaries could be used "out of the box" by other enterprise applications or other systems. A provider could potentially include tens or hundreds of summaries for a student, or even generate them on demand to requests for certain time ranges.

[mattharris5]

What do you think @Access4Learning/natb ?

[vinceparedes]

Sounds good. I think it should also be set up for time-based sampling, for example, 13:40 Mon-Fri weeks 27-52.

---

Vince Paredes vinceparedes@gmail.com 512-785-7116

On Aug 10, 2016, at 3:08 PM, Matt Harris notifications@github.com wrote:

What do you think @Access4Learning/natb https://github.com/orgs/Access4Learning/teams/natb ?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Access4Learning/NADM/issues/111#issuecomment-238987878, or mute the thread https://github.com/notifications/unsubscribe-auth/AK22-3E8HKkPYzOxFV41mh01_VPkxcf9ks5qei-lgaJpZM4Jhhjo.

[tqwhite]

Excellent. I like the choice of the name 'resolution'.

I think I would vote against the time-based sampling suggestion for now. It is a complicated thing to include and would reduce the clarity of the data structure. Also, I don't see anything about the current proposal that would preclude it in the future.