Moodle SECTIONS Element Example

Processing Notes

  • Candidate mappings for a /MOODLE_BACKUP/COURSE/SECTIONS/SECTION elements:

    Target Service

    Notes

    Melete

    Map each SECTION to a Melete Module. Map each MOD to a Melete Section in that module where the Section contains a link to the corresponding Sakai object (assumes "direct" URLs can be crafted for any given mapped MOD). Or, collapse those Sections a single "table of contents" Melete Section.

    ContentHosting

    Similar to Melete mappings, but options are somewhat more open-ended since content can be placed directly in the top-level container. For example, could map each SECTION to a ContentCollection and each MOD to a UrlResourceType ContentResource therein. Or could create a "table-of-contents" HtmlDocumentType ContentResource for each SECTION, placing those resources at the top of the site's content tree, or in top-level ContentCollections to allow for the addition of other first-class resources to the mapped SECTION.

    Wiki

    Similar to previous two mappings, but where links to mapped MODs are added to Wiki pages representing each SECTION

    Nothing At All

    Since an obvious mapping from Moodle SECTIONS does not exist, attempting such a thing may introduce so much needless confusion.

  • Bi-directional dependencies exist between SECTIONS and the modules (/MOODLE_BACKUP/COURSE/MODULES/MOD) which they reference. For example, in order to construct a set of Sakai direct URLs to place on a "table of contents" HTML resource in content hosting it is necessary to first create the referenced objects. Conversely, Moodle modules frequently contain indirect references to other modules which point to /MOODLE_BACKUP/COURSE/SECTIONS/SECTION/MODS/MOD/ID rather than /MOODLE_BACKUP/COURSE/MODULES/MOD/ID. Furthermore, nothing necessarily prevents cyclic inter-module references such that module X cannot be completely mapped until the Sakai identifier of module Y is known and vice versa.
  • Since several options exist for mapping SECTIONS, it probably makes sense to map them to their own generic Importable type, rather than, for example, treating them explicitly as Folders during the archive translation process.
  • SECTION Importables must be processed after module Importables and the HandlesImportable responsible for mapping SECTION Importables must be able to resolve module references to Sakai objects. This can be accomplished by maintaining an in-memory or persistent lookup table, but HandlesImportable implementations would need to be modified (or hopefully just wrapped) accordingly to keep tha table up to date.
  • Module Importables will need to be mapped into Sakai in a dual-pass fashion. The first pass will create Sakai objects, replacing references to other module Importables with the appropriate placeholder values. The second pass will, with assistance from the mapped ID lookup table described above, replace those tokens with the appropriate Sakai URLs. In order to resolve mapped SECTION references, this pass must occur after HandlesImportables have already passed through SECTION Importables.
  • Ideally, the translation of Moodle modules into Importables can dereference inlined module pointers such that access to SECTIONs is not necessary during the HandlesImportable phase. This implies, though, that we need Moodle-specific Importable subclasses.

Example

    <!-- Moodle "sections" are collections of "resources" and "activities." They provide, for example, 
         sequenced interaction with otherwise unstructured course resources (weblinks, files, SCORM 
         packages, etc). For (limited) examples see http://docs.moodle.org/en/Course_sections. -->
    <SECTIONS>

      <!-- An example of a section consisting entirely of a forum "module", the complete
           definition of which appears in
           /MOODLE_BACKUP/COURSE/MODULES/MOD[MODTYPE = "forum" and ID = "11"] -->
      <SECTION>
        <ID>58</ID> <!-- A key for the section itself -->
        <NUMBER>0</NUMBER>  <!-- A section ordinal. This particular sections illustrates a "news forum"
                                 section, which I believe is implicitly created as the default (zero)
                                 section in Moodle courses. The concept of ordering should be preserved
                                 in some fashion in Sakai, regardless of the objects onto which 
                                 SECTIONS are mapped. -->
        <!-- Note that we have entity-escaped HTML markup in SUMMARY, as well as a "macro": $@FILEPHP@$.
             Presumably, this macro should typically expand in Sakai to the base of an Access Servlet URL, or a 
             Sakai-equivalent macro (does such a thing exist?). 

             But... Sakai does not support image refs as resource names. Unfortunately, there is no other 
             field which might serve as the "title" of the section. Therefore, when handling this field, 
             logic should strip all markup and produce a default name, possibly based on the section's ID or 
             ordinal, in the event markup scrubbing resulted in an empty string. Also, it is difficult to 
             imagine a need for any macro expansion in SECTION SUMMARY fields when mapped to Sakai, so those 
             values should be similarly stripped.

             We have seen other examples of SECTION SUMMARY fields which contain arbitrary HTML anchors, which allow
             module content to construct SECTION URLs. We cannot allow such markup to remain in Sakai-mapped
             objects, but depending on the type of Sakai-mapped object, we may still be able to construct
             direct URLs to mapped SECTION objects in the second pass of the {{HandlesImportable}} phase. -->
        <SUMMARY>

&lt;p align=&quot;center&quot;&gt;&lt;img src=&quot;$@FILEPHP@$/banners/conartbanner_00.jpg&quot;&gt;&lt;/p&gt;
</SUMMARY>
        <VISIBLE>1</VISIBLE> <!-- On-screen visibility, presumably. Why not a boolean? If mapping to a Sakai
                                  resource, could hide or skip the resulting object. Probably a low-value mapping, 
                                  though. -->
        <MODS> <!-- Seems to be a collection of references to resources and activities, i.e. "modules" -->
          <MOD> <!-- Schema seems to be consistent across all values of ./TYPE -->
            <ID>24</ID> <!-- Seems to be a key for the MOD _reference_ -->
            <TYPE>forum</TYPE> <!-- Correlates with /MOODLE_BACKUP/COURSE/MODULES/MOD/MODTYPE --> 
            <INSTANCE>11</INSTANCE> <!-- So, complete module def is at 
                                         /MOODLE_BACKUP/COURSE/MODULES/MOD[MODTYPE = "forum" and ID = "11"] -->
            <ADDED>1109616181</ADDED> <!-- Timestamp -->
            <DELETED></DELETED> <!-- We see this field in 1.5.3+ archives, but not 1.6.1. Presumably, if 1 or true, skip the
                                     SECTION. May be difficult, though, if references still exist in module content. -->
            <SCORE>0</SCORE>  <!-- Presumably a grading scale of some sort. Unsure of Sakai mapping. -->
            <INDENT>0</INDENT> <!-- Presumably UI layout information. Probably skipped in Sakai mapping -->
            <VISIBLE>1</VISIBLE> <!-- Presumably UI layout information. See ../../../VISIBLE. Probably another low-value mapping. -->
            <GROUPMODE>0</GROUPMODE> <!-- Actual meaning of '0' is unclear. But apparently Moodle allows each "activity" to define 
                                          group-related behaviors, or for course-level behaviors to either default or
                                          override those activity-level configurations. The English names for available group modes
                                          are No groups, Separate groups, and Visible groups. Presumably '0' would correspond to
                                          "No groups". See http://docs.moodle.org/en/Groups. So far, the value of this field
                                          doesn't seem to have an impact on corresponding module descriptors. Hopefully, this
                                          is another low-value mapping since I'm very much unclear on correct handling. -->
          </MOD>
        </MODS>
      </SECTION>

      <!-- An example of a section consisting of a quiz module and a resource modules. Both
           modules are defined in more detail by /MOODLE_BACKUP/COURSE/MODULES/MOD instances.
           Field semantics are identical to those in the previous SECTION, except where noted. 
           Sequencing within a SECTION seems to be implicit.  -->
      <SECTION>
        <ID>59</ID>
        <NUMBER>1</NUMBER> <!-- Presumably sequenced _after_ the news forum above since 1 gt 0 -->
        <SUMMARY>Mixed Content Section Summary</SUMMARY> 
        <VISIBLE>1</VISIBLE>
        <MODS> 
          <MOD>
            <ID>25</ID> 
            <TYPE>resource</TYPE>
            <INSTANCE>38</INSTANCE> <!-- So, complete module def is at 
                                         /MOODLE_BACKUP/COURSE/MODULES/MOD[MODTYPE = "resource" and ID = "38"] -->
            <ADDED>1108244959</ADDED>
            <DELETED></DELETED>
            <SCORE>0</SCORE>
            <INDENT>0</INDENT>
            <VISIBLE>1</VISIBLE>
            <GROUPMODE>0</GROUPMODE>
          </MOD>
          <MOD>
            <ID>28</ID>
            <TYPE>quiz</TYPE>
            <INSTANCE>16</INSTANCE> <!-- So, complete module def is at 
                                         /MOODLE_BACKUP/COURSE/MODULES/MOD[MODTYPE = "quiz" and ID = "16"].
                                         That module def only contains quiz metadata (release schedule, grading parameters etc).
                                         Questions are defined as a pool by /MOODLE_BACKUP/COURSE/QUESTION_CATEGORIES and
                                         included in quiz modules by reference. -->
            <ADDED>1104683711</ADDED>
            <SCORE>0</SCORE>
            <INDENT>0</INDENT>
            <VISIBLE>1</VISIBLE>
            <GROUPMODE>0</GROUPMODE>
          </MOD>
        </MODS>
      <SECTION>

      <!-- A summary-only SECTION. Don't think these need to be mapped to Sakai. -->
      <SECTION>
        <ID>64</ID>
        <NUMBER>6</NUMBER>
        <SUMMARY>This section has no content</SUMMARY>
        <VISIBLE>1</VISIBLE>
      </SECTION>

      <!-- A completely empty SECTION. Don't think these need to be mapped to Sakai. -->
      <SECTION>
        <ID>65</ID>
        <NUMBER>7</NUMBER>
        <SUMMARY></SUMMARY>
        <VISIBLE>1</VISIBLE>
      </SECTION>

    </SECTIONS>