Interoperability is defined by the IEEE Standard Computing Dictionary (IEEE, 1990) as “the ability of two or more systems or components to exchange information and to use the information that has been exchanged.” From the user perspective, interoperability is the ability of systems to work together, to “plug and play” without any hassles. The interoperability of a digital learning resource is the degree to which it can run properly on multiple systems and can successfully be used in its potential audience’s computing and learning environments. It also refers to the ease with which an author or developer can modify a resource for adaptation.

Standards and Interoperability

Standards are crucial for interoperability. In practice, there are two kinds. The first are standards that are authored and maintained by organizations such as:

  • The World Wide Web Consortium (W3C)
  • The International Organiation for Standardization (ISO)
  • The Digital Library Federation (DLF)
  • The IMS Global Learning Consortium (IMS)
  • The Aviation Industry CBT Committee (AICC)
  • The IEEE Learning Technology Standards Committee (IEEE LTSC)
  • The Advanced Distributed Learning initiative (ADL)
  • And many, many others (AMMO)

All of these organizations are different in composition, process and legal standing but have the common characteristics that:

  1. Groups of individuals, companies and other “stakeholders” work together to produce technical specifications that anyone can obtain and use. (Rules vary: participation can be by invitation only, by members only, or by anyone. Membership can be for individuals, for organizations or for nations. Fees can be non-existent, minimal, or many thousands of dollars per year. Almost all organizations of this type use a consensus process, but definitions of consensus, rights of appeal, due process, etc. can differ.)
  2. The specifications are maintained by the group that produced them and there are mechanisms by which the “marketplace” can participate or give feedback.

Although it is not accurate to call all of these “standards”, it is common to do so and will be done here. (There is a formal distinction between a “specification,” which tells you what to do, a “de facto standard,” which is a specification that a community has agree to use and a “de jure standard,” which is a specification that has been approved as a standard by an accredited standards body such as the IEEE or ISO (the International Organization for Standardization).)

The second type of “standards” arises from the proliferation of a particular product or group of products in the marketplace. Examples include Microsoft Word, Flash, and Portable Document Format (PDF). Although almost anyone can open and use a Word file, and the Acrobat Reader and Flash plug-ins for Web browsers are ubiquitous and freely available, the intellectual property behind these formats is owned and maintained by single companies. It is acceptable to call these “standard file formats” or “standardized formats” but it is best to avoid calling them “standards.”

Basic Content Interoperability

The first requirement for (re)use of a digital learning resource is that it be able to work in as many relevant computing environments as possible. Issues that impact reusability include:

  • Software that behaves differently (or does not run) on different platforms. (“Platform” is used to denote a combination of hardware, operating system and software environment.)
  • Web content that behaves differently in different browsers and operating systems.
  • Java applets that behave differently on different platforms.
  • Specialized plug-ins that are available for a limited number of platforms.

Since digital learning resources run on desktop and notebook computers , these issues are unavoidable. Nonetheless, it is possible to achieve a reasonable degree of cross-platform functionality. Web content authoring tools can be configured to produce HTML that runs fairly well in most browsers, and many Java applets work quite well on different platforms. Word processors, spreadsheets and image editors have versions that run on a variety of platforms and can convert files back and forth without too much loss of functionality. Formats such as Flash, PDF or QuickTime™ can be read using free plug-ins that are readily available and install themselves when needed (if an Internet connection is present).

Interoperability for Specialized Software

Specialized software presents a lot of reusability problems. For some examples, look at the references to system requirements for Chime (Martz, 2002), WebEQ (Design Science, 2004) and TI-Navigator (TI, 2004). Applications with small markets are rarely as well-supported as standard applications (such as spreadsheets and word processors) and often are developed for only one platform. It is best to stay away from content that is written in a proprietary format that can only be understood by a non-standard tool.

It should be noted that some communities have developed formats such as TEX and MathML that are far from standards in the world at large but that are widely supported within a given community of practice and can safely be used, with the understanding that doing so will limit reusability outside of the community in question.

Course Management and Learning Management Systems

Course management systems (CMS) are being used more and more in education. According to Campus Computing 2002 (Green, 2003), over one-third of college courses used a CMS/Learning Management System (LMS) tool in 2003 and almost half of the institutions participating in a 2003 survey reported strategic plans for deploying a CMS/LMS. The spread of these platforms raises two interoperability questions for authors and users of content:

  • Can content be ported between course management systems?
  • Can content be developed that will run in any course management system?

These questions are addressed by “standards” produced by the IMS Global Learning Consortium (IMS, 2004) and by the Sharable Content Object Reference Model (SCORM) that has been produced and is maintained by the Advanced Distributed Learning initiative (ADL, 2004).

Authoring Tools

Digital learning resources are produced with the aid of general purpose authoring tools and (possibly) tools that are designed specifically for producing learning content . Learning Content Management Systems and Course Management Systems also provide environments for producing digital learning resources by assembling existing assets and objects.

Common general purpose authoring tools include Microsoft Word & PowerPoint; Macromedia Dreamweaver, Flash, Authorware, Fireworks and Director; Adobe Photoshop, Illustrator and PageMaker. Tools designed specifically for authoring learning content include DazzlerMax, Elicitus, IBT Web Authoring, Lectora Publisher, ReadyGo, and many others. There are also products such as HotPotatoes and QuestionMark Perception that can be used for authoring quizzes and products such as RoboDemo and Viewlet Builder that are specifically designed for authoring “software simulations.” See (Nantel 2004) for a review of learning content authoring tools.

See (Chapman, 2003) for information and a review of learning content management systems.

The most important interoperability requirement for an authoring tool or environment is that it be able to ingest and publish content in standardized formats. It does not matter what format is used to store content internally.

Software “Sharability”

It is not uncommon for educators to develop instructional software tools which they wish to share with other educators who will adapt them for their own purposes. Frank Wattenberg suggests several requirements for the effective sharing of software.

  • A clear statement of use restrictions, if any. Ideally there would be no restrictions. If the creator intends to allow modifications, the rights statements should include permission to modify the software.
  • All necessary files packaged with the software in an easily accessible/downloadable form. If modification is allowed, this would include the source code.
  • Complete technical and functional documentation.
  • Software that is designed to be flexible. This might include, for example:
    • Software components that provide parameters to change their behavior. This allows modification / adaptation of use without requiring modification of source code.
    • Software components designed to be used with general purpose tools, for example spreadsheets. This allows the software to be reused by more people because of the wide availability of these tools.
    • Java applets, Shockwave, and other browser-based components that are “scriptable” – designed to be used with Javascript and forms.
  • Stability – the units in question are housed in and maintained by a dependable Digital Library.

See the “Light Applets” project for an example of sharable software developed with these guidelines in mind (Wattenberg, Stewart & Alejandre 2002).

Interoperability for Learning Environments

The interoperability discussed so far is for content, but interoperability is important for learning environments as well. Learning environments rely on what is called “enterprise software,” i.e., software that supports the operations of a school, college, government agency, hospital, or corporation. In the academic world, enterprise software includes databases, Web and file servers, student information systems, financial management systems, human resource systems, facilities management systems, library information systems and, more recently, course management systems.

Among the most important enterprise systems in an educational organization are those that manage the learning process. Interpreted narrowly, these include student information systems and course management systems. Interpreted more broadly, these also include library systems, digital libraries, knowledge and content management systems, portals, Web content development environments, authentication and directory services, and other technologies. Interoperability among these systems is not highly developed. “Single sign-on” has been achieved at many institutions, but the data exchange between course management systems and student information systems is often managed on an ad hoc basis and interoperability among other components is still in its infancy. The IMS Global Learning Consortium (IMS, 2004), the Open Knowledge Initiative (OKI, 2004), the Schools Interoperability Framework (SIF, 2004) and other organizations are creating standards, but it is still early in the adoption cycle.

Granularity Impact on Interoperability

The meaning of “interoperability” of a digital learning resource depends on the granularity of the resource in question.

Interoperability for a raw media file means the ability of others to open it, possibly edit it, and certainly display it. Interoperability for a course refers to its ability to run in a variety of learning environments as well as to the ability of an instructor to modify or select parts of its contents for reuse.

The following table shows how the types of standards and products vary with granularity:

Standards and Characteristics of Dominant Products as a Function of Granularity
Granularity Standards Characteristics of Dominant Products
Content Asset Text and pure HTML are standardized formats for content assets, although HTML produced by most authoring tools is not standards conformant. XHTML is an improvement.

Interoperability is improved by associating appropriate metadata to a content asset.

Content assets are usually edited and displayed using common authoring suites, plug-ins and browsers. For widest use, it is best when no plug-in is needed, or when a plug-in is freely available, automatically downloaded and widely in use, e.g. Flash™ or Acrobat Reader™. Products, plug-ins and formats can be community-specific, as in those needed to produce and display MathML.
Information Object Information objects are similar to content assets. For applets, Java™ is considered a standardized format by some, although it has many platform and versioning issues. There are specification and standards that specifically address test questions. Information objects are similar to content assets in that they generally require a single application to edit and a single plug-in or application to display. The products involved are usually not specific to learning, although it is possible to use learning-specific authoring tools to produce information objects. Look for products whose output can be edited by more commonly available tools.
Learning Object SCORM and IMS specifications are relevant to learning objects. Learning objects whose structure is expressed in XML, even if proprietary, can usually be transformed for use in other environments. Metadata is always important. Working with learning objects may require authoring and editing tools that are built for that purpose. As with information objects, the output is paramount for interoperability. On the delivery side, learning objects that are not tracked require standard server technology, but if data is to be exchanged between the learning object and the delivery system, then products like course management systems and learning management systems must be used to have any degree of interoperability. Assessment engines are also important for learning objects that include quizzes.
Learning Component Learning components are similar to learning objects. Learning components are similar to learning objects although they may rely more on course management technology. If a learning component (e.g. a course) can only run on a particular course management system, it is not very interoperable.
Learning Environment The standards relevant to learning environments are those relevant to IT infrastructure. Learning environments must integrate with registrar systems, library information systems, content and knowledge management systems, etc.

Collection Interoperability

Another area of interoperability is the interoperability of collections or repositories of resources. Standardized metadata, harvesting protocols and search and retrieval protocols play an important role in collection interoperability. The following diagram from the IMS Digital Repository Interoperability specification (IMS, 2004) indicates the scope and complexity of the problem, even for a single repository.

IMS Digital Repository Interoperability Diagram
Image depicting various elements of interoperable digital repositories.
IMS Digital Repository Interoperability Diagram