CRAMS - Curriculum Repository and Metatagging System
JOSEPH SANT, GARY CLOSSON, PEGGY HILLIARD, XIAOLAN SHI
Applied Computing and Engineering Sciences
Sheridan Institute of Technology and Advanced Learning
1430 Trafalgar Rd., Oakville, Ontario, Canada, L6H 2L1
CANADA
Abstract: - The goal of the typical Learning Object Repository is to provide a secure database of educational resources that allows the retrieval of learning materials based on criteria important to educators. Other benefits include better management of intellectual property and the ability to archive the content taught in a specific delivery of a course for administrative purposes. CRAMS (Curriculum Repository and Meta-tagging System) is a Learning Object Repository System being implemented at the Sheridan Institute of Technology and Advanced Learning that is designed to be easy to use and easy to manage. The system design includes the core functionality expected of a Learning Object Repository and advanced features not available in other Repositories. This paper discusses lessons learned in the design and implementation of CRAMS from project initiation to the alpha stage.
Key-Words: -Learning Object Repository, Curriculum, Meta-tag, Database, Distributed System
1 Introduction
The increased use of mobile teaching environments and learning management systems (LMS's) combined with the dynamic nature of many subject areas is driving a need for a more organised way to store and retrieve learning resources. Sheridan Institute of Technology and Advanced Learning was an early adopter of the use of mobile teaching environments (i.e. student use of laptop computers for learning) and learning management systems amongst third-level educational institutions in Canada. Students at Sheridan are provided with leased laptops and an infrastructure to support mobile learning, including the provision of high-speed internet connections for every seat in most classrooms and network drops outside of classrooms. Sheridan has standardised on the WebCT Learning Management System and many courses are supported by a WebCT course site [1].
While WebCT provided excellent support for individual courses there was no facility for cross-referencing or searching learning objects across multiple courses. There were many high-quality learning objects being developed by faculty that would only be known to the faculty member, his or her immediate colleagues and the faculty member’s students.
It was decided to investigate the implementation of a Learning Object Repository System to compensate for WebCT’s inability to manage the growing inventory of learning objects. A Learning Object Repository (LOR) System provides facilities to store Learning objects such as slide sets and HTML pages along with metadata pertaining to these Learning Objects [2]. This metadata might include the author name(s), short description, the file format, file location, resource type and copyright information [3].
At the time (February, 2002), WebCT did not provide a Learning Object Repository as a feature and had no firm schedule to provide one. A multi-disciplinary team was assembled to develop a Learning Object Repository, called Curriculum Repository and Meta-tagging System (CRAMS). The project began as a departmental initiative of the School of Computing and Information Management, Sheridan Institute of Technology and Advanced Learning but is now being considered for use in several Schools within the Institute. Our team decided to join a consortium of several third-level educational institutions across Canada in order to contribute to the eduSource project and share ideas with others trying to solve similar problems [4]. The eduSource project will attempt to create a test-bed of linked and interoperable learning object repositories across Canada. CRAMS is now in the alpha stage of a production system. Currently CRAMS can be used to upload and download learning objects and their associated metadata to and from a repository and can perform searches for learning objects using the metadata for these objects. CRAMS was implemented using Java servlets, Java Server Pages, and ORACLE database on the server and W3C-compliant browsers for the clients.
2 Problem Formulation
Educational institutions that use the current generation of the most popular Learning Management Systems typically have extensive collections of valuable learning materials embedded within their course websites. The utility of these materials is severely limited because it is not possible with current LMS’s to inventory the learning objects or efficiently search for materials based on criteria important to an educator. A learning object repository could increase the utility of these materials by storing meta-data with the learning materials to facilitate later searching and retrieval. For administrative purposes, the Object Repository should also be able to archive collections of learning objects that refer to a specific course given during a specific semester for later reference.
Several options for managing Sheridan’s Learning Object Inventory were considered. Sheridan had access to a remote Learning Object Repository operating operated by the Belle Project [5]. While Sheridan was contributing objects to the Belle Project (and later would contribute to its successor, the eduSource Project), it was decided that maintaining control of access and security to the complete inventory was important. The existing LOR’s were in various stages of stability and functionality. There would be considerable effort in retrofitting these LOR’s to integrate with Sheridan’s IT infrastructure. It was decided to investigate the feasibility of developing a custom-built LOR that could integrate well with an ORACLE-based IT infrastructure and existing LMS’s (i.e. WebCT).
2.1Project Goals
Project goals were as follows:
To develop a Learning Object Repository that could be effectively searched based on metadata pertinent to educators and course architects. The repository should be available to administrators, full-time faculty, sessional faculty (i.e. faculty hired on contract for one semester) and part-time faculty.
Optimise the Repository’s utility by ensuring that the user interface was easy to learn and easy to use.
Provide a method to archive complete courses for later reference by administrators.
Facilitate the interchange of records describing educational resources and the discovery of these resources within Sheridan and across eduSource sites within Canada.
2.2Project Constraints
Project constraints were as follows:
Minimise staffing requirements for development and maintenance.
Ensure security of objects once they have been loaded into the repository.
Provide for future integration with the Sheridan Institute of Technology and Advanced Learning Student Information System. This system is Oracle-based.
Provide for future integration with the Institute’s Web Portal.
Where possible, support international accepted standards for the representation of Learning Materials.
Allow for the future integration with a Canada-wide project, eduSource, intended to allow distributed searches of multiple learning object repositories from one site.
3Problem Solution
A project team was assembled under the leadership of Gary Closson, Dean, Applied Computing and Engineering Sciences, Sheridan Institute of Technology and Advanced Learning. The team included a Systems Analyst and Database Architect (Peggy Hilliard), Software Engineer (Xiaolan Shi) and two consultants; Joseph Sant (User Interface Design and Software Architecture) and Sean McShane (Database Architecture). The team members had an aggregate of approximately 45 years of teaching experience. All members had both software development and database implementation and design expertise.
3.1 Phase One: Prototype Design
This phase involved capturing the requirements for CRAMS, designing and implementing a database based on those requirements, and building a simple PC-based prototype system. While the focus of the prototype was on the sharing of curriculum objects within Sheridan’s School of Computing and Information Management (SCIM), an effort was made to align this project with the Belle Project (the predecessor of the eduSource Project), which was developing a system to catalogue and meta-tag curriculum objects for sharing amongst educational institutions across Canada. The Peggy Hilliard, the project team’s System Analyst and Database Architect conducted this phase of the project using regular input from the other team members.
3.1.1 Activities of Phase One:
Activities in Phase One included:
Background research of similar work at other institutions [5,6,7].
Surveys were conducted with Sheridan faculty members.
Metadata standards were investigated to find an appropriate subset or superset of an existing standard that would satisfy our needs. Metadata standards that were investigated and compared included IMS, Dublin Core, IEEE LTSC, SCORM and CanCore [8,9,10,11].
A report was produced that identified all of the issues and questions that required consensus and/or decision before the full system could be developed. In the report, a subset of data elements and the rules for populating them, were recommended for the prototype system.
A Sheridan subset of the CanCore Metadata Standard was chosen with some extensions added to allow us to cross-reference materials to courses and programs at Sheridan.
Sheridan’s information systems were investigated to identify possible interfaces to the student information systems and Information Technology systems.
A relational database schema was designed that would properly represent all the metadata and their necessary relationships.The schema was implemented using ORACLE 8.1.
A PC-based prototype system for Object entry and retrieval was developed using ORACLE Forms.
3.1.2 Discussion of Phase One:
Some of the key issues identified and their proposed solutions are listed below:
Which internal systems would the LOR potentially interact with? The student information system and the human resource system.
Which external systems would the LOR interact with? Unknown, but the college was part of a Canada-wide project known as Belle. One of the goals of Belle was to create a single access point to multiple distributed Learning Object Repository Systems.
Versioning of Learning Objects? Objects once loaded could not be modified. New “modifications’ became new objects. This would help with archiving for historical purposes.
Versioning of Metadata? Metadata would not be versioned. Metadata would be stored when objects were uploaded.
Copyright Issues? Initially only Sheridan-owned available for use throughout the College would be uploaded.
Granularity? System should support very fine levels of granularity but not below the “operating system file” level.
Categorisation of Materials? Initial focus will be to support categorisation based on a pre-defined hierarchy of subjects or topics. Future support for unconstrained keyword entry and search should be accommodated in the database design. Meaningful categorisation of the learning objects would be a critical issue in the utility of the LOR. The use of a constrained vocabulary (a pre-defined set of keywords to describe topics or subjects) would mean that two contributors describing the same resource was more likely to use the same keyword to describe the object. Without a constrained vocabulary, similar objects from different contributors might have totally dissimilar descriptors.
Types of Objects to be stored? A list of the different types of objects that might be considered for storage was defined. It would be necessary to shorten this list for it to be practicably implemented as a pick-list.
System and Database Operations? Production system would have to run 24/7 excepting scheduled downtime for backup and maintenance. Backup and maintenance procedures would need to be documented.
Method of Uploading Objects? Initial implementation would be for the School of Computing and Information Management. FTP would be acceptable for the initial implementation (restricted to the School of Computing and Information Management) but a more transparent method would be necessary if other Schools within the Institute were to use the repository.
The CanCore (Canadian Core Learning Object Metadata Application Profile), a subset of the IMS standard, was used as a starting point. eduSource has standardised on CanCore as the metadata standard for describing learning resources. CanCore is a participant in the IMS Global Learning Consortium, Inc. through the sponsorship of Industry Canada.Peggy used a Sheridan subset of the CanCore subset of the IMS standards for meta-tags and added extensions necessary to identify cross-references to courses and programs at Sheridan.
3.2 Phase Two: Prototype Evaluation.
This phase of the project involved porting the PC-only version of the prototype to a server, loading learning objects into the repository, and then attempting retrieval of those objects. During this phase the system primarily managed the metadata and the actual objects were uploaded or downloaded via FTP or copied to shared directories. Primary participants in this phase included Gary Closson (Project Leader), Peggy Hilliard (Systems Analyst), Joe Sant (User Interface Consultant) and Sean McShane (Database consultant).
3.2.1 Activities of Phase Two
Activities in Phase Two included:
Create a networked CRAMS database that would enable School of Computing and Information Management faculty members to run Oracle Forms locally within Sheridan and meta-tag objects on the CRAMS server.
Procedures were developed and documented for the installation and configuration of client software to properly allow remote access to the server database.
Procedures were developed and documented for the loading and meta-tagging of learning objects.
A topic category hierarchy was developed to enable association of a topic with a learning object. The model for this topic hierarchy was derived from the Association of Computing Machinery Topics.
The prototype was tested by attempting to load 25 learning objects of various types including HTML pages, graphics files, data sets, PowerPoint slide sets, course descriptions and course schedules.
A mock-up of a browser-based client was developed. This mock-up preserved the core data entry fields but eliminated several fields that could be defaulted or were considered extraneous.
3.2.2 Discussion of Phase Two
The key goal of Phase Two was to convert the stand-alone prototype to a client-server implementation then evaluate its effectiveness by using it to catalogue a variety of learning objects. One instructor and two student interns were asked to use the CRAMS prototype to enter meta-data for approximately 25 learning objects of various types. The instructor was very proficient in the use of Windows-based application programs while the interns were intermediate-level users of Windows-based applications. The prototype did not feature automatic uploading of the actual learning objects from the client to the server. This was to be implemented by mapping a directory on a networked drive to a local drive. Concurrent uploading of learning objects and their meta-data was not considered essential for a prototype.
All three participants in the study were able to enter the meta-data for the 25 learning objects successfully. All three noted that the entry of the fields using the Oracle Forms client was awkward when compared to other applications that the users were familiar with. Some of the bugs identified in the program behaviour were later identified as bugs in the Oracle Forms product. The prototype allowed for the entry of all data fields in the Sheridan subset of CanCore. This necessitated the use of several ‘tabs’ on a tabbed form and forced the user to navigate between several tabs in order to complete the entry of any single object. This was in spite of the fact that many of the fields in the various tabs were optional or could be defaulted.
The prototype was implemented using an Intel-based server running Windows 2000 and IBM Thinkpad R31 laptop clients using the Windows 2000 Operating System. The prototype was implemented in ORACLE Forms to facilitate porting to Linux or Unix if necessary. To run the prototype on the IBM Thinkpad R31 clients, it was required that an ORACLE Forms run-time client be loaded on the laptop, the laptop be enabled as a virtual network client, the user map specific directories as a local drive, and that certain environment variables be set.
During the evaluation, it was determined that meta-data entered into the Repository could be retrieved using various data fields. All meta-data entered was retrieved as it was entered. The database implementation was able to properly save and retrieve all the critical learning object metadata elements identified in the requirements documents.
The system was intended for use by advanced, intermediate and novice users. The fact that one advanced and two intermediate-level users had difficulty entering the object metadata indicated that the prototype as designed would definitely not be appropriate for novice users. Furthermore, because of the awkwardness of the field entry and the forced navigation through several tabs, entering object meta-data was slow.
It was very important for Sheridan that sessional and part-time instructors could quickly and reliably gain access to the repository shortly after being hired. The difficulty of deploying the prototype on the laptops indicated that guaranteeing quick access to the repository to part-time and sessional instructors would be problematic.