Minor Changes to the Data Model 

Minor changes are those believed to be non-breaking to widely operationalized domains of the Ed-Fi data model (i.e., they should break few, if any, implementations).

Changes discussed in this section:

Changes to Reduce Overlap in Capture of Student Characteristics (DATASTD-1083, DATASTD-1084)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

Over time, the Ed-Fi Unifying Data Model has acquired multiple, often overlapping ways to capture concepts around (broadly speaking) "student characteristics." In some cases, the semantics of these entities has also become overly broad, further inviting overlap. A few changes were made to improve this situation.

Change Detail

The following changes were made in Ed-Fi Data Standard v3.0:

• Definition change for StudentCharacteristic to clarify differences from program characteristics.
• Removal of the LearningStyle common type.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-1083, DATASTD-1084).

Changed Representation of Assessment Family in the Model (DATASTD-926)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

In the Ed-Fi Data Standard v2.0, the AssessmentFamily entity duplicated many data fields from the Assessment entity. For example, both had attributes for GradeLevel, AcademicSubject, Category, Version, and several other fields. This duplication introduced ambiguity. If values for the same field name such as AcademicSubject differed between the Assessment and the AssessmentFamily associated with that Assessment, which value would be judged to be correct? Rather than create rules at the Data Standard level for interpretation of such situations (which would have been a new direction, and could easily be missed by those implementing API and other clients), Data Standard v3.0 instead simplifies the model.

Though AssessmentFamily has been used to group Assessments in field work, there was no identified use of the optional (and redundant) fields in AssessmentFamily and no use cases using these fields were noted during the Request for Comment periods.

The model is changed by removing the AssessmentFamily domain entity and introducing an AssessmentFamily field directly on Assessment. Assessments can be associated with each other through use of this new field.

Change Detail

The following changes were made:

• Removed the AssessmentFamily domain entity from the model. 
• Replaced the reference to AssessmentFamily in the Assessment domain entity with optional string AssessmentFamily. 
• Changed Assessment.Namespace to be required (since it was previously required in AssessmentFamily).

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-926).

Removal of Volatile Fields in Keys of Less Used Entities (OpenStaffPosition and RestraintEvent) (DATASTD-908, DATASTD-978)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

In the Ed-Fi Data Standard v2.0, the infrequently used entities OpenStaffPosition and RestraintEvent had volatile keys. Similar to the change on Section, key fields were dropped from these less-used entities in the model. In both cases, the entity is expected in field work to have surrogate source system key, and also has an EducationOrganization reference (e.g., an organizational scope); those two attributes should be sufficient to define the identity. 

Change Detail

The following changes were made:

• StaffClassification, EmploymentStatus, and DatePosted were removed from the OpenStaffPosition key and included as required fields.
• EventDate was removed from the RestraintEvent key and included as a required field.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-908, DATASTD-978).

Added Date Support to Student Education Organization Responsibility Association (DATASTD-967)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

StudentEducationOrganizationResponsibilityAssociation is used to represent cases in which a particular responsibility for a student (e.g., funding, discipline, etc.) has been assigned to a different education organization than the one in which the student is enrolled (enrollment is captured through a StudentSchoolAssociation).

The Ed-Fi Data Standard v2.0 model only permitted representation of a static, “current” representation of such a responsibility relationship as the entity had no dates attached. Adding a BeginDate and EndDate to StudentEducationOrganizationResponsibilityAssociation permits the history of changes in an EducationOrganization's responsibility for a student to be preserved, which was a documented field need. Consistent with other enrollment and assignment records in the model, BeginDate attribute was made part of the key.

Change Detail

The following changes were made:

• Added BeginDate to StudentEducationOrganizationResponsibilityAssociation. BeginDate is required and part of the key.
• Added EndDate to StudentEducationOrganizationResponsibilityAssociation as an optional property.
  
  

{
  "id": "458948e3de8547608024bfaf9ab53533",
  "educationOrganizationReference": {
    "educationOrganizationId": 255901107,
    "link": {
      "rel": "school",
      "href": "/school?schoolId=255901107"
    }
  },
  "studentReference": {
      "studentUniqueId": "605266",
      "link": {
        "rel": "Student",
        "href": "/students?studentUniqueId=605266"
      },
  "responsibilityDescriptor": "Individualized Education Program",
  "beginDate": "2016-11-01",
  "endDate": "2017-03-31",
  "_etag": "635696150777400000"
}

Lines 17 and 18 show the new values. In this example, the student was in an individualized education program from November 1, 2016 through March 31, 2017. As with other BeginDate and EndDate date ranges in the Ed-Fi model, an empty or null EndDate element signifies that the association is still current.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-967).

Changes to and Expansion of Staff Credential Model (DATASTD-940)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

Specific staff credentials are often used as the basis for specific teaching or employment assignments. In the Ed-Fi Data Standard v2.0, credentials were captured as a collection directly on Staff as a common type, which meant that they could not be easily referenced from employment and other associations. To solve this problem, Credential is modeled as a core domain entity (rather than as a common type), and optional references to Credentials have been added on StaffEducationOrganizationAssignmentAssociation and StaffEducationOrganizationEmploymentAssociation.

The model also expands the Credential entity to capture new attributes found in field work.

Change Detail

The following changes were made:

• Promoted Credential from common type to domain entity.
• Added reference to Credential on Staff as optional collection.
• Added optional reference to Credential on StaffEducationOrganizationAssignmentAssociation and StaffEducationOrganizationEmploymentAssociation.
• Added Credential to StaffAssociation interchange.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-940).

Removal of the LevelDescriptor Entity (DATASTD-1013)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

In Ed-Fi Data Standard v2.0, the Credential common type (on Staff) included a Level descriptor reference that served the same purpose as — and was essentially a duplicate of — the GradeLevelDescriptor entity. To address this, the Credential type (added as a domain entity) was changed to use GradeLevelDescriptor. LevelDescriptor was removed from the model.

Change Detail

The following changes were made:

• Credential type changed to use GradeLevelDescriptor. 
• LevelDescriptor was removed from the model.

At an API level, this will result in the need to rename the field. Under the latest release, the field changed from name "levelDescriptor" to "gradeLevelDescriptor", as shown below:

{
  "identifier": "9976732B",
  "stateOfIssueStateAbbreviationDescriptor": "NC",
  "credentialTypeDescriptor": "Certification",
  "gradeLevelDescriptor": "First grade",
  ...
}

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-1013).

Removed StateOrganizationID Field and Broadened Applicability of EducationOrganization Concept (DATASTD-972)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

A few changes have been made to reinforce the applicability of the Ed-Fi data model to local education agency use cases.

The initial Ed-Fi model was derived from state-level use cases and therefore required a StateOrganizationId for all EducationOrganizations. In state field work and usage, this field value often confusingly duplicated the concrete subclass keys (e.g., School.SchoolID = School.StateOrganizationId). Further, requiring a StateOrganizationID can make the model more difficult to use in cross-state use cases. Field work also suggests that NCES IDs (a federal identifier) are likely a more efficient option. For all of these reasons, the field EducationOrganization.StateOrganizationId has been dropped from the model

Entity definitions were also adjusted to allow for non-state identifiers for EducationOrganizations (e.g., to allow use of NCES IDs).

Change Detail

The following changes were made:

• Removed attribute StateOrganizationId from EducationOrganization domain entity.
• Removed the text "by the State Education Agency (SEA)" from the annotation of the EducationOrganizationId field in EducationOrganization and all EducationOrganization subclasses (School, LocalEducationAgency, StateEducationAgency, EducationServiceCenter, and EducationOrganizationNetwork).

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-972).

Changed Cardinality of References to Sections and Programs referenced from StudentLearningObjective and StudentCompetencyObjectives (DATASTD-1018)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

In the Ed-Fi Data Standard v2.0, the model only allows for one Section or Program enrollment to be associated with a StudentLearningObjective or a StudentCompetencyObjective.

Feedback from field work has shown that a student's performance on a learning objective or competency objective may be related to multiple sections in which they are enrolled or multiple programs in which they are participating. 

Change Detail

The following changes were made:

• Updated the cardinality of the StudentSectionAssociation and StudentProgramAssociation references in the StudentLearningObjectiveSectionOrProgramChoice and the StudentComptencyObjectiveSectionOrProgramChoice to allow collections.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-1018).

Added EducationOrganization Subclasses to Support Representation of Community Providers and Post-Secondary Institutions (DATASTD-329, DATASTD-1010)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

Community projects and field work continue to expand the scope of EducationOrganization subclasses. As such it is useful to start coordinating community representations and patterns.

• PostSecondaryInstitution is added to represent universities and similar higher-ed organizations.
• In practice, school districts often rely on external providers for instructional services, and these organizations do not fit in any of the existing EducationOrganization subclasses under the Ed-Fi Data Standard v2.0. Such organizations are logically distinct from school districts, schools, and regional education service centers in that they have specific processes and requirements (e.g., specific licensure requirements). The standard picks up some models from field work in Delaware and elsewhere to address this need.

Change Detail

The following changes were made:

• Created CommunityOrganization and CommunityProvider entities (both subclasses of EducationOrganization).
• Created PostSecondaryInstitution entity.
• Added CommunityProviderLicense domain entity to track credentialing of such entities, which was a demonstrated use case in field work.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-329, DATASTD-1010).

Introduction of Period Entity and Pattern to Capture Entity History (DATASTD-1085, DATASTD-1092)

Impacts: Ed-Fi UDM Handbook, Ed-Fi ODS / API, Ed-Fi XSD for Bulk Data Exchange

Over time, the ability of the model to capture multi-year data has grown in importance in the community. Implementers have sought to leverage the standard to exchange historical data, and have also extended the model to make the data "multi-year" aware. This work has been difficult. Since identity in UDM bindings such as the ODS / API is driven by natural keys, dates are often needed to distinguish repeated events and to capture history (e.g., StudentSchoolEnrollments, where BeginDate is part of the key and allows implementations to capture a history of re-enrollment).

While forcing data providers to supply dates may work in areas where dates are strongly governed (e.g., enrollment), in other situations where dates are not strongly governed (e.g., a student's surname is changed) this practice may force on data providers a requirement that cannot be fulfilled (e.g., the data provider system may not record dates for the name change event).

Change Detail

Data Standard v3.0 contains a pattern for capturing history via a Period entity, employed as an optional collection. This model allows for entities to capture and retain dates reflecting periods in which the data was valid. An example of Period entity to capture entity history is shown below. 

      "addresses": [
      {
        "addressTypeDescriptor": "Home",
        "stateAbbreviationDescriptor": "TX",
        "streetNumberName": "89 South Milton St",
        "city": "Grand Bend",
        "postalCode": "78834",
        "periods": [
          {
            "beginDate": "2017-08-12",
            "endDate": "2017-11-20"
          },
         {
            "beginDate": "2018-02-01",
            "endDate": "2017-06-06"
          }
        ]
      }

The principal concern with the pattern is that in places where multiple clients write/exchange the same entity, it seems possible that a client without the historical context could overwrite the data in the Period entity.

Reference

View ticket in the Ed-Fi Alliance Tracker / JIRA system (DATASTD-1085 , DATASTD-1092).