Open Knowledge Initiative

Phillip D. LongSenior Strategist for the Academic Computing

EnterpriseMassachusetts Institute of Technology

eLearning Standards Business Stakeholder’s Group

Feb. 3, 2003

The Problem

The Problem

Universities and other institutions are building:

Boutique customized learning tools

The Problem

Universities and other institutions are building:

Boutique customized learning tools

Trying to implement commercial learning systems (VLE/LMS) across heterogeneous learning domains

The Problem

Universities and other institutions are building:

Boutique customized learning tools

Trying to implement commercial learning systems (VLE/LMS) across heterogeneous learning domains

On top of divergent underlying enterprise infrastructures

It’s not working

1st Generation Technology

Course Mgmt

Content Mgmt

Assessment

Etc...

Software for Teaching and For Learning

AuthN

AuthZ

DBMS File GUID

Log

Etc...

DigitalLibrariesBrowser

Environments

Simulations

RemoteDevices

2ndGeneration Technology

Course Mgmt

Content Mgmt

Assessment

Etc...

Software for Teaching and For Learning

AuthN AuthZ DBMS File GUID Log Etc...

DigitalLibrariesBrowser

Environments

Simulations

RemoteDevices

Enterprise Services

Assumptions

• Things Change– New Services & Functions – Method of Accessing Services – More Central Software Services

• Authorization, Calendaring, etc.

– Evolving Systems• Definitions

– Protocols and transport layers will evolve

More Assumptions

• Enterprises have different technologies

• Enterprise systems will use different technologies

• Need for sharing will grow• Agreement beyond APIs needed for

interoperability (vocabularies, metadata, etc)

Goals of Interoperability

What do we mean by Interoperability?

First -

Goals of Interoperability

• Data Synchronization• Enterprise Integration• Tool/UI Integration• Application Portability• Programming Language

Integration• Inter-Enterprise Resource Sharing

OKI Addressing

• Data Synchronization• Enterprise Integration• Tool/UI Integration• Application Portability• Language Integration• Inter-Enterprise Resource Sharing• Etc…

Dimensions of Interoperability

Data Definitions

Technology Choices

UI/Application Frameworks

Service Definitions

Dimensions of Interoperability

Serv

ice

Data

UI

Tech

Gov.CorpHESchool

Open Knowledge InitiativeS

erv

ice

Data

UI

Tech

Gov.Corp.H.E.School

J

Data SpecificationsIMS/1.X

EnterpriseApplication A

EnterpriseApplication B

Data

OKI in a Nutshell

An ApplicationBefore O.K.I.

An ApplicationAfter O.K.I.

Tool and Implementation Portability

The API Approach

• API are interfaces only, not implementations

• Code reuse• Could achieve real-time integration• Clean separation or boundaries• Facilitates changes by minimizing

impact

Common Service Level APIs

• Allows integration with enterprise services

• Adapts to multiple standards• Allows several sites to share

services• Independence from changing

technology

Service Based Architecture

public class Factory implements org.okip.service.Example.api.Factory { private static final blah blah bhal

private static final yada yada yada } …

ExampleAPI

…org.okip.service.shared.api.Thing things = myFactory.getSomething();

if (null != thingss) { for (int i = 0; things.length != i; i++) { out.println(things[i]); System.err.println(types[i]); } } …

User Application

Implementation

Infrastructure

Service

OKI Services

Course MgmtContent Mgmt Assessment

AuthN

Etc…

LocalIdFileDBCAuthZ Hierarchy UserMessagingLogging Etc…

Etc… Etc…

SharedObjects

EducationalService

APIs

CommonService

APIs

Educational Service Implementations

Common Service Implementations

Educational Software“MLE”

Institutional Infrastructure

Core Institutional Partners

• Cambridge University• Dartmouth College• MIT• North Carolina State University• Stanford University• University of Michigan• University of Pennsylvania• University of Wisconsin

Core OKI Deliverables

• Service specifications/APIs– 13 “Common Services”– 3 “Educational Services”

• Reference implementations• Exemplar applications (including

“MLE/LMS”)• Sustainability strategy

O.K.I. Service Definition Process

0.2

0.9

1.0 draft

Common Service API Status

• Authentication• Authorization• DBC• Logging• LocalID• Shared• Filing• Hierarchy• Localization• Group• User Messaging• Scheduling• Workflow

0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.9 – Public0.90.90.90.50.50.5

Educational Service API Activity

• Class Admin– Student Information Systems Integration– Approaching 0.9

• Digital Repository– Digital Library Community Engagement– Approaching 0.9

• Assessment

OKI Application Activity• LMS’s

– Stellar – MIT– CourseWork – Stanford University– CHEF – University of Michigan– OnCourse II – Indiana University (with CHEF)

• Client Demo Apps– Filing Demo – MIT– Hierarchy Demo – MIT– User Messaging Demo – MIT– Digital Repository and Class Admin Management Apps – MIT

• Digital Library Systems– DSpace – MIT– Fedora –University of Virginia/Tufts University

• Educational Tool Development– VUE Concept Mapping Tool – Tufts University– Assessment Components – Stanford University – SCORM Player – University of Cambridge

The Service Definition Sweet Spot

Too ConcreteToo Abstract

Protocol andData Model

ChoicesDefined

“Java”“Perl”

O.K.I. Abstraction and Bindings

Abstract Service Definition

Emitters

Java InterfacesDocumentation

Other…

Phase 2Phase 1

OKI General TimeLine

Jan 01 Jan 02 Jan 03 Jan 04 Jan 05 Jan 06

Initial Core Service Development Further Spec. Dev. – “Institute”

Ref. Implementations

Applications

Developer Community Coordination/Support

Core Service Maintenance/Evolution

Adopter Engagement

Vendor Engagement

Grant Funded OKI App Activity

Data and Functional Specifications

• Data standards serve two goals– Data exchange inter/intra enterprise

• Functional specifications define behavior

• Both are needed• Agreed upon standards allows parallel

development– Above the line - in learning apps– Below the line - in enterprise technologies

An Example

OKI Content Repository API

• What functions do “Learning Systems” need from content repositories?

• How can we complement existing data specifications?

• Allow for a single “System of record” for an asset

Many Repositories

IDC

iMac

I

BM

Remote

Local

IDC

Institutional

Content Repository Goals

• Allow for reuse of assets• Allow the definition of assets to be preserved

& extended.• Easy & flexible search & access• Allow for organization & classification of assets• Maintain authorship & IP information• Allow for inheritance

Learning Use Assumptions

• A learning system might use more than one content repository

• A Learning System needs to store many types of assets for local use

• User software tools shouldn’t care if assets are local or remote

• User software tools shouldn’t care about protocols or transport

Many Protocols

IDC

iMac

I

BM

IDC

SOAPZ39.50

V2

HTML

Z39.50

File System

OAI

Remote

Local

Institutional

Asset Assumptions

• Assets can contain other assets• There are many types of assets• Assets may be references• There will be different metadata structures

required for different asset types • Assets types might share sets of attributes

definitions• Assets might share sets of attributes

Content Repositories Assumptions

• Content repositories store and retrieve assets and information about those assets (metadata structure and values).

• A content repository may store permanent or temporary assets

• Determines asset types managed• Determines metadata required for particular

asset types• Determines the search functionality supported • Content repositories have other functions not

addressed

What is the work ahead?

Decomposition

What is the work ahead?

Finding the right boundaries

What is the work ahead?

Engaging in a process, not selecting an end state

What is the work ahead?

Learning as a science– Apply formalism to describe

behavior

The End

&The Beginning

longpd@mit.edu