Date: Thu, 28 Mar 2024 10:46:38 -0500 (CDT) Message-ID: <281982977.30076.1711640798533@PUBEDFIPRDWEB5.public.local> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_30075_1631339880.1711640798532" ------=_Part_30075_1631339880.1711640798532 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Data Standard v3.1a introduces a limited set of breaking changes to the =
Data Standard v3.0 model in the Assessment domain and a small number of non=
-breaking changes in other core student information system domains. The changes with the most impact on fi=
eld implementations are described below. Those working with assessment data=
integrations are advised to review all changes listed in the All Individua=
l Changes section below.
A number of issues raised by implementers concern the composite key of t= he Assessment entity. The composite key in the Data Standard v3.0 is compos= ed of 4 elements: AssessmentTitle, Version, GradeLevel and Subject. This ke= y cascades into other domain entities including ObjectiveAssessment, Assess= mentItem, and StudentAssessment.
This structure presents a few issues in field use:
The proposed v3.1a introduces a new key consisting of AssessmentIdentifi= er and Namespace. This key follows the "partial-key surrogate pattern" wher= e a source system surrogate key (in this case, AssessmentIdentifier) is int= roduced and is scoped organizationally (in this case, by a vendor-specific = Namespace). Based on implementer feedback, it appears that vendors most typ= ically use UUIDs for the surrogate key.
The Data Standard v3.0 requires a grade level collection on the Assessme= nt entity. Assessment providers note that assessments often do not target a= particular grade level, but rather can be applicable to many grade levels.= In addition, some assessments have no clear grade-level indexing (e.g., an= IQ test). In accordance with this, GradeLevel is made an optional collecti= on in Assessment in the proposed v3.1a.
Assessment providers also noted that assessments can cover multiple subj= ect areas, so AcademicSubject was made into a required collection on Assess= ment.
Since learning objective metadata regarding grade level and subject beha= ve similarly to that of the Assessment entity, the changes above were also = made to the GradeLevel and AcademicSubject in the LearningObjective entity.= On LearningStandard, GradeLevel was additionally converted from a required= field into a required collection.
The Ed-Fi core data model has a multi-leveled hierarchy for courses:
Over time, we have seen that many characteristics can be assigned to any= level of this hierarchy. For example, a Course could be designed as dual c= redit, or it could be offered as dual credit during a particular semester (= i.e., as a CourseOffering). Or, in some circumstances, only a particular Se= ction could be dual credit. The same is often true of grade-level indexing = for course-data: it can occur at any level.
Accordingly, Course, CourseOffering, and Section are all made "parallel"= with respect to these characteristics: with this change, each entity has a= n optional collection of CourseLevelCharacteristics and an optional collect= ion of OfferedGradeLevels. Further, the definitions state that these proper= ties should only be assigned at lower levels of the hierarchy if the values= differ. This change introduces an "override" semantic into this part of th= e data model.
If the list does not appear, you can use this direct link to all changes.