Meeting 3 - 2019-07-11
Agenda
- Open source rules engine
- Inventory of existing rules engine implementations in Ed-Fi Ecosystem
- Edwire feedback
- Next steps
- Validation API
- Review of notes and comments from last meeting
- Next steps
Meeting deck: Rules_engine_and_Validation_API_SIG - Meeting 3.pptx
Participants
- Chris Moffatt (Deactivated) , Ed-Fi Alliance
- Audrey Shay , Wisconsin DPI
- Jeff Dodds (Deactivated), West Ada School District
- Neal Schuh , Skyward
- jennifer.downey , Infinite Campus
- Doug Quinton, PowerSchool
- Jon Hickam (Unlicensed) , Learning Tapestry
- Jim McKay (Deactivated), Keith D. Brown (Deactivated) ,Certica Solutions
- david.cintron, Edwire
- Douglas Loyo , Student1
- Shannon Kerlick (Deactivated) , Ed-Fi Alliance
- Vinaya Mayya . Ed-Fi Alliance
- Lyria Zeh , MSDF
Meeting Notes
The group reviewed the draft of Inventory of Rules Engines in the Ed-Fi Ecosystem in Survey of Rule Engines. (SIG participants, please add comments to this document to note additional instances you are aware of.)
David Cintron led a discussion around an existing open source approach to, that has similarities to the proposed "Option 3: the "Pure SQL approach", in the Open Source Rules Engine Survey and Recommendation document:
I want to share a really good model that includes similar use cases around an open source T-SQL base rules engine, data submission broker, shared validation rules and finally an open source website and data visualization dashboard. Here are some resources that I found insightful on how to create a loosely coupled solution around business rules:
- Write-Up on Open Source Rules Engines
- Data Broker Validation and Back-end
- Rules Engine Validation
- Opensource Website/Dashboard (End-Result)
The use case of Ed-Fi implementors wanting to compare data in the ODS with source system data came up, and there was discussion around whether this should be considered a form of "L2 validation", that could be addressed with the "SQL-based approaches being discussed", or is a largely different undertaking. The general consensus seemed to be that it may overlap, but would need to be proven out. A key difference though is access to source-system data for comparison - which is not contemplated in the SIG approaches to rules engine or validation API.
LEA's/Collaboratives with Ed-Fi implementations that are interested/motivated to understand that state/quality of data landing in an Ed-Fi ODS include: West Ada, YESPrep, San Francisco, and Oregon Nexus. (SIG participants, please add comments to this document to note additional agencies you are aware of.)
The meeting concluded with discussion of potential for Ed-Fi implementations to move both Validation API and a "simple SQL-based rules engine" concepts forward. There remains interest, but requires further discussion within agencies.