• Kollaboration & E-Learning
• Virtuelle Projektarbeit
• Online-Vorlesungen
• Virtuelle Treffen
• Digitale Lernbibliothek
  • About SWITCHcollection
  • Architecture
  • Documents
  • Evaluation
  • Metadata and Model
  • Specification
    • 1. Collections
    • 2. Object Model
    • 3. Access Policy
    • 4. Web API
    • 5. LMS Integration
    • 6. REST API
    • 7. Harvesting
  • Related Projects
  • Help
  • Events
  • Conditions
  • About OER
  • Kontakt
• E-Learning-Community
• SMS/Fax senden

5. LMS Integration

5.    LMS Export Adapters

5.1.    General Considerations

The purpose of LMS export adapters

• Give the course authors a easy to use method to export existing courses to the repository
• Integrate the export feature with the LMS and collect as much existing content and metadata as possible or reasonable.
• The main purpose of exporting a course to the repository is making it available for later re-use and to create a citable reference. Archiving the course is not a main purpose and it should therefore be avoided to export personal live data like chat histories, forum postings, private messages, comments, student submissions, grades etc.
• In the usual case, a course is exported in its entirety. Exporting a course creates exactly one new (or updates one existing) item in the LOR.
• If an entire course is exported, the item is usually an IMS content package. If possible the course structure should be reflected by packing logical course parts into separate IMS content packages, SCORM modules or IMS-QTI packages. This could lead to an IMS-CP for the course that contains nothing than other IMS-CP, SCORM or IMS-QTI packages which represent chapters, self contained learning entities or test sections.
• Exporting a course should require as little user interaction as possible
  • Packing a course should mostly be an automatic process. (Exception: if the user decides what parts of a course are to be exported)
  • Metadata should be collected from the course and the LMS environment. Default metadata should be generated based on personal user preferences.
  • Interaction is required when the user reviews the metadata and confirms to export a course to the repository.

5.1.1.    Workflow (user’s perspective)

Steps:

1. From the administration panel of a course the user (course editor) hits the export to repository… button.
2. Optional: A window opens where the user can specify which parts of a course are packaged and exported.
3. The course is packed into an IMS-CP package. Either the user specified items or the default items are included. During the packaging procedure the progress is displayed (progress bar and/or item being currently packaged).
4. Redirection to metadata confirmation / modification page. The page is shibbolized – if the user is not already logged in to AAI he/she is authenticated now.
5. In a web page (see chapter 5.1.1), all automatically collected metadata information and default values are displayed in an editable form. The user may edit / review the metadata entries.
6. The user has two options (buttons):
   • Definitively submit to repository
   • Cancel submission
7. The user sees a final confirmation page depending on choice at step 6.

5.2.    Moodle Export Adapter

Parts of a Moodle course that should be exported to the external content repository:

++    mandatory
+    nice to have
-    not needed

5.3.    Ilias Export Adapter

Baseline for the ILIAS Export Adapter is ILIAS 3.10.

++    mandatory
+    nice to have
-    not needed

5.4.    Claroline Export Adapter

The table shows the Claroline modules that should be exported to an external repository.
The modules shown are the standard modules for Claroline 1.8.5.

++    mandatory
+    nice to have
-    not needed