This section covers the components of the Ed-Fi Data Standards, how the standards are defined, and who is involved in their creation and ratification.
Those new to the Ed-Fi community, particularly those with expertise in other data domains, often have questions about the data covered by the Ed-Fi Data Standards — why some pieces of information are included while others are not, why we bother with an extension model in a "standard," and other good questions. Brief answers to the big questions follow.
There are a number of standards in the K–12 education space or that intersect with that space, and understanding how organizations develop those standards is important. The core principles that inform how we work are:
The Ed-Fi Data Standards focus on K–12 information related to students and their academic performance. The standards cover:
The standards are student-centric, meaning that detailed data is described at the individual student level. Many Ed-Fi products aggregate or otherwise process information to give a look at school, district, and state-level trends – but central to our philosophy is that any aggregation should be calculated based on student-level information, since each student's story is unique.
The Alliance publishes a number of normative and non-normative standards.
Normative standards include API endpoint descriptions and JSON messages and bulk data exchange specifications defined as XSD. The API Technical Design and Implementation Guidelines contains additional normative and non-normative documentation. The Ed-Fi Unifying Data Model is a logical model only and non-normative.
The Ed-Fi Unifying Data Model (UDM) serves a special function in the Ed-Fi technology suite. The Ed-Fi UDM is an abstract model that specifies the organization, structure, and types for all concrete Ed-Fi Data Standards and Ed-Fi technology – meaning that elements like Student First Name will contain similar and analogous definitions in all Ed-Fi products, including API endpoints, XSD definitions, ODS SQL tables, and so forth.
The UDM exists primarily to reconcile all published Ed-Fi standards to ensure they work together. It takes more effort as a community to maintain and ensure this harmonization via the UDM, but the experience of many data standards efforts shows that it is common to produce specifications with conflicting underlying data models, which results in complexity and incompatibility in actual data systems in the field.
Extensibility exists in a natural state of tension with standardization – and the Ed-Fi Data Standards are no exception. However, all our field work has shown that extensions are a necessary complexity in the K–12 education space. Schools, districts, and state education agencies are often required by law to track or report certain data unique to their environment, but that otherwise directly relates to the information covered by the Ed-Fi Data Standards.
Rather than deny implementers the means to extend the standards, the Alliance issues non-normative Extension Framework Guidelines for each technology component. These guidelines are updated with each version, with the goal of increasing flexibility while getting as close as possible to perfect interoperability.
The Ed-Fi Data Standards are not static, nor is the Ed-Fi Unifying Data Model intended to fulfill every possible use case. For this reason, the Alliance has a governance process that allows for gradual change.
The process also supports the creation and publication of standards for leading-edge work, and the publication of standards that support technology aligned to the Alliance's mission – even if that technology is not baked into the Ed-Fi core technology offerings.
As noted, the Alliance may publish standards that aren't necessarily part of the Ed-Fi technology core offerings. This section outlines the distinctions.
The Core Standard contains data elements that are part of our student-centric, academically focused K–12 data model. These standards are directly developed by (or under the auspices of) the Ed-Fi Alliance.
Data elements in Core Standards are found in the Ed-Fi Unifying Data Model and the Ed-Fi Data Handbook, and generally adhere to Ed-Fi Design and Implementation Guidelines.
Request for Comment (RFC) versions contain data elements and models proposed for use by the community, but not yet part of core standards. It is expected that elements and exchanges defined in RFCs will be implemented in field usage in order to find issues and refine the model further. However, those using RFC versions should be cautious to stay on the latest versions, in order to avoid fragmenting the ecosystem, as early iterations naturally occur more frequently.
The Ed-Fi Alliance has a certification program that covers many use cases based on its Core Standards.
Ed-Fi certifications allow product developers to demonstrate a product's fidelity to Ed-Fi standards and guidelines, and for purchasers or users to be confident that a product conforms to those same Ed-Fi standards and guidelines. The program's goal is to ensure that systems can inter-operate and exchange data using Ed-Fi standards and technology.
The Ed-Fi certification program was developed from the experience of education agencies in certifying Ed-Fi-compliant data exchanges for their enterprise systems. The Ed-Fi Alliance has built on that foundation to provide a certification that can be used across different agencies and organizations, alleviating the need for vendors to undergo multiple, overlapping local quality assurance efforts.
Information about the Ed-Fi Certification Program can be found here.
The Ed-Fi Alliance doesn't develop standards in a vacuum. It relies on field work and community expertise to produce solid, workable solutions. The Alliance's role in data standard development is a coordinating one: it sets schedules, assigns (and often funds) development work on the standard, arranges for field testing, shepherds draft standards through an RFC process, and publishes the final, authoritative artifacts.
While the processes and players are different, standards generally follow the same cycle: