At its core, the Assessment package defines a hierarchical +container model of a "survey", "questionnaire" +or "form". This approach not only follows the precedent +of existing work; it also makes excellent sense and no one has come +up with a better idea.
+We choose the terms Assessment-Sections-Items-Choices over +Surveys-Sectdions-Questions-Choices partly to reduce naming clashes +during the transition from Survey/Questionnaire packages, but +mostly because these terms are more general and thus suit the +broader applicability intended for this package.
+As is the custom in the OpenACS framework, all RDBMS tables in +the package will be prepended with "as_" to prevent +further prefent naming clashes. Judicious use of namespaces will +also be made in keeping with current OpenACS best practice.
+Several of the Metadata entities have direct counterparts in the +Data-related partition of the data model. Some standards (notably +CDISC) rigorously name all metadata entities with a +"_def" suffix and all data entities with a +"_data" suffix -- thus "as_item_def" and +"as_item_data" tables in our case. We think this is +overkill since there are far more metadata entities than data +entities and in only a few cases do distinctions between the two +become important. In those cases, we will add the "_data" +suffix to data entities to make this difference clear.
+A final general point (that we revisit for specific entities +below): the Assessment package data model exercises the Content +Repository (CR) in the OpenACS framework heavily. In fact, this use +of the CR for most important entities represents one of the main +advances of this package compared to the earlier versions. The +decision to use the CR is partly driven by the universal need for +versioning and reuse within the functional requirements, and partly +by the fact that the CR has become "the Right Way" to +build OpenACS systems. Note that one implication of this is that we +can't use a couple column names in our derived tables because +of naming clashes with columns in cr_items and cr_revisions: title +and description. Furthermore we can handle versioning and internationalization through +the CR.
+Here's a detailed summary view of the entities in the +Assessment package. Note that in addition to the partitioning of +the entities between Metadata Elements and Collected Data Elements, +we identify the various subsystems in the package that perform +basic functions.
+ +We discuss the following stuff in detail through the subsequent +pages, and we use a sort of "bird's eye view" of this +global graphic to keep the schema for each subsystem in perspective +while homing in on the relevant detail. Here's a brief +introduction to each of these section+At its core, the Assessment package defines a hierarchical container +model of a "survey", "questionnaire" or "form". This approach not only +follows the precedent of existing work; it also makes excellent sense +and no one has come up with a better idea. +
+ +We choose the terms Assessment-Sections-Items-Choices over +Surveys-Sectdions-Questions-Choices partly to reduce naming clashes +during the transition from Survey/Questionnaire packages, but mostly +because these terms are more general and thus suit the broader +applicability intended for this package. +
+As is the custom in the OpenACS framework, all RDBMS tables in +the package will be prepended with "as_" to prevent further prefent +naming clashes. Judicious use of namespaces will also be made in +keeping with current OpenACS best practice. +
+Several of the Metadata entities have direct counterparts in +the Data-related partition of the data model. Some standards (notably +CDISC) rigorously name all metadata entities with a "_def" suffix and +all data entities with a "_data" suffix -- thus "as_item_def" and +"as_item_data" tables in our case. We think this is overkill since +there are far more metadata entities than data entities and in only a +few cases do distinctions between the two become important. In those +cases, we will add the "_data" suffix to data entities to make this +difference clear. +
+A final general point (that we revisit for specific entities +below): the Assessment package data model exercises the Content +Repository (CR) in the OpenACS framework heavily. In fact, this use of +the CR for most important entities represents one of the main advances +of this package compared to the earlier versions. The decision to use +the CR is partly driven by the universal need for versioning and reuse +within the functional requirements, and partly by the fact that the CR +has become "the Right Way" to build OpenACS systems. Note that one +implication of this is that we can't use a couple column names in our +derived tables because of naming clashes with columns in cr_items and +cr_revisions: title and description. Furthermore we can handle versioning and internationalization through +the CR.
+ ++Here's a detailed summary view of the entities in the Assessment +package. Note that in addition to the partitioning of the entities +between Metadata Elements and Collected Data Elements, we identify the +various subsystems in the package that perform basic functions. +
+We discuss the following stuff in detail through the subsequent +pages, and we use a sort of "bird's eye view" of this global graphic to +keep the schema for each subsystem in perspective while homing in on +the relevant detail. Here's a brief introduction to each of these +sectionAt its core, the Assessment package defines a hierarchical -container model of a "survey", "questionnaire" -or "form". This approach not only follows the precedent -of existing work; it also makes excellent sense and no one has come -up with a better idea.
-We choose the terms Assessment-Sections-Items-Choices over -Surveys-Sectdions-Questions-Choices partly to reduce naming clashes -during the transition from Survey/Questionnaire packages, but -mostly because these terms are more general and thus suit the -broader applicability intended for this package.
-As is the custom in the OpenACS framework, all RDBMS tables in -the package will be prepended with "as_" to prevent -further prefent naming clashes. Judicious use of namespaces will -also be made in keeping with current OpenACS best practice.
-Several of the Metadata entities have direct counterparts in the -Data-related partition of the data model. Some standards (notably -CDISC) rigorously name all metadata entities with a -"_def" suffix and all data entities with a -"_data" suffix -- thus "as_item_def" and -"as_item_data" tables in our case. We think this is -overkill since there are far more metadata entities than data -entities and in only a few cases do distinctions between the two -become important. In those cases, we will add the "_data" -suffix to data entities to make this difference clear.
-A final general point (that we revisit for specific entities -below): the Assessment package data model exercises the Content -Repository (CR) in the OpenACS framework heavily. In fact, this use -of the CR for most important entities represents one of the main -advances of this package compared to the earlier versions. The -decision to use the CR is partly driven by the universal need for -versioning and reuse within the functional requirements, and partly -by the fact that the CR has become "the Right Way" to -build OpenACS systems. Note that one implication of this is that we -can't use a couple column names in our derived tables because -of naming clashes with columns in cr_items and cr_revisions: title -and description. Furthermore we can handle versioning and internationalization through -the CR.
-Here's a detailed summary view of the entities in the -Assessment package. Note that in addition to the partitioning of -the entities between Metadata Elements and Collected Data Elements, -we identify the various subsystems in the package that perform -basic functions.
- -We discuss the following stuff in detail through the subsequent -pages, and we use a sort of "bird's eye view" of this -global graphic to keep the schema for each subsystem in perspective -while homing in on the relevant detail. Here's a brief -introduction to each of these section-At its core, the Assessment package defines a hierarchical container -model of a "survey", "questionnaire" or "form". This approach not only -follows the precedent of existing work; it also makes excellent sense -and no one has come up with a better idea. -
- -We choose the terms Assessment-Sections-Items-Choices over -Surveys-Sectdions-Questions-Choices partly to reduce naming clashes -during the transition from Survey/Questionnaire packages, but mostly -because these terms are more general and thus suit the broader -applicability intended for this package. -
-As is the custom in the OpenACS framework, all RDBMS tables in -the package will be prepended with "as_" to prevent further prefent -naming clashes. Judicious use of namespaces will also be made in -keeping with current OpenACS best practice. -
-Several of the Metadata entities have direct counterparts in -the Data-related partition of the data model. Some standards (notably -CDISC) rigorously name all metadata entities with a "_def" suffix and -all data entities with a "_data" suffix -- thus "as_item_def" and -"as_item_data" tables in our case. We think this is overkill since -there are far more metadata entities than data entities and in only a -few cases do distinctions between the two become important. In those -cases, we will add the "_data" suffix to data entities to make this -difference clear. -
-A final general point (that we revisit for specific entities -below): the Assessment package data model exercises the Content -Repository (CR) in the OpenACS framework heavily. In fact, this use of -the CR for most important entities represents one of the main advances -of this package compared to the earlier versions. The decision to use -the CR is partly driven by the universal need for versioning and reuse -within the functional requirements, and partly by the fact that the CR -has become "the Right Way" to build OpenACS systems. Note that one -implication of this is that we can't use a couple column names in our -derived tables because of naming clashes with columns in cr_items and -cr_revisions: title and description. Furthermore we can handle versioning and internationalization through -the CR.
- --Here's a detailed summary view of the entities in the Assessment -package. Note that in addition to the partitioning of the entities -between Metadata Elements and Collected Data Elements, we identify the -various subsystems in the package that perform basic functions. -
-We discuss the following stuff in detail through the subsequent -pages, and we use a sort of "bird's eye view" of this global graphic to -keep the schema for each subsystem in perspective while homing in on -the relevant detail. Here's a brief introduction to each of these -section