Embed Size (px)
Citation preview
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
