Index: openacs-4/packages/imsld/www/doc/README.txt =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/README.txt,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/imsld/www/doc/README.txt 27 Jun 2005 11:34:37 -0000 1.1 @@ -0,0 +1,4 @@ +Before Editing: + +You are welcome to edit this documentation, but please do it in the xmlfiles (located in the xmlfiles dir), and then convert it to html (we recomend dockbook), and of course, notify the autors and the corresponding package mantainer about the changes. + Index: openacs-4/packages/imsld/www/doc/ch01s01.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch01s01.html,v diff -u -r1.2 -r1.3 --- openacs-4/packages/imsld/www/doc/ch01s01.html 25 Jun 2005 20:23:25 -0000 1.2 +++ openacs-4/packages/imsld/www/doc/ch01s01.html 27 Jun 2005 11:34:37 -0000 1.3 @@ -1,3 +1,3 @@ - 1. Introduction
1. Introduction
Prev Chapter 1. Introduction Next

1. Introduction

Given the current need of the professors as .LRN users of having a tool that lets them define and set up the workflow of their courses and a synchronization and interaction between different roles of an e-learning experience, the imsld package provides the support to fullfill these needs, making use of the IMS Learning Design (from now on referred as IMS LD). We recommend to read the IMS LD specification in order to understand better this document. If you are already familiarized with the specification, continue reading this document, otherwise you can take a quick introduction by reading our very short introducion to IMS LD)

Prev Up Next
Chapter 1. Introduction Home 2. Integrating IMS LD with .LRN
\ No newline at end of file + 1. Introduction
1. Introduction
Prev Chapter 1. Introduction Next

1. Introduction

Given the current need of the professors as .LRN users of having a tool that lets them define and set up the workflow of their courses and a synchronization and interaction between different roles of an e-learning experience, the imsld package provides the support to fullfill these needs, making use of the IMS Learning Design (from now on referred as IMS LD). We recommend to read the IMS LD specification in order to understand better this document. If you are already familiarized with the specification, continue reading this document, otherwise you can take a quick introduction by reading our very short introducion to IMS LD)

Prev Up Next
Chapter 1. Introduction Home 2. Integrating IMS LD with .LRN
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch01s04.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch01s04.html,v diff -u -r1.2 -r1.3 --- openacs-4/packages/imsld/www/doc/ch01s04.html 25 Jun 2005 20:23:25 -0000 1.2 +++ openacs-4/packages/imsld/www/doc/ch01s04.html 27 Jun 2005 11:34:37 -0000 1.3 @@ -1,3 +1,3 @@ - 4. Historical Considerations
4. Historical Considerations
Prev Chapter 1. Introduction Next

4. Historical Considerations

There is some work done so far that we could use in the near future:

Prev Up Next
3. Pedagogical Flexibility Home 5. Competitive Analysis
\ No newline at end of file + 4. Historical Considerations
4. Historical Considerations
Prev Chapter 1. Introduction Next

4. Historical Considerations

There is some work done so far that we could use in the near future:

Prev Up Next
3. Pedagogical Flexibility Home 5. Competitive Analysis
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch01s11.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch01s11.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch01s11.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch01s11.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - 11. Architectural Model
11. Architectural Model
Prev Chapter 1. Introduction Next

11. Architectural Model

The architectural model is described in the Architectural Model Chapter, and it presents the general architectural related to the ims-ld package. It explains each part of the system and particullary the ims-ld package, and are described the aspects about the implementation as for example the mapping between .LRN services and IMS LD services,

Prev Up Next
10. Data Model Home 12. Authors
\ No newline at end of file + 11. Architectural Model
11. Architectural Model
Prev Chapter 1. Introduction Next

11. Architectural Model

The architectural model is described in the Architectural Model Chapter, and it presents the general architectural related to the ims-ld package. It explains each part of the system and particullary the ims-ld package, and are described the aspects about the implementation as for example the mapping between .LRN services and IMS LD services,

Prev Up Next
10. Data Model Home 12. Authors
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch04.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch04.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch04.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch04.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - Chapter 4. Data Model
Chapter 4. Data Model
Prev   Next

Chapter 4. Data Model

Table of Contents

1. Level A
2. Level B
3. Level C
4. Run Tables

The following data model stores the relevant information that can be in an IMS LD file. The tables are the ones needed to store the interesting part of the information from IMS LD specification that we consider is necessary in order to play the unit of learning correctly.

At present, the data model does not have into account the interaction with the rest of the .LRN packages, because the tables needed for that interaction will be defined in the development phase. Also, the tables might change during the development phase, because we can find better ways to structure the information, but the final data model, in our opinion, will not be too different from the one presented here.

The complete data model is presented in an Entity-Relationship (ER) diagram that is divided in three blocks, each one related to a level of the IMS LD specification. The tables of the .LRN model for supporting IMS LD of a level are not independent from the other levels, and the relationships of the three diagrams have been represented. In the tables of the E-R diagrams are presented only the primary keys and foreign keys. This is in order to achieve clarity and simplicity because the diagram is too big. Nevertheless, all the fields of the proposed diagram are presented and explained next, divided by the three levels of IMS LD.

Next, each table of the data model is described divided in the three levels of the IMS LD specification

IMPORTANT NOTE: The present Data Model will be normilize in the near time in order to improve its understanding.

Prev   Next
2. Final Comments Home 1. Level A
\ No newline at end of file + Chapter 4. Data Model
Chapter 4. Data Model
Prev   Next

Chapter 4. Data Model

Table of Contents

1. Level A
2. Level B
3. Level C
4. Run Tables

The following data model stores the relevant information that can be in an IMS LD file. The tables are the ones needed to store the interesting part of the information from IMS LD specification that we consider is necessary in order to play the unit of learning correctly.

At present, the data model does not have into account the interaction with the rest of the .LRN packages, because the tables needed for that interaction will be defined in the development phase. Also, the tables might change during the development phase, because we can find better ways to structure the information, but the final data model, in our opinion, will not be too different from the one presented here.

The complete data model is presented in an Entity-Relationship (ER) diagram that is divided in three blocks, each one related to a level of the IMS LD specification. The tables of the .LRN model for supporting IMS LD of a level are not independent from the other levels, and the relationships of the three diagrams have been represented. In the tables of the E-R diagrams are presented only the primary keys and foreign keys. This is in order to achieve clarity and simplicity because the diagram is too big. Nevertheless, all the fields of the proposed diagram are presented and explained next, divided by the three levels of IMS LD.

Next, each table of the data model is described divided in the three levels of the IMS LD specification

IMPORTANT NOTE: The present Data Model will be normilize in the near time in order to improve its understanding.

Prev   Next
2. Final Comments Home 1. Level A
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch04s01.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch04s01.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch04s01.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch04s01.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - - - 1. Level A
1. Level A
Prev Chapter 4. Data Model Next

1. Level A


Next, the tables necessary for Level A are drawn in the form of an E-R diagram

Prev Up Next
Chapter 4. Data Model Home 2. Level B
\ No newline at end of file + + + 1. Level A
1. Level A
Prev Chapter 4. Data Model Next

1. Level A

Next, the tables necessary for Level A are draw in the form of an E-R diagram

Prev Up Next
Chapter 4. Data Model Home 2. Level B
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch04s02.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch04s02.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch04s02.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch04s02.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - - - 2. Level B
2. Level B
Prev Chapter 4. Data Model Next

2. Level B

Level B extends the table email_data and add: username_property_id and email_property_id * Next is shown the E-R diagram for these tables

Prev Up Next
1. Level A Home 3. Level C
\ No newline at end of file + + + 2. Level B
2. Level B
Prev Chapter 4. Data Model Next

2. Level B

Level B extends the table email_data and add: username_property_id and email_property_id * Next is shown the E-R diagram for these tables

Prev Up Next
1. Level A Home 3. Level C
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch04s03.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch04s03.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch04s03.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch04s03.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - - - 3. Level C
3. Level C
Prev Chapter 4. Data Model Next

3. Level C

Level C modity the imsld_email_data (**), add a reference to imsld_notifications table from imsld_on_completion, imsld_thens and imsld_view_set_properties table (**). Next is shown the E-R diagram that adds Level C

Prev Up Next
2. Level B Home 4. Run Tables
\ No newline at end of file + + + 3. Level C
3. Level C
Prev Chapter 4. Data Model Next

3. Level C

Level C modity the imsld_email_data (**), add a reference to imsld_notifications table from imsld_on_completion, imsld_thens and imsld_view_set_properties table (**). Next is shown the E-R diagram that adds Level C

Prev Up Next
2. Level B Home 4. Run Tables
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch04s04.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch04s04.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch04s04.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch04s04.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - - - 4. Run Tables
4. Run Tables
Prev Chapter 4. Data Model Next

4. Run Tables

The previous tables are referred to the IMS LD specifications level A, B and C. They have all the information necessary to map an XML conformant IMS LD document to the tables in the .LRN platform. But also, for the ims-ld package to interact with real users, we need additional tables. These new tables are necessary for the execution of the player where the information is sequenced to the student. These tables are described in this Section. Next is shown the E-R diagram for these tables

Prev Up Next
3. Level C Home Chapter 5. Architectural Model
\ No newline at end of file + + + 4. Run Tables
4. Run Tables
Prev Chapter 4. Data Model Next

4. Run Tables

The previous tables are referred to the IMS LD specifications level A, B and C. They have all the information necessary to map an XML conformant IMS LD document to the tables in the .LRN platform. But also, for the ims-ld package to interact with real users, we need additional tables. These new tables are necessary for the execution of the player where the information is sequenced to the student. These tables are described in this Section. Next is shown the E-R diagram for these tables

Prev Up Next
3. Level C Home Chapter 5. Architectural Model
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/ch05.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/ch05.html,v diff -u -r1.1 -r1.2 --- openacs-4/packages/imsld/www/doc/ch05.html 25 Jun 2005 00:44:28 -0000 1.1 +++ openacs-4/packages/imsld/www/doc/ch05.html 27 Jun 2005 11:34:37 -0000 1.2 @@ -1,3 +1,3 @@ - - - Chapter 5. Architectural Model
Chapter 5. Architectural Model
Prev   

Chapter 5. Architectural Model

Here we give an explanation of the way the inner components of the imsld package interact internally between them and externally with some other packages of .LRN Next, a figure about the general architecture about IMS LD and the ims-ld package is shown.

We have two methods for loading the information into the ims-ld package. One is by means of an internal .LRN editor (as we said this is not planned for the short term). The other method is loading an IMS LD compliant XML file, as we said before, it can be generated using an authoring tool wich is not part of .LRN, at least not when writing this specification. The file is requested to the user by the UI of the parser. This UI will conist of a small number of pages with a form where the user can upload the file and with some others with error or log messages displayed to the user via web. In this step, the imsld package will also validate the IMS LD file for proving conformance with the IMS LD standard. It indicates when the parser didn't parse the whole file correctly and it needs human help in order to finish its job. So, the first component of the imsld package that interacts with the database is the parser, using the tcl and sql API.

At the lowest level we have the information stored in the data base. The information that have been loaded from an IMS LD file is parsed and stored in the database in the tables related to the level A, B and C that have been shown in the previous Data Model Section. With this mapping we will have all the information contained from the IMS LD package in the .LRN

Once all the information of the IMS LD compliant XML file is stored in the database, the course is ready to be played. As we mentioned above, the player has two modes for the professor, on-line and off-line. The first one is the off-line mode, because the course has not being played or instanced yet. In the off-line mode the teacher should associate the students and course admins to their respective roles in the unit of learning. In this step are fullfilled the tables imsld_party_roles_map and imsld_parties_property_values_map. Also the rest of the tables of the run tables are initialized for each user at this time. All the information that is stored in this Run Tables is not contained in the IMS LD file, this information is particular for each run. At this step the information is particularized for the users of the unit of learning.

Be aware that a professor can have the student role in the unit of learning or vice versa, that is the professor's choice. The roles of the unit of learning are stored in the database, but the mappings between the real users with their respectives roles is the professor's task. When doing these mappings, the respective conditions recently obtained from the XML file start to be verified. For instance, there is a max-number-of-persons tag for a role, so the professor can't assign more than n users to that role. There is also a match-person tag, that implies that the person with that role can't have any other role inside the unit of leaning while being assigned to the first role. In this off-line mode, the professor can take a general perspective of the unit of learning. He/she can take a look at all the activities that will be done by the students, as well as the conditions and every information that is important to be shown.

Once the real users are mapped to the roles, the unit of learning can be instantiated. This will start the on-line mode of the viewer.

For the professor, the on-line mode of the viewer lets him/her to see the status of the course(unit of learning). As mentioned in the user requirements chapter, this mode of the viewer lets the professor to do any tracking activity of the students. Such as seeing how many students are in what act of the play, what user-choice activities are being accessed and what aren't, etc. By the time when writing this specification, the professor can't modify anything from the viewer, it is read only information. At the time of run of the unit of learning the Run Tables are refreshed with new completed activities, acts and plays of each user.

For the student, the on-line mode of the viewer is very similar to the one for the professor, with the main difference that with the student can only see his/her own information, whereas the professor can see the information of all the class students. From the viewer the students can see what activities have already completed, as well as how much time between activities they took, and how much time they spent in each activity. In some designs (of the IMS LD compliant XML file), the student can see the rest of activities that he/she has to complete in order to finish the unit of learning. This is not true in every case, because, for instance, when creating the unit of learning, the professor can set the is-visible tag to false for every activity in the unit of learning, not allowing the students to see any more than what they have already done.

Everything is ready now for the most important component of the imsld package: The Player. Of course, the viewer will be allways accessible to the class members, so they can interact with the player and then with the viewer, any time they want and in any sequence.

The player, from the visualization point of view, is nothing more tan a cetralized page. This centralized page has some menus and message sections at the sides and at the bottom, with instructions and descriptions that the student has to read. The professor can be part of the unit of learning being played too, the only thing he/she has to do is assign him/herself to a role of the unit of learning.

The player is the component that is in charge of verifying the poperties and conditions that were specified in the XML file. It will detect wichever change in the properties, check the completion of activities, acts, etc. and evaluate the conditions. In particular the properties that at least the ims-ld package is going to support are:

Every time that for wichever user a resource is served, an activity is started or completed, an assessment is finished, etc, the player must check for every possible condition in order to follow the worklow defined by the unit of learning. The player is also the one in charge of changing the corresponding property values of each resource and to make sure that the workflow of the course is the one the course creator intended.

Moreover, the player is the component that interacts with the .LRN packages mentioned before. It make use of them in order to interact with the users. The information about every resource is stored in the database by the parser, but the actual interaction happens when the player finds out that a given resource has to be instanciated and shown to the user. This is then the intercomunication between .LRN packages takes place. As mentioned before, in order to make this intercomunication as clean as possible, we will make use of the callbacks functionallity. Using callbacks is the best way of intercomunicating .LRN packages, because we don't have to rewrite the code and we can verify if two packages are connected. Besides, we can't depend on the packages that are not required by .LRN. In fact, we can't assume that any package is installed, because we don't know how the site wide admin configured the .LRN service. Tha is something that the player is aware of.

This is a detailed explanation of what .LRN packages and for what resources we will use:

What specific funcions of each package we use will be defined during the development phase.

Prev   
4. Run Tables Home 
\ No newline at end of file + + + Chapter 5. Architectural Model
Chapter 5. Architectural Model
Prev   

Chapter 5. Architectural Model

Here we give an explanation of the way the inner components of the imsld package interact internally between them and externally with some other packages of .LRN Next, a figure about the general architecture about IMS LD and the ims-ld package is shown.

We have two methods for loading the information into the ims-ld package. One is by means of an internal .LRN editor (as we said this is not planned for the short term). The other method is loading an IMS LD compliant XML file, as we said before, it can be generated using an authoring tool wich is not part of .LRN, at least not when writing this specification. The file is requested to the user by the UI of the parser. This UI will conist of a small number of pages with a form where the user can upload the file and with some others with error or log messages displayed to the user via web. In this step, the imsld package will also validate the IMS LD file for proving conformance with the IMS LD standard. It indicates when the parser didn't parse the whole file correctly and it needs human help in order to finish its job. So, the first component of the imsld package that interacts with the database is the parser, using the tcl and sql API.

At the lowest level we have the information stored in the data base. The information that have been loaded from an IMS LD file is parsed and stored in the database in the tables related to the level A, B and C that have been shown in the previous Data Model Section. With this mapping we will have all the information contained from the IMS LD package in the .LRN

Once all the information of the IMS LD compliant XML file is stored in the database, the course is ready to be played. As we mentioned above, the player has two modes for the professor, on-line and off-line. The first one is the off-line mode, because the course has not being played or instanced yet. In the off-line mode the teacher should associate the students and course admins to their respective roles in the unit of learning. In this step are fullfilled the tables imsld_party_roles_map and imsld_parties_property_values_map. Also the rest of the tables of the run tables are initialized for each user at this time. All the information that is stored in this Run Tables is not contained in the IMS LD file, this information is particular for each run. At this step the information is particularized for the users of the unit of learning.

Be aware that a professor can have the student role in the unit of learning or vice versa, that is the professor's choice. The roles of the unit of learning are stored in the database, but the mappings between the real users with their respectives roles is the professor's task. When doing these mappings, the respective conditions recently obtained from the XML file start to be verified. For instance, there is a max-number-of-persons tag for a role, so the professor can't assign more than n users to that role. There is also a match-person tag, that implies that the person with that role can't have any other role inside the unit of leaning while being assigned to the first role. In this off-line mode, the professor can take a general perspective of the unit of learning. He/she can take a look at all the activities that will be done by the students, as well as the conditions and every information that is important to be shown.

Once the real users are mapped to the roles, the unit of learning can be instantiated. This will start the on-line mode of the viewer.

For the professor, the on-line mode of the viewer lets him/her to see the status of the course(unit of learning). As mentioned in the user requirements chapter, this mode of the viewer lets the professor to do any tracking activity of the students. Such as seeing how many students are in what act of the play, what user-choice activities are being accessed and what aren't, etc. By the time when writing this specification, the professor can't modify anything from the viewer, it is read only information. At the time of run of the unit of learning the Run Tables are refreshed with new completed activities, acts and plays of each user.

For the student, the on-line mode of the viewer is very similar to the one for the professor, with the main difference that with the student can only see his/her own information, whereas the professor can see the information of all the class students. From the viewer the students can see what activities have already completed, as well as how much time between activities they took, and how much time they spent in each activity. In some designs (of the IMS LD compliant XML file), the student can see the rest of activities that he/she has to complete in order to finish the unit of learning. This is not true in every case, because, for instance, when creating the unit of learning, the professor can set the is-visible tag to false for every activity in the unit of learning, not allowing the students to see any more than what they have already done.

Everything is ready now for the most important component of the imsld package: The Player. Of course, the viewer will be allways accessible to the class members, so they can interact with the player and then with the viewer, any time they want and in any sequence.

The player, from the visualization point of view, is nothing more tan a cetralized page. This centralized page has some menus and message sections at the sides and at the bottom, with instructions and descriptions that the student has to read. The professor can be part of the unit of learning being played too, the only thing he/she has to do is assign him/herself to a role of the unit of learning.

The player is the component that is in charge of verifying the poperties and conditions that were specified in the XML file. It will detect wichever change in the properties, check the completion of activities, acts, etc. and evaluate the conditions. In particular the properties that at least the ims-ld package is going to support are:

Every time that for wichever user a resource is served, an activity is started or completed, an assessment is finished, etc, the player must check for every possible condition in order to follow the worklow defined by the unit of learning. The player is also the one in charge of changing the corresponding property values of each resource and to make sure that the workflow of the course is the one the course creator intended.

Moreover, the player is the component that interacts with the .LRN packages mentioned before. It make use of them in order to interact with the users. The information about every resource is stored in the database by the parser, but the actual interaction happens when the player finds out that a given resource has to be instanciated and shown to the user. This is then the intercomunication between .LRN packages takes place. As mentioned before, in order to make this intercomunication as clean as possible, we will make use of the callbacks functionallity. Using callbacks is the best way of intercomunicating .LRN packages, because we don't have to rewrite the code and we can verify if two packages are connected. Besides, we can't depend on the packages that are not required by .LRN. In fact, we can't assume that any package is installed, because we don't know how the site wide admin configured the .LRN service. Tha is something that the player is aware of.

This is a detailed explanation of what .LRN packages and for what resources we will use:

What specific funcions of each package we use will be defined during the development phase.

Prev   
4. Run Tables Home 
\ No newline at end of file Index: openacs-4/packages/imsld/www/doc/xmlfiles/imsld-package.xml =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/xmlfiles/Attic/imsld-package.xml,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/imsld/www/doc/xmlfiles/imsld-package.xml 27 Jun 2005 11:34:37 -0000 1.1 @@ -0,0 +1,3145 @@ + + + + imsld + + + Introduction + +
+ Introduction + + Given the current need of the professors as .LRN users of having a + tool that lets them define and set up the workflow of their courses and + a synchronization and interaction between different roles of an + e-learning experience, the imsld package provides the support to + fullfill these needs, making use of the IMS Learning Design (from now on + referred as IMS LD). We recommend to read the IMS LD + specification in order to understand better this document. If + you are already familiarized with the specification, continue reading + this document, otherwise you can take a quick introduction by reading + our very short introducion to IMS + LD) +
+ +
+ Integrating IMS LD with .LRN + + Using the IMD LD specification, the professor is able to indicate + the moment (which could be based on conditions) in which a role is going + to do an activity and which materials and services are going to be used. + Integrating IMD LD into .LRN, the professor is able to use all the + services provided by .LRN, such as forums for asynchronous interaction, + chat as synchronous interaction, assessments to evaluate the e-learning + process (students and contents), the evaluation package (grade book) to + support a a variety of learning and support activities, etc. And all of + this is done in a centralized way, from an IMS LD editor. + + The main idea is to load an IMS LD document (which is an XML + document) and play it. To play an IMS LD document is nothing more than + to peform the activities prescribed in the document with its related + enviroment which defines the learning objects and services, and this is + when the interaction with the .LRN services begin. The imsld package is + able to detect and indicate what .LRN service is the most indicated one + to perform a given IMS LD service. The activities will follow the + sequence prescribed in the IMS LD document, each member of the course + will perform a specific set of activities according to the member's role + inside the course. The professor is able to decide the different roles + that the course supports, and which role can do what at any given time + during the course life, and following the defined sequence. + + With the imsld package, the professor is able to let the learner + choose betwen the activities, make the learner follow a specific + sequence or use a combinaiton of both sequenced and learner's choice + activities. And that's not all, the professor is also able to define the + sequence of the learning activities using conditions and properties that + change according to the learner behavior during the course (as defined + at the the level B of the Learning Design Specification). Moreover .LRN + can take advantage from the power notification system in order to send + messages and set new activities based on events (as defined at the level + C of the Learning Design Specification) + + The imsld package provides an IMS LD editor, an IMS LD player, an + IMS LD viewer and an IMS LD importer/exporter. Each one of these is + described later on this document. +
+ +
+ Pedagogical Flexibility + + "The IMS LD specification is flexible in the description of all + different kinds of pedagogies and not prescribe any specific pedagogical + approach." (IMS LD spec) The IMS LD specification does not follow any + pedagogy. When doing the integration with .LRN, this pedagogical + flexibility has to be preserved, letting the professor to give the + course in any way he or she wants, limiting as less as possible the + professor choices when creating the IMD LD document. +
+ +
+ Historical Considerations + + There is some work done so far that we could use in the near + future: + + + + Alfanet.The + people of Alfanet has already done some integration of IMS LD with + OpenACS. At the time of writing this specification we were waiting + to have access to their code in order to evaluate the possibility to + make use of what they have already done, avoiding the waist of + resources, but by the moment we don't know if this will be + possible. + + + + LAMS. At + the time of writing this specification, we were plannig to do an + integration with LAMS, which is a tool for designing, managing and + delivering online collaborative learning activities. The LAMs + project is already integrated with Moodle. We can take advantage of + that integration experience, but we expect to write all the code at + .LRN from scratch, and maybe later work on the integration. + + + + RELOAD. It has + an IMS LD editor wich is independent from any LMS. By means of this + editor, you can generate an IMS LD for a concrete course. Also it + has integrated the CopperCore player + + + + CopperCore. It has + an IMS LD editor wich is independent from any LMS. By means of this + editor, you can generate an IMS LD for a concrete course. Also it + has a player. + + Our purporse is to be able to interpret the IMS LD generated + by RELOAD, CopperCore and LAMS and whichever IMS LD that can be + generated by other different authoring tools. + + +
+ +
+ Competitive Analysis + + There are a lot of competing products.The IMS LD specification is + very large and has many different options. Each product can implement + the most suitable features. Also, it does not indicate how to implement + it. And therefore, different LMS can implement it in a different way + depending on their services. This is a compatibility problem, but it can + be solved by a convenient mapping between the different IMS LD + references and the different services of a LMS + + Moreover, when writing the specification we tried to incorporate + the ideas from the competing products (each one of them has its own way + of dealing with the IMS LD specification), and from the experience we + had when using them. A detailed analysis would be too much for the + moment. +
+ +
+ Extensibility + + The .LRN implementation must be easily extensible. The IMS LD + specification may change in the future, so the .LRN implementation has + to be done taking that into account. The .LRN implementation must be so + flexible in order to adapt to the posible changes of the IMS LD + specification. This means that if a change is produced in IMS LD + specification, then this should imply only minor changes in our .LRN + implementation of IMS LD. Also, if the initial specification should be + extended it should be done in an easy way. + + Reusability and standards + + The implementation must follow, as much as possible, the standards + defined by the IMS Global Learning Consortium. For example for the + compatibility problem that was mentioned before, there should be an easy + way to modify which .LRN service performs wich IMS LD service, and also + to add a new type of IMS LD service and the corresponding .LRN service + that will be in charge of dealing with it. + + Our XML parser has to be aware of this flexibility, being easy to + modify according to the, probably often, changes or improvements in the + specification. The mapping between the service types and its + corresponding .LRN services can be easily edited via web. Everything + that can possibly change in the near future, must be easily extensible + as this was mentioned in the previous section +
+ +
+ User Requirements + + The user requirements are described in detail in the User + Requirements Chapter. In this section we explain in detail the + objectives of the imsld package, as well as the way to achieve + them. +
+ +
+ Use Cases + + In this Chapter we give some use cases that correspond to + frequently applications that can be handled by the ims-ld package +
+ +
+ API + + The API will be defined during the development phase. +
+ +
+ Data Model + + The data model is described in the Data Model Chapter, and it + intends to show all the tables where the information will be + stored. + + The IMS LD specification is large and the number of tables to + store all the information is large too. We don't store every information + that comes in the IMS LD compliant XML file when parsing it, because + there are some metadata and tags that can be ignored, not affecting the + behavior of the unit of learning. + + Anyway, you can take a look at the data model and see how we store + the information in the different tables and how these tables are related + betwheen them. As you will notice, the data model is almost the exactly + the representation of the tables in the IMS LD Information Model in a + relational database, plus some control tables. +
+ +
+ Architectural Model + + The architectural model is described in the Architectural Model + Chapter, and it presents the general architectural related to the ims-ld + package. It explains each part of the system and particullary the ims-ld + package, and are described the aspects about the implementation as for + example the mapping between .LRN services and IMS LD services, +
+ +
+ Authors + + The specifications for the imsld package have been written by + Pedro + Muñoz and Jose + Pablo Escobedo with help from people within and outside the + OpenACS community. +
+ + + + User Requirements + +
+ Importing IMS Learning Design Documents + + As we mentioned before in this specification, an IMS LD document + is an XML file, so by practical means, we are just dealing with an XML + file, which is easy to parse. In this XML file is defined all the unit + of learning. We took advantage of the work already done in the assessment + package, where an IMS QTI parser was + implemented. In the case of the assessment package, the document follows + the IMS QTI specification, and it is parsed and imported into the data + base. The imsld package will do something similar but with documents + following the IMS LD specification, and with the big difference that the + MS LD document can not be displayed in only one .LRN package, as happens + with IMS QTI. IMS LD deals with activities, roles (users), properties, + conditions, workflows, etc, and that is why the imsld package will + interact with other .LRN services. + + Besides the XML parser, we need .LRN to recognize each one of the + activities and roles defined in the IMS LD and to know what to do with + each one of them. + + The professor or IMS LD designer will only have to enter a path + where it is located an IMS LD file and then push upload. By these way a + profesor can upload an existing IMS LD file which describes a unit of + learning. The IMS LD importer will recognize IMS LD files that are + integrated in IMS CP or files that are IMS LD, but are not in an IMS + CP. + + We call the process of parsing and interpreting the IMS LD + document the import stage. This IMS LD document can be generated with + any external or internal editor that follows the IMS LD specification, + such as LAMS, Coppercore, Reload, etc, wich is one of the + main advantages and purposes of following a well defined + standNoard. +
+ +
+ Interaction Between imsld package and .LRN Services + + The imsld package is a .LRN service (or package, we use these + terms indifferently in this specification when referring to .LRN), wich + will interact with some other .LRN services. When writing this + specification, we expect the imsld package to interact with at least the + following .LRN packages: + + + + Forums. + + + + Jabber. + + + + Assessment. + + + + Evaluation (grade + book). + + + + Calendar. + + + + News. + + + + FAQ + + + + Notifications. + + + + File Storage. + + + + As we mentioned earlier, the imsld package allows to easily modify + the mappings between the elemnts of the IMS LD specification and the + .LRN services. And not only modifying the mappings, but also to add new + ones. By these way if the IMS LD specification change in some aspect, + then the package will addapt to the new changes easily. From our point + of view it is necessary that in the future the IMS LD specification will + add more tags that univoquily mapping with services. By these way + compatibility between LMS are obtained, and if an LMS doesn't understand + one tag because it is not available, then it will be ignored and nothing + will be presented to the user. + + Besides, we take advantage of the new callbacks used in OpenACS in + order to provide a clean interaction between different .LRN packages. + With the callbacks we can determine if some needed package is not + installed, and instead of displaying an error to the user, try to map + the activity or whatever we are mapping to other package, and if after + trying with all the available packages we can't map the item to .LRN, a + message is shown to the user with this and any other item that coud not + be mapped by the system and with the purpose of leting the user to do + the manual mapping. + + We have to take into account that the item will not allways have + all the necessary information to let the mapping be done easily, but we + try to do our best by providing at least the required information to + create the forum, chat, assessment, task, etc, and if definetively no + mapping can be done, a final error message is shown to the user + indicating that there is at least one item that .LRN can't + understand. +
+ +
+ Editing IMS Learning Design Documents + + When writting this specification, we were not thinking about + implementing an IMS LD editor in the short term. We think that in the + market there are already very good IMS LD editors, and that instead of + investing efforts and resources in doing one more, we better work in + order to provide a good IMS LD player and a viewer. + + In the future we might work on an editor, but now there is a + greater need of a good player. We therefore provide support for the most + commonly used IMS LD editors (Reload, Coppercore and LAMS), wich we + mentioned above. Even tough there is a standard, there is always + something different in the way each editor makes use of it, and we try + to deal with it by being as flexible as possible, even tough sometimes + it is hard to achieve. +
+ +
+ Viewing an IMS LD Document and Groups assignation + + The imsld package provides an IMS LD viewer that will have two + modes for the professor: off-line mode and on-line mode. + + In the off-line mode only the professor will have access and + he/she will be able to see all the plays, acts, properties, conditions, + etc. Definitively, all the things that are described in an IMS LD + document. But this information of the XML package will not include the + mapping between roles and members of the .LRN course or community. It is + the professor who must do this association before running the IMS LD for + concrete students. The interface will allow to select the students + inside a concrete .LRN course. This tool will allow assignate students + and professors (or other groups if exists) to the roles defined in the + IMS LD file. + + On the other hand, in the on-line mode, it is visualized the IMS + LD when it is running. It will give to both the teacher and the student + (staff and learner) an overview of the activities in the workflow, i.e. + the visualization of the play, as well as their current status. + + For the teacher, the viewer also offers in on-line mode the + possibility of seeing the properties and conditions, tracking the + students, watching the users in every activity of an act, etc. The + teacher is able to view more details in every act and see who has done + what. He/she can verify if a given test is too difficult and the + students can't continue with the flow of the course, or if the teaching + method is not working as planned. The viewer shows the list of acts that + conforms the play, as well as the activities that conforms each act, the + list of students that are part of that given course, etc. It display + this information in a graphical way, in order to make the information + easy to understand. It will also display links to the .LRN services + involved, in case the teacher wants to make use of the functionalities + of that specific package (because eventhough we make use of them, it + doesn't mean that we are replacing them). In the future the teacher will + be able to edit the sequence of activities from the viewer, when the + editor is finished. + + On the other hand, the viewer offers the possibility to the + students to see their status inside the play. They can see how much have + completed and how much they have yet to complete. Of course, when + viewing the IMS LD level B, this current status is not that easy to see + nor to reproduce, because the workflow can depend on the students + themselves because of the properties and contitions. Even more, there + can be sometimes that this status is impossible to represent (we mean, + the exact path that the student has not completed yet), because the + conditions change during the lifetime of the course. This gets even more + complicated when viewing IMS LD level C, because it adds the + notifications, wich combined with the conditions and properties of level + B, can make the play to follow a path impossible to represent. But no + matter what level the student is viewing, he is able to see what he or + she have already done. +
+ +
+ IMS LD Player + + The player is the part of the imsld package that present to all + the roles of the unit of learning the different activities in a sequence + ordered way based on the properties and conditions. + + When deciding how the player should interact with the user, we + thought two different implementations: + + + + Show a little portlet to the user that indicates the next + activity to complete, showing the corresponding link to the + appropriate .LRN package. + + + + Render all the information in a single window, in a + centralized way. Something that the LORS package currently do when + playing an SCORM document. + + + + After analizing each one of these approaches, we concluded that + rendering all the information in a single window was the better option, + because we think is more simple for the users (teachers and students) to + centralize the visualization instead of following different links, and + also it can give us some kind of controll of what the user is doing, and + we can be sure of what the user is actually seeing on his/her + screen. + + Also, for example if the activity is a forum and we redirect the + user to this forum, the user can easily get distracted and end up + reading a forum that does not form part of the activity. In the other + hand, if we render the forum inside a centralized window, we have the + controll on the user's window, and by using some kind of iframe, we can + easily show any important message to the user and be sure (well, not + entirely), that he/she read it. Besides, in this centralized window we + can show in the bottom the activities that are completed and, when + possible, the ones that are yet to complete. + + Therefore the selected option is the single window. The users + (students, professors, etc.) will see in the single window in a concrete + moment of time, some resource associated with an activity. The user will + have at the left hand a list of the possible activities that he/she can + see in a concrete moment (this depends on the design of the course). The + student can select between the activities presented. Also for each + activity it will be a description that will be shown always if the + current activity is selected by the user (this description will appear + in a little space), and also the user will be able to choice between the + different resources of the associated enviroment of the activity. + Therefore the student will select between the given resources for the + activity. These resources can be any of the .LRN services or learning + objects as files that comes for example in the IMS CP. + + The activities presented to the different roles will change in the + time depending on the different properties and conditions. For example, + it can change depending on the evaluations of the professors, on the + results of the assessments, on the user models, etc. Therefore not all + the users will see the same information because it is personalized + depending on conditions. Also different paths in the workflow can be + defined based on roles. +
+ + + + Use Cases + +
+ Use Cases + + The following Use Cases describe how the ims-ld package for .LRN + can be applied in different situations. Some of these Use Cases have + been inspired for the experience in the E-LANE project . The ims-ld package for + .LRN will have a wide range of capabilities and it could be applied to a + wide range of powerful pedagogies and scenarios. Here we explain + different Use Cases where this package can be used. The Use Cases + doesn't present the detailed diagram about the interactions beween the + different roles involved, but they can be easily deduced from the given + explanation. + +
+ Integration in the same execution framework of different .LRN + packages combined in a workflow + + The ims-ld package will communicate with different .LRN + services, as part of different activities, presenting them in a + prescribed order. The ims-ld package allows to visualize in the same + window different .LRN services like assessments, calendar, + evaluation(gradebook), forums, FAQs, chat, etc. + + With the ims-ld package the user only has to click the execution + window link, and then he/she will be able to visualize all the + workflow of the activities designed for him/her without having to go + to the concrete links. +
+ +
+ Evaluation of the educational process + + With the IMS LD package can be used to evaluate the users in the + unit of learning (using evaluation, for instance), but it also can + evaluate them using the contents and activities of the e-learning + process, and even tests, that the professor have designed. Therefore + the entire educational process is evaluated. The professor can assign + tests for some activities, for some contents, for some users, + etc. + + As a particular example of this scenario, several contents can + be presented to the students grouped in different activities. The + activities are presented to the students in a sequencial order and + after each activity an assessment associated to its content has to be + done. These way the professor can evaluate the students for all the + different contents, and also evaluate the content. For example, if the + majority of the students fails an exam then it is a signal of a + content that could require modification. + + Moreover, IMS LD allows to evaluate the process in function of + the obtained objectives (learning objectives). The ims-ld package + defines overall objectives and objectives for each activity, so an + analisys of the obtained objectives can be made with respect to the + initial requirements. +
+ +
+ Content Personalization depending on different user + properties + + The possibility of the ims-ld package of defining personal + global properties allows to define a concrete user modeling in the + e-learning experience (unit of learning). A user model in ims-ld + package can be viewed as a set of global properties for a user. The + idea is that a user should follow a particular path in the unit of + learning depending on its particular profile. The ims-ld package + allows to define concrete sequences along with the contents depending + on the user properties and also to show or hide some content inside a + document depending on them. + + As a particular example, in the E-LANE project we are several + different partners, and some or them speak spanish, so at the E-LANE + project we have designed different courses in spanish. Each country + has its special form of the spanish language, and some words doesn't + mean exactly the same in all the countries, also some courses can be + applied in some countries but not in others. With the use of IMS LD we + can solve this problem, defining a property named country and + personalizing each content depending on the country of the user. + Therefore, if a word has different meanings in different countries, + the system will be show the appropiate word depending on the country + property of each user. +
+ +
+ Different paths of contents for users depending on the + evaluation of activities or on the assessments results + + The ims-ld package allows to define different paths along with + the different activities depending on the result of an evaluation of a + homework, task, depending on the grade of an assessment or a on + combination of several evaluations. + + For example, we can define three levels of the student + knowlodge: low, medium and high. If a students receive a set of + evaluations, assessments, etc. and with the tests results the systems + detects that they have a low knowledge level, the system, based on the + unit of learning dessign, can detect it and present to the students an + easy exercise. Neverless, if the tests show that the student has a + high knowledge level, then the system presents to the student a more + difficult exercise. By this way we are adapting the content to the + necesities and knowledge of the students. +
+ +
+ Give the students exactly what they don't know + + Each unit of learning can have a set of prerequisites and a set + of objectives. The prerequisites can be considered as the previous + related knowledge necessary about a given subject and the objectives + can be considered as the future knowledge to aquire. The ims-ld + package allows to check if a particular user has the required + knowledges (the previous and future ones) using assessments or/and + evaluations. This way the system can determine the weak knowledge + areas of the students and show them only the knowlodges they don't + have. This way, for instance, if the student already knows some + concepts of the course, we can avoid to show them because it is a + waste of time for the students. +
+ +
+ Repeating activities for students + + A student can repeat the same activity if the obtained results + are not the desirable or expected ones. He/She can repeat all the + activity or only one part of the it. The repeated activity can consist + of assessments, forums, content, FAQ, chat, etc. +
+ +
+ Give the students the capacity for selecting options + + A user can select different options during the cycle of the unit + of learing, for example, checking a checkbox or fullfiling a text box, + and depending on this selection he/she can go trough different paths + along the course. +
+ +
+ Problem based learning + + The ims-ld package allows to use a common framewok for different + pedagogical models. One of the most beneficious techniques in order to + learn is the problem based learning, where a problem is given to the + students and evaluated by a professor. + + For example we can apply the Polya model for problem solving. + This method has four phases: 1) Understanding the problem 2) Doing a + plan 3) Execution of the plan 4) Review and examining the + solution. + + In IMS LD all of this can be described. Ther could be infinite + possibilities for applying this model in IMS LD. This example uses the + Polya model appliet to a mathematics problem: We have only one play + and one act for this example. The act has one learning-structure which + shows the different activities in an stablished order. Each phase of + the Polya model will have at least one associated activity. + + 1) Understanding the problem: The activity consists in reading + the enunciation of a problem. The problem is presented to the student + as a description. Also, there is a resource inside an enviroment that + asks the student the next questions: What are the variables? What are + the conditions? Is enough the conditions to determine some variables?, + etc. IMS LD can indicate that only when the user answer these + questions he/she can move on to the next step. this will be + interpreted in our .LRN package and only when this condition is done + the student will go to the next step. + + 2) Doing a plan: The activity consists of thinking an adequate + strategy for solving the problem. To help tje student, he/she can + consult an enviroment during the activity that consists of a set of + files that contains the theoretical concepts thay helps to understand + the problem. With the IMS LD specification, the professor can indicate + that only when the student push a specific bottom, then he/she will go + to the following step. The ims-ld package deal with this case + too. + + 3) Execution of the plan: This phase has two activities. Both of + them use the Evaluation(Gradebook) package. The first activity is for + the students, they have to do the solution of the problem and submit + it to the system. The second one is for the professors and it is a + support activity. They have to grade the submissions and also they + provide feedback for the students. + + 4) Reviewing and examining the solution: The student has to + debug his/her answer according to the feedback received by the + professor. The professor in the previous phase has given the + studentsthe solution and they should extend it to other type of + problems. In this phase, the students can access the course materials, + use the chats, forums, etc, in orther to discuss their ideas among + them, and finally they have to take an assessment. +
+ +
+ Learning in student groups + + The benefits of working with groups of students in order to + learn are well known. The ims-ld package allows this approach in + several ways. It allows to define different roles wich in the + execution time will be transformed in different groups. Each group can + receive a common problem to solve, being in a common forum, chat, etc. + Also, there can be different groups with people of different roles, + where each person has to do a different task in order to get the work + done, wich at the end is discussed by all members of the group. +
+ +
+ Collaboratibe Learning + + The ims-ld package allows to produce different ways of + Collaboratibe Learning. For example, it can establish that until a + certain group doesn't finish one set of activities, then the following + activity will not begin. This can be done thanks to the contitoins of + the different acts. It also allows the interaction between people + with, for example, the notifications of the Level C of IMS LD. Also, + for the Collaborative Learning, the chat, forums, etc. can be + used. + + For example, in a learning experience, until all the members of + a group have not finished reading an on-line text, they cannot start a + discusison forum about it. +
+ +
+ Learning by Games + + As a lot of games requires a sequence of activities and + interaction between different roles, then some Games could be modelled + as IMS LD, and they could be played using the Player of the ims-ld + package +
+ +
+ Reusing Methodologies + + The methodology represented in an IMS LD file can be reused for + other purposes. For example the methodology of a successful course of + "Computer Architecture" could be reused in another course of + "Communication Software". Although the content of the courses have + nothing in common, the methodology can be reused in the sense of the + order of the activities, conditions, services that are going to use, + etc. +
+
+ +
+ Final Comments + + The presented use cases are only a set of examples about some + possible applications of the ims-ld package in .LRN, but it is not + restricted to this applications. There can be a use case that combines + some or all of the ones described above too. For example, a + collaboratibe learning activity, problem based and content personalized + e-learning experience with an evaluation of the educational process is + possible. Whichever other combinations are also possible. + + We have tried to represent the more common applications but there + are some other applications that can be applied with the ims-ld package + and have not been mentioned. + + In Summary the ims-ld package provides a wide range of + possibilities for both teachers and students, and many different and + interesting use cases have been exposed. +
+ + + + Data Model + + The following data model stores the relevant information that can be + in an IMS LD file. The tables are the ones needed to store the interesting + part of the information from IMS LD specification that we consider is + necessary in order to play the unit of learning correctly. + + At present, the data model does not have into account the + interaction with the rest of the .LRN packages, because the tables needed + for that interaction will be defined in the development phase. Also, the + tables might change during the development phase, because we can find + better ways to structure the information, but the final data model, in our + opinion, will not be too different from the one presented here. + + The complete data model is presented in an Entity-Relationship (ER) + diagram that is divided in three blocks, each one related to a level of + the IMS LD specification. The tables of the .LRN model for supporting IMS + LD of a level are not independent from the other levels, and the + relationships of the three diagrams have been represented. In the tables + of the E-R diagrams are presented only the primary keys and foreign keys. + This is in order to achieve clarity and simplicity because the diagram is + too big. Nevertheless, all the fields of the proposed diagram are + presented and explained next, divided by the three levels of IMS + LD. + + Next, each table of the data model is described divided in the three + levels of the IMS LD specification + + IMPORTANT NOTE: The present Data Model will be normilize in the near + time in order to improve its understanding. + +
+ Level A + + + + imsld_imslds: This table is used to store all the units of + learning. This is the high level in the hierarchy. Each IMS LD + file loaded in .LRN will generate an entrance in this table. This + table contains all the different units of learning. Each unit of + learning will contain global information and also references to + other tables for having all the required information of a unit of + learning + + + + imsld_id - identifier + + + + version - version number + + + + uri - uri of the imsld + + + + level - A, B or C. It is the level of the IMS LD file + that arrive + + + + sequence_p - sequence used, true or false. True means + simple sequencing is being used. Defaults to false + + + + learning_objective_id - references + imsld_learning_objectives + + + + title + + + + method_id - references imsld_methods + + + + prerequisite_id - references imsld_itemmodel + + + + component_id - references imsld_components + + + + complete_unit_of_learning_id - references + complete_unit_of_learning + + + + + + imsld_complete_unit_of_learning. This tables describes the + actions to do when a unit of learning is completed + + + + complete_unit_of_learning_id + + + + when_property_value_is_set_id * - references + imsld_when_property_value_is_set + + + + + + imsld_prerequisites. It has all the prerequisites of a unit + of learning. These are the previous knolowdges that are required + for doing the unit of learning + + + + prerequisite_id + + + + prerequisite_item - references imsld_items + + + + + + imsld_components: Used to store all the components of the + IMS LD + + + + component_id + + + + role_id - references imsld_roles + + + + activity_id - references imsld_activities + + + + environment_id - references imsld_environments + + + + property_id * - references imsld_properties + + + + + + imsld_roles. This table contains all the defined + roles + + + + role_id - references imsld_roles + + + + role_types - references role_types_id + + + + create_new_p - multopleoccurrences of this role may be + created during runtime? + + + + match_n_persons - exclusively-in-roles, + not-esclusively + + + + max_persons. Maximum number of persons for this + role + + + + min_persons. Minimum number of persons for this + role + + + + role_name. The name of the role + + + + information_id - references imsld_items + + + + role_parent_id. The parent role. This allows a hierarchy + of roles. The root of the hierarchy are learner and stuff, + which has not a parent role + + + + + + imsld_activities. This table defines the three types of + activities in IMS LD: learning activities, support activities and + structure activities. These three tables references to this + table + + + + activity_id + + + + activity_structure_id - references + imsld_activity_structures + + + + + + imsld_learning_activities. This table stores all the + learning activities of IMS LD + + + + learning_activity_id - references + imsld_activities + + + + title + + + + isvisible_p - initial visibility attribute. Initial + value: true + + + + learning_obective_id - references + imsld_learning_objectives + + + + prerequisite_id - refereces imsld_itemmodel + + + + parameter_id - references imsld_parameters + + + + activity_description_id - references imsld_items + + + + complete_activity_id - references + complete_activities + + + + on_completion_id * - references + imsld_on_completions + + + + + + imsld_complete_activities. This is a table where for each + entry is specified when an activity is considered completed + + + + complete_activity_id + + + + user_choice - the user specifies that this activity is + completed + + + + time_limit - references imsld_time_limits. The activity + is completed when the time is completed + + + + when_property_value_is_set_id * - references + imsld_when_property_value_is_set + + + + + + imsld_learning_activity_environments_map This table maps + learning activities with enviroments + + + + learning_activity_id - references + imsld_learning_activities + + + + environment_id - references imsld_environments + + + + + + imsld_support_activities. This table stores all the support + activities of IMS LD + + + + support_activity_id - references imsld_activities + + + + component_id - references imsld_components + + + + isvisible_p - initial visibility attribute. Initial + value: true + + + + title. The name of the support activity + + + + activity_description_id - references imsld_items + + + + complete_activity_id - references + imsld_complete_activities + + + + on_completion_id - references + imsld_on_completions + + + + + + imsld_support_activity_roles_map. This table maps a support + role to an activity + + + + support_activity_id - references + imsld_support_activities + + + + role_id - references imsld_roles + + + + + + imsld_support_activity_environments_map. This table maps + support activities with enviroments + + + + support_activity_id - references + imsld_support_activities + + + + environment_id - references imsld_environments + + + + + + imsld_activity_structures. This table contains all the + activity structures of IMS LD. Each entry is one activity + structure. + + + + activity_structure_id - references + imsld_activities + + + + number_to_select - if not null, the activity structure + is completed when the number of activities completed equals + the number set + + + + sort - possible values: as-is, visibility-order + + + + structure_type - sequence or selection + + + + title. The name of the activity structure + + + + information_id - references imsld_items + + + + + + imsld_activity_structure_choices + + + + choice_id + + + + learning_activity_id - references + imsld_learning_activities + + + + support_activity_id - references + imsld_support_atcivities + + + + unit_of_learning_id - references imsld_imslds + + + + activity_structure_id - references + imsld_activity_structures + + + + + + imsld_activity_structure_choices_map + + + + activity_structure_id - references + imsld_activity_structures + + + + choice_id - references + imsld_activity_structure_choices + + + + + + imsld_activity_structure_environments_map + + + + activity_structure_id - references + imsld_activity_structures + + + + environment_id - references imsld_environments + + + + + + imsld_environments + + + + environment_id + + + + + + imsld_enviromnent_instances + + + + enviroment_id - references imsld_environments + + + + environmen_instance_id + + + + title + + + + + + imsld_environment_instance_choices + + + + choice_id + + + + learning_object_id - references + imsld_learning_objects + + + + service_id - references imsld_services + + + + environment_id - references imsld_environments + + + + + + imsld_environment_instances_environment_instance_choices_map + + + + choice_id - references + imsld_environment_instance_choices + + + + environment_instance_id - references + imsld_enviromnent_instances + + + + + + imsld_learning_objects + + + + learning_object_id + + + + class + + + + isvisible_p - the user decides when the activity is + completed? + + + + parameter_id - references imsld_parameters + + + + type - knowledge-object, tool-object, test-object, etc. + (learning resource type from the IEEE LTSC LOM) + + + + item_sequence_id - references + ims_leanring_object_item_sequences + + + + schema_sequence_id - references + ims_learning_object_schema_sequences + + + + item_id - references imsld_items + + + + environment_id - references imsld_environments + + + + + + imsld_learning_object_item_sequences: First sequence of the + learning objects + + + + sequence_id + + + + title + + + + + + ims_learning_object_schema_sequences: Second sequence of the + learning objects + + + + sequence_id + + + + schema + + + + schemaversion + + + + + + imsld_learning_object_item_sequence_items_map + + + + sequence_id - references + imsld_learning_object_item_sequences + + + + item_id - references imsld_items + + + + + + imsld_parameters: Table for holding the parameter values. + This table will possible dissapear, depending if in the + development phase there is the need of storing more information + about the parameters + + + + parameter_id + + + + parameter_value + + + + + + imsld_services. It contains all the services + + + + service_id + + + + class + + + + identifier + + + + isvisible_p + + + + parameter_id + + + + email_service - (send_mail) references + imsld_email_services + + + + conference_service_id - references + imsld_conference_services + + + + index_search_id - refernces + imsld_index_search_services + + + + + + imsld_email_services. It describes all the email + services + + + + email_id - references imsld_services + + + + select - all-persons-in-role, persons-in-role + + + + title + + + + + + imsld_email_data + + + + email_data_id + + + + role_id - references imsld_roles + + + + email_property_id - references imsld_properties * + + + + username_property_id - references imsld_properties + * + + + + + + imsld_email_service_email_data_map + + + + email_id - references imsld_email_services + + + + email_data_id - references imsld_email_data + + + + + + imsld_conference_services + + + + conference_id + + + + conference_type - synchronous, asynchronos or + announcement + + + + title + + + + conference_manager_id - references imsld_roles + + + + moderator_id - references imsld_roles + + + + item_id - references imsld_items + + + + + + imsld_conference_participants_or_observers_map + + + + conference_id - references + imsld_conference_services + + + + role_id - references imsld_roles + + + + + + imsld_index_search_services + + + + search_service_id + + + + title + + + + index_class - this element selects the clss to make the + index on + + + + index_element - this element selects the element to make + the index on + + + + index_type_of_element - type of element to index + on + + + + search - how a user can access the indexed + entities + + + + search_type - type of search facility that is expected + at runtime: free-text-search, index-with-reference, + index-without-reference + + + + + + imsld_learning_objectives. This table contains all the + different objectives of the different unit of learning and + activities. Each entry of this table is a set of objectives. A set + of objectives is symbolized by an itemmodel_id + + + + learning_objective_id + + + + itemmodel_id - references imsld_itemmodels + + + + + + imsld_methods + + + + method_id + + + + time_limit_id - references imsld_time_limits. If not + null, the mehod is completed when this time has been + completed, otherwise, the method is completed when all the + plays mapped to this method through the + imsld_plays_to_complete_method are completed + + + + on_completion_id - references + imsld_on_completions + + + + condition_id * - references imsld_conditions + + + + + + imsld_plays_to_complete_method. It contains all the plays + that has a method. Each play can be selected in parallel by an + user during the delivering of a unit of learning + + + + method_id + + + + play_id + + + + + + imsld_plays + + + + play_id + + + + isvisible_p - the user decides when the activity is + completed? + + + + title + + + + complete_play_id - references imsld_complete_play + + + + on_completion_id - references + imsld_on_completions + + + + + + imsld_complete_play + + + + complete_play_id + + + + when_last_act_completed - references imsld_acts. The + play is completed when this act is completed + + + + time_limit_id - references imsld_time_limits. The play + is completed when this time is completed + + + + when_property_value_is_set_id * - references + imsld_when_property_value_is_set + + + + + + imsld_method_plays_map + + + + method_id - references imsld_methods + + + + play_id - references imsld_plays + + + + + + imsld_play_acts_map + + + + play_id - references imsld_plays + + + + act_id - references imsld_acts + + + + + + imsld_acts + + + + act_id + + + + title + + + + complete_act_id - refrences imsld_complete_acts + + + + on_completion_id - references on_completion + + + + when_condition_true * - references + imsld_when_condition_true + + + + + + imsld_complete_acts + + + + complete_act_id + + + + time_limit_id - references imsld_complete_acts. When not + null, the act is completed when this time has been completed, + otherwise, the act is completed until all role parts mapped to + this complete_act_id trhoug the imsld_act_role_parts are + completed + + + + when_property_value_is_set_id * - references + imsld_when_property_value_is_set + + + + + + imsld_act_role_parts + + + + complete_act_id - references imsld_acts + + + + role_part_id - references imsld_part_id + + + + + + imsld_act_role_parts_map + + + + role_part_id - references imsld_role_parts + + + + act_id - references imsld_acts + + + + + + imsld_role_part_choices + + + + choice_id + + + + learning_activity_id - references + imsld_learning_activities + + + + support_activity_id - references + imsld_support_activities + + + + unit_of_learning_id - references imsld_imslds + + + + activity_structure_id - references + imsld_activity_strutcures + + + + environment_id - references imsld_environments + + + + + + imsld_role_parts - mapping table between acts and + roles + + + + role_part_id + + + + title + + + + role_id - references imsld_roles + + + + choice_id - references imsld_role_part_choices + + + + + + imsld_on_completion + + + + on_completion_id + + + + feedback_description_id - references + imsld_itemmodels + + + + change_property_value_id * - references + imsld_change_property_value + + + + notification_id - references imsld_notifications + ** + + + + + + imsld_itemmodels. This is a table that contains a text and + an id. In conjuction with the tables imsld_itemmodel and + imsld_itemmodel_items_map allow to associate several items to the + same itemmodel. + + + + title + + + + itemmodel_id + + + + + + imsld_itemmodel_items_map + + + + item_id - references imsld_items + + + + itemmodel_id - references imsld_itemmodels + + + + + + imsld_items. Items are used for multiple purporses in other + tables. For example it can describe objectives, prerequisites, + references to files, etc. + + + + item_id + + + + identifier. Unique identifier for the IMS LD + + + + identifierref. It references the IMS CP + + + + isvisible_p. + + + + parameter_id + + + + title: A text that can represent a prerrequisite, an + objective, the name of a file, etc. + + + + parent_item - references imsld_items. An item can + reference to another item, wich is a sub-item or child of the + one referencing it. + + + + + + imsld_time_limits + + + + time_limit_id + + + + time_limit - amount of time in a specific format + + + + property_id * - references imsld_properties + + + + Next, the tables necessary for Level A are draw in the + form of an E-R diagram + + + + + + +
+ +
+ Level B + + Level B extends the table email_data and add: username_property_id + and email_property_id * Next is shown the E-R diagram for these + tables + + + + + + + + + + imsld_properties (add a reference to properties from + imsld_components and time_limits *) + + + + property_id + + + + + + imsld_loc_locpers_locrole_properties: Combined table for the + loc, locpers and locrole properties + + + + property_id - references imsld_properties + + + + title. The name of the property + + + + datatype - references imsld_datatypes + + + + initial_value + + + + + + imsld_globpers_glob_property: Combined table for the glob and + globpers properties + + + + property_id - references imsld_properties + + + + global_definition_id - references + imsld_global_definitions + + + + existing + + + + + + imsld_global_definitions + + + + property_id - references imsld_properties + + + + uri + + + + title + + + + global_definition + + + + datatype_id + + + + initial_value + + + + + + imsld_property_groups + + + + property_group_id + + + + property_id - references imsld_properties + + + + title + + + + + + imsld_group_property_coices + + + + choice_id + + + + property_id - references imsld_properties + + + + proerty_group_id - references imsld_property_groups + + + + + + imsld_restrictions + + + + restriction_id + + + + restriction_type - minExclusive, minInclusive, + maxExclusive, maxInclusive, totalDigits, fractionDigits, length, + minLength, maxLength, enumeration, whiteSpace, pattern + + + + restriction + + + + + + imsld_property_restrictions_map + + + + restriction_id - references imsld_restrictions + + + + property_id - references imsld_properties + + + + + + imsld_datatypes + + + + datatype_id + + + + datatype - string, boolean, integer, uri, datetime, file, + real, tet, duration, other + + + + + + imsld_when_property_value_is_set (add a reference to this + table from the tables: complete_activities, complete_act, + complete_play and complete_unit_of_learning *) + + + + when_property_value_is_set_id + + + + property_id - references imsld_properties + + + + property_value_id - references property_values + + + + + + imsld_property_values + + + + property_value_id + + + + langstirng + + + + calculate_id - references imsld_calculates + + + + property_id - references imsld_properties + + + + + + imsld_change_property_values: A reference to this table must + be added from the imsld_on_completion table in level A + + + + change_property_value_id + + + + property_id - references imsld_properties + + + + property_vaue_id - references property_values + + + + + + imsld_monitors + + + + monitor_id + + + + serivce_id - references imsld_services + + + + monitor_choice_id - references + imsld_monitor_choices + + + + + + imsld_monitor_choices + + + + choice_id + + + + role_id - references imsld_roles + + + + self - references imsld_roles + + + + + + imsld_conditions: A reference to this table must be added fom + the table imsld_methods in level A + + + + condition_id + + + + title + + + + + + imsld_sequences + + + + sequence_id + + + + condition_id - references imsld_conditions + + + + sequence_sort - to know how to evaluate the + condition + + + + if_id - references imsld_ifs + + + + + + imsld_then_model + + + + then_model_id + + + + show_id - references imsld_show_hide + + + + hide_id - references imsld_show_hide + + + + change_property_value + + + + + + imsld_ifs + + + + if_id + + + + expression_id - references imsld_expressions + + + + true_thenmodel_id - 'then', evaluated if the expression is + true. References imsld_then_model + + + + false_thenmodel_id - 'else', evaluated if the expresison + is false. References imsld_then_model + + + + + + imsld_expressions - table holding the expressions. Instead of + makin a table for each type of expression, we store the + expression_type and according to that value we know what other + attributes in the table have to be stored in order to use + them + + + + expression_id + + + + expression_type - is-member-of-role, is, is-not, and, or, + sum, substract, multiply, divide, greater-than, less-than, + users-in-role, no-vaue, time-unit-of-learning-started, + datetime-activity-started, current-datetime, complete, + not + + + + expression_id - references imsld_expressions + + + + calculate_id - references imsld_calculates + + + + expression_one_id - references imsld_expressions + + + + expression_two_id - references imsld_expressions + + + + role_id - references imsld_roles + + + + property_id - references imsld_properties + + + + time_unit_of_learning_started + + + + datetime_activity_started + + + + current_datetime + + + + + + imsld_calculates + + + + calculate_id + + + + right_operand - references imsld_operands + + + + left_operand - references imsld_operands + + + + + + imsld_operands + + + + operand_id + + + + property_id - references imsld_properties + + + + property_value - references imsld_property_values + + + + expression_id - refernces imsld_expressions + + + + + + imsld_when_condition_true (add a reference from the + imsld_complete_acts table *) + + + + when_condition_true_id + + + + role_id - references imsld_roles + + + + expression_id - references imsld_expressions + + + + + + imsld_show_hide + + + + show_hide_id + + + + class + + + + item_id - references imsld_items + + + + environment_id - references imsld_environments + + + + learning_activity_id - references + imsld_learning_activities + + + + support_activity_id - references + imsld_support_atctivities + + + + activity_structure_id - references + imsld_activity_structures + + + + play_id - references imsld_plays + + + + unit_of_learning_id - references imsld_imslds + + + + + + imsld_global_elements + + + + global_element_id + + + + view_set_property_id - references + view_set_properties + + + + + + imsld_view_set_properties + + + + view_set_property_id + + + + type - view-property, view-property-group, set-property, + set-property-group + + + + href + + + + property_of - self or supporter-person + + + + ref + + + + view - value or title-value + + + + max_transactions + + + + transaction_type + + + + notification_id - references imsld_notifications ** + + + + +
+ +
+ Level C + + Level C modity the imsld_email_data (**), add a reference to + imsld_notifications table from imsld_on_completion, imsld_thens and + imsld_view_set_properties table (**). Next is shown the E-R diagram that + adds Level C + + + + + + + + + + imsld_notifications + + + + notification_id + + + + choice_id - references imsld_notifications_choice + + + + subject + + + + + + imsld_notification_emails_data_map + + + + notification_id - references imsld_notifications + + + + email_data_id - references imsld_email_data + + + + + + imsld_notifications_choice + + + + choice_id + + + + learning_activity_id - references + imsld_learning_activities + + + + support_activity_id - references + imsld_support_activities + + + + +
+ +
+ Run Tables + + The previous tables are referred to the IMS LD specifications + level A, B and C. They have all the information necessary to map an XML + conformant IMS LD document to the tables in the .LRN platform. But also, + for the ims-ld package to interact with real users, we need additional + tables. These new tables are necessary for the execution of the player + where the information is sequenced to the student. These tables are + described in this Section. Next is shown the E-R diagram for these + tables + + + + + + + + + + imsld_party_roles_map. This table maps parties of a .LRN + course to the roles defined in the IMS LD document. A party can be + either a user or a group. One party can belong to several + roles. + + + + party_id references parties + + + + role_id references imsld_roles + + + + + + imsld_parties_property_values_map. This table maps parties of + a .LRN course to the properties defined in the IMS LD document. One + party can have several property values to establish. The properties + can be local or global. + + + + party_id references parties + + + + property_id references imsld_properties + + + + property_value. This is the value of the property for the + party in a current moment. The value can change during the + delivering of the unit of learning + + + + + + imsld_roles_property_values_map. This table maps roles of the + IMS LD document to the properties of the IMS LD document. One role + can have several property values to establish. The properties can + only be local. + + + + roles_id references imsld_roles + + + + property_id references imsld_properties + + + + property_value. This is the value of the property for the + role in a current moment. The value can change during the + delivering of the unit of learning + + + + + + imsld_property_values. This table stores the values of the + properties that are common for all the users of the the IMS LD + document. There can be several property values to establish. The + properties can be local or global. + + + + property_id references imsld_properties + + + + + + property_value. This is the value of the property for the + role in a current moment. The value can change during the + delivering of the unit of learninging + + + + + + + + imsld_parties_activities_audit. This table stores all the .LRN + parties information about the IMS LD delivering that is of interest. + related to activities At present we have defined only a little + information, but in the future this information may be expanded. + Each entry of the table has an activity that has been realized by a + party. + + + + party_id references parties + + + + activity_id references imsld_activity + + + + delivering_order. It represents the order of visualization + of the activity in the sequence of activities + + + + selected_p. It is true if the party select by himself the + activity. It is false if the activity was sequenced to the + party + + + + start_time. The start time of the activity + + + + end_time. The end time of the activity + + + + done_p. It is true if the activity is complete + + + + act_id references ismld_parties_acts_audit + + + + + + + + imsld_parties_acts_audit. This table stores all the .LRN + parties information about the IMS LD delivering that is of interest + related to acts. At present we have defined only a little + information, but in the future this information may be expanded. + Each entry of the table has an act that has been realized by a + party. + + + + party_id references parties + + + + + + act_id references imsld_acts + + + + + + start_time. The start time of the act + + + + + + end_time. The end time of the activity + + + + done_p. It is true if the act is complete + + + + + + imsld_parties_plays_audit. This table stores all the .LRN + parties information about the IMS LD delivering that is of interest + related to plays. At present we have defined only a little + information, but in the future this information may be expanded. + Each entry of the table has an act that has been realized by a + party. + + + + party_id references parties + + + + + + play_id references imsld_plays + + + + + + start_time.The start time of the act + + + + + + end_time. The end time of the activity + + + + done_p. It is true if the act is complete + + + + +
+ + + + Architectural Model + + Here we give an explanation of the way the inner components of the + imsld package interact internally between them and externally with some + other packages of .LRN Next, a figure about the general architecture about + IMS LD and the ims-ld package is shown. + + + + + + + + We have two methods for loading the information into the ims-ld + package. One is by means of an internal .LRN editor (as we said this is + not planned for the short term). The other method is loading an IMS LD + compliant XML file, as we said before, it can be generated using an + authoring tool wich is not part of .LRN, at least not when writing this + specification. The file is requested to the user by the UI of the parser. + This UI will conist of a small number of pages with a form where the user + can upload the file and with some others with error or log messages + displayed to the user via web. In this step, the imsld package will also + validate the IMS LD file for proving conformance with the IMS LD standard. + It indicates when the parser didn't parse the whole file correctly and it + needs human help in order to finish its job. So, the first component of + the imsld package that interacts with the database is the parser, using + the tcl and sql API. + + At the lowest level we have the information stored in the data base. + The information that have been loaded from an IMS LD file is parsed and + stored in the database in the tables related to the level A, B and C that + have been shown in the previous Data Model Section. With this mapping we + will have all the information contained from the IMS LD package in the + .LRN + + Once all the information of the IMS LD compliant XML file is stored + in the database, the course is ready to be played. As we mentioned above, + the player has two modes for the professor, on-line and off-line. The + first one is the off-line mode, because the course has not being played or + instanced yet. In the off-line mode the teacher should associate the + students and course admins to their respective roles in the unit of + learning. In this step are fullfilled the tables imsld_party_roles_map and + imsld_parties_property_values_map. Also the rest of the tables of the run + tables are initialized for each user at this time. All the information + that is stored in this Run Tables is not contained in the IMS LD file, + this information is particular for each run. At this step the information + is particularized for the users of the unit of learning. + + Be aware that a professor can have the student role in the unit of + learning or vice versa, that is the professor's choice. The roles of the + unit of learning are stored in the database, but the mappings between the + real users with their respectives roles is the professor's task. When + doing these mappings, the respective conditions recently obtained from the + XML file start to be verified. For instance, there is a + max-number-of-persons tag for a role, so the professor can't assign more + than n users to that role. There is also a match-person tag, that implies + that the person with that role can't have any other role inside the unit + of leaning while being assigned to the first role. In this off-line mode, + the professor can take a general perspective of the unit of learning. + He/she can take a look at all the activities that will be done by the + students, as well as the conditions and every information that is + important to be shown. + + Once the real users are mapped to the roles, the unit of learning + can be instantiated. This will start the on-line mode of the + viewer. + + For the professor, the on-line mode of the viewer lets him/her to + see the status of the course(unit of learning). As mentioned in the user + requirements chapter, this mode of the viewer lets the professor to do any + tracking activity of the students. Such as seeing how many students are in + what act of the play, what user-choice activities are being accessed and + what aren't, etc. By the time when writing this specification, the + professor can't modify anything from the viewer, it is read only + information. At the time of run of the unit of learning the Run Tables are + refreshed with new completed activities, acts and plays of each + user. + + For the student, the on-line mode of the viewer is very similar to + the one for the professor, with the main difference that with the student + can only see his/her own information, whereas the professor can see the + information of all the class students. From the viewer the students can + see what activities have already completed, as well as how much time + between activities they took, and how much time they spent in each + activity. In some designs (of the IMS LD compliant XML file), the student + can see the rest of activities that he/she has to complete in order to + finish the unit of learning. This is not true in every case, because, for + instance, when creating the unit of learning, the professor can set the + is-visible tag to false for every activity in the unit of learning, not + allowing the students to see any more than what they have already + done. + + Everything is ready now for the most important component of the + imsld package: The Player. Of course, the viewer will be allways + accessible to the class members, so they can interact with the player and + then with the viewer, any time they want and in any sequence. + + The player, from the visualization point of view, is nothing more + tan a cetralized page. This centralized page has some menus and message + sections at the sides and at the bottom, with instructions and + descriptions that the student has to read. The professor can be part of + the unit of learning being played too, the only thing he/she has to do is + assign him/herself to a role of the unit of learning. + + The player is the component that is in charge of verifying the + poperties and conditions that were specified in the XML file. It will + detect wichever change in the properties, check the completion of + activities, acts, etc. and evaluate the conditions. In particular the + properties that at least the ims-ld package is going to support + are: + + + + Global user properties. These type of properties are as the + nationality, user model, etc. + + + + Properties selected by the user when navigation throuh html + page. The user can select different values and this became properties. + Depending on the values selected by the user, he/she can go through + different paths in the course. For this option is necesary that the + player understand HTML modified with some IMS LD properties in order + to enable this + + + + Properties that are the result of an evaluation or an + assessment. Depending on the values of the evaluation or assessment, + he/she can go through different paths in the course. + + + + + + + + Every time that for wichever user a resource is served, an activity + is started or completed, an assessment is finished, etc, the player must + check for every possible condition in order to follow the worklow defined + by the unit of learning. The player is also the one in charge of changing + the corresponding property values of each resource and to make sure that + the workflow of the course is the one the course creator intended. + + Moreover, the player is the component that interacts with the .LRN + packages mentioned before. It make use of them in order to interact with + the users. The information about every resource is stored in the database + by the parser, but the actual interaction happens when the player finds + out that a given resource has to be instanciated and shown to the user. + This is then the intercomunication between .LRN packages takes place. As + mentioned before, in order to make this intercomunication as clean as + possible, we will make use of the callbacks functionallity. Using + callbacks is the best way of intercomunicating .LRN packages, because we + don't have to rewrite the code and we can verify if two packages are + connected. Besides, we can't depend on the packages that are not required + by .LRN. In fact, we can't assume that any package is installed, because + we don't know how the site wide admin configured the .LRN service. Tha is + something that the player is aware of. + + This is a detailed explanation of what .LRN packages and for what + resources we will use: + + + + Forums. To deal with the + asynchronous IMS LD defined services. More specifically, it will + deal with the <conference> IMS LD tag, when conference-type is + asynchronous. + + + + Jabber. To deal with the + synchronous IMS LD services. More specifically, it will deal with + the <conference> IMS LD tag, when conference-type is synchronous. + + + + Assessment. To deal with + activities in which enviroment has a QTI resource or a reference to + an assessment. Therefore, whichever QTI file or a predefined + reference to an assessment will be interpreted by the assessment + module. + + + + Evaluation (grade book). We + will have an standard way in order to recognize that Evaluation + package should be invoked when interpreting an IMS LD file. This is + not mentioned in the IMS LD specification so it is an adaptation to + our LMS system. So we have to stablish a new propietary criterion: A + necessary condition for launching the Evaluation package will be + that we would have two associated resources together in the same act + with a concrete reference to the evaluation package. One resource + inside an enviroment of a learning activity (usually for students) + and the other resource for a support activity (usually for a + professor). When the consensued href for evaluation arrives, then + the ims ld package will be launched and the professor will + parametrize a new exam, file to submit, homework, etc. with its + respective mark load if proceeds. On the other hand the student will + be able to upload his/her solution. But another necessary condition + will be that there would be in the following act another two + associated resources together: one for the professor in order to be + able to mark and evaluate his/her work, and other for the students + that will receive the results and comments for the professor and + should study them. As we can see there are really 4 different + resources that could be in 4 different activities. + + + + Calendar. We will have an + standard way in the IMS LD package in order to recongnize that the + Calendar package should be invoked. Some activities can require as a + resource to see dates or/and notes in a Calendar or to put them in + it. + + + + News. To deal with the + announcements. More specifically, it will deal with the + <conference> IMS LD tag, when conference-type is announcement. + + + + FAQ We will have an standard + way in the IMS LD package in order to recognize that the FAQ package + should be invoked. When the package is invoked then a set of FAQ + will be presented to the student. + + + + Notifications. The system + will generate notifications in the form of emails for all the users + of the learning experience or for particular roles, and also the + different applications will communicate in order to advice about + some events + + + + File Storage. The IMS LD can + refer to an existing resource (file or URL) of the File Storage. + Although, the more usual case is that if we want to refer to some + files, then the files will go inside the IMS LD package instead of + being a reference to the File Storage. + + What specific funcions of each package we use + will be defined during the development phase. + + + + \ No newline at end of file Index: openacs-4/packages/imsld/www/doc/xmlfiles/imsld-short-intro.xml =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/imsld/www/doc/xmlfiles/imsld-short-intro.xml,v diff -u --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ openacs-4/packages/imsld/www/doc/xmlfiles/imsld-short-intro.xml 27 Jun 2005 11:34:37 -0000 1.1 @@ -0,0 +1,195 @@ + + +
+ Very Short Introduction to IMS LD + +
+ IMS Learning Design (very short introduction) + + IMS Learning Design (from now on referred as IMS LD) is a + specification done by the IMS Global Learning Consortium. It is an + XML-based description for e-learning. It provides a global framework for + including the description of different pedagogical and methodological + learning models. Therefore IMS LD is independent from a concrete pedagogy + or methodology. + + The XML file that is compliant with IMS LD specifies a set of + learning activities (which are usually related to a set of resources and + services) and who and when can do these activities and with which + conditions. Therefore, it establishes a sequencing of activities for each + role. IMS LD is in principle independent from IMS Content + Packaging (IMS CP), so it can be used without IMS CP. + Nevertheless, the most common case is to insert the IMS LD file inside the + organizations element of an IMS CP and the result is called "unit of + learning". A unit of learning, as defined in the IMS LD specification, is + an abstract term used to refer to any delimited piece of education or + training, such as a course, a module, a lesson, etc. In this + specification, the terms unit of learning and course are used to represent + the same thing: a collection of ordered activities which has associated + resources and services to learn that are going to be delivered to + different defined roles and the workflow of the activities. + + Unit of learning and IMS Learning Design are not the same thing. A + learning design is a description of a learning method used to achieve + certain goals (learning objectives), and a unit of learning is the result + of packaging a learning design (for example using IMS CP). There are some + other terms introduced by IMS LD that need to be defined, which are + briefly explained bellow: + + + + Prerequisites. The previous + requirements for learners for doing the unit of learning. + + + + Objectives: They are the goals + to obtain in a unit of learning. Also it is possible to write + objectives for each particular activity. + + + + Components. It defines + statically the following elements of a unit of learning: roles, + activities, environments and properties + + + + Roles. It defines the different + types of users in a unit of learning. There are two basic types of + roles: Learner and Staff. But additional roles can be defined. The + roles form a hierarchical graph where the root roles are the basic + ones. For example inside Learner role we can have additional roles + depending on the students level or inside the staff role we can have + professors, teaching assisstants, tutors, etc. .LRN. in fact, has + defined predefined roles, so the sutdent role will be linked to the + Learner one and the proffessor, teaching assisstant, etc. can be + mapped to the IMS LD corresponding ones. When there is no an exact + correspondence, then we will create new .LRN subgroups that match with + the IMS LD roles. + + + + Properties. This is something + that defines a concrete feature. There are local properties , + local-person properties, local-role properties, global-personal + properties and global properties. They are used depending on the scope + of the property. + + + + Activities. An activity is + something to be done, that usually has a description and an + enviroment. There are two types of activities: learning activities + (activities that are done by students in order to learn) and support + activities (activities to support or help students, usually done by + professors). Also there are structure activities which are an union of + several activities that can be presented to the student either in a + sequencial mode or for the user to select. The activities are the core + of the workflow of the learning design. + + + + Environment. Collection of + learning objects (for example files to be viewed by the student), + services (like foros, chat, etc.) and sub-environments, in wich + activities take place. When a student has to complete an activity that + have a concrete enviroment, then he/she can do whichever of the + learning objects and services that are defined inside this + enviroment + + + + Service. For instance, a + discussion forum, email, conference service and monitor service (to + look at the properties). + + + + Method. It defines the dinamic + part of learning design. It consists of several plays and contitions. + If a method has several plays then each play is executed in parallel + for all the roles. Therefore, for example a Learner can select in an + instant of time between the different parallel activities (one + activity for each play) + + + + Play A play has a set of acts. + Each act is not executed until the previous one has been executed. + Therefore, it can be viewed as a sequence of acts. A play finishes + when all its acts has finished + + + + Act It defines what activity to + do for each of role. Each role make the activity in parallel respect + to the rest of roles. An act is finished when all the roles have + finished its activity. This provides a synchronization point. + + + + Conditions. They are used in + conjunction with properties to further refinement and to add + personalization facilities in the learning design. By these way, for + example is possible to take decissions taken into account the user + profile, assessments done by the student, selections of the students + during the course, etc. + + + + Notification. Allows to send + messages between roles or to assign new learning or support activities + to roles based on certain events. When integrating IMS LD with .LRN, + we take advantage of this capability in order to send messages between + the system's components. This can only be done if .LRN is fully aware + of the learner status inside the course. + + + + Item. When a component, a + learning objective, or a prerequisite needs a resource, an item + element is used. The learning design provides a semantic context for + these items, so that runtime systems can know what to do with the + resource. + + +
+ +
+ Levels A, B and C + + There are tree levels of complaint in the IMS LD + specification: + + + + Learning Design Level A includes everything + described above except the conditions, properties and notifications. + It thus contains all the core vocabulary needed to support dedagogical + diversity. + + + + Learning Design Level B adds Properties and + Conditions to level A, which enable personalization and more elaborate + sequencing and interactions based on learner porfolios. It can be used + to direct the learning activities as well as record outcomes. + + + + Learning Design Level C adds Notification + to level B, which, although a fairly small addition to the + specification, adds significantly to the capability. + + + + There is a IMS + Learning Design XML Binding document, where you can find detailed + information about how each one of the elements described above is mapped + in the final xml file. +
+
\ No newline at end of file