The way ahead
The way ahead is a metaphor, chosen to suggest that the eLearning interoperability process is a work in progress, and that on our journey we now need to take stock of where we have reached, and which route to take from here. This is a good summary of the current situation, but the power of a metaphor comes from the richness of its associations, and some of these may be unexamined or ambiguous.
In eLearning interoperability we should not think of a group of eLearning strategists poring over a map, considering the relative merits of the Boulevard Peripherique or taking a wide detour around Paris. Rather we should imagine a trackless wilderness with the travellers doing their best to work out their route by exploring the terrain. They plan a series of coordinated expeditions, hoping to find some high ground from which to get some perspective on the territory. They gather together the results, try to achieve agreement on where they are, and postulate barriers to progress and the best ways to circumvent them.
Taking the second interpretation of the metaphor, we can see eLearning interoperability initiatives as more or less coordinated explorations of various way of achieving more effective applications of Information Technology in education. the relationship between education and technology. Each is explicitly or implicitly informed by theories, ideas and assumptions. These may be different for the various specifications, and should be reviewed in the light of the results of use. Moreover, specifications are developed within a particular technological context, and as this context changes so do the consequences of using any given specification.
In eLearning today there are a relatively small number of successful interoperability specifications, many of them produced or adopted by IMS. They are the product of a great deal of effort and reflection, and a substantial amount of implementation has been carried out to support their use. This is a very valuable resource for eLearning. On the other hand, in order to plan the way ahead reliably we should remember that their development has been an exploratory process. This means that in order to establish where we are now, we should reflect on the context and use of specifications. In particular we should consider:
• Do established specifications lock eLearning into the technology which was prevalent when they were created?
• Are there conflicting underlying assumptions in the minds of various specification developers and user groups. If so, does this have implications at the level of use of the specifications in education?
• Are new needs emerging from education which are putting new requirements on eLearning specifications. Indeed eLearning specifications and other IT applications themselves changing the way that eLearning works, and so shifting the ground under our feet?
When we have answered these questions, we can then address the best way of moving forward.
Technology
As an example of the kinds of strains put on specifications by technical change, let's look at the case of the familiar zip file.
When eLearning specifications first started to be discussed we were back in the age of Multimedia and the CD ROM. One perspective from which Content Packaging, and Simple Sequencing can be viewed is as an effort to enable the material produced for CD ROMS to be sold over the Web. This explains why it was important to include all the resources in a single zip file, which could be delivered either on a CD ROM, or downloaded, with no difference to the performance.
This zip based solution, which was a reasonable one at the time when it was proposed, sat uncomfortably with Web based VLE (Virtual Learning Environment) systems, where pages were delivered one at a time, and where linked pages could easily take the user out of one site and into another. Nevertheless the suite of specifications which is available from IMS, plus some extensions and additions, provides a solid basis for interoperability between VLEs
In a typical VLE, however, most content and all the functionality is still delivered from a single server. There is a trend, however, for the VLE to become disaggregated. There is no longer such a compelling reason to have all the functionality in a single application. It is no longer technically challenging to have a discussion in a web page, or to link this to a WIKI. This is the logic behind the eFramework, which proposes that a range of services will be provided by different providers in different locations. In this context the use of a zip file to deliver a self contained study package is an historical oddity.
IMS LD is a specification which can orchestrate run by a VLE. In this task it is successful, but the question arises of what it's role is if the VLE is disaggregated, and how it can be adapted. No doubt the integrated VLE will not entirely disappear, but it will no longer be the only option.
At a more general level, educational institutions are finding that their students independently can now set up their own web pages, mail accounts, blogs, wikis, etc, and that these are often more powerful than what the institution can provide. Rather than seeking to keep up with the infrastructure provided by the web at large, it would seem more sensible to provide aggregation mechanisms.
These reflections do not mean that the specifications which we have should all be thrown away. The fact that they have structured data means that it is possible to produce imaginative solutions which can make them more flexible. For example, a zip file can be disaggregated, stored, processed, and re-aggregated for transmission in a way which is transparent to the user. Nevertheless, there comes a point where the load of legacy methods and code becomes too heavy, and users start being attracted to non-standard but simpler solutions. This reflection leads to the first of our ways ahead
Ensure that elearning interoperability specifications can handle a world where the VLE is no longer a given, and where radically distributed services and resources are integrated by a wide range of personal and institutional applications.
Underlying assumptions
The xml code which is generated when specifications are used is technical, and seemingly an objective and neutral description of a resource or an activity. Nevertheless, the choice of what to represent, and how to represent it is informed by theory and assumptions. For example the underlying assumption of the SCORM application profile is that learning is carried out by a learner working alone at a computer without the intervention of a human teacher. In some environments this is exactly what is required. In other situations, for example in the support of face to face teaching, it may be that SCORM resources are valuable if an appropriate methodology is used.
Similarly IMS LD was developed explicitly to support large scale distance education. This means, for example, that it assumes the concept of the cohort, and of a distinction between design time and run time. IMS LD is, however, being applied in a number of quite different environments, in some contexts because of its capabilities as a modelling language are required. Similarly it is not yet clear to what extent it will be possible to create design time systems which are truly user friendly for teaching practitioners, rather than professional learning designers. Still more challenging, perhaps, is the definition of small scale learning activities by peer learners, perhaps in a Personal Learning Environment (PLE). It is not immediately clear that the IMS LD specification is necessarily the best solution for defining learning activities in this context.
At a more theoretical level it seems broadly true that the SCORM application profile was developed from a perspective informed by cognitive psychology. This assumes that it is possible to describe the way in which people learn and respond to stimuli with sufficient accuracy to determine the way in which they should be taught.
Pedagogy, from this perspective, should consist of using the tools of psychology to identify the best stimulus at the best moment to lead to the best learning outcomes. This fits well with the use of a "single learner and a computer" approach, and is well suited to the use of computers to model the learner (perhaps using artificial intelligence) so that the ideal learning experience is provided.
IMS LD can also model this approach, but has a quite different focus on coordinating interactions between actors in an environment composed of resources and services. This makes it better suited than SCORM to use by teachers who assume that you cannot predict the results of a learners exposure to learning materials, and that learning is best facilitated through dialogue. These pedagogic issues, and indeed philosophical issues, are deeply entwined with the development and use of the specifications. This is not a criticism of the specifications concerned. Rather we argue that it is inevitable that any educational implementation will be made from a particular perspective. This will inform the way in which it is developed and implemented, and will in this way determine the limits of the ways in which it can be used. It is also true, however, that the limits of use cannot be determined simply by stating that a specification was developed from a particular perspective, or indeed by inspecting an application. The only way in which it is possible to find out the limits of use of a tool is to try it out in different environments with different users who will explore its potential, and even to subvert the intentions of the designers.
The way forward in this respect is to carry out well planned trials to establish the extent to which the benefits of these specifications can be extended to environments which were not those for which they were initially intended, and what the benefits and costs of that extension are.
Institutional aspects
The world of education is changing rapidly. In the UK for example there has been a huge expansion of higher education, which inevitably changes the nature of higher education institutions. Similarly the ideas of the Learning Organisation, and of Communities of Practice are becoming more widely accepted. These changes mean that eLearning is developing specifications in relation to a shifting set of educational needs.
Moreover the impact of IT, and of the successful interoperability specifications themselves, is also changing the way in which education institutions think about themselves and do their business. So it would be quite possible for eLearning specifications to be entirely successful in meeting the needs of education institutions, only to find that they needed to be adapted or extended because their very success changed the nature of the needs of education. What, for example, would be the impact on Higher Education in the UK if the eFramework were to be adopted across the sector. It would surely change the nature of institutions significantly.
In this context the TENCompetence project is significant, because it sets out to provide an integrated standards based infrastructure for a competence based life long learning. Similarly the PLEX project at CETIS proposes a model for eLearning infrastructure controlled by and centred on the learner. Projects like this, in which specifications are used together for learning which is not based on a single institution, or (necessarily) on a conventional qualification structure, may reveal the degree to which eLearning interoperability specifications are tied to the assumptions about the institutional context for which they were designed.
Policy at both the institutional and state level can also be a determining factor for the success of specifications. The SCORM has been heavily promoted by ADL and through funding policies, and has had significant levels of adoption as a result. Similarly the environment within which ePortfolios will be adopted or not will be strongly influenced by the current interest of the UK government in the initiative, and their adoption as a required system by examining or professional bodies.
The way forward in this respect is to analyse the evolving activities and needs of educational institutions, and to examine the degree to which these are met and/or constrained by interoperability specifications. The relationship between institutional and state policy and the success of specifications needs to be clarified, and perhaps coordinated.
Recommendations?? Some random thoughts...
- More research and development as outlined above in italics (expand on this)
- The E Framework
- IMS conformance? (though it is fine to require projects to state their position and what they are going to do).
- There are some "let's have another UNFOLD points" in Vigo's bullet list, which seems OK to me
- Favour of funding Open Source implementations
- Support Creative Commons. That's OK. Maybe we need to talk about CC somewhere.
