Chapter 5: INVESTIGATING INTEROPERABILITY
6.2 The WHURLE Framework
WHURLE: Web-based Hierarchical Universal Reactive Learning Environment (Brailsford et al. 2001; Brailsford 2002b, a; Zakaria et al. 2002) is an online learning system designed to provide a discipline-independent framework, which is pedagogically flexible and is capable of providing adaptation. The adaptive components of the WHURLE architecture depend on one of Nelson’s original visions of hypertext, which is transclusion or conditional transclusion in the case of WHURLE. Transclusion consists of:
“dynamic inclusion of arbitrary components of one document inside the other” (Nelson [6] as cited in (Brailsford et al. 2001).
WHURLE implemented a simplified model of transclusion where the content is adapted to the needs of the user to create virtual documents that only the learner can view. The conditions respected in this context are the information stored in the user profile, which allows the creations of such documents dynamically to match the needs or
requirements of the learners. WHURLE was previously used to teach a Biodiversity module at the University of Nottingham.
6.2.1 WHURLE’s Architecture
WHURLE stores educational content in separate files called chunks. Lessons are created, by educators, to provide a default pathway in the Lesson Plan through the available chunks. In the lesson plan, a teacher defines a hierarchy of pages (each consisting of one or more chunks) that can then be navigated by learners. This default pathway is adapted to the needs of individual learners by reference to their user profile. WHURLE also provides a robust linking system, and automatically-generated navigation around the lessons.
The WHURLE framework was designed to be modular, separating the functions of adaptation and rendering. During parse time the system builds a node-tree from the lesson plan. This is then processed by the adaptation filter, a XSLT style-sheet that would implement the lesson plan against the user profile. The result produced by the adaptation filter would be then passed to the adaptation engine, which is also an XSLT style-sheet that renders the final output to be presented to the learner. In creating this output, the engine overlays the navigational system on the top of the learning content (chunks) in addition to a user’s interface that is described by the skin. The skin is an XML file which defines the appearance and any associated learning tools, links or resources. Finally the output document (the lesson) is a dynamic HTML document.
The concept of XML pipeline75 is fundamental to the WHURLE architecture and it is a:
75 Pipelining is technique that allows multiple requests to be sent out to a single socket without having to
“series of events generated at parse-time, that follow through a
predefined sequence of filters or processes”(Zakaria 2003).
It resembles the Unix pipeline which uses the outputs of one program as an input for another. Hence all the outputs of the XSLT transformation of the XML documents (described above) are passed to this pipeline and then to the display engine, all which occurs transparently where the learner receives only the adaptive virtual document. A conceptual description of the WHURLE architecture and how its components collaborate to produce the adaptation effects is presented in figure (6.1) while figure (6.2) shows a snapshot of one of WHURLE’s end documents as it appears to a learner, available in figure (6.3).
Figure 6.2: “The adaptation filter in WHURLE. A teacher creates a lesson plan that defines all possible content of a lesson. This is filtered according to the user model that makes use of information stored in the user profile. The output of the filter is rendered by the display engine and student interactions update the user profile”, taken from (Zakaria 2003).
6.2.2 The Limitations of WHURLE:
The WHURLE framework aimed to be modular to a large extent to allow easy modification of its architectural components. It was designed to be flexible and not tied to any specific user interface or user model. However, different implementations of WHURLE had their own issues and generally presented closed systems where the interdependencies between different components were significant and as a result limited the modularity as intended by the original framework. Nevertheless, the WHURLE framework was designed to take into account the technologies and demands of its time. Achieving interoperability of content or user profiles between different adaptive systems was not one of the design’s core objectives. In order for WHURLE to use content developed in other systems the external content or user profile needed to be converted to WHURLE’s own formats, as described in the MOT to WHURLE conversion (also see chapter 5, section 5.2).
WHURLE did not have any built-in collaborative learning tools but it provided hooks that allow the inclusion of external social tools (such as Forums) by specifying their URLs. Different implementations or versions had therefore enabled the use of a variety of tools such as Chat, Forum or News. However, the ability to integrate WHURLE (with its adaptation capabilities) into a popular LMS, which has a set of social tools in addition to other desired functionalities, would have been a very challenging task. This is due to different components being interconnected together including those which are responsible for preparing and presenting the output using the WHURLE’s interface. To conclude, WHURLE, along with the majority of AEHS, suffered from a number of issues that are not directly related to its useful adaptation functionality, but rather to its
architecture and implementations, which might have served their purposes at design time but became limited in the context of the current demands for e-learning. WHURLE 2.0, on the other hand, was designed to address those limitations and serve those demands.