Thursday, April 7, 2022
10:30 AM - 11:45 AM | Descriptors are important sets of data in SEA and LEA systems that allow for communication and usage of common values for data systems to interoperate. Without common descriptors, systems will be left to guess or lose parts of information in translation between interconnecting data exchanges. This session will be an open discuss on methods to manage descriptors given various contexts between SEAs and LEAs, how to set expectations when using descriptors and discuss certification implementations of producing and consuming applications connected by Ed-Fi implementations. |
These broad session notes attempt to capture the spirit of the discussion and should not be interpreted as a transcript. Although Ed-Fi Alliance staff were involved in capturing these observations, the notes below should not be construed as official, complete, or 100% accurate.
The descriptor approach has been over the course of years a pendulum between local context and fully standardized. There is a need to support the local context for value in the LEA. If we disrupt the local context then we may make teachers unable to leverage the data in their classroom. The pain point is that standard descriptors is not in every implementation so what do we do?
There was also significant concern about how to “make it easier” for agencies and also how to not give agencies (particularly LEAs) any additional responsibilities. Ditto for vendors: they should not be overburden with tasks for which they should not be responsible. There was also some discussion about where mapping data should lie within the Ed-Fi data architecture.
Most discussion oriented around action seemed to point in these directions:
- Generally, Ed-Fi’s technology and standards should prioritize data as it exists in the source system, because other data can be derived from that data and because that version is the most student-centric
- This allows for a more clear starting point for an agency and vendor: it reflects the current vendor product use context
- Agencies – and perhaps Ed-Fi specifications -- need to be made very aware of context when they proscribe use of certain descriptor sets to vendors.
- While mapping to Ed-Fi descriptors may enhance data comparison, but it also creates more work for LEAs and vendors.
- Even simple mappings create a risk: district data users may not recognize important data after such changes.
- As local agency needs to compare data are better understood, then mapping can be engaged and performed – i.e., wait to do mapping until you understand the value you will get from it
- Where certain sets are highly important to results interpretation, generally those should be taken in from the source system (e.g., in the source system namespace).
- This should probably be more common than it is today – i.e., potentially a standard “best practice” Why?
- In some cases, it may make sense for an agency to ask a vendor to norm to a certain set when providing the data via API (for example, “use these academic subjects to classify your data”), but if they are doing that, then it is likely best that the agency is asked to play an active role in that mapping – i.e. model that in the source system, so that the mapping is controlled by the agency.
- As a community we should actively explore/test/move in the direction that when a system has mappings to other important contexts, that mapping data should be treated as data and move via an Ed-Fi API. This is important because it removes the burden on LEAs to map data multiple times, and reduces possibility of errors.
There were a few other points that were raised during the discussion:
- There was a hope that people would post their namespace (e.g. EdFacts) but that never materialized
- There are descriptors that change over time and even within the year like StudentCrisisEventsDescriptor
- Do we mix namespaces or use other people's namespaces?
- can we propose that you send your own context and someone can map later. This was a concern to vendors who worry about having to send a significant amount of changes with each future mapping change
TEA guidance is they can publish any codes their want to their local ODS. Each district is required to map local codes to state codes
- There are a lot of Assessment vendors when there is usually only 1 SIS vendor. descriptors can cause a lot of overhead of assessment options
- We shouldn't lose the "core" options like grade levels