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 MeleteSection
in that module where theSection
contains a link to the corresponding Sakai object (assumes "direct" URLs can be crafted for any given mapped MOD). Or, collapse thoseSections
a single "table of contents" MeleteSection
.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 aUrlResourceType
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-levelContentCollections
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 asFolders
during the archive translation process. - SECTION
Importables
must be processed after moduleImportables
and theHandlesImportable
responsible for mapping SECTIONImportables
must be able to resolve module references to Sakai objects. This can be accomplished by maintaining an in-memory or persistent lookup table, butHandlesImportable
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 moduleImportables
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 afterHandlesImportables
have already passed through SECTIONImportables
. - Ideally, the translation of Moodle modules into
Importables
can dereference inlined module pointers such that access to SECTIONs is not necessary during theHandlesImportable
phase. This implies, though, that we need Moodle-specificImportable
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> <p align="center"><img src="$@FILEPHP@$/banners/conartbanner_00.jpg"></p> </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>