LON-CAPA 1 Management Issues in Distributed Learning Content Management Systems Gerd Kortemeyer Michigan State University.

LON-CAPA1

 Management Issues in Distributed

Learning Content Management Systems

Gerd KortemeyerMichigan State University

LON-CAPA2

OverviewExample System: LON-CAPA

Issues:

Content Exchange

Content Assembly

Content Catalogization

Content Rights and Licenses

Commercial Content

Protected Content

Content Integrity

Content Quality Control

Scalability

Content Replication

Load Balancing

Distributed Authorizations

Distributed Coding

Maintenance and Security

LON-CAPA3

Example SystemFor illustration, examples from the LearningOnline Network with CAPA will be used

Cross-Institutional Learning Content Management and Assessment System

Today, I will only focus on Content Management

Implemented components, from bottom up (“Just Do It”):

a cross-institutional distributed content repository

a tool to seamlessly assemble this content

a course management system to readily deploy this content

LON-CAPA4

Example System

Initial development started in 1992 at Michigan State University

Distributed Content Management component since 2000

Model System for National Science Foundation Information Technology Research Project “Investigation of a model for online resource creation and sharing in educational settings”

Faculty are the authors and users of the content material (sort of grassroots).

LON-CAPA5

Example System

Currently used at 3 middle schools, 16 high schools, 2 community colleges, and 16 universities

Approx. 23k students/semester

LON-CAPA6

Example System20,900 content pages

18,600 homework and exam problems

12,500 images

2,100 content assemblies

1,100 simulations and animations

500 movies

Publisher libraries, “back of the chapter problems”

LON-CAPA7

Example System

LON-CAPA8

Content ExchangeProviding high quality learning content in an online environment is time and cost intensive

Typical scenario today:

Online material is developed by only one instructor

Online material is used by only one instructor

Online material is used in only one course

No assessment of learning effectiveness

In-effective use of time and resources

LON-CAPA9

Content ExchangeMuch better scenario:

Online material is developed and reviewed by more than one instructor

Online material is shared among instructors

Online material gets used across many courses and disciplines

Continual assessment of learning effectiveness

LON-CAPA10

Content ExchangeIssue: Content Compatibility

Content developed at institution A needs to run at institution B

Three approaches

Standardize content

Standardize APIs for content handlers

Standardize on one platform

LON-CAPA11

Content ExchangeApproach 1: Attempt to define how the content is coded:

IMS, SCORM, QTI, etc

Advantage: Portability between vendors

Problems:

content has to run in lowest common denominator system

restrictive on content

no standard is perfect: long loop to implement innovations

no guarantee that this will really work all the time

LON-CAPA12

Content ExchangeApproach 2: Attempt to define how content handlers interact (APIs; “content can come with its own handler”):

OKI

Advantage: only mildly restrictive on content

Problem:

restrictive on overall system functionality

no standard is perfect: long loop to implement innovations

where is it?

LON-CAPA13

Content ExchangeApproach 3: Attempt to have the same platform everywhere:

LON-CAPA (content-level), BlackBoard Building Blocks (API-level), etc

Advantages:

content that runs on machine A is guaranteed to run on machine B

faster turn-around on innovations

Problem:

potentially costly solution for commercial products

creating dependencies, “all eggs in one basket”

LON-CAPA14

Content AssemblyWrites module onstatistical averages

Writes module onstatistical errors

Includes the twointo her unit on survey analysis

Uses that unit inhis course

LON-CAPA15

Content AssemblyMade possible (in LON-CAPA) through:

Reuse: Separation of content for navigation/interface and presentations

Self-contained content can be reused on low level of granularity

Content Assemblies themselves can be reused

Navigation is provided by the system based on the assembly data, not by the content

On-the-fly rendering: XML structures for multi-lingual presentation, server-side style files

LON-CAPA16

Content AssemblyVirtual cross-

institutional file system “The aisles

of your supermarket”

Your shopping cart: The Resource

Assembly Tool

LON-CAPA17

Content Assembly

LON-CAPA18

Content Rights and Licenses

Very important: distinguish between copyright and different rights of use (“licenses”)

Who has the right to use a resource?

Who has the right to deterimine that somebody else may use it?

Who has the right to modify a resource?

LON-CAPA19

Content Rights and Licenses

LON-CAPA: Authors keep copyright

LON-CAPA: Authors (currently) grant right of use

private

only for own institution (after other instructor selects it)

network-wide (after other instructor selects it)

public

customized: for certain institutions, courses, ...

access keys

LON-CAPA20

Content Rights and Licenses

Setting custom access rights

Allowing access by key only (publisher content)

LON-CAPA21

Content CatalogizationSharable content is useless if you cannot find it

Metadata (“data about data”) needed

What standard?

Dublin Core?

IMS?

Too much data: nobody will fill it out

Too restrictive data: cannot be used to store additional data, for example geo-coordinates

Who does the cataloging?

Librarian: not scalable

Author: potentially inconsistent, unreliable

LON-CAPA22

Content CatalogizationLON-CAPA Static metadata:

Dublin Core plus additional fieldscross-walk to some of IMSDone by author with system assistance (keyword suggestions, hierarchical default entries)

Dynamic metadata: use assembly data for recommender system:

LON-CAPA23

Content IntegrityWhat if you use somebody else’s resource in your course …

… and it goes away?

… it changes in an undesirable way?

LON-CAPA:

once-published resource cannot be deleted

Persistent system-wide URLs

versioning: can choose to fix course to current version of a resource, can check on changed resources and selectively adopt new versions

resource users cannot edit resource unless explicitly given co-author rights to the original source

LON-CAPA24

Content Quality ControlCould implement peer-review (example: MERLOT)

Can inhibit growth of resource pool, not easily scalable

LON-CAPA: keep dynamic metadata regarding

Number of courses using the resource

Number of other resources importing it

Number of students who accessed it

Problem-Content:

Number of students who worked on it

Degree of difficulty

Subjective evaluations

Usage data

LON-CAPA25

Scalability

Success can be a problem:

Successful resources: server load

Number of users: processing load

Success must not be a problem: scalability

LON-CAPA26

ScalabilityNetwork of connected servers

Any server in the network can serve any resource in the system

Content replication in background

Network-wide persistent URL paths

LON-CAPA27

Scalability

North Dakota State University server serving resource from Michigan State University

First time the resource is accessed, it is copied in the background (replicated)

closer to userMSU not stuck with serving the resourcewill continue to work if connection to MSU down

Leaves behind subscription on MSU server

When resource updated at MSU, NDSU copy is either updated or deleted, depending on usage pattern

LON-CAPA28

ScalabilityNetwork of connected servers

Any server in the network can serve sessions for any user

Servers can offload sessions to each other cross-institutionally

Load-balancing

LON-CAPA29

Scalability

x5

LON-CAPA30

Distributed AuthorizationsOne user can have roles across the network

Each role comes with a set of privileges within a certain realm (course, domain, whole network)

LON-CAPA31

Distributed CodingOpen-source free software

GNU General Public License

No license fees

Can be modified, extended, improved, adapted ...

Runs on Linux, no license fees for operating system

Developed by educators for educators

Central CVS code repository

Releases defined centrally

LON-CAPA32

Distributed CodingCode contributions by

Florida State University

Ohio University

Simon Fraser University Vancouver

Hebrew University Jerusalem

UNICAMP São Paulo

Nagoya University

LON-CAPA33

Distributed Coding

LON-CAPA34

Maintenance and SecurityDanger in distributed network: trust relationships

between machines:

one rogue machine can leak problem source codes or be abused to grant higher authorizations to users

Monitoring processes

Local system administrators need to keep machines up-to-date

Remote maintenance options

Frequent release schedule and quick updates

Mechanisms to quickly take machine offline

LON-CAPA35

FundingMichigan State University

Mellon Foundation

Sloan Foundation

National Science Foundation

Ohio University, Florida State University, Ohio University, Nagoya University, UNICAMP, Simon Fraser University, Hebrew University of Jerusalem

People who drive too fast