Overview

The Item and Section catalogues are central parts of the assessment system. These repositories support reuse of Assessment components by storing of the various Items (or questions if you like) and groups of Items (ie Sections) that can be used in an assessment. You are able to add/edit/delete an item of a certain type to a certain scope. Furthermore it allows you to search and browse for questions for inclusion in your assesment as well as import and export multiple questions using various formats.

In this description here we will only discuss the design implications for Items. Green colored tables have to be internationlized.

Each Item consists of a specific Item Type like "Multiple Choice Question" or "Free Text". Each Item Type adds additional Attributes to the Item, thereby making it pretty flexible. Additionally each item has a related display type storing information on how to display this item. This way we can create an adp-snippet which we can include to display a certain item (the snippet is stored de-normalized in the as_items table and update on every change to the item or the item_type).

Categorization and internationalization will make it into OpenACS 5.2, therefore we are not dealing with it in Assessment seperately but use the (to be) built in functionality of OpenACS 5.2

Additionally we have support functionality for an item. This includes the help functionality. To give Assessment authors flexibility in adapting Item defaults, help messages, etc for use in different Assessments, we abstract out a number of attributes from as_items into mapping tables where "override" values for these attributes can optionally be set by authors. If they choose not to set overrides, then the values originally created in the Item supercede.

Seperately we will deal with Checks on Items. These will allow us to make checks on the input (is the value given by the user actually a valid value??), branches (if we display this item, which responses have to have been given) and post-input checks (how many points does this answer give).

Also, note that discussion of how Items are displayed (via display types and various other attributes) has been separated into a separate page here.

Here is the graphical schema for the Item-related subsystems, including the Item Display subsystem described here.

(Omnigraffle Source File)

Specific Entities: Core Functions

Here are the components of the Item model in Assessment:

• Items (as_items) are the "questions" that constitute the atomic focus of the Assessment package. Each item is of a certain type, that can give the item additional attributes, making it really flexible. The following attributes are common to all item types.
  • item_id
  • name - some phrase used in admin UIs
  • item_text - the primary "label" attached to an Item's display
  • item_subtext - a secondary label, needed for many kinds of questions
  • field_code - a short label for use in data output header rows, etc
  • definition - some descriptive text
  • shareable_p - whether Item is shareable; defaults to 't' since this is the whole intent of this "repository" approach, but authors' should have option to prevent reuse -- This is no longer needed. We will deal with shareable_p through the permission system of OpenACS
  • enabled_p - whether Item is released for actual use
  • required_p - whether Item must be answered (default value, can be overriden)
  • item_default - optional field that sets what the Item will display when first output (eg text in a textbox; eg the defaults that ad_dateentrywidget expects: "" for "no date", "0" for "today", or else some specific date set by the author; see this example)
  • data_type - This is the expected data_type of the answer. Previously "abstract_data_type" but omitting the superfluous "abstract" term; selected from the data types supported in the RDBMS:
    1. integer
    2. numeric
    3. exponential - stored in the db as a varchar; of form 9.999e99
    4. varchar
    5. text
    6. date
    7. boolean (char(1) 't' 'f' in Oracle)
    8. timestamp (should work for all coarser granularities like date etc)
    9. content_type -- a derived type: something in the CR (instead of a blob type since we use the CR for such things now)
    This value was previously stored with each as_item_type. For retrieval purposes it makes more sense thought to store it with the item itself, as this prevents us to follow each relationship to the as_item_type objects if we want to retrieve the answer.

  • max_time_to_complete - optional max number of seconds to perform Item
  • adp_chunk - a denormalization to cache the generated "widget" for the Item (NB: when any change is made to an as_item_choice related to an as_item, this will have to be updated!)

  Permissions / Scope: 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 item.

  • Read: An assessment author (who is granted this permission) can reuse this item in one of his sections. (NB: Usually the original author has admin priviledges.)
  • Write: Author can reuse and change this item.
  • Admin: Author can reuse, change and give permission on this item

• Item Types (as_item_types) define types of items like "Open Question", "Calculation" and others. The item type will also define in what format the answer should be stored. For each item type a cr_item_type will be generated. Each object of this type is linked to the primary object of the item (see above) using relationships. This has the benefit that we split the core attributes of an item from the type specific ones and the display ones (see down below). Using cr_item_type usage allows us to create and reuse standard items (e.g. for the likert scale), by linking different questions with the answer possibilities (and the same attributes) to one as_item_type object. If we have objects that are linked this way, we can generate the matrix for them.

  Alternatively we could make the as_item_type object a child of the as_item and therefore prevent storing all the relations. In that case we'd loose the ability described before, but it might be a considerable performance gain.

  Common attributes for *all* item_types:

  • item_type_id
  • item_type_name - name like "Question Type"
  • item_type_description

  A list of all item types and their attributes can be found in the requirements section

• Item Choices (as_item_choices) contain additional information for all multiple choice item_types. Obvious examples are radiobutton and checkbox Items, but pop-up_date, typed_date and image_map Items also are constructed via Item Choices. Each choice is a child to an as_item_type Object. Note the difference. A choice does not belong to an item, but to the instance of the item_type! This way we can reuse multiple choice answers easier. It is debatable if we should allow n:m relationships between choices and item_types (thereby allowing the same choice been reused). In my opinion this is not necessary, therefore we have the parent_id. Following the Lars Skinny Table approach of conflating all the different potential data types into one table, we provide columns to hold values of the different types and another field to determine which of them is used. Item Choices have these attributes:
  • choice_id
  • parent_id (belonging to to an as_item_type object).
  • name
  • choice_text - what is displayed in the choice's "label"
  • data_type - which of the value columns has the information this Choice conveys
  • numeric_value - we can stuff both integers and real numbers here - this is where "points" could be stored for each Choice
  • text_value
  • boolean_value
  • content_value - references an item in the CR -- for an image, audio file, or video file
  • shareable_p - whether Choice is shareable; defaults to 't' since this is the whole intent of this "repository" approach, but authors' should have option to prevent reuse
  • feedback_text - where optionally some preset feedback can be specified by the author

  NB: In earlier versions (surveys/questionnaire), each Choice definition carried with it any range-checking or text-filtering criteria; these are now abstracted to the Item-Checks and Inter-Item Checks.

Help System

The help system should allow a small "?" appear next to an object's title that has a help text identified with it. Help texts are to be displayed in the nice bar that Lars created for OpenACS in the header. Each object can have multiple help texts associated with it (which will be displayed in sort order with each hit to the "?".) and we can reuse the help text, making this an n:m relationship (using cr_rels). E.g. you might want to have a default help text for certain cr_item_types, that's why I was thinking about reuse...

Relationship attributes:

• item_id
• message_id - references as_messages
• sort_order (in which order do the messages appear)

Messages (as_messages) abstracts out help messages (and other types of messages) for use in this package. Attributes include:

• message_id
• message
• locale (Actually I hope the i18n system Joel proposed makes this obsolete).