OERInterop-Scenarios

<- Back to OER Interoperability 2007

Motivation

As we have developed the agenda for the meeting we have tried to focus on what end-users (learners, instructors and service providers) need to effectively and efficiently locate and use content.

While we have focused the meeting on “technical interoperability”, we probably need to better define what we mean. It has not been our intent to focus on purely technical standards for learning object interoperability nor to focus on plugging and playing learning objects (in this case “smaller”, “interactive” resources). Instead we chose to focus on including the flow of OER content and enablers for common services/tools across OERs and OER repositories.

We could probably discuss forever the promise and challenges of learning object based approaches—some of the initial leaders in the development of learning objects and related technical standards are participating in this workshop. Rather we wish to focus on what low barrier enablers can we propose to OER providers, and more importantly get participants in the room to adopt, to get a large return on our investment. Our goal is to focus on what we can do now to enable the use of the multitude of OER resources that exist today, bearing in mind the average sophistication of our users. Our ultimate goal is enable increased access to open educational resources worldwide.

About the Scenarios

Each scenario contains a description, the challenges and general enablers. It is our goal to extend this list and work on recommended practices to facilitate the goals of each use case.

1. Content Translation
2. Offline Versions
3. Low Bandwidth/Mobile Versions
4. Upload/Import Course Materials into a Course Management System/Virtual Learning Environment
5. License Compatibility
6. Linking Between Versions
7. Services/Tools Across Multiple Sites
8. Accessibility/Universal Design
9. Creating a Curriculum/Bundling Content
10. Creating a Custom Course (for oneself as a learner)
11. Quality assurance mechanisms in peer-collaboration models
12. Investing in soft technologies for interoperability
13. Sharing and Remixing Rich Media
14. Content Flow - Content that Travels, besides Translation
15. Authoring Courses from Content across Many Sources
16. Additional Scenario 1 - Edit me!
17. Additional Scenario 2 - Edit me!
18. Additional Scenario 3 - Edit me!

General Technical Notes

A technical interoperability framework (e.g. for course/curriculum construction by educators/learners) could be set up independently of all the various sources of learning resources.

Ideally, the repositories would not need to do anything other than expose some metadata about their content (or perhaps permit certain bots/crawlers to browse and construct metadata).

In practice it might be necessary for some to offer a set of interfaces to metadata and internal search engines (if required).

The framework could permit a general search of all the repositories based on profiles of target learners (or the learner's own profile).

Some technologies worth looking into:

• Cocoon - aggregation via XML pipelines - e.g. imagine an XML file describing a course comprised of distributed components - this framework can put all the pieces together on the fly.
• SIMILE - Semantic Interoperability of Metadata and Information in unLike Environments - some work has been done with DSpace - generalise for the various repositories of learning resources. Semantic interoperability will become even more relevant as translation tools become viable and more mainstream. Sometimes the same concept is described using different terms and in different ontologies (in different institutions/fields/continents/....).
• Consider working with Wikia and their new search initiative.

Definitions: In recent conversations, the following definitions have proven useful:

Interoperability: The measure of ease of integration between two systems or software components to achieve a particular goal. A highly interoperable integration is one that can be easily achieved by the individual who requires the result

Integration: The act of getting two systems to work together to achieve a goal, regardless of how difficult or expensive that task might be.

So as we look at the use cases presented above it will be valuable to ask two questions:

1) what is the integration goal that is being described, and

2) to what extent is a highly interoperable approach to achieving that goal of value

Consumers and Providers:

With respect to interoperability and integration it is helpful to categorize software as either a consumer of things or functionality, or a provider (supplier) of things or functionality. A particular software application or system may be both a consumer and provider, and its important to keep these "hats" straight when discussing integration and interoperable approaches.

Goals of Interoperability:

It is also helpful to think about “goals”, relating to scenarios, which truly benefit from highly interoperable approaches. Talking about interoperability in general usually does not move the conversation forward effectively. Here are some example with corresponding example scenarios:

Example Goal - Content Exchange: "We have identified a number of content authoring tools (providers) that look like they could be potential sources of content for a number of learning management systems."

Example Goal - Modularity: “We have identified a number of functional components that want to be inserted into a number of larger systems, perhaps learning management systems, and take advantage of core systems functionality”

Example Goal - Risk Mitigation: “We have a number of choices today and into the future of systems or software applications to achieve a particular goal. We want to be able to make a choice today and know that it will be easy and cheap to swap out for something else later on.”

Example Goal – Enterprise Service Integration: "We have identified a number of applications that students are using for various purposes and a number of systems-of-record that store information about students' particular accessibility requirements. These applications should all be able to determine if their behavior needs to change to meet the needs of the current user."

Many to Many, etc:

Note that "a number of..." is a key aspect of the above example scenarios as an indicator for the value of a highly interoperable approach. If there is "only one" imaginable consumer of a thing or functionality AND "only one" imaginable provider of that thing or functionality, then perhaps there is no need for a highly interoperable approach. A one-time integration achieved through a more straight-forward software development techniques (like defining and consuming a one-off Web Service) may be sufficient.

If there is "only one" imaginable provider of a thing or a service, and a number of potential consumers then that provider will likely drive the particular interoperability approach. The same can be said for the only one imaginable consumer and many providers – the consumer will drive the approach. This often leads to an acceptable level of interoperability for the average user.

However, we usually find that over time we can identify "a number of..." on both sides of the equation for a particular goal, and there is usually somebody who finds themselves in the middle wishing for a higher level of interoperability, and this is where standards begin to become important.

For instance: I use Photoshop for post-processing my photographs. There are many third-party modules that I can "plug" into Photoshop. This is great for me and I can do it myself, without calling a software developer. Adobe dictates the standard. I have now discovered Apple's Aperture and wish those same modules could plug into Aperture. That would make me even happier. As it stands now I would have to call the developers of my favorite modules and try to convince them to write an Aperture version. Not so easy for me. A standard begins to look attractive.

Value Proposition, “precarious values”:

For software developers and project managers, building highly interoperable software is harder than not doing so, and usually more expensive. The immediate value to a project of easing future integration is usually not highly regarded.

Open source projects often assume that ease of integration can be achieved simply through providing source code to the community, regardless of design considerations. Unfortunately this assumes that the person or organization requiring the integration goal will have the software development expertise necessary to do so.

Binary integration, using commonly available technologies is often easier for developers and is therefore the most common approach. It is significantly more difficult to follow a highly interoperable approach, since the standards/specifications/best practices that are designed to achieve high levels of interoperability present a higher hurdle, and for the early adopter this effort comes with little immediate apparent value. This is what Chris Mackie from Mellon has been calling a “precarious value” for Mellon funded projects.

So other, more global questions include: How can we provide incentives a project to follow an appropriately interoperable approach when there may be no immediate benefit to the developer or even to project stakeholders? The benefit is usually clearer for the next project, or the one after that, or for the eventual end users. How and why do we move from integration to interoperability?

Additional Scenarios to Consider

Many states are currently developing statewide digital repositories for use by their teachers and faculty. In Florida, this represents hundreds of thousands of educators teaching 4.5 million students. Faculty want to locate targeted resources easily and quickly using a system that they are familiar with. From one portal, inside a learning management system, they want to search, locate, tag, use, re-use, re-purpose, and contribute content. Think online banking and investing! Think Quicken Deluxe where you can have all your bank and investment information brought to one location automatically. It would be very eneficial to encourage each of the OCW sites to become searchable by federation or harvesting so that these resources can be automatically discovered through federated searching using the content authoring tools within the LMS - Sakai, Moodle, Bb, Bb WebCT, Angel, Desire2Learn - to customize and build their course. Faculty tell us we'll use digital resources if they are accurate, easy to get to from their desktop, and easy to use. Simple and easy are the key words.

Content is critical to the success of any repository. OCW has excellent content. Make it easy to locate and use OCW resources. Make it easy to connect faculty to content.