Index: openacs-4/packages/assessment/www/doc/as_items.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/assessment/www/doc/as_items.html,v diff -u -N -r1.9 -r1.9.14.1 --- openacs-4/packages/assessment/www/doc/as_items.html 16 Dec 2004 16:56:31 -0000 1.9 +++ openacs-4/packages/assessment/www/doc/as_items.html 16 Jul 2016 17:39:21 -0000 1.9.14.1 @@ -77,7 +77,7 @@
Permissions / Scope: as_items need a clearly defined +
Permissions / Scope: as_items need a clearly defined scope, in which they can be reused. Instead of defining a special scope variable we will use the acs permission system to grant access rights to an @@ -144,8 +144,8 @@
-Messages (as_messages) abstracts out help messages (and other +Messages (as_messages) abstracts out help messages (and other types of messages) for use in this package. Attributes include:
@@ -29,11 +29,11 @@
To support user modification of submitted data (of which @@ -44,7 +44,7 @@ itself, different authors may be using different versions of the 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 itself. They do fit the semantics of a given user's Assessment "session" however.
We distinguish here between "subjects" which are users whose information is the primary source of the Assessment's responses, and @@ -53,8 +53,8 @@ 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. Note that subjects may or may not be - OpenACS users who can log into the system running Assessment. Thus subject_id - will be a foreign key to persons not users. If the responding + OpenACS users who can log into the system running Assessment. Thus subject_id + will be a foreign key to persons not users. If the responding user is completing the assessment for herself, the staff_id will be identical to the subject_id. But if the user completing the assessment is doing it by proxy for the "real" subject, then the staff_id will be hers while the subject_id will belong @@ -65,14 +65,14 @@ here is how and why:
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 + 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. + 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 + 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.
Note: please refer to the discussion of Items Note: please refer to the discussion of Items here. That discussion complements the discussion here, and the data model graphic pertaining to the Item Display Types system is available there -also. +also.
Table of Contents
Table of Contents