1. Open Knowledge Initiative Phillip D. Long Senior Strategist for the Academic Computing Enterprise Massachusetts Institute of Technology eLearning Standards Business Stakeholder’s Group Feb. 3, 2003

2. The Problem

3. Universities and other institutions are building: Boutique customized learning tools

4. The Problem Universities and other institutions are building: Boutique customized learning tools Trying to implement commercial learning systems (VLE/LMS) across heterogeneous learning domains

5. 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

6. It’s not working

8. 1 st Generation Technology Course Mgmt Content Mgmt Assessment Etc... Software for Teaching and For Learning AuthN AuthZ DBMSFileGUID Log Etc... Digital Libraries Browser Environments Simulations Remote Devices

9. 2 nd Generation Technology Course Mgmt Content Mgmt Assessment Etc... Software for Teaching and For Learning AuthNAuthZDBMSFileGUIDLogEtc... Digital Libraries Browser Environments Simulations Remote Devices Enterprise Services

10. 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

11. 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)

12. Goals of Interoperability What do we mean by Interoperability? First -

13. Goals of Interoperability Data Synchronization Enterprise Integration Tool/UI Integration Application Portability Programming Language Integration Inter-Enterprise Resource Sharing

14. OKI Addressing Data Synchronization Enterprise Integration Tool/UI Integration Application Portability Language Integration Inter-Enterprise Resource Sharing Etc…

15. Dimensions of Interoperability Data Definitions Technology Choices UI/Application Frameworks Service Definitions

16. Dimensions of Interoperability Service Data UI Tech Gov.CorpHESchool

17. Open Knowledge Initiative Service Data UI Tech Gov.Corp.H.E.School J

18. Data Specifications IMS/1.X Enterprise Application A Enterprise Application B Data

19. OKI in a Nutshell An Application Before O.K.I. An Application After O.K.I.

20. Tool and Implementation Portability

21. 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

22. Common Service Level APIs Allows integration with enterprise services Adapts to multiple standards Allows several sites to share services Independence from changing technology

23. 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 } … Example API … 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

24. OKI Services Course MgmtContent MgmtAssessment AuthN Etc… LocalIdFileDBCAuthZHierarchy User Messaging LoggingEtc… Shared Objects Educational Service APIs Common Service APIs Educational Service Implementations Common Service Implementations Educational Software “MLE” Institutional Infrastructure

25. Core Institutional Partners Cambridge University Dartmouth College MIT North Carolina State University Stanford University University of Michigan University of Pennsylvania University of Wisconsin

26. Core OKI Deliverables Service specifications/APIs –13 “Common Services” –3 “Educational Services” Reference implementations Exemplar applications (including “MLE/LMS”) Sustainability strategy

27. O.K.I. Service Definition Process 0.2 0.9 1.0 draft

28. Common Service API Status Authentication Authorization DBC Logging LocalID Shared Filing Hierarchy Localization Group User Messaging Scheduling Workflow 0.9 – Public 0.9 0.5

29. Educational Service API Activity Class Admin –Student Information Systems Integration –Approaching 0.9 Digital Repository –Digital Library Community Engagement –Approaching 0.9 Assessment

30. 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

31. The Service Definition Sweet Spot Too ConcreteToo Abstract Protocol and Data Model Choices Defined “Java” “Perl”

32. O.K.I. Abstraction and Bindings Abstract Service Definition Emitters Java Interfaces Documentation Other…

33. Phase 2Phase 1 OKI General TimeLine Jan 01Jan 02Jan 03Jan 04Jan 05Jan 06 Initial Core Service DevelopmentFurther Spec. Dev. – “Institute” Ref. Implementations Applications Developer Community Coordination/Support Core Service Maintenance/Evolution Adopter Engagement Vendor Engagement Grant Funded OKI App Activity

34. 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

35. An Example

36. 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

37. Many Repositories IDC iMac I BM Remote Local IDC Institutional

38. 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

39. 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

40. Many Protocols IDC iMac I BM IDC SOAP Z39.50 V2 HTML Z39.50 File System OAI Remote Local Institutional

41. 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

42. 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

43. What is the work ahead? Decomposition

44. What is the work ahead? Finding the right boundaries

45. What is the work ahead? Engaging in a process, not selecting an end state

46. What is the work ahead? Learning as a science –Apply formalism to describe behavior

47. The End & The Beginning longpd@mit.edu