Index: openacs-4/packages/assessment/www/doc/data_collection.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/assessment/www/doc/data_collection.html,v diff -u -N -r1.1 -r1.2 --- openacs-4/packages/assessment/www/doc/data_collection.html 13 Jun 2004 23:20:44 -0000 1.1 +++ openacs-4/packages/assessment/www/doc/data_collection.html 28 Jul 2004 10:35:57 -0000 1.2 @@ -17,11 +17,9 @@

This suffices for one-shot surveys but doesn't support the fine @@ -32,17 +30,11 @@

To support user modification of submitted data (of which "store&resume" is a special case), we base all these entities in @@ -53,52 +45,21 @@ Assessment. While this situation may be unusual, the fact that it must be supported means that the semantics of cr_items don't fit the Assessment itself. They do fit the semantics of a given user's -Assessment "session" however.) -

-

Note that all these entities derive from the CR, they are also all -acs_objects and thus automagically have the standard creation_user, -creation_date etc attributes. We don't mention them separately here. -

-

Also, while this doesn't impact the datamodel structure per se, -we add an important innovation to Assessment that wasn't used in -"complex survey" or questionnaire. When a user initiates an Assessment -Session, an entire set of Assessment objects are created (literally, -rows are inserted in all the relevant tables as defined by the -structure of the Assessment). Then when the user submits a form with -one or more Items "completed", all database actions from there on -consist of updates in the CR, not insertions. (In contrast, the systems -to date all wait to insert into "survey_question_responses", for -example, until the user submits the html form.) The big advantage of -this is that determining the status of any given Item, Section or the -entire Assessment is now trivial. We don't have to see whether an Item -Data row for this particular Assessment Session is already there and -then insert it or else update it; we know that it's there and we just -update it. More importantly, all of our reporting UIs that show -Assessment admins the current status of users' progress through the -Assessment are straightforward. -

+Assessment "session" however.)

We distinguish here between "subjects" which are users whose information is the primary source of the Assessment's responses, and "users" which are real OpenACS users who can log into the system. Subjects may be completing the Assessment themselves or may have completed some paper form that is being transcribed by staff people who are users. We thus account for both the "real" and one or more "proxy" -respondents via this mechanism. +respondents via this mechanism. To make live not too complicated we +will assume that all subjects have a user_id in OpenACS.

Note that we assume that there is only one "real" respondent. Only one student can take a test for a grade. Even if multiple clinical staff enter data about a patient, all those values still pertain to that single patient. 

-

One final note: we denormalize several attributes in these entities --- -event_id, subject_id and staff_id. The reason for putting these foreign -keys in each row of the "data" is to produce a "star topology" of fact -tables and dimension tables. This will facilitate data retrieval and -analysis. (Are there other dimension keys that we should include -besides these?) -

-

Synopsis of Data-Collection Datamodel

Here's the schema for this subsystem:
@@ -107,8 +68,7 @@

Data Modell -

+ style="width: 1022px; height: 680px;">

@@ -123,238 +83,108 @@
  • Assessment Sessions (as_sessions) are the top of the data-collection entity hierarchy. They provide the central definition of a given subject's performance of an Assessment. Attributes include: -

    -

    -

    +

    • -
  • Assessment Data (as_assessment_data) captures -information about the Assessment (NB this may overlap with -as_sessions). Attributes include: -

    - -

    -

    -
    • -
  • Assessment Section Data (as_section_data) tracks the +
  • Assessment Section Data (as_section_data) tracks the state of each Section in the Assessment. Attributes include: -

    -

    -

    +

  • Assessment Item Data (as_item_data) is the heart of the data collection piece. This is the "long skinny table" where all the primary data go -- everything other than "scale" data ie calculated scoring results derived from these primary responses from subjects. Attributes include: -

    -

    -

    +

    • -
  • Assessment Scale Data (as_scale_data) captures derived -data calculated from subjects' raw responses. Attributes include: -

    - -

    -

    +
  • Assessment Scales will for the time being be handled by +an external grading / evaluation package. Assessment will only work +with percentages internally. It might be necessary to add scales into +assessment as well, but we will think about this once the time arrives. +

    • -
  • Assessment Annotations (as_annotations) provides a +
  • Assessment Annotations provides a flexible way to handle a variety of ways that we need to be able to "mark up" an Assessment. Subjects may modify a response they've already made and need to provide a reason for making that change. Teachers may want to attach a reply to a student's answer to a specific Item or make -a global comment about the entire Assessment. This mechanism provides -that flexibility, and is designed like the old general_comments system. -An argument could be made to use a generic OpenACS Comments system but -such doesn't exist now, and probably our uses here are specific enough -that it makes sense to have our own. Attributes include: -

    - -

    -

    +a global comment about the entire Assessment. This will be achieved by +using the General Comments System of OpenACS
    • + + +