doc/gutshtml/SessionThre1.html - view

File: [LON-CAPA] / doc / gutshtml / SessionThre1.html
Revision 1.2: download - view: text, annotated - select for diffs
Tue Jul 22 14:47:00 2003 UTC (21 years, 4 months ago) by bowersj2
Branches: MAIN
CVS tags: version_2_9_X, version_2_9_99_0, version_2_9_1, version_2_9_0, version_2_8_X, version_2_8_99_1, version_2_8_99_0, version_2_8_2, version_2_8_1, version_2_8_0, version_2_7_X, version_2_7_99_1, version_2_7_99_0, version_2_7_1, version_2_7_0, version_2_6_X, version_2_6_99_1, version_2_6_99_0, version_2_6_3, version_2_6_2, version_2_6_1, version_2_6_0, version_2_5_X, version_2_5_99_1, version_2_5_99_0, version_2_5_2, version_2_5_1, version_2_5_0, version_2_4_X, version_2_4_99_0, version_2_4_2, version_2_4_1, version_2_4_0, version_2_3_X, version_2_3_99_0, version_2_3_2, version_2_3_1, version_2_3_0, version_2_2_X, version_2_2_99_1, version_2_2_99_0, version_2_2_2, version_2_2_1, version_2_2_0, version_2_1_X, version_2_1_99_3, version_2_1_99_2, version_2_1_99_1, version_2_1_99_0, version_2_1_3, version_2_1_2, version_2_1_1, version_2_1_0, version_2_12_X, version_2_11_X, version_2_11_5_msu, version_2_11_5, version_2_11_4_uiuc, version_2_11_4_msu, version_2_11_4, version_2_11_3_uiuc, version_2_11_3_msu, version_2_11_3, version_2_11_2_uiuc, version_2_11_2_msu, version_2_11_2_educog, version_2_11_2, version_2_11_1, version_2_11_0_RC3, version_2_11_0_RC2, version_2_11_0_RC1, version_2_11_0, version_2_10_X, version_2_10_1, version_2_10_0_RC2, version_2_10_0_RC1, version_2_10_0, version_2_0_X, version_2_0_99_1, version_2_0_2, version_2_0_1, version_2_0_0, version_1_99_3, version_1_99_2, version_1_99_1_tmcc, version_1_99_1, version_1_99_0_tmcc, version_1_99_0, version_1_3_X, version_1_3_3, version_1_3_2, version_1_3_1, version_1_3_0, version_1_2_X, version_1_2_99_1, version_1_2_99_0, version_1_2_1, version_1_2_0, version_1_1_X, version_1_1_99_5, version_1_1_99_4, version_1_1_99_3, version_1_1_99_2, version_1_1_99_1, version_1_1_99_0, version_1_1_3, version_1_1_2, version_1_1_1, version_1_1_0, version_1_0_99_3, version_1_0_99_2, version_1_0_99_1, version_1_0_99, version_1_0_3, version_1_0_2, version_1_0_1, version_1_0_0, version_0_99_5, version_0_99_4, loncapaMITrelate_1, language_hyphenation_merge, language_hyphenation, bz6209-base, bz6209, HEAD, GCI_3, GCI_2, GCI_1, BZ4492-merge, BZ4492-feature_horizontal_radioresponse, BZ4492-feature_Support_horizontal_radioresponse, BZ4492-Support_horizontal_radioresponse

Convert GUTs HTML to PROPER line endings.

<html> <head> <meta name=Title content="Session Three: Publication, Content Maps, Course Maps (Gerd)"> <meta http-equiv=Content-Type content="text/html; charset=macintosh"> <title>Session Three: Publication, Content Maps, Course Maps (Gerd)</title> <style> </style> </head> <body bgcolor=#FFFFFF class="Normal" lang=EN-US> <div class=Section1> <h2>Session Three: Publication, Content Maps, Course Maps (Gerd)</h2> <h3><a name="_Toc514840855"></a><a name="_Toc421867109">Publication of a Resource</a></h3> Authors can only write-access the /~authorname/ space. They can copy resources into the resource area through the publication step, and move them back through a recover step. Authors do not have direct write-access to their resource space. <div class=Section9> <div style='border:solid windowtext .5pt;padding:1.0pt 4.0pt 1.0pt 4.0pt'> Construction space � Publication Step � Resource space � Retrieve � </div> During the publication step, several events will be triggered. Metadata is gathered, where a wizard manages default entries on a hierarchical per-directory base: The wizard imports the metadata (including access privileges and royalty information) from the most recent published resource in the current directory, and if that is not available, from the next directory above, etc. The Network keeps all previous versions of a resource and makes them available by an explicit version number, which is inserted between the file name and extension, for example foo.2.html, while the most recent version does not carry a version number (foo.html). Servers subscribing to a changed resource are notified that a new version is available. <h3><a name="_Toc514840857"></a><a name="_Toc421867110">Content Re-usage and Granularity</a></h3> Any faculty participating in the Network can publish their own learning resources into the common pool. To that end, the Network provides a �construction space� which is only accessible to the author, and a publication process, which transfers the material to the shared pool � during the publication process, metadata about the resource is gathered, and system-wide update notification and versioning mechanisms are triggered.. Learning resources could be simple paragraphs of text, movies, applets, individualizing homework problems, etc. In addition to providing a distributed digital library with mechanisms to store and catalog these resources, the Network enables faculty to combine and sequence these resources at several levels: An instructor from Community College A could combine a text paragraph from University B with a movie from College C and an online homework problem from Publisher D, to form one page. Another instructor from High School E can take that page from Community College A and combine it with other pages into a module, unit or chapter. Those in turn can be combined into whole coursepacks. Faculty can design their own curricula from existing and newly created resources instead of having to buy into a complete off-the-shelf product. Fig. 2.3.1 shows a general overview of the resource assembly mechanism and the different levels of content granularity supported by the current implementation of this principle. The topmost puzzle piece represents a resource at the fragment level � one GIF, one movie, one paragraph of text, one problem, or one regular web page. Attached to the resource is metadata gathered at the publication time of the resource. Using the resource assembly tool described below, these fragments and pages can be assembled into a page. A page is a resource of the grain size which would be rendered as one page on the web and/or on the printer. Using the same tool, fragments (which would then be rendered as standalone pages), pages and sequences can be assembled into sequences. Sequences are resources which are rendered a sequence of pages, not necessarily linear. Examples are one lesson, one chapter, or one learning cycle On the third granularity level, fragments (rendered as standalone pages), pages, and sequences can be assembled into courses. Courses are a sequence which represents the entirety of the resources belonging to a learning unit into which learners can be enrolled. Examples are a University one-semester course, a workshop, or a High School class. <img border=0 width=291 height=436 id="_x0000_i1029" src="handout_files/image005.png"> Fig. 2.1.1 � Resource Assembly <h3><a name="_Toc514840858"></a><a name="_Toc421867111">Maps</a></h3> To increase the utility of the materials, the number of hard-coded hyperlinks between the resources should be minimized. The actual combining and sequencing is part of the system functionality and driven by external "roadmaps", which are constructed by the instructors. With this mechanism, one and the same resource can be part of different courses in different contexts. The soft-linking makes it possible to import only the desired set of resources without effectively importing additional parts another instructors resources through hard-linked menus or "next page" buttons that might resided on those resources. <h3><a name="_Toc514840859"></a><a name="_Toc421867112">Curriculum Adaptivity</a></h3> Maps allow for conditional choices and branching points. The actual path through and presentation of the learning resources is determined by instructor-specified combinations of learner choices and system-generated adaptations (for example, if the learner does not pass a test, additional resources may be included). Each learner can have an individualized curriculum according to preferences, capabilities and skills. These maps can be generated at different levels of granularity with a graphical tool, or in an automated way through custom scripts. <h3><a name="_Toc514840860"></a><a name="_Toc421867113">Resource Assembly Tool</a></h3> The Network provides the Resource Assembly Tool as one means to generate maps. The Resource Assembly Tool provides a graphical user interface inside of a standard web browser. The current implementation is written in JavaScript. Fig. 2.3.2 shows screenshots of the current implementation. The interface usually consists of two browser windows, one resizable one with a frameset that contains the menu and the map under construction, and a multipurpose non-resizable window that displays information and input forms. When a new map is started, it only has a start and a finish resources. The author can then enlarge the map area and insert resources into it. In Fig. 2.3.2A, the author is editing information about a resource in the map after clicking on the box representing the resource in the map. In the dialog, the author can enter a map-internal title for the resource, which is displayed to the learners when navigating the maps. In the same dialog, the author will specify the URL of the resource, which can either be internal to the Network, or any URL of a web page outside of it. For internal resources, the author can also browse the Network filesystem or search the resource metadata to locate an appropriate resource. <img border=0 width=431 height=327 id="_x0000_i1030" src="handout_files/image006.jpg">Fig. 2.3.2A � Example, Graphical User Interface of Resource Assembly Tool The resource priority can be chosen. A resource can be �regular,� �mandatory� or �optional.� These resource priorities are only used in book-keeping of earned points by the learners. Within the map, resources of different priorities are displayed in different colors. The dialog also allows for two modes of removing the resource from the map: deleting it from the map including every link to and from it, and deleting it while reconnecting any links that went through the resource. As an example, resources A and B might both connect to resource C, and resource C might connect to D. When removing C from the map using the first option, A and B will not be connected to D anymore. Using the second option, in the end, A will connect to D, and B will connect to D. In the latter case, the Resource Assembly tool will also handle link conditions correctly: if A connected to C under condition 1, and C connected to D under condition 2, then in the end A will connect to D under a new condition which is (1 AND 2). Finally, this dialog allows the author to connect the resource to another resource (or itself) through a new link. When selecting this option, the Resource Assembly Tool goes into link mode, and will link the current resource to the next resource clicked on (unless the action is cancelled). <img border=0 width=431 height=327 id="_x0000_i1031" src="handout_files/image007.jpg"> Fig. 2.3.2B � Example, Graphical User Interface of Resource Assembly Tool Fig. 2.3.2B shows the Resource Assembly Tool in info mode, that is, when no specific component of the map is edited, and if the Tool is not in link mode. In info mode, the contents of the dialog window change dynamically as the mouse is moved over the components of the map. In this case, the mouse pointer is over the link condition between two resources. The dialog window shows the titles of the connected resources, as well as the condition priority. In this scenario, the condition priority is set such that the link cannot be taken (�is blocked�) if the condition is false. The condition priority can also be set such that the link is recommended if the condition is true (possibly giving the learner several options where to go next), or that the link has to be taken (�is forced�) over any other possible link if the condition is true. Within the map, conditions of different priorities are displayed in different colors. If the author now were to click on the condition, the Tool would go into edit mode, and the condition could be edited. Fig. 2.3.2C shows the Tool in edit mode for the link between the resource titles displayed. The author can remove the link, or insert a new resource into the link. Obviously, by this mechanism, rather complex maps can be generated. These are different from binary trees, both because branches can loop back, and because branches can be re-united � in fact, most branches re-unite in the finish resources. Into each link, a condition with one of three different priorities can be attached. Whether or not a certain resource in the map can be displayed depends on whether or not it can be reached through any path along allowed links, starting with the start resource of the course. If a resource is not linked to, it is assumed to be accessible if the map which it is part of is accessible. <img border=0 width=431 height=327 id="_x0000_i1032" src="handout_files/image008.jpg"> Fig. 2.3.2C � Example, Graphical User Interface of Resource Assembly Tool <h3><a name="_Toc514840861"></a><a name="_Toc421867114">Map Representation and Storage Format</a></h3> Fig. 2.3.3 shows the XML representation of the resource map constructed in Fig. 2.3.2, which is the format in which maps are stored. In the figure, however, additional graphical map layout information generated by the Resource Assembly Tool is not displayed. This graphical information is optional to re-generate the same graphical layout when the map is brought up again in the Resource Assembly Tool, and is not needed for any other system functionality. Maps can be generated by tools other than the Resource Assembly Tool. In particular, an author might have some other representation of a course sequence, which can be converted into a map using scripts. If this map then were to be brought up in the Resource Assembly Tool, the Tool would automatically generate a graphical layout for it. Each entry of the map (resources, conditions and links) is stored in a separate tag. Resources and conditions have to have unique ID numbers. These numbers are automatically generated by the Resource Assembly Tool when the entry is first created, or added to the entries when a map generated outside the Resource Assembly Tool is first retrieved. They can also be assigned by custom scripts or added in by hand. In this example, Fig. 2.3.3, entry 1 is the start resource of the map � when this map is accessed, the source (src) URL of this tag will be the first resource rendered. Entry 2 is the finish resource of this map. This resource will be the last resource in the sequence of resources. Entry 6 is a problem resource with the given URL and title, as well as the priority �mandatory�. Entry 19 is a condition, which is used by the link between entries 6, the problem, and 9, a sequence. The final syntax for conditions has not yet been determined. <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> <map> <resource id="1" src="/res/msu/korte/phy231welcome.html" type="start" title="Start"></resource> <resource id="2" src="" type="finish" title="Finish"></resource> <resource id="6" src="/res/msu/korte/tests/units.problem" type="mandatory" title="Physical Units Test"></resource> <resource id="9" src="/res/msu/korte/chapters/onedim.sequence" title="Motion in One Dimension"></resource> <resource id="11" src="/res/msu/bauer/bridges/units.sequence" title="Physical Units Refresher"></resource> <condition id="19" type="stop" value="user.assessments[this./res/msu/korte/tests/units.problem].status=solved"> </condition> <link from="1" to="6"></link> <link from="6" to="9" condition="19"></link> <link from="6" to="11"></link> <link from="11" to="6"></link> </map> </td> </tr> </table> Fig. 2.3.3 � XML representation of the map in Fig. 2.3.2C (non-graphical information only). <h3><a name="_Toc514840866"></a><a name="_Toc514840862"></a><a name="_Toc514920452"></a><a name="_Toc421867115">Example of Nested Maps</a></h3> Fig. 2.3.4 shows the XML representation of three maps which are imported into each other. Fig. 2.3.4B is the sequence that is referenced as resource 9 in the course map Fig. 2.3.4A. In the resulting map, the entry point of resource 9 in Fig. 2.3.4A is in fact the entry point of the start resource of Fig. 2.3.4B, namely, resource 1 there. The exit point of resource 9 in Fig. 2.3.4A is the exit point of the finish resource of Fig. 2.3.4B, namely, resource 2 there. Fig. 2.3.4C is the page which is referenced as resource 24 in Fig. 2.3.4B. A course can easily contain several hundreds of these nested maps. Since the accessibility of each individual resource in the course depends on the state of all possible paths linking it to the start resource of the course across all intermediate maps, the computation and disk-I/O effort per single transaction could quickly become prohibitive. Thus, all maps and conditions are compiled into a pre-processed binary data structure at the start of a session. <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=442 valign=top class="Normal"> <map> <resource id="1" src="" type="start" title="Start"></resource> <resource id="2" src="" type="finish" title="Finish"></resource> <resource id="5" src="/res/msu/korte/tests/pretest.problem" type="mandatory" title="Pretest"></resource> <resource id="9" src="/res/msu/korte/parts/part1.sequence" type="mandatory" title="Part 1"></resource> <resource id="11" src="/res/msu/korte/tests/midterm.sequence" type="mandatory" title="Midterm"></resource> <resource id="15" src="/res/msu/korte/parts/part2.sequence" type="mandatory" title="Part 2"></resource> <condition id="19" type="stop" value="user.assessments[this./msu/korte/tests/pretest.problem].status=solved"> </condition> <resource id="20" src="/res/msu/korte/refresh/refresher.sequence" title="Refresher"></resource> <resource id="29" src="/res/msu/korte/tests/final.sequence" type="mandatory" title="Final Exam"></resource> <condition id="30" type="stop" value="user.assessments[this./msu/korte/tests/midterm.sequence].percent>60"> </condition> <resource id="36" src="/res/msu/korte/refresh/review.sequence" title="Review"></resource> <condition id="43" type="force" value="user.assessments[this./msu/korte/tests/midterm.sequence].percent<10"> </condition> <resource id="58" src="/res/msu/korte/chapters/applications.sequence" type="optional" title="Applications"></resource> <condition id="70" type="stop" value="user.assessments[this./msu/korte/tests/final.sequence].percent>60"> </condition> <link from="1" to="5"></link> <link from="9" to="11"></link> <link from="11" to="15" condition="30"></link> <link from="5" to="9" condition="19"></link> <link from="5" to="20"></link> <link from="20" to="5"></link> <link from="11" to="36" condition="43"></link> <link from="36" to="9"></link> <link from="36" to="11"></link> <link from="15" to="29"></link> <link from="29" to="2" condition="70"></link> <link from="11" to="11"></link> </map> </td> </tr> </table> Fig. 2.3.4A � Example of a course map that has nested sequences <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=442 valign=top class="Normal"> <map> <resource id="1" src="" type="start" title="Start"></resource> <resource id="2" src="" type="finish" title="Finish"></resource> <resource id="5" src="/res/msu/korte/parts/part1intro.html" title="Part 1 Introduction"></resource> <resource id="6" src="/res/msu/korte/parts/part1dir.xml" title="Directions"></resource> <resource id="12" src="/res/msu/korte/tests/part11.problem" title="Problem 1"></resource> <resource id="13" src="/res/msu/korte/tests/part13.problem" title="Problem 3"></resource> <resource id="19" src="/res/msu/korte/tests/part12.problem" title="Problem 2"></resource> <resource id="24" src="/res/msu/korte/parts/summary.page" title="Summary"></resource> <condition id="47" type="stop" value="user.assessments[this./msu/korte/tests/part11.problem].status=solved"> </condition> <condition id="48" type="stop" value="user.assessments[this./msu/korte/tests/part12.problem].status=solved"> </condition> <condition id="49" type="stop" value="user.assessments[this./msu/korte/tests/part13.problem].status=solved"> </condition> <link from="5" to="6"></link> <link from="1" to="5"></link> <link from="6" to="12"></link> <link from="6" to="13"></link> <link from="6" to="19"></link> <link from="12" to="24" condition="47"></link> <link from="19" to="24" condition="48"></link> <link from="13" to="24" condition="49"></link> <link from="24" to="2"></link> </map> </td> </tr> </table> Fig. 2.3.4B � Example of a sequence (part1.sequence) that has nested pages <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> <map> <resource id="1" src="" type="start" title="Start"></resource> <resource id="2" src="" type="finish" title="Finish"></resource> <resource id="5" src="/res/msu/smith/racecar.problem"></resource> <resource id="6" src="/res/msu/smith/toofast.html"></resource> <resource id="8" src="/res/msu/smith/tooslow.html"></resource> <resource id="15" src="/res/msu/smith/accelerate.html"></resource> <condition id="40" type="force" value="user.assessments[this./msu/smith/racecar.problem].status=solved"></condition> <condition id="41" type="stop" value="user.assessments[this./msu/smith/racecar.problem].answer=friction"></condition> <condition id="42" type="stop" value="user.assessments[this./msu/smith/racecar.problem].answer=sliding"></condition> <condition id="43" type="stop" value="user.assessments[this./msu/smith/racecar.problem].answer=nonconstant"></condition> <link from="1" to="5"></link> <link from="5" to="6" condition="41"></link> <link from="5" to="8" condition="42"></link> <link from="5" to="15" condition="43"></link> <link from="6" to="2"></link> <link from="8" to="2"></link> <link from="15" to="2"></link> <link from="5" to="2" condition="40"></link> </map> </td> </tr> </table> Fig. 2.3.4C � Example of a page (summary.page) <img border=0 width=432 height=456 id="_x0000_i1033" src="handout_files/image009.jpg"> Fig. 2.3.5 � Flow chart of the course initialization routine run when a learner first accesses a course during a session (see Figs. 2.1.6A and 2.1.8A for the procedures loadmap and traceroute) <h3><a name="_Toc514840863"></a><a name="_Toc514920453"></a><a name="_Toc421867116">Initialization of a Course for a Learner</a></h3> When a learner first enters a course during a session, the system will initialize this course for the learner. In particular, at this point, the course map and all nested (embedded) maps and resources are evaluated, and the information is compiled into two binary structures, which are stored with the session information: the resource properties hash, and the link conditions array. This information will be used over the duration of the session for several purposes: navigation (which resource is the next, which one the previous?), for access control (can the resource be reached under the link conditions given the current state of the student?), and to register assessment results within the context of a certain course and map (there might be several instances of the same problem resource within a course). <h3><a name="_Toc514840864"></a><a name="_Toc514920454"></a><a name="_Toc421867117">Evaluation of the Map Structure for a Course</a></h3> The URL of the course is passed to the procedure readmap (Fig. 2.3.5). Procedure readmap first initializes the resource properties as an empty hash, seeds the link conditions array with a 0th element, which is set to �true�, priority �normal�, and sets the map counter to 0 (Fig. 2.3.5, Step R1). While the resource properties hash, the link conditions array and the map counter are global variable of the initialization process, all other variables are local to the procedures (an important property for these routines to run recursively). The procedure readmap then calls procedure loadmap for the URL of the course (Fig. 2.3.5, Step R2). Figs. 2.1.6, 2.1.7 show a dump of excerpts of the binary structure generated in loadmap for the nested maps of example Fig. 2.3.4. Procedure loadmap (Fig. 2.3.6A) first checks if the map URL has already been processed (multiple inclusion of the same map in a course structure) (Fig. 2.3.6A, Step L1) � if it was, it has been assigned a map counter value in the resource properties hash. If the map has been processed, there is no need to process it again, and loadmap returns. If the map has not been processed yet, the map counter is incremented and the map is registered under the current value in the resource properties hash (Fig. 2.3.6A, Step L2). The file is then opened (Fig. 2.3.6A, Step L3), which might entail prior replication, and the contents are parsed. If there are no further entries, loadmap returns (Fig. 2.3.6A, Step L4). The new entry tag is then read (Fig. 2.3.6A, Step L5) and the type is determined (Fig. 2.3.6A, Step L6). If the entry is a resource (Step L7), a resource ID is formed by combining the map counter and the resource ID within the map. For example, the �Part I Introduction� resource of part1.sequence (Fig. 2.3.4B) was assigned the resource ID 2.5, since it has the internal resource ID 5 in the 2nd map processed (see Fig. 2.3.6B under �ids_�). If the same URL is found again, additional IDs are assigned to it. It is necessary to store the IDs under the URL in the resource properties hash for reverse lookup if a user simply requests a URL. If the resource is a start or finish resources, the resource ID is registered as the start or finish resource of the map, respectively (Fig. 2.3.6B, �map_start_�, �map_finish_�). The properties of the resource (URL, Title, Priority, etc) are now stored under the resource ID, see for example Fig. 2.3.6B �title_2.5�. If the resource is not a map itself (Fig. 2.3.6A, Step L8), the next entry is read. Otherwise, procedure loadmap calls itself recursively to process that map (Step L9). If in Step L6, the type of the entry was determined to be a condition, a condition ID is formed (Step L10) by again combining the map counter with the internal ID. The condition is also added to the end of the condition array (see Fig. 10), which is a compilation of all conditions in the course (Step L11). The conditions in this array are evaluated when a transaction occurs that could change the state of the student, and the state of each condition is stored by the index number in the session environment. A reference to the index number in the condition array is stored under the condition ID (Fig. 2.3.6D, �condid_�). If the entry is a link (Step L6), a link ID is generated (Step L12). This ID is formed by combining the map counter and another counter which is incremented for every new link within the map. Under this ID, the IDs of the originating and the destination resource of the link are stored, as well as that of the link condition (Fig. 2.3.6D). For the originating resource, in Step L13 the link ID is added to the list of outgoing links (Fig. 2.3.6C, �to_�), and for the destination resource, the link ID is added to the list of incoming links (Fig. 2.3.6C, �from_�). After the last entry has been processed, procedure loadmap returns. After the last map has been processed, the original course-level instance of loadmap returns to readmap (Fig. 2.3.5, Step R2). <img border=0 width=432 height=547 id="_x0000_i1034" src="handout_files/image010.jpg"> Fig. 2.3.6A � Flow chart of procedure loadmap <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> ids_/res/msu/korte/chapters/applications.sequence: 1.58 ids_/res/msu/korte/parts/part1.sequence: 1.9 ids_/res/msu/korte/parts/part1dir.xml: 2.6 ids_/res/msu/korte/parts/part1intro.html: 2.5 ids_/res/msu/korte/parts/part2.sequence: 1.15 ids_/res/msu/korte/parts/summary.page: 2.24 ids_/res/msu/korte/refresh/refresher.sequence: 1.20 ids_/res/msu/korte/refresh/review.sequence: 1.36 ids_/res/msu/korte/tests/final.sequence: 1.29 ids_/res/msu/korte/tests/midterm.sequence: 1.11 ids_/res/msu/korte/tests/part11.problem: 2.12 ids_/res/msu/korte/tests/part12.problem: 2.19 ids_/res/msu/korte/tests/part13.problem: 2.13 ids_/res/msu/korte/tests/pretest.problem: 1.5 ids_/res/msu/smith/accelerate.html: 3.15 ids_/res/msu/smith/racecar.problem: 3.5 ids_/res/msu/smith/toofast.html: 3.6 ids_/res/msu/smith/tooslow.html: 3.8 � map_start_/res/msu/korte/foo.sequence: 1.1 map_start_/res/msu/korte/parts/part1.sequence: 2.1 map_start_/res/msu/korte/parts/summary.page: 3.1 � map_finish_/res/msu/korte/foo.sequence: 1.2 map_finish_/res/msu/korte/parts/part1.sequence: 2.2 map_finish_/res/msu/korte/parts/summary.page: 3.2 � title_1.11: Midterm title_1.15: Part 2 title_1.20: Refresher title_1.29: Final Exam title_1.36: Review title_1.5: Pretest title_1.58: Applications title_1.9: Part 1 title_2.12: Problem 1 title_2.13: Problem 3 title_2.19: Problem 2 title_2.24: Summary title_2.5: Part 1 Introduction title_2.6: Directions � </td> </tr> </table> Fig. 2.3.6B � Dump of the resource properties hash. Excerpt of the resource properties gathered in procedure loadmap <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> to_1.1: 1.1 to_1.11: 1.3,1.7,1.12 to_1.15: 1.10 to_1.20: 1.6 to_1.29: 1.11 to_1.36: 1.8,1.9 to_1.5: 1.4,1.5 to_1.9: 1.2 to_2.1: 2.2 to_2.12: 2.6 to_2.13: 2.8 to_2.19: 2.7 to_2.24: 2.9 to_2.5: 2.1 to_2.6: 2.3,2.4,2.5 to_3.1: 3.1 to_3.15: 3.7 to_3.5: 3.2,3.3,3.4,3.8 to_3.6: 3.5 to_3.8: 3.6 � from_1.11: 1.2,1.9,1.12 from_1.15: 1.3 from_1.2: 1.11 from_1.20: 1.5 from_1.29: 1.10 from_1.36: 1.7 from_1.5: 1.1,1.6 from_1.9: 1.4,1.8 from_2.12: 2.3 from_2.13: 2.4 from_2.19: 2.5 from_2.2: 2.9 from_2.24: 2.6,2.7,2.8 from_2.5: 2.2 from_2.6: 2.1 from_3.15: 3.4 from_3.2: 3.5,3.6,3.7,3.8 from_3.5: 3.1 from_3.6: 3.2 from_3.8: 3.3 � </td> </tr> </table> Fig. 2.3.6C � Dump of the resource properties hash. Excerpt of information gathered about links between resources in subroutine loadmap. <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=148 valign=top class="Normal"> goesto_1.1: 1.5 goesto_1.10: 1.29 goesto_1.11: 1.2 goesto_1.12: 1.11 goesto_1.2: 1.11 goesto_1.3: 1.15 goesto_1.4: 1.9 goesto_1.5: 1.20 goesto_1.6: 1.5 goesto_1.7: 1.36 goesto_1.8: 1.9 goesto_1.9: 1.11 goesto_2.1: 2.6 goesto_2.2: 2.5 goesto_2.3: 2.12 goesto_2.4: 2.13 goesto_2.5: 2.19 goesto_2.6: 2.24 goesto_2.7: 2.24 goesto_2.8: 2.24 goesto_2.9: 2.2 goesto_3.1: 3.5 goesto_3.2: 3.6 goesto_3.3: 3.8 goesto_3.4: 3.15 goesto_3.5: 3.2 goesto_3.6: 3.2 goesto_3.7: 3.2 goesto_3.8: 3.2 � </td> <td width=148 valign=top class="Normal"> comesfrom_1.1: 1.1 comesfrom_1.10: 1.15 comesfrom_1.11: 1.29 comesfrom_1.12: 1.11 comesfrom_1.2: 1.9 comesfrom_1.3: 1.11 comesfrom_1.4: 1.5 comesfrom_1.5: 1.5 comesfrom_1.6: 1.20 comesfrom_1.7: 1.11 comesfrom_1.8: 1.36 comesfrom_1.9: 1.36 comesfrom_2.1: 2.5 comesfrom_2.2: 2.1 comesfrom_2.3: 2.6 comesfrom_2.4: 2.6 comesfrom_2.5: 2.6 comesfrom_2.6: 2.12 comesfrom_2.7: 2.19 comesfrom_2.8: 2.13 comesfrom_2.9: 2.24 comesfrom_3.1: 3.1 comesfrom_3.2: 3.5 comesfrom_3.3: 3.5 comesfrom_3.4: 3.5 comesfrom_3.5: 3.6 comesfrom_3.6: 3.8 comesfrom_3.7: 3.15 comesfrom_3.8: 3.5 � </td> <td width=148 valign=top class="Normal"> undercond_1.1: 0 undercond_1.10: 0 undercond_1.11: 1.70 undercond_1.12: 0 undercond_1.2: 0 undercond_1.3: 1.30 undercond_1.4: 1.19 undercond_1.5: 0 undercond_1.6: 0 undercond_1.7: 1.43 undercond_1.8: 0 undercond_1.9: 0 undercond_2.1: 0 undercond_2.2: 0 undercond_2.3: 0 undercond_2.4: 0 undercond_2.5: 0 undercond_2.6: 2.47 undercond_2.7: 2.48 undercond_2.8: 2.49 undercond_2.9: 0 undercond_3.1: 0 undercond_3.2: 3.41 undercond_3.3: 3.42 undercond_3.4: 3.43 undercond_3.5: 0 undercond_3.6: 0 undercond_3.7: 0 undercond_3.8: 3.40 � condid_1.19: 8 condid_1.30: 9 condid_1.43: 10 condid_1.70: 11 condid_2.47: 5 condid_2.48: 6 condid_2.49: 7 condid_3.40: 1 condid_3.41: 2 condid_3.42: 3 condid_3.43: 4 � </td> </tr> </table> Fig. 2.3.6D � Dump of the resource properties hash. Excerpt of information gathered about links and link conditions between resources in subroutine loadmap. <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> 0 : true:normal 1 : user.assessments[this./msu/smith/racecar.problem].status=solved:force 2 : user.assessments[this./msu/smith/racecar.problem].answer=friction:stop 3 : user.assessments[this./msu/smith/racecar.problem].answer=sliding:stop 4 : user.assessments[this./msu/smith/racecar.problem].answer=nonconstant:stop 5 : user.assessments[this./msu/korte/tests/part11.problem].status=solved:stop 6 : user.assessments[this./msu/korte/tests/part12.problem].status=solved:stop 7 : user.assessments[this./msu/korte/tests/part13.problem].status=solved:stop 8 : user.assessments[this./msu/korte/tests/pretest.problem].status=solved:stop 9 : user.assessments[this./msu/korte/tests/midterm.sequence].percent>60:stop 10 : user.assessments[this./msu/korte/tests/midterm.sequence].percent<10:force 11 : user.assessments[this./msu/korte/tests/final.sequence].percent>60:stop � </td> </tr> </table> Fig. 2.3.7 � Excerpt of the dump of the condition array constructed in procedure loadmap (the final syntax of conditions has not yet been determined) <h3><a name="_Toc514920455"></a><a name="_Toc421867118">Paths and Path Conditions</a></h3> The next mayor step will be to determine all possible paths and conditions leading up to a resource for access control. readmap checks if the course has a start resource from its map_start entry in the resource properties (Step R2), and if does not, continue to store the two global binary data structures (Steps R5,R6) � in this special case, all resources which are part of any maps in the course are assumed to be accessible. If the course has a start resource, readmap calls the procedure traceroute (Fig. 2.3.8A) with the following parameters (Step R4): The cumulative condition along this path or route so far is set to �true� (the map is accessible); the resource ID of the start resource of the course map; and an empty list for all resources processed so far along this route. It is again important to note that all variables except the global binary structures are local to traceroute, since traceroute will recursively call itself whenever there is a branching to follow all possible paths of the maps. traceroute will establish a section within the resource properties hash that builds up all conditions leading up to a resource. Fig. 2.3.8B shows an excerpt of the final result. For example, resource 2.5, the introduction to part 1, can be reached under condition 8 (see Fig. 2.3.7), meaning, after solving the pretest problem. traceroute first checks if the resource has already been processed on this route by its resource ID (Fig. 2.3.8A, Step T1) � this test avoids that traceroute runs into endless loops when the links on the map loop. Next, the resource ID is added to the list of processed resources on this route (Step T2). The resource conditions are now OR�d with the cumulative conditions on this route (Step T3) � the route represents another way of getting to the resource. A small routine with simplification rules for boolean expressions is called to simplify the potentially very long expression. In the next step, it is determined if the resource is itself a map (Step T4). If it is, the exit route conditions can differ from the entry route condition by all additional conditions along the paths in the embedded maps (for non-map resources, entry and exit route conditions are the same). If however the embedded map does not have a start resource (Step T5), that is not the case � again, the missing of entry point to an embedded link structure is interpreted as the resources being openly accessible. If the embedded map does have a start resource, traceroute is called recursively with the current route conditions, the ID of the start resource of that map, and the list of already processed resource IDs (Step T6). Upon return, if the embedded map does not have a finish resource, the entry and exit conditions of this map are assumed to be the same (Step T7). If the map had a finish resource, the route condition so far is set to the resource condition of the finish resource of the embedded map (Step T8) � in order go on from here, the user would have had to reach the finish resource of the embedded map. Now the route conditions are correctly set for exiting the resource and going on from here. traceroute now loops over all outgoing links of the resource (Step T9). If the link does have a link condition (Step T10), then for this path, the cumulative route condition so far AND the link condition (Step T11). If there is no link condition, then there is no change in route conditions (Step T12). To further process the routes along this link, traceroute is called recursively with the resource ID of the destination resource of the link, the new route conditions, and the list of already processed resources (Step T13). traceroute returns after processing the last outgoing link of the resource it had been called for. Fig. 2.3.8B shows part of the output of traceroute for the example Fig. 2.3.4. <img border=0 width=432 height=557 id="_x0000_i1035" src="handout_files/image011.jpg"> Fig. 2.3.8A � Flow chart of procedure traceroute <table border=1 cellspacing=0 cellpadding=0> <tr> <td width=443 valign=top class="Normal"> conditions_1.1: 0 conditions_1.11: (((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)) conditions_1.15: ((((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)))&9 conditions_1.2: (((((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)))&9)&11 conditions_1.20: 0 conditions_1.29: ((((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)))&9 conditions_1.36: ((((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)))&10 conditions_1.5: 0 conditions_1.9: 8 conditions_2.1: 8 conditions_2.12: 8 conditions_2.13: 8 conditions_2.19: 8 conditions_2.2: (((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)))|((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)) conditions_2.24: ((8&5)|(8&7)|(8&6)) conditions_2.5: 8 conditions_2.6: 8 conditions_3.1: ((8&5)|(8&7)|(8&6)) conditions_3.15: ((8&5&4)|(8&7&4)|(8&6&4)) conditions_3.2: ((8&5&2)|(8&5&3)|(8&5&4)|(8&5&1)|(8&7&2)|(8&7&3)|(8&7&4)|(8&7&1)|(8&6&2)|(8&6&3)|(8&6&4)|(8&6&1)) conditions_3.5: ((8&5)|(8&7)|(8&6)) conditions_3.6: ((8&5&2)|(8&7&2)|(8&6&2)) conditions_3.8: ((8&5&3)|(8&7&3)|(8&6&3)) </td> </tr> </table> Fig. 2.3.8B � Dump of resource properties hash. Excerpt of cumulative link conditions to reach a certain resource. <h3><a name="_Toc514840865"></a><a name="_Toc514920456"></a><a name="_Toc421867119">Multivalued Boolean Evaluation of Link Priorities</a></h3> When a user accessed a resource on a map and desires to access the �next� resource, the request is processed by a number of steps. From the data examplified in Fig. 2.3.6C, it is determined which outgoing links exist. From the data in Fig. 2.3.6D it is determined to which resources those links lead. For each of the resources, the expressions in Fig. 2.3.8A are evaluated as follows. Stored in the session environment is the evaluation of the table Fig. 10, where the boolean part is evaluated as �0� or �1�. In addition, a multivalued boolean value is computed incorporating the condition priority. A false blocking condition is assigned the value zero, all other false conditions the value 1. A true forced condition is assigned the value 3, all other true conditions the value 2. In the expressions Fig. 2.3.8A an �&� (�AND�) is processed as the minimum (min) operation, a �|� (�OR�) is processed as the maximum (max) operation. The outcome �0� means �blocked�, the outcome �1� mean �not recommended�, the outcome �2� recommended, and the outcome �3� forced. </div>   </div> <div class=Section2> </div> </body> </html>