1. Open Knowledge Initiative Educause Focus Group
Geoff Collier and Robby Robson, Eduworks Educause 2002, Atlanta
Introduce ourselves:
Eduworks – company, qualifications of Robby and Geoff, relationship to OKI (very briefly)
A professional services company specializing in the design, selection and implementation of e‑learning solutions.
Eduworks actively participates in the development of e‑learning standards, and supports organizations in their adoption of these standards.
Involved in the IMS, SCORM, IEEE e-learning standards for a number of years, active participation and leadership positions
Development and implementation of learning management / learning administration systems with schools and vendors
Why being done by an external group – supporting OKI, fairly structured feedback process, looking for unvarnished feedback
OKI Focus Groups at Educause, October Page 1

2. Today’s Agenda Introductions The Open Knowledge Initiative (OKI)
The challenge
OKI architecture and API’s
Open source implementations
OKI community
Benefits for higher education
Focus Group Feedback
Hold questions / comments until after presentation
Introductions:
Each participant briefly introduces themselves, their organization, their role (maybe what their interest is in OKI)
OKI presentation:
Explain that we will first give a brief (15 minute) overview presentation of the OKI initiative, that attempts to clearly focus on the core objectives, deliverables and benefits of the Open Knowledge Initiative.
We will briefly describe the challenge that OKI is intended to address, the OKI architecture as embodied in the OKI APIs, the open source implementations on which some of the partners are working, the OKI community, and the benefits we see for the entire higher education community (schools, faculty, students, and vendors that serve the community)
Focus Group Approach:
Our intent today is to have a relatively structured Focus Group process to get feedback on the key OKI objectives / messages which we have tried to succinctly embody in this presentation.
Therefore, our approach will be to go through a brief presentation, and then to get feedback and questions from all participants after the presentation (hence the limited size of the group).
Is the message clear? Do you see value? Do you see issues? What direction should OKI go in the future?
END
OKI Focus Groups at Educause, October Page 2

3. The Challenge Learning management is an enterprise system
Integration and stability
One size does not fit all
Application of global standards
Learning technology from other industries
Learning management is an enterprise system
Mission critical application for higher education, increasing in criticality every year
Increasing volume and complexity of use
Stability, and the ability to scale to handle increasing volume, is critical
Integration and stability
Integrating infrastructure and other applications
Providing stability when components change
Protecting investments in tools and content
One size does not fit all
More sophisticated users
Ease of use is key
Support for a range of tools and styles
What math needs is not what english needs
Application of global standards
Appropriate application of e-learning standards in a higher education environment
Need for an appropriate model of how to use these standards, including higher ed specific extensions
Learning technology from other industries
Higher education has unique needs, but should be positioned to make use of components from other industries
Higher education needs access to everything
Proprietary or industry-unique interoperability limits opportunities
END
OKI Focus Groups at Educause, October Page 3

4. What is OKI? Architecture Application Programming Interfaces (API’s)
Open source implementations
Community
First and foremost, an architecture physically realized through Application Programming Interfaces
Open source implementations that demonstrate the use of the architecture and provide examples of learning management components
A community of higher education innovators and developers, including school based developers, researchers, and commercial product vendors
OKI Focus Groups at Educause, October Page 4

5. OKI Architecture
Defines points of interoperability between components of a learning technology environment
Defines interoperability behavior at those points
Allows incremental adoption of the architecture
Technology independence
Defines points of interoperability – where?
What services are required to support interoperability of learning in a higher ed environment
Defines interface points between components
Defines the nature of interoperability at those points – how?
Data and behaviors
Supports web services model
It supports a component based view of the world, clearly defining the boundary and interoperability behaviors between components
Allows incremental adoption of the architecture
It can be implemented selectively or a piece at a time – do not have to immediately adopt the entire suite of API's, and do not need to wait until all API's are adopted until you begin to adopt
Can leave some of the APIs ‘unexposed’ … inside an LMS for example
Technology independence
It is not a development framework like J2EE, only the points of interoperability are dealt with by this architecture
Supports multiple protocols – SOAP, SRMI etc. These protocols are evolving too, you don’t want to have to change your system each time there is an improvement.
APIs are written in Java, but are first defined abstractly, with no dependence on Java capabilities
Summary – intended to enables the implementation of an open and extensible architecture for learning technology
Component based, Stable and scalable, Flexible to support higher education needs, Built on global standards
OKI enables interoperability to occur. In a specific implementation, it does not resolve all the dimensions of interoperability, but certainly resolves a number of the behaviors and data interoperability issues. END
OKI Focus Groups at Educause, October Page 5

6. Application Programming Interfaces
API's define how components of a learning technology environment communicate with:
Other learning technology components
Other campus systems
Common infrastructure services
OKI API's are:
Described abstractly and written in Java
Royalty free
Stable – license prohibits modification
Supported by reference implementations and documentation
How to access and provide common services and education services defined by OKI.
OKI API’s:
Important to emphasize the described abstractly message. This description is not Java dependent, and could be implemented in another environment such as C-sharp / .NET.
OKI implemented in Java, because they need a physical implementation and this is their preferred environment.
OKI Focus Groups at Educause, October Page 6

7. OKI Focus Groups at Educause, October 2002 Page 7
This is a conceptual diagram intended to provide a simple visualization of the OKI architecture. OKI is defining the API’s – behavior and data, and nothing else. The business logic and applications that sit behind the API’s can be developed in any way.
Educational applications: Learning management components such as grade book, assessment tools, chat services, etc. Other applications such as student administration and human resources
Institutional Infrastructure such as: Security applications such as Kerberos, LDAP. File management, etc
Educational Services: The API’s that support functions such as search for content, enroll in a learning group, etc (OKI defines). Local implementations of the services behind those API’s, provided by functionality in applications or by standalone tools.
Common Services: API’s that define how a learning technology application accesses an infrastructure service such as authentication, authorization, file service, etc. (OKI defines). Full list – Authentication, authorization, DBC, Logging, LocalID, Shared, Filing, Hierarchy, User messaging, Scheduling, Workflow. Local implementations of services that support those API’s
Shared Objects – Data definition of the objects shared by services (learner, content, etc.) (OKI defines)
Allows system to use service to hide: functions performed in different places, different systems responsible for shared data objects. Don’t want to have to deal with those issues in each application. Abstract it BELOW the API, in the local implementation, so the details of the local implementation are hidden behind the API. You don’t want the LMS to determine which system you go to for what. Nothing is free, you still have to write the code, but it can be abstracted out of the Applications. It’s all about separating out the implementation-specific details so the us of the services is generic in the applications themselves.
Also allows systems to share functionality (Group function for example).
You do not have to implement all APIs, you can implement the ones that provide value to your organization, the areas where you have a need for interoperability. You do not have to use the APIs that address areas where you do not have a need to manage integration with external components. - END
OKI Focus Groups at Educause, October Page 7

8. Open Source Implementations
OKI Partners are providing:
Examples of API Implementation
Examples of Education Components
Royalty free examples can be used in:
Development projects
Vendor products
Not a “free LMS” project
MIT / OKI Open source license shows you how to use it and provides examples of code anyone can use in any way, royalty free.
Does not mean you have to give away anything you build using the API’s
Do not have to post modifications back to the open source community
People can build proprietary and licensed solutions using the API’s, only the API’s have to be exposed.
Partners will choose which part of their applications they share under this license.
Not a “free LMS” project
This does not imply that OKI is distributing and supporting a "free LMS" as a low cost alternative to commercial products. The open source examples provided by OKI partners are not complete, and do not come with a warranty, training, implementation guidelines, support services, a bug fix process, a help desk, or ongoing upgrades. If an organization tries to use OKI software as a basis for a production implementation, the cost of providing this support internally will have to be factored in.
OKI is intended to make it easier to share, implement and stabilize components built anywhere, so in that sense it will make it easier for schools and vendors to do these things. - END
OKI Focus Groups at Educause, October Page 8

9. Projects University of Michigan MIT Stanford University
Course Work – a set of applications around quiz and test
Stellar – Content aggregation and management
Chef – Community model – Learning, teaching and research
Tufts – Visual representation of learning paths, link tool to environment using OKI
University of Cambridge – Learning object tracking, effectiveness
Indiana University - OnCourse
Tufts University
University of Cambridge
Indiana University
OKI Focus Groups at Educause, October Page 9

10. OKI Community OKI founding partners and core collaborators
Working closely with IMS and ADL / SCORM
OKI Developers Network
Begins October 2002
Online developer forum
Access to OKI experts
Technical documentation access
Developer workshops - February 3-4, 2003 in Cambridge, MA
Development of OKI specifications is not an open process
There is a lead architect
Input comes primarily from core collaborators
No direct engagement with vendors and a broader community during this design process
Allows OKI to move quickly in abstract definition and physical creation of the APIs
Ensures that particular vendors do not gain too much influence over the design
IMS and ADL / SCORM provide a place for OKI to engage and bring input from vendors and the broader community
Working to influence those specs / models
Working to provide Higher education requirements to those processes
Working to implement those specifications / models in OKI
OKI Developers Network
The place for vendors and the next level of school implementers to engage with OKI
Contact OKI for specifics on joining / participating.
END
OKI Focus Groups at Educause, October Page 10

11. OKI Benefits
Defines how to integrate learning technology into enterprise infrastructure
Provides stability when learning or infrastructure components change
Provides a stable environment for innovation and sharing between developers and researchers
Supports heterogeneity of learning applications
Creates a common interoperability architecture for higher education developers and for commercial product vendors
Integration - Defines how learning technology / learning management systems can be integrated into a complex enterprise infrastructure.
Stability - Abstraction of the points of interoperability provide a buffering between components of the learning technology environment, so they can change independently without destabilizing one another. The services provided by these components are ‘hidden’ behind the API, so when the local implementation changes it does not affect the components that call / use that service. This protects a school’s investments in tools, content, innovative products, etc. It ‘future proofs’ them against ongoing changes in the environment, and also allows a school to more quickly adopt / implement new infrastructure / scalability components. It also reduces development effort and encourages the development of specialized components that integrate into larger systems. Also allows components to scale without disrupting other components
Innovation and Sharing - This in turn allows developers and researchers (local, community, vendor, etc) to innovate and develop new products that have a clear way to access and provide services. The APIs make it easier to develop these new components (because the APIs provide access to services that do not have to be built into the product), and also buffer the environment and other applications from those new innovations, should they prove to be unstable. This provides a catalyst for cooperative and commercial development.
Heterogeneity - Learning technologies appropriate for a range of teaching and learning requirements can be integrated together into a common environment. The needs of the Math department are not those of the English department, and tools that work well for new users may not be adequate for seasoned users. One size does not fit all. Faculty and researchers can: Select a standard tool, Plug in their favorite tool, Invent their own tool, Not gum up the works
Common Interoperability Architecture – A common approach to interoperability allows schools to take advantage of vendor products and components built at other schools, and integrate these more easily with each other and with local development efforts.
Summary for CIO’s: Those responsible for the technology environment (CIOs, CTOs, System Architects) can use OKI architecture when they build a new learning infrastructure, expand an existing learning infrastructure, maintain a complete learning infrastructure. OKI contributes to their ability to enjoy a scalable and reliable infrastructure. Enables an open and extensible architecture for learning technology - Component based, Stable and scalable, Flexible to support higher education needs, Built on global standards. - END
OKI Focus Groups at Educause, October Page 11

12. OKI Status Partners Current State
Massachusetts Institute of Technology (lead)
Stanford University, Dartmouth College, North Carolina State University, University of Michigan, Indiana University, University of Pennsylvania, University of Wisconsin-Madison, University of Washington, University of Cambridge
Current State
Common Service API's v0.9 available
Educational Service API's being defined
Reference implementations and reference code available
Developers Network introduced
The sense to convey here is one of momentum and broadening influence and involvement. First, building / defining the architecture in cooperation with some of the best minds (and the best schools) in the business. Reaching out to coordinate efforts with key industry groups (IMS and ADL). Then, executing on the delivery of APIs, reference implementations, and other projects. Now introducing further outreach here at Educause and through Developers Network.
Recent uptake by Indiana University for OnCourse is also significant.
OKI Focus Groups at Educause, October Page 12

13. Architecture and API’s
"We intended to enable an open source community that supported innovation and sharing of components and tools within the University. The evolution of OKI in parallel with our work was a remarkably valuable development for us. We were designing a new framework and a set of interoperability API's, and here came a group committed to the same vision, but planning to define a set of API's that are common across all of higher education."
Joseph Hardin
The University of Michigan, OKI Partner Institution
Provide information about the context of the quote. U of Michigan was working on developing a university-wide framework for learning technology, to support innovation and the sharing of components in a stable, scalable environment. Learning about OKI, they saw the benefit of having a common model for all of higher education.
The value of the API’s in supporting people who are developing robust, component-based architectures.
Rather than developing a local set of API’s that can then be plugged into internally and externally developed products, define an industry wide set of API’s that can be adopted by all developers (vendors and higher education teams) that support the sharing and interoperability of components across the entire global industry.
OKI Focus Groups at Educause, October Page 13

14. Focus Group Feedback Communication: Is the OKI message clear?
What material would help you present OKI to others in your organization?
OKI:
Where do you see the value of OKI?
What should OKI do next? Do differently?
Go around and get feedback from each person, building on the answers of others, each person gets 3 or 4 minutes. They do not have to respond to each question. These questions are intended to suggest areas for comment and feedback.
Indicate that there are two areas we are looking for feedback on
1. How well we are communicating the objectives, products and benefits of OKI (including all your knowledge and exposure so far, not just this presentation).
2. Feedback on the objectives, products, benefits and status of OKI. This would include what they need from OKI to use it.
Ask each participant what previous exposure they have had to OKI, and what it was (to evaluate how well we are communicating, we need to know what communication has occurred.)
Capture the feedback, including who provided what feedback. If a person expresses support for a previous comment, capture that, so we know how many people supported a comment.
OKI Focus Groups at Educause, October Page 14

15. Atlanta Marriot Marquis
Contact
Geoff Collier –
OKI web site -
OKI at -
Thank you, and please be our guest at the OKI reception on Wednesday night!
5:30 to 7:00
Atlanta Marriot Marquis
Champagne Room
Who to contact for more feedback or information on the focus groups.
Where to contact OKI, or see more information about OKI.
Please come to reception (except for Thursday folks)
OKI Focus Groups at Educause, October Page 15