An e-learning system for standard compatible and uniform course development.

This article introduces the architecture and implementation of an authoring system capable of modular and standard compatible course development. This system enables the aggregation of learning objects into higher course structures and reuse in different learning scenarios. The concept of modular course development is based on the construction kit metaphor for e-learning systems that represents a general solution for specific content creation and publishing. The learning objects are implemented as IMS Content Packages containing a special asset coded in XML. The XML document consists of the semantical content of learning objects without defining a specific format and layout. The authoring system facilitates the composition and aggregation process of learning objects for designing standard compatible and uniform courses used by instructors and students through Learning Management Systems (LMS).

INTRODUCTION

Today, there is an ever increasing demand for multimedia online courses, scientific curriculums, and learning units; a wide range of e-learning content to help students and professors in higher education has already been developed. Professors use multimedia courses in their lectures to convey complex topics while students use them online to increase their knowledge or explore materials in detail. In most cases, however, the content already developed can neither be reused by other authors nor used in an interdisciplinary manner. This is because authoring tools, such as Macromedia Authorware, Macromedia Dreamweaver, Click2Learn Toolbook, or LRN Toolkit do not support the development of modular learning objects as Hodgins (2002) or Wiley (2000) have introduced. With these systems, it is not possible to take learning objects and to put them together like LEGOs. The reason is that most authoring systems do not provide modular course structures that allow the user to extract parts of the course and combine them with other courses. Although many tools, such as LRN Toolkit, provide export filters using IMS Content Packaging (IMS, 2002), their results cannot be merged to build consistent and uniform courses that can be reused in an interdisciplinary manner. This is caused by the lack of separation between the definition of the content and its representation.

Imagine a basic mathematics course on complex numbers: For example, an online course in the field of machine dynamics requires knowledge of complex numbers for the explanation of Harmonic oscillations. In additon, the basic courses, mathematics for engineers and technical computer science, require complex numbers to enhance the topic exponential function, sine and cosine in the complex plane. No authoring tool supports a simple integration of content written by different authors or generates a consistent visualization of them.

In order to address this problem, the project Math-kit (1) (Unger, Oevel, & Mertsching, 2002; Mathkit, 2004) developed the Math-kit authorware, which consists of the authoring system Lyssa and the platform CKS (Construction Kit Server), for the creation of technical and modular learning units for interdisciplinary use in higher education. This authoring system enables the development of semantical learning units without definining style or layout. Due to the strict separation of style and layout, authors can use learning units developed by other authors and integrate them into their own courses. This enables the transformation of each course into a specific format with an individual layout definition. Moreover, learning content already available and based on authoring tools such as Microsoft Word or Latex can be integrated easily. For this purpose, special import filters are included to provide a mapping of the content of the documents to the course structure of the authoring system.

During the development of the system, the metaphor, a construction kit (Bungenstock, Baudry, & Mertsching, 2002), was used; this provided both authors and software developers with a common understanding of its architecture and usage. In this metaphor, reusable learning objects (RLO) (Wiley, 2000; Hodgins, 2002; Heng, 2003; Downes, 2000) resemble bricks in a conventional construction kit, which can be reused in different contexts and education scenarios. The metaphor covers the process of development, composition, and publication of modular e-learning content and also solves problems arising from the combination of bricks, like the consistent composition of course structure and presentation.

This system has been used effectively within the joint project mathkit at the German universities of Hamburg (2), Bayreuth, Hagen, and Paderborn. At these universities, several mathematics learning units were developed and integrated into courses including disciplines like mathematics for mechanical engineering, mathematics for computer science, technical computer science, and the correspondence course, linear algebra.

First, this article describes the bases of the construction kit approach and how the authoring system Lyssa was implemented. Second, it provides an example of modular and standard compatible course development.

THE CONSTRUCTION-KIT METAPHOR

During the software engineering process, metaphors are used by the developer team to get a better and more uniform understanding of a particular problem that a software system should be capable of solving. Metaphors of this kind also support the communication between users and developers.

During the design phase of the Math-kit system, the metaphor of a construction kit was used. A conventional construction kit consists of bricks, models, and sometimes construction plans. Bricks can be assembled to form different models. The organization of these models may be described by a construction plan, which helps a user to understand the complex structure. The construction kit itself stores the bricks, models, and plans. With reference to the e-learning system Math-kit, the terms of the construction kit metaphor for e-learning systems can be described as follows: The bricks resemble learning objects (LOBs), which can be integrated into courses. These are the smallest units for exchange and are independent from each other. The models are course objects (COBs) consisting of learning objects and of other course objects. The construction kit resembles the Math-kit system administrating the dynamic behavior, which includes the search or archivation of LOBs and COBs.

The technical realization of bricks and models was inspired by the sharable content object (SCO) of the SCORM standard (ADL, 2004). In brief, an SCO represents a collection of various resource files (the assets) and is the smallest learning unit of a Learning Management System (LMS). An SCO is defined as independent unit to be reused in different learning contexts and communicates data by an LMS via specified application program interfaces (APIs). It uses the IMS content package mechanism for the bundling of course structures, resource files, and metadata into a single file (the manifest). SCORM offers two types of content packages; resource packages and content aggregation packages. The resource packages only contain asset files such as images or videos. In contrast, content aggregation packages contain other resource or aggregation packages, so that higher-level structures like lessons, learning units, or complete courses can be built.

In the construction kit metaphor, resource packages are used to define the LOB, whereas COBs are realized as content aggregation packages. Although the SCO approach meets the demands for content interchange and execution with applications it does not support the separation of content and view, which is one of the essential goals of Math-kit. Therefore, an LOB has the same structure as a resource package with one exception and special asset: a document file based on the Extensible Markup Language (XML) (W3C, 2004). The need for such a content separation was also considered by the SCORM Dynamic Appearance Model (Canadian Department of National Defence, 2002). However, since it mainly focuses on the common appearance of the navigation, it does not meet the requirements of the Math-kit project.

ARCHITECTURE

Roles

Roles are necessary for modeling different views of the Math-kit e-learning system. It is important to understand that a person can appear in several roles. The roles help to model the static and dynamic behavior of the system with different use-cases and sequential diagrams (Bergner, Rausch, & Sihling 1998) in order to gain a strict and controllable development process. The roles defined within Math-kit are the following: instructor, student, composer, LOB developer, publisher, and administrator.

* Instructor: The instructor uses single blocks or complete courses to extend his/her own lectures or to create new ones. Important operations for this role are searching, archiving, and presentation of courses and LOBs.

* Student: This role requires similar operations albeit for another purpose. Individuals in this role want to learn something and are able to explore the entire database using LOBs and courses of interest. These two roles are not directly dependent on the construction kit metaphor because they work with Math-kit through an LMS or access the courses with a simple Web browser. Nevertheless, the construction kit is the basis of the created content.

* Composer: The composer combines existing LOBs and courses to build new ones. Useful operations of this role include the search for LOBs, their combination, preview, and editing. This role creates and edits the content package. In relation to the construction kit metaphor, the composer defines the construction plan.

* LOB developer: The LOB developer designs and implements new LOBs. This role consists of the collection and assemblage of images, text, and animations into LOBs. In the view of the metaphor, the LOB developer merely creates bricks containing semantically defined learning content based on XML.

* Publisher: The publisher translates semantically defined LOBs into a readable format. The main operations of the publisher are the definition or the selection of particular layouts and the compilation of the source document into a destination format.

* Administrator: The administrator installs basic packages and software for the construction-kit. The main task is to help the other roles and to act as troubleshooter. Further important operations are maintenance, consultation, and user administration.

A small example should clarify the relationships between the roles. Imagine a professor intending to extend and existing lecture in electrical engineering with a multimedia course and exercises. The first role will be that of the composer. Math-kit offers a wide range of content and, at best case, most of the required themes are available. If some content is missing or needs to be adapted, the professor takes on the role of the LOB developer. For instance, the LOB developer is able to enhance the technical content of the course by integrating mathematical content acquired from a colleague and not yet stored in Math-kit. Figure 1 illustrates the roles of creating a course for electrical engineering.

After the course has been completed, another person, e.g., a scientific assistant, takes over the role of the publisher. The university emblem or any other stylistic features such as font, background color, or page size can be adjusted. The product, a viewable document in a prefered format, can then be used by the professor--in the role of instructor--in the lecture to illustrate complex themes with animations. If students do not understand all points of the lecture, they can read the complete course at home online. Moreover, intructors can build more substantial courses with exercises, exploration tools and animations. If students require more detailed information, for example about complex numbers, they will be able to access the entire content database. Additionally, the student is able to work through special exploration units also provided by the professor. The role of the administrator does not appear in this example since this role is only intended as support for the other roles.

Construction Kit

Understanding the realization of the construction kit requires a look at its architecture (Baudry, Bungenstock, & Mertsching, 2002a). Students usually use online courses through an LMS such as ILIAS (2004), LON-CAPA (2003), or Blackboard (2003). An LMS provides different categories, e.g., communication with other students, distribution of solutions for exercises that accompany lectures, work through courses, or use of multiple choice tests in order to check individual learning progress. The courses can be created with the help of authoring tools, e.g., Macromedia's Authorware (Macromedia, 2005) application. Tools like these, however, can only be used for universal content creation. They provide solutions for quizzes or enable the author to adjust predefined design properties. Within the Math-kit project, a special mechanism for the definition of individual learning content is required. On the one hand, LOBs should be combined and transformed into individual courses. Therefore, an authoring tool must provide for the possibility of defining LOBs without any style definition. On the other hand, different output formats should be provided as well. Consequently, it would seem that, for example, an abstract mechanism for the definition of equations is required.

[FIGURE 1 OMITTED]

Starting from these facts, an arbitrary LMS or Web browser is used to provide the content of Math-kit. This enables students and instructors to use their favorite Web browser to work through the courses or to select a special course block for presentations within lectures. In order to meet our requirements, however, the process of content creation must be supported by special tools. According to the role concept, the LOB developer, the composer, and the publisher are experts in content creation and each of them has a specific tool. In relation to our construction kit approach, these tools work with a server storing COBs and LOBs.

Therefore, the CKS is an important extension of an existing LMS for individual content creation. Figure 2 illustrates an e-learning system consisting of an LMS and Math-kit components, which truly forms a contruction kit. The tools are divided into two groups: The first one is distribution and the second is development. The development tools are used for the production of COBs that will be distributed to instructors and students. The tool for the LOB developer creates new LOBs that can be stored into the CKS. It enables the developer to create or modify the XML document easily by integrating new assets, for instance, images, text, or applets.

[FIGURE 2 OMITTED]

The developer works with a copy of the original LOB file stored in the construction kit server. When the LOB is saved, the client works with its own copy of the LOB merged with the original file. A separate authoring tool is available for the composer role. This tool helps in the process of combining LOBs to create COBs. Therefore, a manifest file containing the structure of the course has to be created. In relation to the construction-kit metaphor, the manifest file resembles the construction plan.

Another tool is available for the publisher for transforming COBs into courses that can be stored into different LMSs. With the help of this authoring tool, an individual design and layout can be defined. The CKS uses transformers generated by the tool of the publisher to transform a COB into a special output format like a PDF. The publisher may opt to choose a pre-defined layout, modify an existing layout, or define a new layout.

The consumers of the learning content do not pay attention to the CKS. They only have to access an LMS to work through courses or to use single LOBs for lectures. If no LMS is available, Math-kit offers the possibility of accessing the content with simple browsers.

REALIZATION

This section describes the basic concepts of the authoring system derived from the role definition of the construction-kit metaphor. These results lead to an application called Lyssa (3) (Bungenstock, Baudry, & Mertsching 2003) that is responsible for the creation of bricks, their combination to models, and their publication.

LOB Development

Editing XML Content

The first step in creating new e-learning content is to aggregate different files of different types into single bricks. For best results and media independent production, it is recommended that the described XML templates to create LOBs be used (Baudry, Bungenstock, & Mertsching, 2002b; NetQuest 2003; Wollowski, 2002; Kohlhase, 2002). For the LOBs used in the Math-kit project, an XML-scheme facilitates the development of mathematical content. The resulting markup language is called MathkitML and is divided into three groups of elements: structure, mathematics, and multimedia. The structure element group comprises tags for the definition of, for example, itemization, enumeration, or table environments. For the mathematical group, elements for definitions, theorems, proofs, lemmas, and equations are available. The last group contains a collection of elements for the definition of multimedia objects such as images, audio streams, video streams, or quiz environments. However, MathkitML does not support tags for the definition of books, chapters, or sections in the way DocBook (Walsh & Muellner, 2002) does. This decision was made in accordance with the design goals of Math-kit, which are granularity and reuseability. Standards such as IMS content packaging have defined the structure of courses separately so as to make sections and chapters exchangeable. Consequently, sections and subsections should not be defined in the XML document but rather in the COB.

Integration of Course Material

The integration of existing e-learning content and documents into new online courses is a fundamental problem within the development of modular courses. Although there is a wide range of authoring tools such as Macromedia Autorware, Macromedia Dreamweaver, or Microsoft Word, each has its individual concept, technical realization, and data format. The extraction of text and structures is exceedingly difficult and is impossible in Macromedia Authorware. The main problem is caused by the combination of structure, layout, and content. For the partial reuse of content, the structure of the document must be separated from its content. However, most authoring systems do not support such a dispartment. For instance, Microsoft Word has its own hidden data format, which cannot be reused by other programs and does not support the extraction of the document structure.

In order to facilitate the course development process, Lyssa supports the integration of existing materials like Microsoft Word, DocBook, or Latex. Therefore, documents must be converted into modular COBs. Figure 3 illustrates several components and files involved in the brick creation process. On the left side, some programs for content creation and their related output files are shown. These files are converted by associated loaders of the document processing framework. The loaders use the document framework for the creation of modular COBs that can be used in a myriad of situations. On the right side, COBs can be aggregated and published in the desired standard format by Lyssa.

Course Development

Where a set of LOBs is available, they can be combined or aggregated into higher structures--the COBs. The construction kit metaphor calls it a model, but for a particular use names like course, chapter, or section are more appropriate. For consistency, the following explanation uses the term model. Figure 4 illustrates the process of model creation. An abstract view on the aggregation process is shown in a). Lyssa reads several bricks and aggregates them into one model. An important aspect of the definition is the recursive use of models. Bricks can be combined in the same way as models. This allows an individual structure of the contents and offers several possibilities of reuse. It then becomes possible to create LOBs, structures, chapters etc. with less effort. The process with internal structure details is shown in b). In this illustration, a tree is used inside Lyssa for the arrangement of different bricks and models, although every other kind of relationship, e.g., list and net, is conceivable. These different data structures influence the appearance and the sequencing of the same content. For this reason, Lyssa uses one independent list of all bricks included and allows the definition of several navigation paths.

[FIGURE 3 OMITTED]

[FIGURE 4 OMITTED]

Course Publishing

The models or COBs, however, cannot be accessed by students or instructors since the content is written in XML and neither style nor layout is defined. For this purpose, Lyssa includes a document processing framework called Nyx (Baudry, Bungenstock, & Mertsching, 2003). This transforms the LOB and COB packages into consistent online courses that can be integrated into learning management systems, like Blackboard or ILIAS. These courses can also be viewed by standard compatible course browsers, such as Microsoft LRN Viewer, supporting both the IMS content package and SCORM standard.

The creation and distribution of uniform e-learning content is an important aspect of the Math-kit project. To meet this demand, Lyssa provides an easy mechanism for the definition or adaptation of presentation formats, layouts, and styles. The style and layout rules are stored separately in a package called Transformation Package, which contains all necessary files and settings that are used for the presentation. The concept of transformation packages enables professors to use many different output formats by only selecting a specific package.

In addition, the packages can be configured by a set of plugins for special tasks such as the conversion of different representations of equations to achieve a consistent and uniform presentation. Figure 5 illustrates the framework, configured with two transformation packages: one for HTML and the other for the PDF generation. A plugin is also available to convert formulas into images or MathML.

[FIGURE 5 OMITTED]

To develop such a framework, it is necessary to analyse the possible output formats. The Math-kit project uses HTML and PDF, which differ in format, usage, and technique. For example, an HTML document consists of many linked assets; a frameset consists of many HTML documents. A PDF document, in contrast, is a single file in which images are integrated as binaries. Additionally, PDF documents are useful for presentations in lectures and printing and for allowing students to browse HTML documents online. Generating these documents is entirely different. For instance, to build a PDF document in the field of mathematics, a pdflatex compiler is required.

In the case of HTML courses, a frameset is needed to display a separate navigation site. To make Lyssa independent of output formats, data necessary for the transformation process are stored separately in transformation packages. The transformation packages consist of a configuration file, transformers, and resources. The configuration file stores important settings needed for the transformation process. For instance, it has a flag, which decides whether or not the output is SCORM compatible. It also specifies tasks supporting the initiation and finalization process of the transformation. With these, format dependent actions, such as the execution of pdflatex, can be started. Two transformers based on XSL stylesheets (W3C, 2004b) or Java classes are also contained to transform the XML content of the LOBs and the course structure of the COBs to build the course. The transformation package contains resources like images needed by specific layouts and styles. With such a strict separation, a course layout change can be achieved by changing a transformation package.

Mathematical formulas in Math-kit

As mentioned above, the focus of the Math-kit project is on the creation of mathematical content. Many formulas and equations are required for these courses. Their definition and presentation, however, is not consistent, because there are several ways to define equations; these include MathML (W3C, 2002) and Latex. Due to the demands of the project Math-kit, MathML is a good solution for formula presentation because it is based on XML and various applications, such as OpenOffice, support MathML. Unfortunately, only some browsers, e.g., the Mozilla browser, are able to support MathML in a satisfactory way. This is why most online courses use images for the presentation of equations. In order to close this gap, Lyssa uses the plugin mechanism that makes it possible to analyze the XML template before it is translated. With reference to the equation example, the author be able to choose the procedure for equation processing.

Course Processing

For the transformation process of the COB packages, it is necessary to analyze their structure. They consist of a set of physical resource files and a special file called manifest. It stores the course structure and handles the connection between structure and content files. These connections are declared as resource entries in the content package and define the type of the resource. Inside a COB package _ remember that COBs can be nested with other COBs and LOBs _ type attributes are used to distinguish between four types of resources described as follows:

* Web content: the webcontent attribute indicates ordinary HTML, JPEG, or MPEG files.

* Template: indicates XML data storing style-independent content.

* LOB: the LOB type indicates an LOB package that is equivalent to a brick in the construction kit metaphor.

* COB: the COB attribute indicates a COB package that is stored inside a package.

To tranform a COB package, the resource entries must be analyzed and, depending on their content type, an action must be chosen. If a Web content resource is found, it will be copied to the transformed course. If an XML resource is found, a transformer is used to convert the content. In the case of a COB or an LOB resource, the analysis process must be repeated recursively. For a common course, it is sufficient to merge the structure and the resources of each COB and LOB package into one course. Figure 6 illustrates an example of nested COBs and LOBs. COB A determines a course structure consisting of two sections and encapsulates LOB 1 and COB B. Both section 1 and section 2 hold a reference to an associated package. LOB 1 represents a brick consisting of an XML-document and an image. In contrast, COB B resembles a model containing another package labelled LOB 2 albeit only one section. LOB 2 itself represents a brick that contains only one XML document.

Lyssa

After the conceptual description of the tools required in the development process, this section presents their implementation. As mentioned above, the tools are combined in one application called Lyssa that offers a wide range of operations to work with bricks and aggregations.

In most cases, users will interact with the graphical user interface (GUI); a mode for batch operations is also provided. The GUI mode is very intuitive, and many tasks can be performed by drag'n'drop. Views are one of the main concepts concerning this mode. A view is a certain window showing all values and operations a task requires. The details of a view can be extended or reduced so that only the important informations is shown. It is possible to get a complete standard compatible package by selecting only a few files. More extended views allow more sophisticated operations so that experts see an application offering access to all elements and attributes of present e-learning standards. The batch mode supports the work with repeating tasks. It allows the execution of scripts written in Python (an object oriented script language) and does not need the GUI. This offers the use of Lyssa in several use-cases. Figure 7 illustrates the GUI mode after Lyssa has been started. The window is divided into three parts: the workbench on the left, the desktop on the right, and the tool bar on top. The workbench supports the whole file handling and is the place where the bricks and models are stored. In normal cases, the workbench contains the four directory entries Courses, Learning Objects, My Home and System. My Home is mounted to the user's home directory and System allows viewing of the drives in the user's operating system (e.g., A;, C: for Windows and/for Linux).

[FIGURE 6 OMITTED]

The mount mechanism is a special feature that allows the mounting of zipped files, Windows shares, and several network file systems. Cooperating authors can share their bricks and models over the network without seeing a difference. All they have to do is remount the folders, courses, and LOBs to the desired network file systems.

Another benefit of the mount mechanism is the transparency while traversing inside models. An opened model does not appear as several separate bricks but as a seamless structure. Lyssa automatically mounts all descending bricks and a model acts independently of the depth as one structure. This behavior makes work easier, particularly maintenance and extension tasks.

Operations on all files are called either by a right mouse click on the tool bar or the menu bar. The pop up window of a right mouse click is context-dependent and contains all commands for one file. The menu bar contains many important commands, although not all of them. The tool bar only offers operations that are used frequently. Most of the operations open a new window on the desktop. This behavior facilitates the system's use, particularly maintenance and window control tasks.

Views

As mentioned above, Lyssa offers different detailed views of the work with its bricks and models. This supports an efficient workstyle, and at the detail level of bricks and models, no influence of the standards is sensitive. It is also possible to edit standard files of other systems including all detailed elements and attributes. In contrast to other products, Lyssa does support features like recursive manifests and multiple organizations.

[FIGURE 7 OMITTED]

Window a) in Figure 8 illustrates the view of the work with bricks. This view consists of a file browser, making it possible to store every file desired in the brick and a start file selector. Each brick has its own file system that can be navigated by clicking on folders, files, and the Folder Up, New Folder, and Top buttons. However, the "navigation to" files stored in the file system cannot be accessed. Therefore, the drag'n'drop feature for moving or copying files from one brick to another, as well as from other file systems, is available. Specific file formats like the XML source file can be added to a brick with a context menu. One file must be declared as the entry point of this brick.

This means that the file chosen by the Start File selector will be identified as the file containing the content of this brick. In this example, it is the export.xml file referring to an image labelled export.jpg. The brick view hides the complex features proposed by the IMS content packaging specification and presents only the functionality required for the production of bricks. If a file is dragged from the workbench and dropped on the file viewer, all values required by the standard will be set automatically. In the case of the export.jpg image, the type value of the IMS content package is set to webcontent. In contrast, in the case of the document.xml file, the type value template denotes the brick for a later translation process by the framework.

Models are edited with a view as illustrated in Figure 8, window b). The organization or course structure is shown in the upper tree. Models can be built with several bricks shown in the lower table associated with one or more items. To offer a convenient composing process, Lyssa allows dragging bricks and models from the workbench or out of other models and droping them into the tree widget. A new item with reference to the brick or model will be added, and only its name remains to be specified. Figure 9 illustrates the fully supported view of the IMS content packaging specification. First of all, a model contains one or more organizations. An organization describes the structure and the navigation for the included content. In this example, the model has two organizations Organization00 and Organization01. A tree is used to arrange the items for a course about design patterns (a software engineering technique). An item resembles a reference to a brick with a specific title. The root node of the tree, for example, references brick Brick00 and is titled Design Patterns.

[FIGURE 8 OMITTED]

There are two ways to create these items: Either a brick is dropped onto the tree, or the command New Item from the context menu is chosen by a right mouse click on an existing item.

All references and titles can be changed by a double click. This is because existing standards do not arrange different resource types such as brick and model. Hence, bricks and models are saved in the same format for content packages, e.g., IMS content package or SCORM. Each content package contains the used files, which are shown in the left tree. The Manifest tab next to the File tab switches to the manifest structure. A manifest can contain other manifests, but this is a special feature and is rarely used.

[FIGURE 9 OMITTED]

Export

Lyssa comes with an export feature supporting the publishing process (illustrated in Figure 10). With the export window, an author determines the course that has to be translated. In the settings area, the transformation package responsible for the generated output format and layout must be chosen. The table contains the active and non-active processors required by the processing framework for modifying XML content. The output field contains the output directory or file, which stores the translated course ready for import into an LMS.

After all necessary settings have been determined, the translation process can be started by pushing the export button. By doing so, information about the translation process is written into the message area. If errors (e.g., XML parser errors) occur during the transformation process, they will be shown in the message field.

As mentioned above, the information about generating the output format is stored in the transformation package separately. The modification of these settings is only necessary if a new format is developed or its layout is to be modified. For this purpose, an additional tool is available for browsing the resources, setting up the package, and modifying the transformers.

The Construction-Kit Server (CKS)

The CKS is an important aspect of the construction kit metaphor; this allows users to share COB and LOB files with other users while developing them. The server supports several access possibilities, like Web browsers, Windows Explorer, or Lyssa itself. With Lyssa, it is possible to establish a connection to the server, select an LOB or COB file of interest, and open it directly with the authoring client. This can be done since Lyssa implements the WebDAV (Network Working Group, 1999) protocol, which is also provided by the CKS. Therefore, any applications implementing the WebDAV API are capable of accessing the files stored in the CKS.

[FIGURE 10 OMITTED]

An important aspect of the server is the locking support. When a brick is opened by a content developer, no other user is able to open it. The file will be unlocked after all necessary changes are made and the brick is saved. This mechanism handles the file communication and ensures that no data will be lost. Another benefit of the CKS is that each file has a version property, allowing a developer to access an earlier version of the brick. This is of special importance in a cooperative work environment.

EXAMPLE COB

This section presents an example introducing the development process of bricks and models. The first step in creating reusable learning material is to determine its granularity. The content should be verbalized coherently, and independently of other modules. This means that there should be no reference to an LOB, which is not part of itself. Where there is a dependency that cannot be resolved, the LOB must be aggregated with a superior COB or model to preserve its reusability.

Next, the example deals with the topic of complex numbers (Thiere, Padberg, & Oeve, 2003). A reusable COB that explains the foundations of complex numbers should be developed. Such a COB can be integrated into various technical course materials, like mathematics for mechanical engineering or mathematics for computer science. One aspect of the complex numbers deals with the topic Euler formula and polar coordinates illustrated in Figure 11.

Bricks can be coded with the brick modeling language MathkitML. Several tags such as paragraph, itemize, or table are available to formulate learning content. However, the document processing framework provides a mapping mechanism that offers the possibility of reading other document formats as well.

With the brick view of Lyssa, the XML file can be created and coded. The result is an LOB file containing both the XML file and IMS manifest. Next, the LOB file must be referenced by the item, Euler formula and polar coordinates, within the model view, as illustrated in Figure 12. It shows the structure of the foundation course labeled basics.cob. The items of the course structure referencing a set of bricks are arrangeable in several ways.

The COB produced has a coarse granularity and can be integrated into lectures or online presentations for self-study access. There are several possible combinations with other COBs. Examples include motivation, general or specific exercises, exploration environment, or extra information. If the course will be used by students for self-study, a basics object must be combined with the exercise or exploration COB. In contrast, the motivation COB can be used in lectures. Figure 13 illustrates the lecture course rendered in HTML.

[FIGURE 12 OMITTED]

[FIGURE 13 OMITTED]

The navigation on the left was generated recursively with the manifest of the bricks and models. For the integration of the course into an LMS, a manifest file representing the course is also available.

A transformation package can be utilized to render a PDF in order to obtain a format that is more usable for presentation in lectures or for printing purposes.

In the case of the PDF format, the transformation package maps the course structure defined in the manifest files to bookmark entries, as illustrated in Figure 14. It should be mentioned that the use of features like Java-Script within a PDF is also possible. Lyssa takes advantage of the link and Java-Script support provided by the PDF format. This enables the use buttons and links to reference applets. In addition, it makes it possible to generate quizzes.

CONCLUSION

This article has presented the architecture and the implementation of the authoring system Lyssa. It supports lecturers in the development process and enables the reuse of existing LOBs with the goal of creating uniform courses. In contrast to other authoring systems such as Authorware, Lyssa provides a mechanism for the semantic definition of granular LOBs, which can be integrated seamlessly into any course structure. Using the construction kit server, many authors are able to share semantic LOBs without modifiying them for presentation. The example of complex numbers has shown that content developers can work together effectively and use the foundation object Euler formula and polar coordinates in several higher courses such as mathematics for engineers and technical computer science.

[FIGURE 14 OMITTED]

The architecture is based on the construction kit metaphor for e-learning systems, which gives authors and developers a common view of modular course design and implementation. Additionally, the role concept helps system and content developers, as well as professors and students, to associate general tasks.

Summarizing our considerations, the authoring tool Lyssa brings together the three developer roles of brick developer, composer, and publisher in the implementation of one single application. The concepts of each role were discussed separately before the tool Lyssa was presented. With Lyssa, the content developer is able to take on the different roles and to perform specialized tasks. The Universities of Hamburg, Hagen, and Paderborn use Lyssa for the production of reusable COBs, developed in the field of mathematics, computer engineering, and mechanical engineering, with remarkable success (Bauch & Unger, 2003).

In the future, improved support of meta data will be added, enabling the construction kit server to provide search algorithms for the locatation of COBs and LOBs. Additionally, the server will be connected to the document API to provide on demand presentations through the Web server.

References

ADL (2004). Sharable content object reference model (SCORM). Retrieved June 12, 2004, from http://www.adlnet.org/downloads/70.cfm

Baudry, A., Bungenstock, M., & Mertsching, B. (2002a). Architecture of an e-learning system with embedded authoring support. In M. Driscoli & T. C. Reeves, E-LEARN 2002--World Conference on E-Learning in Corporate, Government, Healthcare, & Higher Education, 110-116.

Baudry, A., Bungenstock, M., & Mertsching, B. (2002b). Ein multimediales Rahmenwerk fur die Mathematiklehre nach der Baukastenmetapher. In K. P. Jantke, W. S. Wittig, & J. Herrmann, Von e-Learning bis e-Payment. Das Internet als sicherer Marktplatz (LIT '02), 300-307.

Baudry, A., Bungenstock, M., & Mertsching, B. (2003). Nyx--a tool for generating standard compatible e-learning courses with consistent and adaptable presentation. In The IASTED International Conference on Computers and Advanced Technology in Education (CATE 2003).

Bauch, M. J., & Unger, L. (2003). Interactive mathematics with Math-kit--distance learning versus face-to-face learning. In 21st ICDE World Conference on Open Learning & Distance Education, Hong Kong.

Bergner K., Rausch, A., & Sihling, M. (1998). A critical look upon UML 1.0. In M. Schader & A. Korthaus (Eds.), The unified modeling language--technical aspects and applications. Physica-Verlag, Heidelberg, 79-92.

Blackboard (2003). The blackboard e-education. Retrieved August 4, 2003, from http://www.blackboard.com/products/academic/index.html

Bungenstock M., Baudry A., & Mertsching, B. (2002). The construction kit metaphor for a software engineering design of an e-learning system. In P. Barker & S. Rebelsky (Eds.), Proc. ED-MEDIA 2002--World Conference on Educational Multimedia, Hypermedia & Telecommunications, 216-217.

Bungenstock M., Baudry, A., & Mertsching, B. (2003). Lyssa--an authoring system complying with e-learning standards. In ED-MEDIA 2003--World Conference on Educational Multimedia, Hypermedia & Telecommunications.

Canadian Department of National Defence (2002). SCORM Dynamic Appearance Model, Version 1.0.

Downes S. (2000). Learning objects. Leaders in learning 2000. University of Alberta.

Heng, S. (2003). Learning objects--where next? In 3rd Annual CM316 Conference on Multimedia Systems.

Hodgins, W. (2002). The future of learning objects. In Proceedings of the 2002 eTEE Conference, 76-82.

ILIAS (2004). Integriertes Lern-, Informations- und Arbeitskooperationssystem. Retrieved September 20, 2004, from http://www.ilias.de

IMS (2002). IMS Global Learning Consortium, content packaging specification. Retrieved June 10, 2002, from http://www.imsproject.org/content/packaging/

Kohlhase M. (2002). An open markup format for mathematical documents. Pittsburgh, PA: Carnegie Mellon University.

LON-CAPA (2003). The learning online network with capa. Retrieved February 7, 2003, from http://www.lon-capa.org/

Macromedia (2005). Macromedia Authorware 7. Retrieved June 10, 2005, from http://www.macromedia.com/software/authorware

Mathkit (2004). A multimedia construction kit for the mathematical education of undergraduate students. Retrieved April 14, 2004, from http://www.Math-kit.de

NetQuest 2003. TML language specification. Retrieved January 23, 2003, from http://www.ilrt.bris.ac.uk/netquest/about/lang/

Network Working Group (1999). HTTP extensions for distributed authoring--WEBDAV.

Thiere, B., Padberg, K., & Oevel G. (2003, March). Learning mathematics through a multimedia construction kit. In Proc. SITE2003, Albuquerque, New Mexico.

Unger, L., Oevel, G., & Mertsching, B. (2002). Web-based teaching and learning with Math-kit. In Proc. 2th International Conference on the teaching of mathematics.

W3C (2002). World Wide Web Consortium. W3C's math home. Retrieved August 6, 2002, from http://www.w3.org/Math/

W3C (2004). World Wide Web Consortium. XSL transformations (XSLT) version 1.0. Retrieved June 10, 2004, from http://www.w3.org/TR/REC-xml

W3C (2004b) World Wide Web Consortium. XSL transformations (XSLT) version 1.0. Retrieved June 5, 2004, from http://www.w3.org/TR/xslt

Walsh, N., & Muellner, L. (2002) DocBook: The definitive guide, Version 1.0.2. Retrieved August 21, 2003, from http://www.oreilly.com/catalog/docbook/chapter/book/docbook.html

Wiley D. A. (2000). Learning object design and sequencing theory. Doctoral dissertation, Brigham Young University, Provo, Utah.

Wollowski, M. (2002). XML based course websites. In E-LEARN 2002--World Conference on Educational in Corporate, World Conference on E-Learning in Corporate, Government, Healthcare, & Higher Education, 1043-1048.

Notes

(1) Support by the German Federal Ministry of Education and Research, project Math-kit (08NM084D is gratefully acknowledged.

(2) The authors recently moved from Hamburg to Paderborn.

(3) Named after the Greek goddess.

ANDREAS BAUDRY

Department of Computer Science, Germany

[e-mail]

MICHAEL BUNGENSTOCK

Faculty of Computer Science, Germany

[e-mail]

BAERBEL MERTSCHING

Faculty of Computer Science, Germany

[e-mail]

<?xml version="1.0" encoding="ISO-8859-1" ?>

<lob title="Euler formula and polar coordinates"
xml:lang="en">


     If one introduces the angle <formula text="true"
     mode="latex"> \varphi </formula> between the
     "vector" <formula text="true"
     mode="latex">z</formula> and the real axis in the
     Gaussian Plane, then the well-known formulas for
     sine and cosine yield:

     <formula text="false" mode="latex">
       z = r\, (\cos\varphi + \imath \sin \varphi) =
       r \, \cos \varphi + r \, \imath \sin \varphi
     </formula>

     where we use the convention ...
...

Figure 11. Example: XML file of the Euler brick