Because of this variability as well as the recognition that Assessment should be primarily - a data collection package, we've decided to abstract all scoring-grading functions to one - or more additional packages. A grading package - (evaluation) - is under development now by part of our group, but no documentation is yet available about it. - How such client packages will interface with Assessment has not yet been worked out, but this - is a crucial issue to work through. Presumably something to do with service contracts. + student and teacher, for example, about inidividual items, sections or sessions.
Because of this variability as well as the recognition that Assessment should be primarily + a data collection package, we've decided to abstract all scoring-grading functions to one + or more additional packages. A grading package + (evaluation) + is under development now by part of our group, but no documentation is yet available about it. + How such client packages will interface with Assessment has not yet been worked out, but this + is a crucial issue to work through. Presumably something to do with service contracts. Such a package will need to interact both with Assessment metadata (to define what items are to be "scored" and how they are to be scored -- and with Assessment collected data (to do the actual calculations and mappings-to-grades.
We previously used a separate table for this since probably most assessments won't use this (at least, - that is the opinion of most of the educational folks here). However, since we're generating separate - revisions of each of these collected data types, we decided it would be far simpler and more appropriate - to include the signed_data field directly in the as_item_data table. Note that for complex - applications, the need to "sign the entire form" or "sign the section" could be performed by concatenating - all the items contained by the section or assessment and storing that in a "signed_data" field in as_section_data - or as_sessions. However, this would presumably result in duplicate hashing of the data -- once for the - individual items and then collectively. Instead, we'll only "sign" the data at the atomic, as_item level, and - procedurally sign all as_item_data at once if the assessment author requires only a section-level or assessment-level - signature.
-We previously used a separate table for this since probably most assessments won't use this (at least, + that is the opinion of most of the educational folks here). However, since we're generating separate + revisions of each of these collected data types, we decided it would be far simpler and more appropriate + to include the signed_data field directly in the as_item_data table. Note that for complex + applications, the need to "sign the entire form" or "sign the section" could be performed by concatenating + all the items contained by the section or assessment and storing that in a "signed_data" field in as_section_data + or as_sessions. However, this would presumably result in duplicate hashing of the data -- once for the + individual items and then collectively. Instead, we'll only "sign" the data at the atomic, as_item level, and + procedurally sign all as_item_data at once if the assessment author requires only a section-level or assessment-level + signature.
+While this doesn't impact the datamodel structure of this data collection subsystem per se, we do add an + important innovation to Assessment that wasn't used in "complex survey" or + questionnaire. When a user initiates an Assessment Session (either by requesting the assessment form + to complete herself -- such as in an online survey -- or by an admin user "assigning" the assessment to be + performed by -- or about -- a subject at some point in the future), an entire set of + Assessment data collection objects is created (literally, rows are inserted into all the + relevant tables -- as_section_data, as_item_data). Since these are CR-based entities, this means that + a cr_item and the initial cr_revision record are created for each of these entities. Then when + the user submits a form containing responses to one or more items in the assessment, the database + action consists of updates in the CR, not insertions. This contrasts to the existing "survey" packages, + in which "survey_response" or "survey_question_response" rows are only inserted once the user submits + the html form.
+Why is this a good idea? Here's the use case: for an educational course, a teacher plans a set of six + exams that the students can complete at their own rate. The teacher wants Assessment to tell her at any + moment the status -- at the individual item level -- the status of each student's progress through the exam + series. In fact, the UI to do this should create a grid consisting of columns corresponding to the exams (and + the individual exam questions in a drill-down) and rows consisting of each student. Each cell in this grid + will be colored red if the item is unanswered, yellow if answered but not "confirmed" (ie the student has "saved&resumed" + the exam and wants to revise it further), and green if "confirmed" ie "handed in".
+If the data collection subsystem doesn't create a set of "empty" records, the only way that procedurally this + kind of report can be generated is by repeatedly looping through the assessment's metadata and looking for the + existence or nonexistence of corresponding records in the data collection entities for each of the students. This + is the way the current survey and questionnaire packages have had to do it; it is ugly, error prone, and inefficient. + We need to do it differently in Assessment!
Here's the schema for this subsystem:
@@ -207,17 +233,17 @@