Gradebook and Grade Data Model Changes

Owned by Eric Jansson
Last updated: Jan 25, 2023 by Jason HoekstraVersion comment
3 min read

Gradebook

References

Gradebook has not bee a part of Ed-Fi certification, and as a result has been used less. However, it is clear that there is growing community interest in this domain, for example as evidenced in the recent Learning Management Systems Data and Analytics Special Interest Group.

However, the Gradebook data model has presented several challenges, and the community needs to consider alternative and likely breaking changes to address these issues. 

Issues are listed in general order of priority.

Gradebook Identity

Gradebook domain identity is a legacy of the Ed-Fi Suite 1 focus on file-based transfers. In this model of exchange, there was an assumption that data was wiped/erased and re-loaded on a periodic basis (generally overnight). This assumption led to key fields that were often subject to change.

Significant work on Ed-Fi Suite 2 and 3 standards went into addressing this issue across the data model, but gradebook as not covered as usage was low at the time and it was not part of Ed-Fi certification. 

As a result, GradebookEnty and StudentGradebookEnty  identify is almost certainly volatile. The issues come from these identity fields:

  • DateAssigned: generally dates have been found to make poor identifying characteristics as they are frequently mis-entered and corrected. Dates should only be used when they are part of a high-stakes, highly monitored process (e.g. an enrollment date). An assignment date does not rise close to that level of solidity.
  • GradebookEntryTitle: a title to a gradebook entry is likely volatile and can change   
  • Section (reference): while a section is an important and likely stable identifying characteristic, the issue is that many gradebooks are not likely to be able to supply (or know about) all fields on the Ed-Fi Section key. This was discovered in the work on the LMS Toolkit, where generally a LMS uses a single identifier to track section identity (see analysis on LMS - Joining Entities across Systems and LMS - Joining Sections)

Proposed Solution

GradebookEntry key changed to

  • GradebookEntryIdentifier (key)Namespace (key)
  • SectionIdentifier (key)

This key would naturally propagate to StudentGradebookEnty  

This field added to GradebookEntry 

  • SectionReference (optional)

Significant discussion was dedicated to ideas around resolving the ability to get Section identity via API functionality, for example by supporting "lookup" in references via API (similar to the previous XML concept of LookupTypes).Given current API capabilities however, the best current approach was judged to be the pattern used by the LMS API and Toolkit, by which a the shared fields to join on are included as as key properties, and a separate but optional "whole" reference is also provided. 

Association of Gradebook Entries with Learning Standard

DATASTD-1638 - Getting issue details... STATUS

The ticket adequately captures this need and work on possible designs is happing there for now: please see that for details.

Grades

EDFI-1004 - Getting issue details... STATUS

The main gap expressed for the Grade entity is to be able to get current grades on an interim basis. There are a couple of strategies to do this.

Option 1

The first option is to leverage the current Grade entity. There seem to be 2 possibilities to identifying a current grade.

  • Use the current model as-is, but set the normative requirement (enforced in standards and certification) that a SIS (or other Grade provider) must send a current grading period grade, even if the grading period has not ended,
  • Use the Grade.GradeType field to create a standard value of "Current" that is used to transmit the current grade.

Further, this normative use would specify how to report "no current grade". The proposed way to do this is to transmit a Grade according to one of the systems above, but leave both LetterGradeEarned and NumbericGradeEarned blank. 

Option 2

The second option is to provide some entity from the Gradebook itself that represents the grade. For example, there could be a GradebookEntry that represeants the summative grade for the grading period.

For both options

For both options, there is a question of the periodicity of updates. Should they be made on a transactional basis as values are changed in the gradebook? Doing so could greatly expand the scope of transactions overall. Some other periodicity (e.g., daily) may make more sense.

Analysis

Of these options the first option is preferred, for these reasons:

  • Field experience suggests  that most SIS systems do track a current grading period grade, so having the SIS manage this value alongside historical values seems simpler. If a current grade is tracked through a separate system, that is not necessarily a problem (the SIS updates "final" grades and the gradebook system "current" grades).
  • Adding a new "conventionally-understood" entity of expanding the Gradebook elements to accommodate this does not seem necessary.

The periodicity is a tougher question for which we need to seek community input.

Other changes

Convert grade marks into a descriptor - DATASTD-1343 - Getting issue details... STATUS