Design and Reusability of Learning Objects in an Academic Context: a new Economy of Education?

Permission Based

This principle states in effect that users of the system own their own personal data. The user’s agent operates on behalf of the user, and releases information or money only with the agent’s explicit consent. The purpose of this principle is to engender trust in the system and to ensure privacy when dealing with multiple agencies.

A Network Rather Than A (Single) System

What we are proposing is a set of inter-related applications distributed over the internet and communicating with each other. This seems to me to be the single major factor distinguishing our approach from other approaches as defined in IEEE/P1484.1/D9 of IMS Repositories. This is accomplished in three major steps:

1. 
   Separating the functionality of an LCMS / LMS architecture into distinct, stand-alone components that communicate over TCP/IP
   

2. 
   Allowing (encouraging) the development of multiple instances of these components
   

3. 
   Providing indexing or registries of these instances
   

Thus, for example, instead of envisioning a single metadata repository that indexes all learning objects (or, as we see within common practice, all learning objects within a specific domain, such as a geographic region or company), we envision multiple learning object repositories that may or may not focus on a particular domain.

Core Components of the Network

1. 
   Learning Object Repository - hosted by vendors on vendor sites, provides vendor metadata and learning object servers
   

2. 
   Metadata Repository - hosted elsewhere, harvests metadata from vendors and amalgamates, allows queries from eLearning systems. Norm Friesen has written a useful backgrounder on harvesting: http://www.cancore.ca/harvesting.doc
   

3. 
   eLearning system - queries metadata repository, user selects resource, retrieves resource from learning object repository, displays
   

This core functionality is relatively simple and is already established in other domains, for example, in news syndication. Consider the following combination of components:

1. 
   News Object Repository - Original articles are posted on news site and RSS metadata is available for harvesting
   

2. 
   Metadata Aggregator - such as NewsIsFree collects metadata, indexes (maybe) and provides (topic-specific, sometimes) search
   

3. 
   News Viewer - such as Amphetadesk - accesses the aggregator for an index, then retrieves the selected item from the news repository
   

Contrast to Library Model

Most other implementations, including IEEE/P1484.1/D9, employ a model whereby learning materials are akin to books in a library (or, in some other way, 'content' to be managed). Consequently, they envision that implementations of the architecture will access collections of this content, typically (but not always) stored on location. The process they envision is therefore:

1. 
   Acquire the content
   

2. 
   Index or classify the content
   

4. 
   Deploy the content
   

In a network model, there is no need to manage collections of content. So instead of working with learning objects specifically (as defined by

IEEE/P1484.12.1 or pick your specification) the network works more generally with what may be called learning resources, or even more precisely, learning opportunities. This includes, but is not limited to:

1. 
   Learning objects, properly so-called
   

2. 
   Other academic works, such as journal articles
   

3. 
   In-person classes or seminars
   

4. 
   Instructors, coaches and tutors
   

While it is permissible to search for a specific category of learning opportunities, such as a learning object, the design does not require that all resource fit that particular category. This is enabled by tolerating the use of different schemas in learning object repositories.

Component Registry Services

In the network proposed, there are multiple instances of each component. Of course there are multiple learning objects. But there is in addition multiple learning object repositories (typically, one for each learning object vendor) and multiple metadata repositories.

1. 
   To provide a list of the available instances
   

2. 
   To establish and verify ownership of these resources, for the purpose of maintaining or updating information about them in the system
   

For example, consider the list of learning object repositories. A vendor wishing to offer learning objects through the network will need to declare that the repository exists and where to find the list of available resources. By registering the repository, the vendor is able to make its presence known and to ensure that important information – such as its URI – will not be changed by third parties.

Functionality of the System versus Functionality of the Learning Resource

Many models of learning object architecture presuppose that the system being deployed contains a great deal of functionality. For example, IEEE/P1484.1/D9 includes as two (of the four) essential components the ‘coach’ function and the ‘evaluation’ function. A wide variety of other functions are embedded in LMS and LCMS design, for example, class registration, discussion and chat.

Secondary Components

In addition to the three core elements, a number of secondary elements are also required in order to meet a number of the objectives of learners, learning institutions and content providers. As in the case of the core components, there may be multiple instances of any secondary component. This allows users of any core component to exercise choice in the selection of secondary components. These components include:

1. 
   A system of third-party metadata
   

2. 
   A digital rights system
   

3. 
   A learner (user) information system
   

4. 
   A reporting or tracking system
   

What is significantly different about this model and models envisioned in IEEE/P1484.1/D9 and IMS Repositories is that:

1. 
   The components are optional: you develop (or buy) them and use them only if you need them
   

3. 
   For any given component, you may select one of many instances
   

3. 
   These components may reside outside your own system
   

As in the case of the primary components, a registry service is developed for each type of secondary component.

Third Party Metadata

Third-party metadata is a cruical component of the network that is not really envisioned by IEEE-LOM or IMS (though to be fair they do permit reference to third party ontologies, as in IEEE/P1484.12.1 9.21 and 9.22. See http://www2002.org/CDROM/alternate/744/index.html for some description and uses of third party metadata.

1. 
   A description, in IEEE/P1484.12.1, created by the author or owner of the learning object
   

2. 
   An indication of certification, using a specialized metadata schema, provided by a professional association
   

4. 
   Metadata containing a review (or a reference to a review), provided by a public service agency
   

3. 
   Digital rights information, authored by and hosted by a DRM handling company
   

5. 
   Classification of the object, authored and hosted by a library authority
   

Digital Rights Management

A principle objective of the digital rights system (DRM) enabled by the network is to create a system where multiple suppliers work through a common interface. To enable this, it is important to provide a choice of business models. A business model consists of two essential components:

1. 
   The definition of the business rules, and
   

2. 
   The application of the rules in software functionality
   

In traditional DRM, the definition of business rules is represented in specific DRM metadata. Two major approaches exist, ODRL and XrML, though numerous sub-variants exist. These approaches are XML schemas defining the allowable documentation of specific rights for a specific (group of) learning object(s). See http://xml.coverpages.org/drm.html

Beyond Digital Rights Management: Employee/Consumer Rules

Most examinations of DRM deal in general with the application of business rules to learning object transactions. For the most part, these are rules established by the content owner or vendor. But it is important to look beyond the traditional formulations whereby all the rules are established by the vendor. Classes of employee/consumer rules will also be identified and handled by different parts of the system.

These rules are applied by various subsystems: the metadata repository, the learning object retrieval system, and the viewer itself.

Employer Rules

Employer rules are established using the same system as employee/consumer rules. By ‘employer’ in this document we could also include entities such as school boards, colleges or universities, professional associations, and indeed, any third party given permission by the employee or consumer to apply rules.

Learner / User Information System

An additional secondary component is a set of learner information systems. The concept is similar to the ‘resume’ or ‘portfolio’ system described by Chuck Hamilton of IBM at NAWeb. Details to follow.

Notes
[1] This paragraph was significantly informed by Norm Friesen and Toni Roberts.

References

. Slide Presentation. http://www.cni.org/tfms/2001a.spring/handout/Progress-SChen2001Stf-NSF.ppt

GPL. 1991. The GNU General Public License. Version 2. http://www.opensource.org/licenses/gpl-license.php

Saba Software. 2002. Saba Learning, Enterprise Edition. http://www.saba.com/english/products/pdf/Saba_Learning_Ent.pdf