Upload
kevin-keating
View
219
Download
0
Tags:
Embed Size (px)
Citation preview
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