1. Lightweight Reference Models and the OCKHAM Framework
Martin Halbert
Director for Library Systems, Emory University
ECDL 2002
Monday, September 16, 2002

2. Overview The practical need for coordination of DL development efforts
The DLF OCKHAM meetings
Lightweight Reference Models
Next Steps
Discussion questions
September 16, 2002
OCKHAM / ECDL 2002

3. The Problem Digital library development is complex and expensive
Various DL development communities (in the USA at least) are not working together well
Results are much incompatibility, little common practice, slow progress, and no leverage in investment
If this continues, we are just going to languish and fester
Digital library infrastructures seek to provide integrated access to complex information content
To date this has primarily been accomplished in operational settings by means of very expensive propriety systems that are monolithic, interoperate poorly, and require Byzantine implementation efforts
September 16, 2002
OCKHAM / ECDL 2002

4. The Possibilities
Most DL operations feel quite limited in resources individually
But as a group we are quite large
Better cooperation would lead to mutually beneficial ends through standards
The vast majority of digital library operations are individually quite limited in the infrastructures and tools they can develop or purchase
But as a group we are quite large there is no reason we cannot cooperate toward mutually beneficial ends through standards
What has worked before?
Unix flourished where many monolithic behemoths failed because of its philosophical differences
September 16, 2002
OCKHAM / ECDL 2002

5. The DLF OCKHAM Meetings
Convened to seek out practical possibilities for common architectural approaches and open standards
Hope was to find ways to leverage development costs and foster better interoperation of DL’s
Brought together people from several DL communities for discussions in May 2002
September 16, 2002
OCKHAM / ECDL 2002

6. OCKHAM Activities
Compared major DL architectures for commonalities (OAIS, DNER, etc.)
Analyzed the specific benefits of shared reference models and standardized lightweight protocols
Brainstormed possible collaborative projects
Broadly discussed related issues
September 16, 2002
OCKHAM / ECDL 2002

7. Lightweight Protocols
“Lightweight”, or relatively small and simple protocols seem to have clear advantages over “Full” protocols that attempt to be comprehensive
Successes of protocols considered lightweight is illuminating
Examples: TCP/IP, HTTP, LDAP, and the OAI PMH
September 16, 2002
OCKHAM / ECDL 2002

8. Reference Models
Reference Model: a common vocabulary and description of components, services, and inter-relationships that comprise a system under consideration
Useful as a tool to foster consensus and common understanding in a time of rapid change and/or disagreement
From Carnegie Mellon Software Engineering Institute
Reference model. A reference model is a description of all of the possible software components, component services (functions), and the relationships between them (how these components are put together and how they will interact). Examples of commonly-known reference models include the following:
the Technical Architecture for Information Management (TAFIM) reference model (see TAFIM Reference Model)
the Reference Model for Frameworks of Software Engineering Environments [ECMA 93]
Project Support Environment Reference Model (PSERM)
the Tri-Service Working Group Open Systems Reference Model
Architecture. An architecture is a description of a subset of the reference model's component services that have been selected to meet a specific system's requirements. In other words, not all of the reference model's component services need to be included in a specific architecture. There can be many architectures derived from the same reference model. The associated standards and guidelines for each service included in the architecture form the open systems architecture and become the criteria for implementing the system. Implementation. The implementation is a product that results from selecting (e.g., commercial-off-the-shelf), reusing, building and integrating software components and component services according to the specified architecture. The selected, reused, and/or built components and component services must comply 100% with the associated standards and guidelines for the implementation to be considered compliant.
September 16, 2002
OCKHAM / ECDL 2002

9. Lightweight (Protocol) Reference Models
Builds on successful example of the OAI PMH, clearly understood minimalist concept of metadata distribution, implemented in simple protocol
Leads to developing simple reference models of specific subsystems, with associated simple protocols and standards
September 16, 2002
OCKHAM / ECDL 2002

10. Some LRM Ideas Pathfinder brokerage Electronic reserves syllabi
September 16, 2002
OCKHAM / ECDL 2002

11. Next Steps Agreed to at May DLF meetings
Continue the OCKHAM discussions in DLF and elsewhere
Pursue “catalytic” projects to test and flesh out the LRM concept
Discussed afterwards on listserv
Contextualize via the Keystone Principles
Explore possibility of linkage with OKI
September 16, 2002
OCKHAM / ECDL 2002

12. The Keystone Principles
“A set of principles and action items to guide academic libraries' efforts and establish a foundation for joint future-oriented action based on traditional academic library values”
Developed in 1999 by 80 academic library leaders in Keystone, Colorado
September 16, 2002
OCKHAM / ECDL 2002

13. Keystone Principle Two
“Libraries are responsible for creating innovative information systems for the dissemination and preservation of information and new knowledge regardless of format.”
“Libraries will create interoperability in the systems they develop and create open source software for the access, dissemination, and management of information.”
September 16, 2002
OCKHAM / ECDL 2002

14. The Open Knowledge Initiative
Collaborative project funded by Andrew W. Mellon Foundation, centered at MIT & Stanford, with other participants
“Defining open architectural specifications to support the development of educational software, especially courseware systems”
“Its architecture will provide a modular and extensible development platform for building both traditional and innovative educational applications to help institutions leverage existing infrastructure”
September 16, 2002
OCKHAM / ECDL 2002

15. OKI (cont.)
“The OKI product is designed for broad adoption in the university setting.”
“It will simplify the methods of assembly, delivery and access to educational technology resources, while creating a large collaborative community.”
Cooperating with the IMS Global Learning Consortium and Advanced Distributed Learning initiative
Relatively little contact with the DL development community, apparently
September 16, 2002
OCKHAM / ECDL 2002

16. OCKHAM & OKI
May be that OCKHAM can make faster progress by simply adopting OKI common services API set
Possibility of using OKI standards for DL development efforts will be explored
September 16, 2002
OCKHAM / ECDL 2002

17. Discussion Questions What suggestions do you have for ways to:
leverage DL development costs?
foster better interoperability?
build bridges between various DL communities?
identify initiatives with related aims?
September 16, 2002
OCKHAM / ECDL 2002

18. Contacts/URLs Martin Halbert New OCKHAM URL:
Phone
New OCKHAM URL:
September 16, 2002
OCKHAM / ECDL 2002