EASEL Requirements Specification EASEL D3 EASEL - IST Project 10051 Educator Access to Services in the Electronic Landscape Work Package 2 D03 - Requirements Specification DOCUMENT DETAILS Reference IST-1999-10051/FDE/WP02/D3/P/v0.5 Other references /tt/file_convert/634b3a71e2b881b8bf01c407/document.doc Author(s) Kevin Riley, Thomais Pavlidou (FD), Vincent Wade, Owen Conlan (TCD), John Akeroyd, Paul Sandford (SBU), Dietrich Albert, Cord Hockemeyer, (UoG), Paul Lefrere, (OU), Jan Grant (ILRT), Luigi Romano (UoN), Giorgio Da Bormida, Roberto Trabucchi, Fabrizio Cardinali (GIUNTI Labs), Visibility Internal Ownership Consortium Version 1.2 Version 0.6 31.10.2000 Page 1 Albert, D., & Hockemeyer, C. (2000). State of the art in adaptive learning techniques. EASEL Consortium, D03 Requirements Specification, version 1.0 (pp. 23-38).
Transcript
EASEL Requirements Specification EASEL D3
EASEL - IST Project 10051Educator Access to Services in the Electronic Landscape
Author(s) Kevin Riley, Thomais Pavlidou (FD), Vincent Wade, Owen Conlan (TCD), John Akeroyd, Paul Sandford (SBU), Dietrich Albert, Cord Hockemeyer, (UoG), Paul Lefrere, (OU), Jan Grant (ILRT), Luigi Romano (UoN), Giorgio Da Bormida, Roberto Trabucchi, Fabrizio Cardinali (GIUNTI Labs),
Albert, D., & Hockemeyer, C. (2000). State of the art in adaptive learning techniques. EASEL Consortium, D03 Requirements Specification, version 1.0 (pp. 23-38).
EASEL Requirements Specification EASEL D3
Date 14.11.2000Status Draft
DOCUMENT RELEASE
Accepted by
Ricky Kay, Fretwell-Downing Education
Acceptance date
16.11.2000
DOCUMENT HISTORY
Version Date Status Description Distribution
0.1 03.11.2000 Draft Outline document and Toc generated
Consortium
0.2 09.11.2000 Revision Some FDE bits added incl. CJ input. ARC
FDE
1.0 15.11.2000 Final Formatting changes Commission
Abstract:
This Deliverable reviews the status of IEEE, IMS, OASIS, Dublin Core and other international standards for metadata, interoperability, adaptive learning, Question & Test interfaces and related initiatives in the area of online education. It introduces the EASEL architecture and business model. Relevant viewpoints are presented particularly regarding Learning Object Models and associated metadata issues. Usage scenarios are used in helping capturing the most appropriate requirements. The resulting requirements are tabulated to facilitate the design of the Course Constructor Kit, RDF Search Gateway, Basic Semantic Register and Metadata Repository towards a test assembly that meets educator needs.
2. STATE OF THE ART.......................................................................................................................10
2.1. STATE OF THE ART IN DISTRIBUTED QUERYING.........................................................................102.2. STATE OF THE ART IN METADATA REPOSITORIES.......................................................................152.3. STATE OF THE ART IN ADAPTIVE LEARNING TECHNIQUES..........................................................232.4. STATE OF THE ART IN MODELLING LEARNERS..........................................................................38
3. STATUS OF CANDIDATE STANDARDS.....................................................................................42
3.1. OVERVIEW....................................................................................................................................423.2. THE RELEVANT FORA...................................................................................................................423.3. TIMELINES.....................................................................................................................................493.4. IMPACT OF STANDARDS ON PROJECT AREAS...............................................................................50
5. EASEL REQUIREMENTS AND USAGE SCENARIOS..............................................................57
5.1. REQUIREMENTS IN DISTRIBUTED QUERYING...............................................................................575.2. REQUIREMENTS IN DATA MODELS...............................................................................................625.3. REQUIREMENTS IN METADATA REPOSITORIES.............................................................................665.4. REQUIREMENTS IN LE CONTENT INTERWORKING AND PACKAGING...........................................705.5. REQUIREMENTS IN THE COURSE CONSTRUCTOR KIT...................................................................795.6. OTHER CONTENT ISSUES AND PEDAGOGICAL CONTENT.............................................................82
8. GLOSSARY OF TERMS AND ACRONYMS.............................................................................121
Version 0.6 31.10.2000 Page 3
Published by Fretwell-Downing Education, Brincliffe House, 861 Ecclesall Road, Sheffield, S11 7AE, UK
Fretwell-Downing Education. This document is protected by copyright. Distribution or duplication in any form or processing of the document or any part of it by electronic systems may be done only with the explicit permission of Fretwell-Downing Education.
EASEL Requirements Specification EASEL D3
TABLE OF FIGURES
FIGURE 1: MEMORY STRUCTURES IN THE ACT* MODEL.........................................................................24FIGURE 2: CONTENT AND PERFORMANCE IN COMPONENT DISPLAY THEORY.........................................26FIGURE 3: KNOWLEDGE SPACE AND LEARNING PATH..............................................................................31FIGURE 4: EASEL ARCHITECTURE..........................................................................................................54FIGURE 5: BASIC ARCHITECTURE OF THE SEARCH GATEWAY.................................................................55FIGURE 6: METADATA REPOSITORIES.......................................................................................................66FIGURE 7: THE INTERNAL STRUCTURE OF A METADATA REPOSITORY....................................................67FIGURE 8: PUBLISHING THE DATA............................................................................................................68FIGURE 9: DATA TRANSFER BETWEEN LEARNING CONTENT AND LE UTILISING THE LE JAVASCRIPT API
OR THE CLIENT SIDE DLL...............................................................................................................77FIGURE 10: COURSE CONSTRUCTION KIT................................................................................................79FIGURE 11: RE-USE OF “PASSIVE” SEGMENTED MATERIAL FOR DIFFERENT PEDAGOGICAL SCENARIOS..83FIGURE 12: GRANULARITY OF PEDAGOGICAL DOCUMENTS AND RELATED ISSUES..................................84
Version 0.6 31.10.2000 Page 4
EASEL Requirements Specification EASEL D3
Executive Summary
Deliverables D3 (Requirements Specification) and the closely associated D4 (Evaluation Criteria) have been produced under Contract IST-1999-10051, between the CEC and the EASEL consortium, which has Fretwell-Downing Education (FDE), as the co-ordinating partner. Their scope is to detail the requirements to be met by the demonstrator in the area of on-line educational systems and to define the performance and utility evaluation criteria for the EASEL system and its component developments. The purpose of this scope is to:
Set the stage for the demonstrator, by introducing the EASEL architecture as well as present relevant usage scenarios that the demonstrator needs to satisfy
Review the requirements and outcomes of relevant preceding projects
Identify the most relevant requirements from prior or present initiatives that will form the basis for the construction of EASEL requirements
The main conclusions of this Deliverable are:
The identification and detailing of usage scenarios that helped in the specification of the requirements and that will be of value in their validation.
The capturing of the key requirements, as extracted from major international initiatives in this area
The classification of the requirements so that they can be used to drive the design and implementation of the Course Constructor Kit, RDF Search Gateway, Semantic Register and Metadata Repository towards a test assembly that meets educator needs, and by inference learner needs.
The identification of integration issues that need to be addressed during the design and implementation phases
In the following, an outline of each Section of this deliverable D3 is given:
Section 1 gives a brief introduction of the aims of the project and this deliverable in particular and presents the steps to be taken to fulfil the stated aims.
Section 2 presents the state of the art in relevant areas and leads into the introduction of the EASEL pedagogical environment.
Section 3 presents and explains the status of candidate standards initiatives
Section 4 addresses the EASEL architecture
Section 5 focuses on relevant viewpoints and use cases or scenarios that lead to the most appropriate requirements for the EASEL demonstrator.
Section 6 draws some conclusions from the issues raised in the preceding sections and on the requirements capturing process.
Section 7 lists references including Bibliographic and URL references to relevant initiatives on project web sites.
Version 0.6 31.10.2000 Page 5
EASEL Requirements Specification EASEL D3
1. Introduction
1.1. Overview
The EASEL project will develop and test an online Course Constructor Kit to help course developers in creating and deploying new courses, making use of existing materials and using tools, technologies and standards developed and evolving in ongoing international initiatives. EASEL addresses the need for standards-based provision in the EC’s learning communities' requirements. It will establish a framework to guide the European Community’s ongoing adoption of best practice and participation in the global arena.[EC, 98]
Some of the EASEL participants have been involved in AC367 GESTALT (Getting Educational Systems Talking Across Leading-Edge Technologies): This ACTS Programme project provides trainee access for course discovery in a web-based learning environment, with subsequent delivery of learning materials, and integration with student tracking systems. The emphasis in EASEL is on educator access and influencing the development of international standards.
The needs and expectations of learners for rich and varied sources of learning are increasingly being expressed.
Some of these expectations are described in postings to the [lis-ufi-lifelonglearning]:
“The concept of ‘qualifications’ will become obsolete. Instead we will build our own personal portfolios of learning and development, open and accessible on the Internet.”
“The last thing you want is the technology getting in the way of the learning. If the courseware loads slowly, learners are turned off—not just to that course, but to the entire concept of e-learning.”
Other European–wide expectations are expressed in the PROMETEUS initiative at its launch in March 1999:
optimal strategies for multicultural, multilingual learning solutions,
new instructional and training approaches and new learning environments,
affordable solutions & platforms based on open standards and best practices,
publicly accessible and interoperable knowledge repositories,
Key benefits of web-based learning and performance support are suggested in the following, adapted from online documentation of SupportGate online resources [SUPP], designed primarily for corporate use:
Just in time - Web-based learning and performance support can be available whenever and wherever the learner needs.
Just enough – Students/educators can find and use exactly the piece of instruction or support they need at the moment for the task-at-hand. Why spend 2 hours or 2 days in a class when 5 minutes of learning or a job aid can meet the immediate performance need?
Eliminate travel costs - Travel has historically been the most costly aspect of corporate training. Web-based delivery eliminates travel costs and the time away from the job that travel mandates.
Low cost delivery - An enterprise workforce can have access to hundreds of courses for a fraction of the cost of classroom courses.
Version 0.6 31.10.2000 Page 6
EASEL Requirements Specification EASEL D3
Always up-to-date - With Web-based learning and performance support resources residing on a single Web server, updates are immediately available to all (employees) world-wide.
The novel element of the EASEL project lies in the means of integrating the components drawn from preceding projects and emerging international standards. The proposed integration strategy exploits two mechanisms for enabling the integration: the specification of the interfaces between the various software system components
within the EASEL Architecture; the definition of a metadata format capable of representing the multimedia
courseware resources and their requirements for correct operation. The metadata adhering to the defined format will be developed and deployed in the EASEL demonstrator.
It is the intention of the project to publicise both the object descriptions and the metadata syntax, and wherever possible, to align these with related standards developments both within Europe and globally thus maximising the possibility of their widespread adoption.
The resulting EASEL demonstrator will encompass: Discovery services capable of offering educators the ability to first search, locate and
access through a search Gateway online interactive (multimedia) courseware from Learning Object Repositories and Predefined Assessment Banks, then configure new course offerings from discovered pre-authored material, including resources exploiting adaptive content and interactive assessment.
Online Training through delivery of courseware materials, with the emphasis on associated metadata provided by members of the consortium. The demonstrator will include the following components from the EASEL Architecture: Learning Resources including Adaptive Content Learning Environment for constructed courses Metadata Repositories Search Gateway and Semantic Registry Course Constructor Kit
It is beyond the scope of the project to evaluate the utility of adaptive learning, to conduct widespread user-based trials to engage in re-authoring of learning objects discovered to address QoS, (Quality of Service) client configuration and rendering requirements
for online distance education resources through the specification of network independent LOM schema; these issues were addressed in GESTALT
1.2. Objectives
The more detailed objectives of the project can be presented as following:
Design Objectives:
Demonstrate a viable integration strategy for drawing together the components identified in the EASEL Architecture. The focus of this strategy will be to develop clearly defined object interfaces between key components in the system and a metadata specification for describing the learning objects available.
Implementation Objectives:
Using the modular component approach developed in GESTALT for aggregating course modules into a complete programme of study, EASEL will demonstrate how
Version 0.6 31.10.2000 Page 7
EASEL Requirements Specification EASEL D3
learning objects can be combined to address the needs of the course constructor/educator.
Accessibility Objectives:
Demonstrate how educators can identify the institution or other repository of their choice, irrespective of location, from which they wish to receive their selected course materials - thus anticipating a wide-area open marketplace in the Information Society for online interactive multimedia training;
Provide a light-weight client interface (based on web technology) to the EASEL services, thus offering ease of use to all potential educators with access to a PC with a network connection;
Evaluation Objectives:
The EASEL System will be operational for a period of two weeks at two sites during which time assessment of educators’ responses to the system will be gauged. The sites have a geographical spread to ensure active participation by all partners:
The University of Naples South Bank University, London
The components will be installed on the Internet working test beds by FDE and performance across the various network infrastructures of the communication interfaces within the EASEL Architecture will be measured.
The scientific and technical justification for the EASEL project is based upon the following:
EASEL will explore technologies which can be brought together to offer course constructors an environment in which they can readily combine existing learning objects to create new online educational objects
Much of the technology to support the EASEL trials already exists, having been previously developed under the ACTS and IST Programmes.
The key issues which EASEL will address are the integration of pedagogical adaptation with wider learning technology standards, and emerging Question & Test specification from the IMS.
In this setting, one of the project’s main tasks is the drafting of requirements to be used in the design of the demonstrator. These requirements will emanate from major leading world-wide initiatives. The requirements of the EASEL demonstrator are presented in this Deliverable D3.
This deliverable starts with a ‘State of the Art’ section including requirements developed by key related projects and initiatives such as the requirements of the IMS project, a US initiative, which is attracting a lot of attention world-wide. Version 1 of IMS specifications were published on their web site in February 2000, in which the practical contributions of the EC funded ARIADNE and GESTALT projects are acknowledged. The project partners reviewed these requirements as to their relevancy to the Learning Environment, the resource discovery service, the metadata specification, the enterprise integration and usage scenarios.
The EASEL architecture sets the framework in which project work will evolve. The identification of the various components and the roles they play aids in streamlining and focusing the selection process for choosing the most appropriate requirements that will drive the design phase of the project. This selection process is further fine tuned by identifying suitable use case scenarios that stem out of the architecture and business
Version 0.6 31.10.2000 Page 8
EASEL Requirements Specification EASEL D3
model and their association. The use cases that are also presented in this deliverable will help in directing the design and validate the selection of the requirements as the project progresses.
The resulting set of requirements identified is presented in section 5 of this document and will form the basis for driving the design and implementation of the Course Constructor Kit, RDF Search Gateway, Basic Semantic Register and Metadata Repository towards a test assembly that meets educator needs.
Version 0.6 31.10.2000 Page 9
EASEL Requirements Specification EASEL D3
2. State of the Art
This section presents the current state of the art in the areas that EASEL is actively researching. EASEL is focused specifically on:
Distributed querying of educational content repositories
Educational metadata repositories
Adaptive learning systems and learner models
Courseware resource reuse and re-assembly
In the area of distributed querying, this section identifies the several aspects of querying heterogeneous information sources, including metadata specification and generation, semantic mapping across heterogeneous data models, schema definition using XML/RDF and query distribution techniques and technologies/protocols. Then an overview of current initiatives in the field of metadata repositories flags repository issues and points to standards which may be adopted for the EASEL demonstrator. In the area of adaptive learning and learner systems, this section surveys an illustrative sample of different models of learning then outlines different adaptivity objectives which support various aspects of these models of learning. The adaptive learning system subsection concludes with a review of approaches and dimensions of learner modelling. The area of courseware reuse and re-assembly will be one of innovation for EASEL, and no significant exemplars have so far been identified. The state of the art with respect to standards applied to educational resource delivery, however, is a major area of enquiry in EASEL, and is dealt with in a separate section 3.
2.1. State Of The Art In Distributed Querying
This section is intended to give a general overview of the problems involved with distributing searches across multiple providers. These can be broadly viewed as fitting into the following categories:
Provider discovery: the location of remote providers may be given a priori, or their number and location may be unknown. In the latter case, there is an initial need to actually identify potential providers.
Provider description: linked in with the discovery of remote providers is the requirement to adequately describe the capabilities and contents of a given provider.
Metadata generation: a service provider must provide adequate descriptions (the metadata) of the resources it holds. Strategies for generating these descriptions are discussed.
Query/response expression and delivery: a given query must be delivered to each remote provider (using an appropriate protocol) and the results collected. Since each remote provider may utilise a different schema for their metadata, there is an additional requirement for:
Cross-schema translation: for results from each provider to be comparable, they must be expressed in a common schema. This common schema can either be defined by consensus (ie. each provider agrees to use the same metadata elements) or by labelling components of each schema in such a fashion that the derivation of, and translation to, some middle ground is possible.
The section concludes with a brief list of some current providers of distributed searches.
Version 0.6 31.10.2000 Page 10
EASEL Requirements Specification EASEL D3
2.1.1 Provider Discovery
The first issue with cross-searching multiple resource providers is locating those providers. This can be done in a number of ways: with central (or federated, eg. in an LDAP directory) registration at one extreme, or using the more traditional approach of web search engines to ‘crawl’ links looking for resources.
2.1.1.1 GILS
The goal of GILS (Global Information Locator Service; [http://www.gils.org/]) is “to make it easy for people to find information of all kinds, in all media, in all languages, and over time.” The chosen strategy is to adopt and help evolve international standards for information searching.
GILS Locator records can be used to point to items, catalogues of items, or even catalogues of catalogues. Any level of aggregation can be supported in GILS, and logically nesting of locators can be a powerful navigational aid.
2.1.2 Query/Response Delivery
2.1.2.1 ISO23950 / Z39-50
Z39.50 is a network protocol that allows searching of (usually remote) heterogeneous databases and retrieval of data, via one user interface. It is most often used for retrieving bibliographic records, although there are also some non-bibliographic implementations.
Z39.50-1995, or Version 3 was approved by ANSI at the end of 1995. Technical development of the standard is taken forward by the Z39.50 Implementers’ Group (ZIG), consisting of interested individuals from institutions and companies. The majority of these are North American, but there is an increasing number of European activists.
Z39.50 version 3 was accepted as an ISO standard in March 1997. The new protocol will be known as ISO 23950.
2.1.2.2 RDF
[http://www.w3.org/RDF/]
RDF-the Resource Description Framework-is a framework for metadata; it provides interoperability between applications that exchange machine-understandable information on the Web. RDF emphasises facilities to enable automated processing of Web resources. RDF metadata can be used in a variety of application areas. For example, in resource discovery to provide better search engine capabilities; in cataloguing for describing the content and content relationships available at a particular Web site, page, or digital library; by intelligent software agents to facilitate knowledge sharing and exchange; in content rating; in describing collections of pages that represent a single logical “document”; for describing intellectual property rights of Web pages, and in many others. RDF with digital signatures will be key to building the “Web of Trust” for electronic commerce, collaboration, and other applications.
In February 1999 the RDF Model and Syntax Specification were released as a W3C recommendation.
Model
Version 0.6 31.10.2000 Page 11
EASEL Requirements Specification EASEL D3
RDF uses a directed-graph model to represent resources and literals (nodes of a graph) and resource properties (the labelled arcs from a resource node to another resource or a literal). Resources are identified by URIs; properties form a subset of resources. Primitive container types exist to model sequences, collections (bags) and sets of discrete alternatives.
API
A standard RDF API is currently under discussion and development within the RDF community. While still in the preliminary stages, this opens the possibility of the delivery of RDF using other mechanisms than XML-style serialisation, for example, via CORBA or Java RMI.
Serialisation
The RDF specification defines a serialised form for the transmission of RDF. Alternative syntaxes have been proposed and it is likely that a new standard serialisation will arise from these proposals soon.
In particular, SOAP (the Simple Object Access Protocol), which has grown out of XMLRPC, offers an alternative (but equivalently powerful) syntax for graph serialisation. Information is available at [http://www.oasis-open.org/cover/soap.html].
At the extreme end of distributed querying, the Cycic Friends Network utilises KQML (Knowledge Query and Manipulation Language) to pass partial proof trees between co-operating agents to enable distributed inferencing. The work is interesting but beyond the scope of the EASEL search gateway.
2.1.3 Metadata Generation
Discovery and annotation of resources can be tackled through different means: traditional web-crawling, human cataloguing, automatic classification or some combination thereof.
2.1.3.1 Hand cataloguing
The reliance on keywords stored within a document (in meta tags, for instance) is useful if people who generate resources also accurately categorise those resources. Unfortunately, this mechanism is simple to defeat and on its own gives no indication of the relative importance of an individual resource.
While the most labour-intensive procedure, the use of trained human cataloguers can produce the most reliable results. (Search engines along the lines of Yahoo rely primarily on third-party submissions that include categorisation hints; these undergo a second stage of sanity checking before inclusion.)
2.1.3.2 Automatic classification
Given the disadvantages of human classification there is an understandable interest in the automatic classification of web-based resources against formal taxonomies. Great claims have been made for the capabilities of automatic classifiers; certainly the results seem promising.
As an example, see [http://www.scit.wlv.ac.uk/~ex1253/rdf_paper/] for details of the
Version 0.6 31.10.2000 Page 12
EASEL Requirements Specification EASEL D3
automatic generation of RDF metadata using the Dewey Decimal Classification.
There appears to be some promise in utilising the vast amount of cross-reference information that crawler-based search engines produce to generate relevance scores. For example, the Google search engine [http://www.google.com/] “interprets a link from page A to page B as a vote, by page A, for page B. Google assesses a page’s importance by the votes it receives. But Google looks at more than sheer volume of votes, or links; it also analyses the page that casts the vote. Votes cast by pages that are themselves ‘important’ weigh more heavily and help to make other pages ‘important.’”
2.1.3.3 Annotation
An alternative approach to annotation by resource authors is that of third-party annotation: the use of external metadata repositories to hold relevance and classification information provided by third parties. Subject to scalability issues, this seems a promising direction for peer review of web resources (“Domain-expert organisation A trusts individual B to make value judgements on resources in category C,” etc.)
uses web-of-trust graphs for consumer annotations of real-world products.
It is possible that some combination of techniques (the automatic classification of resources located by link-harvesting quality resources identified by trusted domain experts) will prove to be the most effective balance between cost and scalability.
2.1.4 Interoperability / Schema Translation
There follows a brief description of efforts in the area of metadata interoperability. These may be broadly categorised into two groups: those aiding cross-schema translation (ISO11179) and the attempts to define a common core of metadata elements that may be used by many applications (Dublin Core).
2.1.4.1 ISO11179 and the Basic Semantic Repository
The problem of getting disparate (meta)data repositories to interoperate leads to the notion of a Semantic Registry (or Repository). This is essentially a registry of well-defined concepts and properties. By using elements of the semantic repository as reference points and defining mappings between them and elements of a target schema, it becomes possible to map between two target schemas. The semantics of a particular element of a target schema are then precisely defined according to this mapping. The labels of particular semantic elements can be built up using terms chosen from a formal vocabulary. By identifying synonymous terms for these labels in different languages, the language-neutrality of the semantic registry can be preserved.
Work in the EDI community has lead to the Basic Semantic Repository, constructed according to the guidelines laid down in ISO11179.
Components of a Semantic Registry
The Semantic Repository has three major components: a Control Vocabulary, the Basic
Version 0.6 31.10.2000 Page 13
EASEL Requirements Specification EASEL D3
Semantic Units (which represent properties of Semantic Components) and Bridge Dictionaries. Semantic Components are equivalent to classes in an RDF schema; BSUs are equivalent to properties of those resources.
Control Vocabulary
The prime purpose of the Control Vocabulary (CV) is to provide a set of terms and their definitions from which the labels of the Basic Semantic Units may be built. A secondary function is to hold several terms that have the same meanings (synonyms) and to nominate which of them is the Preferred Term. Only Preferred Terms are permitted in building BSU labels.
Terms in the CV are grouped into classes to provide maximum language flexibility.
Basic Semantic Units
A Basic Semantic Unit, or BSU, has a precisely defined semantic interpretation. The ‘Semantic Labels’ for BSUs are made up of terms from the control vocabulary. BSUs themselves are language-neutral.
Bridge Dictionaries
Bridge directories are repositories in their own right. The function of a bridge directory is to cross-reference the usage of BSUs to another semantic system.
2.1.4.2 Dublin Core
Dublin Core is a set of definitions (semantics) for some common metadata elements. Dublin Core does not specify syntax (although there is a W3C proposed convention for how to represent Dublin Core elements within HTML).
Dublin Core does not specify a search service. GILS-compliant search has been used in combination with Dublin Core semantics in operational implementations.
2.1.4.3 MARC
The MARC (Machine Readable Cataloging) standard provides a combination of syntax and semantics for a range of applications that are primarily bibliographic. (Semantics are more properly described separately in cataloging rules such as the Anglo-American Cataloging Rules.)
2.1.5 Other Interoperability Initiatives
2.1.5.1 Distributed National Electronic Resource: the JISC DNER
The Distributed National Electronic Resource (DNER) is a managed environment for accessing quality assured information resources on the Internet which are available from many sources. These resources include scholarly journals, monographs, textbooks, abstracts, manuscripts, maps, music scores, still images, geospatial images and other kinds of vector and numeric data, as well as moving picture and sound collections. The creation of web portals is a fundamental part of this work.
Work on the DNER has lead to the development of the MIA (MODELS Information Architecture - MODELS is “MOving to Distributed Environments for Library Services”), an architectural model for DNER portals. An expository paper on the MIA is available at
Version 0.6 31.10.2000 Page 14
EASEL Requirements Specification EASEL D3
[http://www.rdn.ac.uk/publications/mia/];
This is similar to the proposed EASEL search-gateway architecture.
2.1.6 Distributed Searching: Current Services
It is not practical to perform comprehensive gathering of information “just in case” you may need it. Even the “all of Web” search engines only sample large sources and often are very out-of-date. An ideal distributed search would not use copies of out-of-date indexes but search all the right sources “just in time” to answer a specific searcher. Given the variable reliability and performance of the public Internet, most distributed searches currently attempt only a few sites at a time.
Some existing services which offer cross-search facilities are given below.
HotOIL (Open Information Locator) is a state-of-the-art distributed search mechanism. It was developed and now being commercialised by the Distributed Systems Technology Centre in Australia. HotOIL features Z39.50 searching and extracting related topics by analysing results (“hyper-indexing”).
2.1.6.2 The National Geospatial Data Clearinghouse
[fgdclearhs.er.usgs.gov/]
The National Geospatial Data Clearinghouse provides a single interface to large and complex collections of environmental data. In this particular version, the user may search up to five sources simultaneously.
Europagate provides a distributed search of European libraries. Each source has different searchable fields. The facility adjusts the user interface to reflect those available across the particular sources selected by the user.
2.1.6.4 Consortium for International Earth Science Information Network
[http://www.ciesin.org/home-page/HPsearch.html]
The Consortium for International Earth Science Information Network supports a distributed search of many different kinds of collections.
2.2. State Of the Art in Metadata Repositories
A metadata repository is a database designed to support the storage, use and retrieval of metadata, ensuring consistency through automated harvesting rather than manual input. With a metadata repository, all the metadata is stored and organised in one place, thus eliminating the risk of inconsistencies that can occur when the metadata is manually re-entered or passed from tool to tool. In EASEL we are essentially concerned with XML repositories. Anna Harvey, in ‘SGML Technologies 1999’, puts the case for XML:
Version 0.6 31.10.2000 Page 15
EASEL Requirements Specification EASEL D3
“XML is on the verge of solving the master problem of global communication. Thanks to its structured and simple nature, it is the only common format that brings independence of data from software”
Probably the most advanced metadata repositories are to be found in the commercial world, associated with delivery of online product catalogues. These are also linked to repositories of metadata schemas, such as Microsoft’s BizTalk and XML.org by OASIS [Alsc, 00]. Our aim in EASEL are not dissimilar, with online catalogues of learning objects envisaged.
A recent publication [Marc, 00] addresses the practical issues in building a metadata repository. This is described as the first guide offering practical business applications for metadata repositories In an effort to help database personnel manage the deluge of data generated by today’s enterprise organisations, Microsoft, Oracle, and other software vendors have spent millions developing metadata repositories. But “repositories are (usually) large and complex, and developers need all the guidance they can get on developing, deploying, and managing them”. Written for ‘DM Review’, this book aims to give that guidance. This vendor-neutral guide provides coverage of metadata sources, standards, and architecture. The accompanying CD-ROM includes a sample implementation project plan, a checklist of metadata requirements, and several models to support specific business functions. It may well provide a useful resource for EASEL.
In [Dove, 00] wider metadata issues are reviewed. Recognising different types of metadata and their function will be important issues in the design of a repository. These metadata types are summarised as administrative, descriptive, preservation, technical and usage in a paper [Gill, 99] offered via the Getty educational web site.
In examining metadata developments of relevance to the environment of educators, the following sources of relevance to the content, size, scope or cost of an educational metadata repository have been explored:
Microsoft Repository TAMINO Repository INFORMATICA Metadata Exchange POET XML Repository White Paper IXIASOFT Interactive Repository PLATINUM Repository FGDC Geospacial Data Clearing House
In addition to these resources which give an insight into the technologies employed and issues surrounding metadata repositories, three examples of the many Internet educational applications of repositories have been explored. These are: Lightspan NICEM, National Information Centre for Educational Media IBM Mindspan Solutions
2.2.1 Microsoft Repository
[msdn.microsoft.com/repository/whatis/goals.asp]
Microsoft’s goal in developing a repository, described below, provides an introduction to the elements of the repository itself. Today’s enterprises are controlled and managed by a large network of computer systems. It has become mission critical to maintain the flow of information throughout the enterprise and to ensure the timeliness and quality of information provided to the individual decision-maker. This is equally true for stretched educators in their own electronic environment.
Version 0.6 31.10.2000 Page 16
EASEL Requirements Specification EASEL D3
Through its Digital Nervous System (DNS) initiative, Microsoft aims to provide all the basic building blocks to run an enterprise in an integrated way. An integrated information architecture requires key technologies, such as databases, middleware, replication services, decision support services, and repositories.
Repository technology is the integration platform for metadata, acting as the hub for data and component definitions, development and deployment models, reusable software components, and data warehouse descriptions. Integrated metadata management provides a global and consolidated view of the structure and meaning of applications and data—information that usually is scattered throughout the enterprise and buried in individual files, catalogues, or databases. Microsoft’s repository technology provides the place in the Microsoft environment to integrate metadata for application development and data warehousing. The technology provides an enterprise with an overview of its information assets, to facilitate sharing and reuse of descriptive information between tools and applications, and most importantly, to assess the impact of changes before they are made.
Sharing and reuse of metadata requires first and foremost an agreement on the metadata structure and semantics. The exact specification of such an agreement is called an information model. An information model ensures that all involved parties can encode and interpret the information that is exchanged. If various independent vendors want to use a common information model, they must embark on a standardisation process.
Microsoft, together with other leading vendors, has developed the Open Information Model, OIM as an industry standard to describe metadata objects in the application development and data warehousing domains. Once an information model has been developed, it needs to be implemented by a repository object management system, which provides global and secure access to metadata described by the model.
Today’s repository market is fragmented and very high-end. Many repository products are focused on centralised management architectures, require extensive customisations, and are intended primarily for data administrators. In contrast, Microsoft Repository is targeted for a much wider audience. With its standard COM and SQL interfaces, it offers an easy-to-use architecture. It ships in Visual Studio and SQL Server—two high-volume products. Including a repository in high-volume products makes it a commodity, thereby providing end-users the benefits of integrated metadata management, which was previously unavailable due to high cost and complexity.
Microsoft Repository is a component of Microsoft SQL Server that provides metadata management services. Microsoft Repository includes the: Open Information Model (OIM) - a core model of shareable and reusable type
descriptions XML Interchange Format - a standard way of interchanging instances of OIM Repository Engine - a repository object management system with COM-based and
SQL-based APIs layered on SQL Server as its storage engine Repository SDK and Modelling Environment - a modelling and administration
environment that includes OIM
The nominal take-up of Microsoft Repository is significant. At March 2000, more than 1,000,000 copies of Microsoft Repository had shipped, over 70 licenses have been signed, and over 50 products based on Microsoft Repository are shipping or have been announced.
In February 2000, a leading electronic learning company, SmartForce (formerly CBT Systems) announced its support for Microsoft’s Learning Resource interchange, LRN, which is Microsoft’s implementation of the IMS online learning content specification. With previous alliances, such as with Platinum, Microsoft has become a leading player in
Version 0.6 31.10.2000 Page 17
EASEL Requirements Specification EASEL D3
the implementation of metadata repository technology for use in the learning environment, and thus becomes a leading candidate for consideration in EASEL.
Tamino is Software AG’s information server for electronic business. The name stands for “Transaction Architecture for the Management of Internet Objects”. Tamino claims to be the first database to store XML information without converting it to other formats, such as relational tables. It integrates relational or object-oriented data into XML structures. Tamino can access data in existing and remote databases that are used by existing applications. Using X-Machine technology, Tamino can also store this data as XML objects. The key technical features of TAMINO are described as follows:
High performance XML object server and metadata repository
The TAMINO XML server is known as the ‘X-Machine’. It is able to handle large volumes of data and handle the requests of many users concurrently and has been designed for URL-based access to XML databases. It cooperates with existing standard HTTP servers which support the Apache API, the ISAPI or NSAPI. The X-Machine’s basic function is to store XML objects in and retrieve them from the respective data sources, in a ‘multi-threaded’ process. It does this based on schemas defined by the administrator in a Data Map. XML objects are stored “natively” in Tamino, considered an essential method to avoid performance limitations. A XML database must be able to store and retrieve any well-formed XML document, even if the DTD is not available.
The X-Machine technology incorporates a high performance, highly reliable XML database nucleus. It implements
performance-enhancing technologies like compression and buffer pool management, and comes close to the concept of “zero administration”
an XML store, a data store of unrestricted capacity holding XML objects in native format.
For the storage and retrieval of XML objects, the X-Machine is supported by a number of subcomponents, briefly outlined below:
XML Parser - XML objects to be stored by the X-Machine are described by their schema stored in Tamino’s Data Map. The X-Machine’s internal XML parser checks syntactical correctness of the schema and ensures that incoming XML objects are well formed.
Object Processor - The Object Processor is used when storing objects in the native XML store. Any SQL data is stored in SQL tables and columns according to the corresponding schema. Support of external data sources is provided by the X-Node.
XML Query Interpreter - The query language for Tamino is XQL. The Query Interpreter resolves XQL requests and interacts with the Object Composer to retrieve XML objects according to the schemas stored in the Data Map.
Object Composer - The Object Composer is used when objects are to be retrieved. Using the storage and retrieving schemas defined in the Data Map, the Object Composer constructs the information objects and returns them as XML documents. The simplest case will be retrieving an object stored natively as XML. In more complex cases, communication with the SQL Engine or X-Node is required to compose an XML object from non-XML data sources.
Version 0.6 31.10.2000 Page 18
EASEL Requirements Specification EASEL D3
Utilities - Various information server utilities are also provided by Tamino. A prime example is support for directory and tree-oriented loading of XML objects (comparable to the mass load and extract capabilities of the SQL Engine).
Single server view by integration of external applications & existing databases
A “single server view” allows data from multiple heterogeneous and distributed data sources to be displayed in a unified form. Via ODBC the Tamino X-Node makes data available from existing databases that remain at their original location. The data can reside in heterogeneous databases (e.g. relational), be stored in file systems or be provided by a message system. Single elements of incoming objects can be stored in different internal and external databases depending on schemas defined in Tamino’s Data Map. XQL queries against the internal databases and the various external database systems connected to the X-Node will be processed. The data is returned to the user in pure XML format.
2.2.3 INFORMATICA Metadata Exchange
[http://www.metadataexchange.com]
This hub site for the exploration of Data Warehousing (DW) issues has the following to say about metadata repositories:
‘A metadata repository is a database designed to support the storage, use, and retrieval of metadata collected from each tool used in data warehouse development and applications, and to make that information available in an appropriate format to the other tools. The more detailed and accessible this metadata, the easier for data warehouse administrators and end users to browse the repository “catalogue” while building analytical reports, and the easier it is to work backwards, via audit trails, to evaluate the quality and consistency of data used in forming these reports. …..In complex applications such as data warehousing where the interaction between technical and business metadata tools are not well defined, a metadata repository is an effective way for these tools to interact.’
The Metadata Exchange provides links and a short description of other resources in through which the state of the art in metadata repositories may be gleaned, including:
The Metadata Coalition – [http://www.he.net/~metadata/]
The Metadata Coalition groups vendors and users allied with a common purpose of driving forward the definition, implementation and ongoing evolution of a metadata interchange format and its support mechanisms.
The Data Warehousing Information Center - [pwp.starnetinc.com/larryg/index.html]
The Data Warehousing Institute - [http://www.dw-institute.com/index.htm]
The Data Warehousing Knowledge Center - [http://www.datawarehousing.org/]
The key points are described in the following extract of a white paper entitled:
‘POET Object Server - The Ideal Repository for XML Data’
“The ideal XML repository should address the needs of XML as well as the needs of the associated applications. In evaluating the requirements of applications in this field, the following criteria are critical:
Version 0.6 31.10.2000 Page 19
EASEL Requirements Specification EASEL D3
scalability, language support, ease of programming and embeddability.
Scalability will be very important since the XML applications described above will run on both the client and the server. It is important that the object database can scale down as well as up, while leveraging the same APIs, to simplify application development. POET is the most flexible commercial database in scaling from laptops to high-end enterprise-wide NT or Unix applications.
Language support is also important. POET maintains a language-independent object model that allows developers to mix and match C++ and Java, even in a single application.
Ease of programming is extremely important due to the compressed development cycles, particularly in the Internet. POET offers the easiest API, without sacrificing functionality or support for standards.
Embeddability encompasses two criteria, zero-management and low memory footprint. Embeddability is an interesting issue since it has both short and long-term ramifications. In the short-term, embeddability it important because most initial XML applications, lacking sufficient XML support in the file system, will build-in this support. However, long-term the object database will replace the standard file manager running on top of the file system. This of course will make embeddability an absolute requirement. Among commercial object databases, POET leads in both zero-management and low memory footprint. It is for these reasons that POET is the leading embedded object database. In conclusion, POET Object Server is ideally suited to provide XML repository functionality.
Because it is a complete and robust object database, POET Object Server-a fifth generation object database-is well suited to the task of storing XML data. However, storing and retrieving XML data is only the start. In addition to standard XML data storage, the ideal repository would offer tightly integrated XML-specific tree navigation, versioning, management of arbitrary links, import/export, publishing of structured content on the web, support for object-oriented programming languages as well as common scripting languages, and more. Building these facilities on top of a object database are non-trivial, yet they are critical to the actual process of managing and manipulating the XML data stored in the object database. POET has built these facilities on top of its object database, and offers this functionality in the POET XML Repository”.
2.2.5 IXIASOFT Interactive Repository
[http://www.ixiasoft.com/Eng/mhome.html]
Ixiasoft employs IRT, Interactive Repository Technology. IRT is the fruit of over ten years of experience in document indexing and publishing technology. IRT offers a robust COM API designed with XML in mind and therefore offers all the performance and flexibility of XML for indexing and publishing purposes. The Ixiasoft TEXTML Server is billed as the ideal tool for creating XML document management solution.
"More than just a document vault or file system, Ixiasoft’s interactive repository technology allows both the database administrator and the document base user to define the structure of the document base and search functions to tailor an intelligent content management solution.
Version 0.6 31.10.2000 Page 20
EASEL Requirements Specification EASEL D3
The Ixiasoft database proposition is interactive because authorised users can add, remove or modify documents dynamically. Such operations generate a real time update of both the indexes and the database to reflect the current status of the database to assure accurate content retrieval. Our technology is interactive because the users can sort, and re-sort, their search results according to parameters that they establish and prioritise. Producing far more relevant content retrieval than pre-determined relevancy rankings based on occurrences or percentages."
2.2.6 PLATINUM Repository
[http://www.platinum.com]
"PLATINUM technology is an active supporter of XML (Extensible Markup Language), a meta language for representing structured information.
Through its support of XML, PLATINUM provides customers with a mechanism for interacting and exploiting the Open Information Model (OIM). Specifically, it enables import and export capabilities with the Microsoft Repository. Through XML, metadata elements can be categorised according to their meaning, rather than how they exist in one particular tool. In addition, external tools can access and use this metadata for maximum reusability.
XML will be supported within PLATINUM’s industry leading Repository/Open Enterprise Edition (OEE) product to provide customers with a solid foundation for using and migrating metadata contained within a variety of technologies into the OIM. PLATINUM provides the ability to extract information from Repository/OEE into an XML format to import into the OIM. This allows users to fully exploit multiple repository configurations and vendors. It also allows PLATINUM customers to leverage their current investments in Repository/OEE without sacrificing the benefits of the OIM. It provides a natural bridge that customers can leverage as PLATINUM converts its Repository product line to the Microsoft Repository engine."
2.2.7 FGDC Geospacial Data Clearing House
[http://www.fgdc.gov/clearinghouse]
The Clearinghouse Activity, sponsored by the US Federal Geographic Data Committee, FGDC, is a decentralised system of servers located on the Internet which contain field-level descriptions of available digital spatial data (i.e. a repository). This descriptive information, known as metadata, is collected in a standard format to facilitate query and consistent presentation across multiple participating sites.
Clearinghouse uses readily available Web technology for the client side and uses the ANSI standard Z39.50 for the query, search, and presentation of search results to the Web client.
A fundamental goal of Clearinghouse is to provide access to digital spatial data through metadata. The Clearinghouse functions as a detailed catalogue service with support for links to spatial data and browse graphics. Clearinghouse sites are encouraged to provide hypertext linkages within their metadata entries that enable users to directly download the digital data set in one or more formats. Where digital data are too large to be made
available through the Internet or the data products are made available for sale, linkage to an order form can be provided in lieu of a data set. Through this model, Clearinghouse metadata provides low-cost advertising for providers of spatial data, both non-commercial and commercial, to potential customers via the Internet.
Version 0.6 31.10.2000 Page 21
EASEL Requirements Specification EASEL D3
Clearinghouse allows individual agencies, consortia, or geographically defined communities to band together and promote their available digital spatial data. Servers may be installed at local, regional, or central offices, dictated by the organisational and logistical efficiencies of each organisation. All Clearinghouse servers are considered “peers” within the Clearinghouse activity—there is no hierarchy among the servers—
permitting direct query by any user on the Internet with minimum transactional processing.
2.2.8 Lightspan
[http://www.lightspan.com]
Lightspan has grown to become a major US provider of online educational resources. The extent of these can be viewed by registering for a 30-day free trial, in which all offerings can be viewed including multimedia Q&T. The results of Lightspan’s efforts are powerful educational software and Internet programs that serve students from kindergarten through college. These programs are making a difference in thousands of schools and educational institutions across the country. Lightspan’s programs include Lightspan Achieve Now™, an interactive curriculum program for K-8 students, as well as an integrated family of Internet products and services for K-12 students offered through Lightspan’s Web site. In an approach to Lightspan for EASEL, an indication of their use of metadata repositories and international standards was requested.
2.2.9 NICEM, National Information Centre for Educational Media XML Repository
[http://www.nicem.com]
The US National Information Centre for Educational Media has developed an online resource, holding over 600,000 items billed as ‘the most comprehensive collection of information about educational non-print materials in existence’. Essentially an XML repository, the database can be searched for materials over a wide range of subject areas. The resulting accessions use descriptors which are different to but can be compared to the standards set in the IEEE LOM.
2.2.10 IBM Mindspan Solutions
[http://www.ibm.com/mindspan]
IBM today launched on May 15, 2000 its newly formed e-learning solutions
business unit, IBM Mindspan Solutions, chartered with providing customers with the capability to plan for, create, and deploy e-learning solutions. In its press release, the scope of the new initiative, piloted in a number of customer sites, appears to be wide
“IBM Mindspan Solutions delivers a full array of e-learning solutions including planning and design services, content capabilities, technologies, and delivery capabilities. IBM Mindspan Solutions leverages IBM’s extensive experience, technologies and worldwide reach to provide organizations with e-learning solutions that solve mission-critical learning needs.
IBM Mindspan Solutions has worldwide reach, utilizing dedicated e-learning sales specialists and an experienced set of worldwide service resources focused on the learning marketplace. These resources include more than 3,400 services practitioners as well as a global content development community with 15 facilities around the world.
Version 0.6 31.10.2000 Page 22
EASEL Requirements Specification EASEL D3
“Our experience in the e-learning marketplace has told us three things.
First, customers demand an integrated solution as opposed to smaller components they have to piece together themselves. Second, because effective learning requires various learning modes, customers demand flexible technology platforms that support these delivery modes. Finally, customers want solutions that provide measurable business results,” said Laura Sanders, vice president of IBM Mindspan Solutions. “Unlike many of the ‘point-solutions’ in the marketplace today, IBM Mindspan Solutions meets these customers’ requirements by providing not only a comprehensive set of e-learning capabilities but service practitioners who are skilled in delivering e-learning solutions worldwide.”
Unlike distance learning, which includes text-based learning and courses conducted via written correspondence, e-learning is focused specifically on the delivery of learning content via all electronic media including the Internet, intranet, extranet, satellite, broadcast, audio/videotape, interactive TV and CD-ROM. According to International Data Corporation, the e-learning marketplace will be $15B worldwide by year end 2002.”
At this time the repository technologies for Mindspan have not been advertised, but may well be worth monitoring during the EASEL project as a principal competitor to the Microsoft initiative summarised in 2.2.1.
2.2.11 Repositories Conclusion
It will be seen from the above summaries and associated references that much activity is taking place in the development of metadata repositories. However, most of this activity appears to be high cost and outside the educational sector. Efficient, lightweight, scaleable and cost-effective fit for purpose solutions present a challenge for the EASEL project. EASEL will monitor developments closely, seeking low cost solutions for educational users under the requirements outlined in section 5.3 of this report
2.3. State of the Art in Adaptive Learning Techniques
In the field of computerised tutoring systems, we first have to consider educational models and theories which were developed independent of computer based systems. As a consequence, we start with a subsection on educational and psychological models about different kinds of learning. Afterwards, we investigate research on adaptive tutoring systems with respect to the objectives of adaptivity aimed at in the various systems, and with respect to the objects of adaptivity including hints to technical realisation.
2.3.1 Different Kinds of Learning1
Introduction
Psychology defines learning as enduring change of behaviour as a consequence of experience as opposed to a change of behaviour as a result of, e.g., maturation. Thus, learning by itself is an adaptive process depending, e.g., on the kind of experience, characteristics of the learning individual and of the situation valid at the moment as well as in the long run. In order to facilitate processes of learning, these dependencies have to be taken into account by a tutoring system in an adaptive way [APA, 97].
1 This description is based fundamentally on the work edited by De Corte and Weinert [CORT96] and done by Kearsley [KEAR99]. Much of the section is taken directly from their work.
Version 0.6 31.10.2000 Page 23
EASEL Requirements Specification EASEL D3
The investigation of learning in cognitive and educational psychology and pedagogy has a long tradition leading to numerous models of learning (and teaching). De Corte and Weinert [Cort, 96] and Kearsley [Kear, 99] have compiled comprehensive articles and lists of such learning models. Besides that, there exist some rather general collections of psychological information including educational models, e.g. [COGP, ENCY]. As a primer, e.g. [Elli, 96] can be used. Information about special characteristics of computer assisted learning can be found, e.g., in [OPEN, 96]. In the following, some selected models with relevance for adaptive learning techniques are described. The described models can be applied to adult learning and education. However, this should be done in a reflective and careful way supported by experts in the respective field (for cognitive psychology, see e.g. [Ande, 98]).
The ACT* Model
ACT* distinguishes among three types of memory structures: declarative, procedural and working memory (see Fig. 1). Declarative memory takes the form of a semantic net linking propositions, images, and sequences by associations. Procedural memory (also long-term) represents information in the form of productions; each production has a set of conditions and actions based in declarative memory. The nodes of long-term memory all have some degree of activation and working memory is that part of long-term memory that is most highly activated.
According to ACT*, all knowledge begins as declarative information; procedural knowledge is learned by making inferences from already existing factual knowledge. ACT* supports three fundamental types of learning: generalisation, in which productions become broader in their range of application, discrimination, in which productions become narrow in their range of application, and strengthening, in which some productions are applied more often. New productions are formed by the conjunction or disjunction of existing productions.
Figure 1: Memory structures in the ACT* model
With respect to teaching, ACT* suggests the following six principles:1. Identify the goal structure of the problem space. 2. Provide instruction in the context of problem-solving. 3. Provide immediate feedback on errors. 4. Minimise working memory load. 5. Adjust the “grain size” of instruction with learning to account for the knowledge
compilation process. 6. Enable the student to approach the target skill by successive approximation.
Activity Theory is based on the notion that human learning is mediated through practical activity; activity is mediated by cultural signs: language, tools, media, and conventions. As the products of learning change, activity changes along with the consciousness of the participants in a continuous, evolving cycle of learning. Activity is fundamental to learning. Proponents of activity theory would argue that it precedes knowledge and there is no understanding apart from it.
Aptitude-Treatment Interaction
Aptitude-Treatment Interaction (ATI) describes the concept that some instructional strategies (treatments) are more or less effective for particular individuals depending upon their specific abilities. As a theoretical framework, ATI suggests that optimal learning results are obtained when the instruction is exactly matched to the aptitudes of the learner. It is consistent with theories of intelligence that suggest a multidimensional view of ability.
The aim of ATI research is to predict educational outcomes from combinations of aptitudes and treatments. The main statements can be summarised as (i) aptitude treatment interactions are very common in education, and (ii) many ATI combinations are complex and difficult to demonstrate clearly, and no particular ATI effect is sufficiently understood to be the basis for instructional practice. Furthermore, the lack of attention to the social aspects of learning is identified as a serious deficiency of ATI research. Learning style differences (see CAL model, below) can be linked to relatively stable person or aptitude variables, but they also vary within individuals as a function of task and situation variables.
Characteristics of Adults as Learners (CAL) Model
The CAL model consists of two classes of variables related to but different from the ATI approach: personal characteristics and situational characteristics. Personal characteristics include: ageing, life phases, and developmental stages. These three dimensions have different characteristics as far as lifelong learning is concerned. Ageing results in the deterioration of certain sensory-motor abilities (e.g., eyesight, hearing, reaction time) while intelligence abilities (e.g., decision-making skills, reasoning, vocabulary) tend to improve. Life phases and developmental stages (e.g., marriage, job changes, retirement) involve a series of plateaus and transitions which may or may not be directly related to age.
Situational characteristics consist of part-time versus full-time learning, and voluntary versus compulsory learning. The administration of learning (i.e., schedules, locations, procedures) is strongly affected by the first variable; the second pertains to the self-directed, problem-centred nature of most adult learning.
The principal requests of the CAL model to adult learning programs are (i) capitalising on the experience of participants, (ii) adapting to the ageing limitations of the participants, (iii) challenging the adults to move to increasingly advanced stages of personal development, and (iv) give the adults as much choice as possible in the availability and organisation of learning programs.
Cognitive Flexibility Theory
Cognitive flexibility theory focuses on the nature of learning in complex and ill-structured domains. Cognitive flexibility here means the ability to spontaneously restructure one’s knowledge, in many ways, in adaptive response to radically changing situational demands. This is a function of both the way knowledge is represented (e.g., along multiple rather single conceptual dimensions) and the processes that operate on those
Version 0.6 31.10.2000 Page 25
EASEL Requirements Specification EASEL D3
mental representations (e.g., processes of schema assembly rather than intact schema retrieval).
The theory is largely concerned with transfer of knowledge and skills beyond their initial learning situation. For this reason, emphasis is placed upon the presentation of information from multiple perspectives and use of many case studies that present diverse examples. The theory also asserts that effective learning is context-dependent, so instruction needs to be very specific. In addition, the theory stresses the importance of constructed knowledge; learners must be given an opportunity to develop their own representations of information in order to properly learn.
Cognitive flexibility theory is especially formulated to support the use of interactive technology (e.g., videodisc, hypertext). Its primary applications have been literary comprehension, history, biology and medicine. One example is the application of cognitive flexibility theory to the design of a hypertext program on transfusion medicine. The program provides a number of different clinical cases which students must diagnose and treat using various sources of information available (including advice from experts). The learning environment presents multiple perspectives on the content, is complex and ill-defined, and emphasises the construction of knowledge by the learner.
The following properties are requested from a system according to cognitive flexibility theory: (i) learning activities must provide multiple representations of content, (ii) instructional materials should avoid oversimplifying the content domain and support context-dependent knowledge, (iii) instruction should be case-based and emphasise knowledge construction, not transmission of information, and (iv) knowledge sources should be highly interconnected rather than compartmentalized.
Component Display Theory Component Display Theory (CDT) classifies learning along two dimensions: content (facts, concepts, procedures, and principles) and performance (remembering, using, generalities) as depicted in Fig. 2. The theory specifies four primary presentation forms: rules (expository presentation of a generality), examples (expository presentation of instances), recall (inquisitory generality) and practice (inquisitory instance). Secondary presentation forms include: prerequisites, objectives, helps, mnemonics, and feedback.
Figure 2: Content and performance in Component Display Theory
The theory specifies that instruction is more effective to the extent that it contains all necessary primary and secondary forms. Thus, a complete lesson would consist of objective followed by some combination of rules, examples, recall, practice, feedback, helps and mnemonics appropriate to the subject matter and learning task. Indeed, the
Version 0.6 31.10.2000 Page 26
EASEL Requirements Specification EASEL D3
theory suggests that for a given objective and learner, there is a unique combination of presentation forms that results in the most effective learning experience
Concept Learning
Concepts represent the fundamental elements of all content areas. In formal content situations, concepts are classes of objects, symbols, and events that are grouped together in some fashion by shared characteristics. An important purpose of education is to provide a learning environment in which student scan both readily learn new concepts and improve the use of acquired concepts.
Conditions of Learning (Gagne)
This theory stipulates that there are several different types or levels of learning. The significance of this classification is that each different type requires different types of instruction. Gagne identifies five major categories of learning: verbal information, intellectual skills, cognitive strategies, motor skills and attitudes. Different internal and external conditions are necessary for each type of learning. For example, for cognitive strategies to be learned, there must be a chance to practice developing new solutions to problems; to learn attitudes, the learner must be exposed to a credible role model or persuasive arguments.
Gagne suggests that learning tasks for intellectual skills can be organised in a hierarchy according to complexity: stimulus recognition, response generation, procedure following, use of terminology, discriminations, concept formation, rule application, and problem solving. The primary significance of the hierarchy is to identify prerequisites that should be completed to facilitate learning at each level. Prerequisites are identified by doing a task analysis of a learning/training task. Learning hierarchies provide a basis for the sequencing of instruction. In addition, the theory outlines nine instructional events and corresponding cognitive processes, i.e. gaining attention (reception), informing learners of the objective (expectancy), stimulating recall of prior learning (retrieval), presenting the stimulus (selective perception), providing learning guidance (semantic encoding), eliciting performance (responding), providing feedback (reinforcement), assessing performance (retrieval), and enhancing retention and transfer (generalisation). These events should satisfy or provide the necessary conditions for learning and serve as the basis for designing instruction and selecting appropriate media.
In short, (i) different instruction is required for different learning outcomes, (ii) events of learning operate on the learner in ways that constitute the conditions of learning, (iii) the specific operations that constitute instructional events are different for each different type of learning outcome, and (iv) learning hierarchies define what intellectual skills are to be learned and a sequence of instruction.
Cooperative Learning
All cooperative learning methods share the idea that students work together to learn and are responsible for one another’s learning as well as their own. In addition to the idea of cooperative work, student team learning methods emphasise the use of team goals and team success which can only be achieved if all members of the team learn the objectives being taught. In student team learning, therefore, the students’ tasks are not to do something as a team but to learn something as a team.
Students team learning requires team goals and team rewards, individual accountability, and equal opportunity for success. Individual accountability means that the team’s success depends on the individual learning of all team members. Thus, the activity of the team members is focused on tutoring one another and making sure that everyone on the
Version 0.6 31.10.2000 Page 27
EASEL Requirements Specification EASEL D3
team is ready for a quiz or other assessment which student swill be expected to complete without team-mate help.
Discovery Learning
“Let him not be taught science; let him discover it” (Rousseau, 1773). With regard to the process of learning it refers to the unique individual experience by which concepts evolve in the mind of the learner rather than being transmitted ready-made. It is the opposite of “reception”, “being told”, or “being passive”. Discovery learning includes inductive learning (that means the subject proceeds from the specific to the general) as well as deductive learning (i.e. the learner begins with a high-order generalisation from which he/she derives more specific conclusions). Discovery is a process of freely searching, selecting, detecting, and solving problems as well as generating and verifying rules and hypotheses (inductive learning), deriving and verifying logical consequences (deductive learning) - reflecting the hypothetical-deductive character of modern science. An important component in discovery learning as well as in scientific discovery is learning and problem solving by analogies.
As another component, confront learning has been investigated. The idea was that confronting students empirically with the inadequacy of the initial concepts would stimulate rejection of the old and the openness to new ideas. Students mostly find ways of reinterpreting the empirical data to fit the initial conceptions, though. Even when they accept the inadequacy of the initial ideas, physical experience and data do not directly suggest new, scientific concepts.
As far as teaching is concerned, discovery learning is often defined in contrast to other methods of instruction called, e.g., “traditional”, “expository”, or “guided”. There exist some views on the level of guidance and the level of discovery learning depending on whether or not the problems, the ways and means, and the answers are given or open. A four level scheme is presented in Table 1; other combinations can easily be imagined.
Table 1: Levels of openness in teaching
Problem Ways and Means Answers
Level 0 given given given
Level 1 given given open
Level 2 given open open
Level 3 open open open
Discovery learning is in close relationship to experiential learning which in more recent conceptions depicts learning as a four-stage cycle. The learner first undergoes a personal experience; second re-examines and reflects on that experience; third, formulates abstract concepts and generalisations; and fourth, tests these in new situations. The learning cycle can be entered by an individual at any of its four stages. In adult education, however, starting with concrete experience is recommended.
Open Learning
There is a strong relationship between discovery learning, experiential learning, and open learning. The latter allows the learner to choose how to learn, where to learn, when to learn, and what to learn as far as possible within the resource constraints of any education and training provision. The main characteristics of open learning are1. It is learner-centred rather than institution-centred.2. It provides a means of equipping adults for self-directed learning.
Version 0.6 31.10.2000 Page 28
EASEL Requirements Specification EASEL D3
3. It implies informal learning and the use of a wide range of teaching/learner strategies.4. It helps in removing barriers to learning, particularly those barriers inherent in the
established patterns of education and training.5. It gives the adult learner more choice by creating a diversity of individual
opportunity.6. It is user-friendly, bringing education closer to the learner who decides on when and
how to engage in the learning task.7. It is in sharp contrast to a supplier-oriented approach to adult education; hence, it has
much to offer in designing powerful learning environments.
While open learning focuses on the offers for the learners, self-directed learning (see below) focuses on the responsibility of the individual.
Open learning - as educational institutions innovative responses to self-directed learning preferences - has spawned, e.g. the most widely known United Kingdom’s Open University, started in 1969, and emulated since in many countries. Currently, development of many distance education efforts using computer-assisted learning is necessitating new research and understanding regarding how technology can enhance self-directed learning in an open and distance learning context.
Self-Directed Learning
In essence, self-directed learning is seen as any study form in which individuals have primary responsibility for planning, implementing, and even evaluating the effort. It can be characterised by the following points.1. Individual learners can become empowered to take increasingly more responsibility
for various decisions associated with the learning endeavour.2. Self-direction is best viewed as a continuum or characteristic to some degree in every
person and learning situation.3. Self-direction does not necessarily mean that all learning will take place in isolation
from others.4. Self-directed learners appear able to transfer learning, in terms of both knowledge and
study skill, from one situation to another (learning transfer).5. Self-directed study can involve various activities and resources, such as self-guided
reading, participation in study and tutorial groups, internships, electronic dialogues, and reflective writing activities.
6. Effective roles for teachers in self-directed learning are possible, such as dialogue with learners, securing resources, evaluating outcomes, and promoting critical thinking.
7. Some educational institutions are finding ways to support self-directed study through open learning programs, individualised study options, non-traditional course offerings, and other innovative programs.
In order to achieve success, (i) adults need to be involved in the planning and evaluation of their instruction, (ii) experience (including mistakes) provides the basis for learning activities, (iii) adults are most interested in learning subjects that have immediate relevance to their job or personal life, and (iv) adult learning is problem-centred rather than content-oriented.
Similar approaches have been introduced under the headings of self-planned learning, autonomous learning, autodidaxy, self-education, andragogy, and empowerment. Self-directed learning is closely related to open learning as mentioned above.
Functional Context
Making learning relevant to the experience of the learner is the key to the functional context approach. New information is related to existing knowledge (information in long
Version 0.6 31.10.2000 Page 29
EASEL Requirements Specification EASEL D3
term memory) and transformed into new knowledge. This transformation is facilitated by cognitive processing skills including language, problem-solving, and learning strategies. Instruction that utilises this approach strives to use the same materials in the training that will be used in the “real world”.
The functional context approach was developed specifically for adult technical and literacy training (reading/writing/mathematics) in military programs, but it has implications for learning of basic skills in general. Functional context theory shares a similar emphasis with Situated Learning theory which also stresses the importance of context during learning.
Situated Learning
Like the functional context approach, situated learning theory argues that learning is a function of the activity, context and culture in which it occurs. Learning occurs as a result of social interaction. This theory is based on Vygotsky’s social learning theory and stresses that social interaction is a critical component of situated learning because learners become involved in a “community of practice” and adopt the beliefs and behaviours of that community. Experts (experienced individuals) within the community often share the beliefs and behaviours of the community unintentionally or model the proper conduct through their behaviour. Newcomers interact with the experts and then themselves move into the community to become experts. This process can be referred to as a cognitive apprenticeship and occurs unintentionally. Cognitive apprenticeship supports learning in a domain by enabling students to acquire, develop and use cognitive tools in authentic domain activity. Learning, both outside and inside school, advances through collaborative social interaction and the social construction of knowledge.
Mastery Learning
The roots of mastery learning are going back to the 19th century trying to transfer components of individualised instruction and tutoring into the classroom with the aim that despite individual differences each student may become a master. Thus, first ideal teaching and learning situations where an excellent tutor is paired with an individual student have been analysed. Second, descriptions of the learning strategies employed by academically successful students have been investigated to identify and distinguish the activities of high-achieving students from their less successful counterparts. Mastery learning is achieved through a learning cycle consisting of (i) instruction, (ii) assessment, and (iii) feedback, correctives, and enrichment. Two essentials clearly differentiate mastery learning from other instructional approaches.
a) Feedback, correctives, and enrichment: The student must receive regular and specific information on his/her learning progress which must be both diagnostic and descriptive; feedback must be paired with specific corrective activities which should be different from the initial instruction. Corrective activities must offer students an instructional alternative, specifically they must present the material differently and involve students differently than did the initial teaching. Enrichment activities provide those students who attained mastery from the initial teaching with exciting opportunities to broaden and expand their learning.
b) Congruence among instructional components: Between the components mentioned above, consistency and congruence must exist. Suppose, for example, a language arts teacher offered students feedback on their learning through short, multiple-choice quizzes on grammar and punctuation, but then evaluated their learning in term of their clarity and precision with which they organised ideas in written compositions. In this case, although students received regular feedback, this feedback clearly was not congruent with the procedures used to evaluate their learning. The feedback students
Version 0.6 31.10.2000 Page 30
EASEL Requirements Specification EASEL D3
receive should always be congruent with the specified learning goals and outcomes and the procedures used to evaluate their learning. They should receive diagnostic feedback based on those criteria, and prescriptive guidance to correct whatever learning difficulties they may be experiencing.
The element of congruence among instructional components has led some to criticise mastery learning as simply “teaching to the test.” Under these conditions, the content and format of the test dictate not only what is taught but also how it is taught. Instead of this, mastery learning teachers are more accurately “testing what they teach.” Identifying the desired learning outcomes, it has to be decided, e.g., what concepts or skills are most important for students to learn and most central to students’ understanding of the subject. Thus, the outcomes are not test performances but competencies and skills. Corresponding to a focus on higher-level learning outcomes, and not simply basic skills, mastery learning seems to be highly effective when instruction focuses on high-level outcomes such as problem-solving, drawing inferences, deductive reasoning, and creative expression.
There is no one best way to implement mastery learning successful. Applications depend, to a large extent, on teachers’ ability to adapt the essential elements of mastery learning to the particular context in which they teach and the unique characteristics of their students.
Knowledge Space Theory and Stochastic Learning Paths
The theory of knowledge spaces developed by Doignon and Falmagne [Doig, 99] applies prerequisite relationships between items (e.g. test problems) of knowledge within a given domain for adaptive assessment, teaching, and training of knowledge. Having formalised these prerequisite relationships through a surmise system, a representation which is equivalent to and-or-graphs, it is possible to determine the knowledge space, i.e. the set containing all knowledge states consistent with the surmise system, through simple operations based on lattice theory.
Figure 3: Knowledge space and learning path
From a mathematical point of view, knowledge spaces are families of subsets of the item set. Their structure can be depicted through Hasse diagrams. Figure 3 shows a small example for a set of four items with a surmise system represented through the and-or-graph with only one and-node in the left diagram. The one in the middle depicts the corresponding knowledge space which contains only seven out of sixteen possible subsets of items. The right diagram illustrate the concept of a learning path through the structure, i.e. it shows one possible path a student might take from the novice having no knowledge of the domain at all to the expert knowing everything within this (limited) field.
Version 0.6 31.10.2000 Page 31
EASEL Requirements Specification EASEL D3
The originally behaviour-oriented approach of Doignon and Falmagne has later been extended by Albert and his research groups in Heidelberg and Graz to take into consideration not only observable problem solving performance but also underlying latent skills and competencies [Albe, 94, Albe, 99]. While the original approach requires experts to specify knowledge about co-occurrences in solving certain problems, in the skill-based approach knowledge about prerequisite relationships within the competencies and between competencies and performances is needed which, for the experts, is much easier to provide and, therefore, results in higher validity and accuracy of the obtained structures.
Conclusion
The models introduced above have more or less in common that they aim at changing the traditional way of teaching where the learners - besides acquiring the knowledge passed to him by experts - had to adapt to a rather standardised and fixed learning environment. An exception to this rule was already in former times the instruction by a private teacher who could adapt to the learner’s specific needs. Adaptive tutoring systems should aim at providing a similar degree of adaptivity as private teachers.
Although the list above is only a selection of models, it already shows that a large variety of demands for adaptivity can be inferred. Before deriving requested properties for meta data standards, a semantic content analysis with respect to synonymity and genus classification is needed. Attempting to realise such a large amount of adaptivity demands simultaneously may even result in contradictions through incompatible demands. As a consequence, we have a closer look at different aims and objectives of adaptivity for which we are confident that they may be realised in a tutoring system simultaneously. By looking at aims and objectives of adaptivity, we mean to investigate what the system may adapt to.
2.3.2 Objectives of Adaptivity
Introduction
One important aspect of adaptivity is the direction towards which the learning system shall be adapted and adapting. Systems realising adaptivity are, in general, developed within the fields of intelligent tutoring systems [Cumm, 99; Ottm, 98] or adaptive hypertext and hypermedia [Brus, 98a; Brus, 98b; Brus, 99; Toch, 99].
Adaptive hypermedia systems (AHS) bridge the gap between computer driven tutoring systems and learner driven educational environments. Two main aims of HS are alleviating difficulties of content comprehension (cognitive overload) and of orientation (‘lost in hyperspace’; [Conk, 87]). Adaptivity is primarily realised through content adaptation and through navigation support.
In the sequel, a more detailed list of possible objectives of adaptivity is given.
Adaptivity to the Learner’s Cultural Background
This is also a more classical approach allowing, e.g., for native language, for familiar measures and weights, or for specific ways of writing things. Especially in the tutoring context, this may, of course, also be extended to cover other local references, e.g. by naming well-known brands, persons, or incidents. This has partly been realised in the ALEKS system [Doig, 99].
This is the classical approach from Human-Computer-Interaction field. The system’s user interface is adapted to the user’s preferences, generally determines through options or preferences menus [Hela, 97].
Adaptivity to the Learner’s Communication Style and Needs
Users differ in their communication style, e.g. in their preference for clear directives vs. a broader freedom of choices. This topic also includes special communication needs, e.g. in case of handicapped learners who may need special input devices with different facilities, or who may be restricted in the selection of for them perceptible output devices. One example for this special type of adaptivity is the AVANTI system developed by Kobsa’s group [Brus, 98a].
Adaptivity to the Learner’s Cognitive and Learning Style
This point is - at least in its realisation - closely related to the former point of communication styles. Learners differ, e.g., in their preferred way of learning material presentation. Examples for considering different cognitive styles are visual, textual, or auditory presentation of information. Different learning styles include the presentation of examples, presentation of theoretical knowledge, and practical exercises. Also more abstract concepts of cognitive styles are suggested (see Section 2.6). An example for a tutoring system adapting according to learning styles is the CAMELEON system by Laroussi and Benahmed [Ottm, 98].
Adaptivity to the Learner’s Knowledge
This type of adaptivity is a central part of research at UoG. Depending on the his/her knowledge, the learning objects made accessible to the learner are determined applying meta information about prerequisite relationships between the available learning objects and the knowledge which is necessary for comprehension. Systems providing such adaptivity based on the theory of knowledge spaces [Albe, 94, Albe, 99, Doig, 99] are the ALEKS system developed by Falmagne and his group, the AdAsTra system by Dowling and her group, and the RATH system developed at UoG.
Adaptivity to the Learner’s Learning Hhistory
The learner’s learning history can be considered in two ways connected to the learner’s learning and communication style, and to the learner’s knowledge, respectively. The knowledge aspect of the learning history deals - besides prerequisite relationships mentioned above - with already existing additional knowledge (including misconceptions) which may need different explanations pointing to connections with this additional knowledge or to differences to other, already known special cases of more general topics, or explicitly correcting existing misconceptions. This approach has been realised, e.g., in the AHA system by De Bra and Calvi [Brus, 98a]. Adaptivity to the learner’s communication style means adaptivity to the learner’s communication behaviour as observed by the system during his/her learning history.
Adaptivity to the Learner’s Expertise
Psychological models of expertise show that novices and experts have quite different ways of acquiring knowledge within their domains. This includes not only different explanation of contents but also different ways of navigation support (more directives towards novices and more freedom towards experts).
Adaptivity to the Learner’s/Teacher’s Aims and Goals
Learners and/or teachers may differ in their conceptions about the aims and goals of the learning. A system could adapt by directing learners towards those contents they (or the teacher) have specified as a goal.
Adaptivity to the Requirements of Different Learning Cultures
Contents, structures, etc. must be adapted to requirements given from outside, often connected with formal or technical demands. Examples are existing curricula which may be predefined by public authorities, or the technical equipment available in a certain school which may depend on the responsible person’s own preferences. In addition to that, material may need adaptation to newly gained knowledge in the field.
Conclusion
The list compiled above shows - although by no means complete, see Section 2.2.1 - a vast variety of possible objectives of adaptivity which would require a high amount of different meta information if all objectives were to be realised. Therefore, it might be reasonable to restrict the development to a subset of objectives of higher importance. A valuable base for such a selection may lie in the question what can and what has to be adapted. The following section tries to giver a first answer to this question.
2.3.3 Objects of Adaptivity
Introduction
The second important aspect of adaptivity are its objects, i.e. the question what is to be adapted according to the objectives presented above. In the following, a list of objects of adaptivity is specified and connected to the list of objectives from the previous section.
Adaptivity of Navigation (Dynamically Generated Learning Paths)
Learning paths can be generated adaptively by offering or recommending to learners access to only those learning objects for which they already have all necessary prerequisites. The underlying user model should not be restricted to quantitative grading and classifying of learners but should include qualitative knowledge about which items of knowledge a learner knows exactly. The learning paths help realise adaptivity to the learner’s knowledge, to the learner’s and/or teacher’s aims and goals, and to the learner’s personal cognitive, learning, and communication styles. For generating learning paths, a model of the domain structure is needed. UoG is experienced in realising learning paths applying the theory of knowledge spaces and its extensions. Such learning paths help reducing difficulties raised by cognitive overload.
Adaptivity of Navigation Support Methods
Navigation support can be given through restriction or through recommendation. The navigation support methods aim towards adaptivity to the learner’s expertise, preferences, communication style, and learning history (with respect to the communication style aspect). Usual techniques for navigation support are link hiding, link annotation, and navigation maps. The appropriateness of these methods strongly depends on the learner’s expertise in the field [Spec, 98; Ottm, 98].
Adaptivity of Documents and their Presentation
Documents can be adapted to the learner in various ways besides the two navigation related ways which are already mentioned above. Adaptivity to the learner’s communication style and needs, learning history (with respect to additional knowledge and misconceptions), preferences, and cultural background is performed through the
Version 0.6 31.10.2000 Page 34
EASEL Requirements Specification EASEL D3
documents’ presentation. This can be implemented, e.g., applying filters or style sheets, or using exchangeable versions of documents or document parts.
Adaptivity to learning cultures and changing knowledge in the field, on the other side, is realised through (manually) changing the contents of the documents stored in the document base.
Adaptivity of the Documents’ Granularity
Depending on their individual expertise, different learners need different granularity of documents. For experts, some technical terms may suffice for a quick overview where novices need more detailed information. On the other side, experts can capture a detailed explanation where novices are overcharged by the high amount of details.
Adaptivity of the Courses’ Contents and Structure
According to changes in the outer requirements and learning culture (including new knowledge in the field), the courses’ contents and structure have to be adapted.
Adaptivity and Automatic Generation of Meta-Data
If course structure are represented through meta-data, these meta-data have, of course, to be adapted after changes in the courses’ contents and structure. Ideally, the generation of structure meta-data should be based on a semi-automatic evaluation of content and prerequisite meta-data.
Adaptivity of the Teacher’s/System’s Teaching Goals
This is again an adaptivity to outer requirements: Like course structures and contents, teaching goals are often specified and changed from the outside, e.g. by educational politics. Such changes must be reflected through accordingly adapted teaching goals within the system.
Conclusion
The list above shows that, similarly to the variety of objectives of adaptivity, we also have a variety of objects to be adapted and methods to be applied. The optimal combination of aims and objectives, and objects and method, however, still has to be found. For this purpose, the internal structure of objectives of adaptivity in a granularity much finer than that above has to be developed first. Using this structure of objectives an adequate granularity and structure for the objects and methods must be derived.
2.3.4 General Conclusion
The psychological models introduced in Section 2.3.1 contain different aspects of “private teachers” and tried to argue that these already can be realised in classroom settings. Today, in a situation where the classroom is more and more replaced and enriched by individual access to tutoring systems, these aspects become more and more important for effective learning and teaching. Moreover, the responsibilities of the learner him-/herself become more and more important - as well as motivational aspects of learning. In Section 2.2.1, the empirical basis and validity of the theoretical concepts have not been investigated which also should be taken into account discussing the construction of tutoring systems. If, however, standardisation of learning objects is the primary focus, considering concrete existing empirical results seems to be less important. However, such standards must be open to give place to nearly any future empirical results. As long as no precise, general, and empirically validated theory of learning exists, it is impossible to examine all aspects of learning and, because of interaction effects more important, their combinations with respect to their empirical consequences for learning and teaching. In
Version 0.6 31.10.2000 Page 35
EASEL Requirements Specification EASEL D3
this situation, the consideration of as many aspects as possible seems to be the best solution.
As the enumeration of models in Section 2.2.1 shows, the conceptual distinction between the different models is often unclear. Actually, there exists a great overlap of concepts described by distinct terms. A consequence of this fact is the need for structuring and unifying the various aspects of the different learning models before using them for defining meta-data components for learning objects. For structuring and unifying these aspects of adaptivity, the principles developed in the fields of knowledge space theory, formal concept analysis, and semantic structures
[Albe, 94] can be applied.
The resulting structure of aspects of adaptivity and the structure of objectives mentioned above (conclusion of Section 2.2.2) should correspond to each other in some way. Developing an adaptive tutoring system which applies such meta-data, again involves the relationship between the objectives and the objects of adaptivity mentioned in the conclusion of Section 2.2.3. This relationship between the structures of objectives and of objects, then, can have a more general nature than that between aspects and objectives of adaptivity. A system adapting to the learner’s cultural background and its structure, e.g., can involve several of the objects. The goal in developing a tutoring system must be to reach as many objectives with as few objects as possible.
2.3.5 Resources – Adaptive Learning
The following list contains scientific or technical societies, conferences, and journals which might be important for the EASEL project. These different types of resources are mixed, since societies, journals, and conferences are often closely related to each other. They are ordered by their directions and from speciality to generality.
W-AIES : Workshop on Adaptive and Intelligent Web-Based Education Systems at the ITS 2000 (see below). This workshop continues a series of corresponding workshops at the AIED’97 and ITS’98. Especially adaptivity with respect to navigation support and presentation and adaptive collaboration support are topics of this workshop. URL: http://www.info.uquam.ca/its2000/w2.html.
AH2000 : International Conference on Adaptive Hypermedia and Adaptive Web-based Systems. This conference continues series of workshops at the ACM International Conference on Hypertext and the International Conference on User Modelling (see below). URL: http://ah2000.itc.it/.
AHH : The Adaptive Hypertext and Hypermedia Homepage contains many important links to resources in the field. URL: http://wwis.win.tue.nl/ah/.
ACM Hypertext : The annual conference of the ACM Special Interest Group on Hypertext and Hypermedia (SIGWEB) traditionally also contains sessions on adaptive hypertext. They also publish the ACM SIGWEB Newsletter three times per year. URL: http://www.ht00.org/.
EARLI : The European Association for Research on Learning and Instruction connects researchers from all areas of learning and instruction (not limited to the tutoring systems field) with a European perspective. They publish a journal, Learning and Instruction. URL: http://www2.unimaas.nl/~earli/earli/default.html.
APA Center for Psychology in Schools and Education . URL: http://www.apa.org/ed/applicat.html.
Psychological Science on the Net : This is a general link page for psychology. URL: http://www.psychologicalscience.net/.
Education.Au Ltd. : This governmental institution co-ordinates the use of internet in education and training in Australia. URL: http://www.educationai.edu.au/.
UoG : The homepage of the Section on Cognitive Psychology contains many resources to the theory of knowledge spaces including a complete list of references. URL: http://wundt.kfunigraz.ac.at/.
JILR : The Journal of Interactive Learning Research, published by the AACE, explicitly includes assessment and authoring systems into its scope. URL: http://www.ace.org/pubs/jilr/.
ED-Media : The World Conference on Educational Multimedia, Hypermedia & Educational Telecommunications is organised by the AACE and is closely related to the Journal of Educational Multimedia and Hypermedia (JEMH). URL: http://www.aace.org/conf/edmedia/ and http://www.aace.org/pubs/jemh.
WebNet : The Annual Conference on the WWW and Internet is organised by the AACE and is closely related to the WebNet Journal. URL: http://www.aace.org/conf/webnet/ and http://www.webnetjrl.com/.
AIED : The International Artificial Intelligence in Education Society organises biannual conferences and publishes the International Journal on Artificial Intelligence in Education (IJAIED). URL: http://www.cbl.leeds.ac.uk/ijaied/aiedsoc.html and http://www.cbl.leeds.ac.uk/ijaied/home.html.
ITS 2000 : The International Conference on Intelligent Tutoring Systems in Montreal is a central conference in the area of tutoring systems with a rather broad spectrum. URL: http://www.info.uquam.ca/its2000/.
ICLS 2000 : The International Conference of the Learning Sciences is strongly engaged in including educational scientists into the tutoring systems field. URL: http://www.umich.edu/~icls/main.html.
ICCE/ICCAI 2000 : The International Conference on Computers in Education and International Conference on Computer Assisted Instruction 2000 is organised by the Asia-Pacific Chapter of the AACE. URL: http://icce2000.nthu.edu.tw/ and http://www.apc.src.ncu.edu.tw/.
New Review of Hypermedia and Multimedia : This journal is a central resource for new research results in the area of hypertext. URL: http://www.comp.glam.ac.uk/~NRHM/.
UM : The non-profit organisation User Modelling Inc. organises the biannual International Conference on User Modelling and publishes a journal User Modelling and User Adapted Interaction (UMUAI). URL: http://www.um.org/.
CHI2000 : Conference on Human Factors in Computing Systems. This conference, organised by the ACM Special Interest Group on Computer-Human Interaction (SIGCH), is a central conference in the Human-Computer-Interaction field. URL: http://www.acm.org/chi2000/ and http://www.acm.org/sigchi/.
International Journal on Human Computer Studies: This journal, formerly published as International Journal on Man-Machine Studies, has a very high reputation and a rather broad scope including artificial intelligence and human computer interaction issues.
A user model contains explicitly modelled assumptions that represent the characteristics of the student which are pertinent to the system. The system can consult the user model to adapt the performance of the system to the students characteristics. User modelling allows the system to personalise the interaction between the student and the contents. To achieve effective learning this personalisation should put the content in a context which the student can understand and relate to. There are several techniques for modelling the student and honing this model.
The Stereotype ModelCreating fixed stereotypes is one of the simplest ways of user modelling. New students are categorised and the system will customise its performance based on the category which has been set for the student. A common example would be the notion of novice, intermediate and expert users within a system.
The Overlay ModelThe overlay model is widely used in the adaptive hypermedia systems in the educational domain. A model of the student’s knowledge is constructed on a concept-by-concept basis and updated as the user progresses through the system. This allows for a flexible model of the student’s knowledge for each topic [Brus, 96].
For this model the knowledge domain must be modularised into specific topics or concepts. The complexity of the model depends on the granularity of the structure of this domain knowledge and the granularity of the estimation of the student’s knowledge. This estimation is build up by examining the sections the student has read and the test he has performed.
The Combination ModelThe Stereotype and Overlay techniques of user modelling are often combined in educational adaptive hypermedia systems. The student may be categorised by stereotype initially and then this model is gradually modified as the overlay model is built from information acquired from the student’s interaction with the system.
2.4.2 Building The User Model
There are a number of sources of information which may be used to construct a user model. The system acquires data about the user and infers user characteristics from this data. The validity of the assumptions depends on the technique used to acquire the information. Automatic modelling by the system may be unreliable. Any inferences made by the system about user characteristics are ultimately a guess [Espi, 95]. For this reason collaborative and cooperative modelling is frequently implemented. The user describes pertinent characteristics directly. The user can provide feedback directly to the system by filling out questionnaires and forms. Indirect feedback is acquired is acquired from the results of exercises or problem solving tasks set by the system. The system may also track the mouse clicks and keyboard strokes of the user to track their navigation path through the system.
Version 0.6 31.10.2000 Page 38
EASEL Requirements Specification EASEL D3
2.4.3 User Properties
The properties chosen to represent the user should be pertinent to the potential customisation by the system. The characteristics may be described in a binary, qualitative or quantitative manner. User characteristics which may influence how the user interacts with an educational system are the user’s objectives, preknowledge, cognitive style, learning style, maturity, general ability, confidence, motivation, preferences and background.
ObjectiveThe objective or goal of the user is a description of what the user is trying to achieve. This may be inferred by the context of the content. The system may infer that when a user follows a specific path it is because the immediate objective is to learn the piece of knowledge to which the paths leads [Eklu, 95]. The user may have to specify their own objectives explicitly and are therefore made more aware of their own learning objectives. Users of adaptive Hypermedia systems have been shown to be more goal-oriented.
PreknowledgeThe rate and manner in which a learner assimilates knowledge is dependent on the learner’s previous knowledge of the subject.
Adaptive systems need to gauge the level of prior knowledge of the student and then monitor the user’s mastery of concepts and build upon the knowledge acquired by the student as they progress through the course. Direct feedback or test results may be used to infer the knowledge of the user at the start of the course. The system should then recognise changes in the user’s knowledge as they progress and update the user model accordingly. Support can be gradually phased out as the student’s knowledge increases [Paol, 98].
Cognitive StyleThe computer can be used as a cognitive tool to develop higher order thinking skills. Learners who learn by associating and linking different ideas and information will be more effective at learning in a Hypermedia based system. Such learners think, perceive and solve problems in an active, exploratory manner. They exercise strategic analysis of the meaning of the subject matter [Dao, 98]. Active learners who are confident in their learning strategies regardless of the subject matter are called field independent learners. Cognitive styles which are critical and field independent are more conducive to the effective use of educational hypermedia [Paol, 98]. Hypermedia systems need to allow for different cognitive styles and attempt to nurture a more analytic cognitive style in students who adopt surface processing of the content [Dao, 98].
Learning StyleThe learning style of a particular user changes depending on the time and context and mood of the learner. The factors which may affect learning style include the user’s physiological and psychological state, the prevalent cognitive style of the user and their prior experience of Hypermedia in general and the course content in particular [Paol, 98]. Field independent learners are better hypermedia learners. Learners may have a holistic learning style and wish to understand the context of the material they are learning. A learner with a serial learning style may tackle a new subject with a step-by-step approach [Dao, Parent, 98]. These learning styles correlate with the specific and generic mental models which are constructed in the mind of learners. It has been claimed that learners may be able to process information more effectively if it is presented in a manner that is closely matched by their learning style [Paol, 98].
Version 0.6 31.10.2000 Page 39
EASEL Requirements Specification EASEL D3
MaturityHypermedia systems do not teach but provide the student with the means and opportunity to learn of their own accord [Eklu, 95]. The student needs to have acquired the skills to apply appropriate learning strategies to each learning task. The student must be able to take responsibility for their own learning and organise the learning environment in a manner that suits their own learning style [Paol, 98]. Adaptive Hypermedia systems need to take account of the sophistication of the learning skills of the user.
General AbilityThe intelligence of the user is a factor in their ability to assimilate information. An adaptive system can take the general ability of a user as sourced from Grade Point Average or Psychometric testing and use this as a measure of how much guidance and support the user may require [Paol, 98]. The aim should be to give the user as much freedom and independence as they are capable of managing effectively.
ConfidenceUsers who are inexperienced in a Hyperspace environment or who are new to the subject matter of a course are more likely to exhibit sequential behaviour i.e navigating forward and back only [Eklu, 98]. These users do not digress from a linear path because they are afraid of becoming disoriented and confused. Adaptive systems should provide security for these users to embark on non-linear paths and be confident that they will be able to cope and find their way to the information they require.
A common feature of learners who are navigating in a non-linear way is the lack of a feeling of closure when a task or course is completed. Because there are so many possible paths, the user is not confident that they have covered the entire information space. Adaptive Hypermedia systems can display the progress of individual users so that they know what has been covered and where. Users can then have the confidence to use greater initiative in their navigation [Eklu, 95].
MotivationSources of motivation are as varied as the users themselves. There are extrinsic motivational factors such as exam results, degrees or certificates and improved career options. Intrinsic motivation is crucial to the Constructivist learning process and can be improved by maximising a learner’s control and independence. However novices may lose motivation if they are given too much freedom and their confidence deteriorates. An adaptive system should maximise motivation by emphasizing interactivity and providing feedback to the learner. It should also provide guidance and support when required. For example intelligent online help systems which sense if the user is having difficulty.
PreferencesUsers preferences should also be incorporated into the user model. These preferences are an adaptable rather than adaptive change to the user model and may include preferred colours, preferred technology or media.
BackgroundThe user’s background may include their profession, work experience, beliefs and hyperspace experience. The user would ordinarily supply this information directly and the system may operate a stereotype model for targeted users.
Version 0.6 31.10.2000 Page 40
EASEL Requirements Specification EASEL D3
2.4.4 Metadata Standards for User Modelling
PAPIPAPI [PAPI, 98] is the IEEE Public and Private Information Specification which is a standard format for the representation and communication of student profiles. The purpose of the specification is to allow the creation of student records which can be communicated between educational systems over the lifetime of a learner.
The profile information for a learner is divided into four areas.1. Personal Information which is for private consumption such as the student’s name,
address and Social Security Number.2. Preference information which may be for public consumption, such as the technology
available to the student, the learning style of the student, physical limitations or disabilities. This information is collected with the cooperation of the student, i.e. it is negotiated.
3. Performance information which is for consumption by technology. This consists of the observable behaviour of the student and may include grades, reports, logs.
4. Portfolio information which is for consumption by humans, such as the student’s accomplishments and works.
The PAPI specification also incorporates the Dublin Core metadata element set.
The information used to construct the user profile is inferred by the system, directly input by the user or is constructed by the user and system in collaboration. PAPI will also discuss the privacy and security issues involved in the storage and communication of user profile information.
GESTALTGESTALT (Getting Educational Systems Talking across Leading Edge Technologies) [GEST, 99] which is funded by the ACTS project, is an educational environment for online learning which extends the IMS metadata definitions. A user profile is constructed from information acquired from the user by asking the user to complete forms displayed by a wizard. The user model is created as an XML document which is then stored physically on the user’s machine. The profile information stored includes the user’s educational history and technology available to the student.
Some of the profile details acquired include personal details, contact details, qualification details, skill details, learning preferences and mode of delivery. The learning preference is stored as a boolean value of ‘Yes’ or ‘No’. The user profile is created as an XML document that will be stored physically on the user’s machine.
Version 0.6 31.10.2000 Page 41
EASEL Requirements Specification EASEL D3
3. Status of Candidate Standards
3.1. Overview
Unlike many standards and specifications activities, those focussed on learning technologies will impact all sections of society. Education and training are becoming increasingly important and on-line access to such materials, processes and systems will dominate developments for the next ten years. Historical precedence shows that the vision of a single set of fully integrated standards and/or specifications is unrealistic. Initially, the reality will be a world with many similar competing and/or complimentary standards and specifications. Over time one camp will eventually dominate, but the question is which.
This section attempts to clarify the current status of the various standards and specifications for learning technologies currently under development. As such, it addresses and predicts those activities as of summer 2000. It is important to note that the rate of development of issues is this field is very fast and as such care should be taken to ensure ongoing tracking of the standards formation process to ensure that events are as anticipated.
Unlike many standards activities, the field of learning technologies has two distinct ‘camps’:
Higher education – which is more concerned with developing principles and philosophy capable of addressing a wide range of novel developments and applications;
Industry – which is more pragmatically focussed on developing standards that can be adopted and implemented very rapidly and which address many of the current real issues as opposed to attempting to predict all possible future developments.
3.2. The Relevant Fora
The following fora are formally recognised standards bodies that are active in specifying technology standards relevant to education and or training:
Of these, IEEE is by far the most advanced in its work programme and both the CEN and ISO groups have committed to aligning their work with the outputs from the IEEE. ISO/IEC JTC1 SC36 is still under formation and is currently canvassing national bodies (BSI for the UK) as to which countries will be participants, observers or non-participants[IEEE, 97].
There also exist a number of consortia (each generally either industry or education sector-based) which whilst not enjoying formal recognition, are nevertheless driving specifications. The intention being to advance consensus in online learning technology and techniques within their communities with specifications which are often ultimately intended to be submitted to one or more of the above bodies to gain formal recognition. These groups include:
Aviation Industry CBT Committee (AICC);
Version 0.6 31.10.2000 Page 42
EASEL Requirements Specification EASEL D3
Instructional Management Systems project (IMS);
Advanced Distributed Learning Initiative (ADL).
Of these, the AICC is most advanced in its work, although the focus here is on CBT training and much of their model stems from LAN-based delivery of CDROM materials. Members of the AICC therefore have to deal with migration of their own legacy systems to the newer online paradigm.
The IMS project is a US-based activity (though with growing international participation) which is focused on educational online learning. It has a wider membership of existing and would-be system vendors as well as US HE institutions. UK HE and FE are represented by the UK IMS Centre funded by JISC.
ADL is a US military programme which is attempting to fast-track standards, drawing on the best work emerging from both the AICC and IMS. Both of these groups converge on the IEEE, but ADL is attempting to anticipate what will emerge from the IEEE. The ADL have been particularly successful in driving acceptance of the content API within AICC and lately the IEEE. More recently, they have taken the AICC Computer Managed Instruction ASCII-based Data Model specification and (with a sub-group of the AICC) reformulated this in XML. This solution is now being promoted back to the AICC to accelerate the translation of the CMI Data Model to operation over the content API. As such, the ADL is not generally making its own specifications, but applies pressure to advance the specifications it would wish to adopt within its reference model. Further details of the ADL work can be found at www.rhassociates.com/ADL-TWG.
Lastly, there are more general consortia such as the Dublin Core (who have formed an education sub-group) and the World-Wide Web Consortium (W3C) which is developing many of the specifications (e.g. XML, RDF, XML schema) which these other groups are building upon.
The IMS (until January 2000, “Instructional Management Systems”) project is a US initiative, driven by EDUCAUSE and incorporating 600 educational institutions across the USA. The original project ran until December 1999, and was then transformed into a ‘non-profit’ incorporated organisation. The consortium also includes a number of industrial partners, many of whom have made a significant financial contribution to the project as investment members of IMS. Over and above the substance of the work, it is this direct participation by a large number of multinational corporations that has fuelled global interest in the IMS and has led to the setting up of satellite IMS centres in Australia, Canada, Singapore and the UK operated by local agencies.
The IMS started work with the academic community in the US in constructing a detailed requirements specification for online learning. This was originally intended to be followed by a pedagogically and platform neutral, functional specification and design leading to a reference implementation which would then be used by others as guidance for their subsequent commercial developments. The original draft specification did not prescribe the distribution environment to be adopted and by way of demonstration, played equally to both CORBA and DCOM. The increasing involvement of the vendor community (each with very strong views on the tools, protocols and technologies to be used for the delivery platform, development environments and management systems) the IMS vision has been broken down into a number of fairly modular areas. Members are able to participate in the specific areas with which they are most concerned.
Version 0.6 31.10.2000 Page 43
EASEL Requirements Specification EASEL D3
Key areas include: E-Commerce Enterprise Systems Metadata Question & Test Security Content Management Profiles Conformance Testing
Of these, the metadata specification, which has been developed in collaboration with the IEEE LOM working Group, has had the most interest amongst IMS members and the specification was released on 2nd September 1999 as a set of three documents: IMS Learning Resource Metadata Information Model v1.0 IMS Learning Resource Best Practice and Implementation Guide v1.0 IMS Learning Resource Metadata XML Binding Specification v1.0
Whilst remaining firmly within the IEEE LOM structure, IMS has identified a core set of metadata elements which it has recommended for implementation by its members and the wider community.
The second key focus of IMS has been the Enterprise Systems group which has taken input from: IEEE Learner Model working group (in the form of the draft Public and Private
Information specification); Schools Interoperability Framework; Speede/Express guidelines on constructing and exchanging student records in an EDI.
On the 2nd November 1999, the Enterprise Systems group released its specification as three documents: IMS Enterprise Information Model v1.0 IMS Enterprise Best Practice and Implementation Guide v1.0 IMS Enterprise XML Binding Specification v1.0
The scope of the Enterprise Systems work as of May 2000 is confined to a single LMS interworking with a single management system; i.e. inter-institutional data exchange is not covered.
Other areas which have made progress include the Content Management which has produced a specification for how to package up content for delivery and what files are required to supported installation and usage etc. This work has been led by Microsoft and is based around XML using XML-Data to define structure. Microsoft have incorporated the AICC ‘Course Interchange Format’ specification, the IMS Metadata schema and the IMS consortium have undertaken to integrate with the QTI specification.
The Question & Test Interoperability group have developed an extensive hierarchy for classifying question modes. Work is already underway to extend this schema for passing the results back to a Learning Management System. This work was included in the version 2.0 release of the QTI specification, released in May 2000.
The IEEE Learning Technology Standardisation Committee is the only body engaged in the educational domain, which has a recognised formal standing. As such, many of the other groups (e.g. AICC, IMS, CEN/ISSS participants and representatives of the US
Version 0.6 31.10.2000 Page 44
EASEL Requirements Specification EASEL D3
branches of the US military) participate in the IEEE process and aim to progress their working specifications through the IEEE adoption procedures. Given the diversity of the fora represented by the participants in the IEEE, there exist a large number of working groups focused on specific activities, as well as more horizontal activities (such as the Architecture and Reference Model and the Glossary working groups) that attempt to tie the wider ranging work together. The IEEE working groups and study groups (note a study group is formed to do preliminary work to scope any subsequent working group in the particular area) can be broken down as shown below:
General Groups WG01 - Architecture and Reference Model * WG03 - Glossary *
Learner-Related Groups WG02 - Learner Model WG04 - Task Model WG WG13 - Student Identifier WG05 - User Interfaces (study group) WG19 - Guide for Application of ISO-9001 to Self-Managed Learning and
Content-Related Groups WG10 - CBT Interchange Language WG06 - Course Sequencing WG17 - Content Packaging
Data And Metadata WG12 - Learning Objects Metadata * WG09 - Localisation (study group) WG14 - Semantic and Exchange Bindings WG15 - Data Interchange Protocols WG16 - HTTP Bindings
Management Systems & Applications WG11 - Computer Managed Instruction * WG18 - Platform and Media Profiles WG07 - Tool/Agent Communications WG08 - Enterprise Interfaces (study group)
Those marked * are the most advanced areas and the Learning Object Metadata and the Computer Managed Instruction will probably enter initial voting stages during 2000.
Most areas are concerned with technical standards, but the WG19 study group - Guide for Application of ISO-9001 to Self-Managed Learning and Knowledge Management, is looking to define something akin to a ‘passport to learning’. This will require a new learner not already accredited, to go through a formal induction process to ensure they have the basic personal skills (e.g. time management, report writing, assessment preparation) to take full advantage of their proposed learning programme in an online setting. For learners working online, possibly remotely and under self-paced study, this is an important consideration in both retaining learners and ensuring that they achieve their full potential. It could be viewed as ‘learning to learn’.
3.2.3 Advanced Distributed Learning Initiative
[http://www.adlnet.org]
Version 0.6 31.10.2000 Page 45
EASEL Requirements Specification EASEL D3
ADL is a US military programme started by the White House in 1997 which aims to advance the use of state-of-the-art online training amongst the countries defence forces. There is some collaboration with experts in military training applications from other NATO countries.
ADL is very focused on content for particular areas of training. It also maintains its Shareable Courseware Object Reference Model (SCORM v0.9) as a working document to encourage discussion and input on the emerging standards. Note that SCORM is not a specification for adoption as it is periodically subject to rapid change. However, the areas that it draws on from the AICC, IEEE and IMS are worthy of exploration. Amongst its other, military-focused activities, the ADL is attempting to fast-track standards, drawing on the best work emerging from both the AICC and IMS. Both of these groups converge on the IEEE, but ADL is attempting to anticipate what will emerge from the IEEE.
The ADL have been particularly successful in driving acceptance of the content API (currently APIComm4) within AICC and lately the IEEE. More recently, they have taken the Course Structure from the AICC Computer Managed Instruction ASCII-based Data Model specification and (with a sub-group of the AICC) reformulated this in XML. This solution is now being promoted back to the AICC to accelerate the translation of the CMI Data Model to operation over the content API. As such, the ADL is not generally making its own specifications, but applies pressure to advance the specifications it would wish to adopt within its reference model. Further details of the ADL work can be found at [http://www.rhassociates.com/ADL-TWG]
3.2.4 Aviation Industry CBT Committee
[http://www.aicc.org]
The Aviation Industry CBT Committee is a membership-based international forum that develops recommendations on interoperable learning technology, principally for the commercial aviation and related industries. As such its members include both plane and equipment manufacturers, carriers, software and multimedia vendors and a growing number of interested parties not directly engaged in the sector, but nevertheless interested in the work being done there.
Given the costs associated with the aviation sector (the initial purchase of the planes, as well as ongoing operational costs such as maintenance, regulated safety procedures and staffing levels etc.), it is not surprising that cost benefits of online training and digital manuals were perceived here at an early stage. Along with some pioneering thinking, this has led to the aviation sector generally being an early adopter of the technology.
One of the key goals of the AICC participants is to extend the usable lifetime of multimedia training materials to match that of the equipment which they are intended to be used with. A plane is intended to fly many hundreds of thousands of miles over a number of years. The lifespan of a particular version of an authoring or tool or delivery environment on the other hand may be just one to two years before significant change is introduced. Whilst this is inevitable given the rapid state of flux within the IT industry, it creates problems in terms of running and maintaining legacy systems and/or re-engineering content for new platforms. A major thrust of the AICC therefore is to define a mechanism for translating content across operating environments. This effort is directed at creating a CBT Interchange Language intended to be common across platforms.
Given the sector’s experience of using CBT for online training, the AICC have developed a detailed model for Computer Managed Instruction (CMI) which is extensive in its coverage from LAN based delivery of traditional CBT to current work on web-based delivery. The specification covers content formats and structure and mechanisms for
Version 0.6 31.10.2000 Page 46
EASEL Requirements Specification EASEL D3
retrieving data from the content being used by learners. This work has attracted interest from the Advanced Distributed Learning initiative (ADL) being run by the US Department of Defence [http://www.adlnet.org]. ADL is a forum to promote widespread collaboration, exploit Internet technologies, develop next generation learning technologies, create reusable content, and lower costs, with object-based tools in support of distributed learning. It thus shares many of the goals of the AICC.
A subgroup of the AICC have been working with the ADL and other players from the IEEE LTSC and elsewhere to define a subset of the CMI specification that is solely concerned with online web delivery. This work has generated a lot of interest and appears to be gaining widespread support.
3.2.5 CEN/ISSS Learning Technology Workshop
[HTTP://WWW.CENORM.BE/isss/Workshop]
CEN/ISSS, in co-operation with the European Commission’s DG III & DG XIII has set up a working group to address European requirements for Educational Technology. This working group aims to achieve a consensus view in this area through the following actions: The establishment of a steering group to guide and monitor progress within the
project A requirements gathering stage to discover the precise needs of European developers
and users Consensus within a working group established under the TEISS (Telematics
European Industry Standardisation Support) framework on the standardisation process for educational technology
Coherent developments within metadata under the CEN/ISSS workshop process after this stage
Coherent development of standards for interoperability which allow learning resources to work together and seamlessly with learning management systems
Publication and transmission of recommendations by the work group to publishers, suppliers of hardware and services, telecommunications operators, industry bodies generally, standardisation bodies, the European Commission and international standards bodies.
The output from this work group will be in the form of: Coherent proposals to European and International standardisation bodies on common
standards supporting the development, storage and indexing of multimedia digital learning resources and delivery of services
Specific proposals on interoperability as defined above Outputs for public dissemination shall be submitted to consensus of a CEN/ISSS
workshop and published in the first instance as CEN workshop agreements.
To its credit (given the scale of standardisation activity ongoing globally for education) this group have decided to follow a course of examining standards emerging from international fora and assessing these for how well they will meeting the multicultural and multilingual requirements within Europe. Only in circumstances where there is a need identified that is not being addressed elsewhere, or an external standard (e.g. US based) needs extension for adoption in Europe, will they embark on creating something afresh. A number of the participants in this group are also active in the various international fora and they thus maintain a liaison with these groups. This working group only held its first working meeting in July so it is still early days for any outputs.
Version 0.6 31.10.2000 Page 47
EASEL Requirements Specification EASEL D3
3.2.6 ISO/IEC JTC1/SC36 Learning Technology
[http://www.jtc1.org]
As of 10th November 1999, the ISO/IEC Joint Technical Committee 1 meeting in Seoul agreed resolution 6, which brought into existence Sub-Committee 36 - Learning Technology. The international secretariat for SC36 will be provided by the US National Body, the American National Standards Institute (ANSI). The full press release is available from [http://www.jtc1.org/news/jtc1press1199.htm]
ISO/IEC JTC1/SC36 is intended to address standardisation in the area of information technologies that support automation for learners, learning institutions, and learning resources. It is the intention that SC36 shall not create standards or technical reports that define educational standards, cultural conventions, learning objectives, or specific learning content.
Clearly SC36 is intended to work closely with existing fora such as the IEEE and draw wherever possible on existing ISO/IEC standards, making appropriate, normative or informative references to these standards in areas such as multimedia, web content, cultural adaptation, and security.
Whilst the goal is for the SC36 work to be aligned with the outputs from the IEEE LTSC, the two groups operate very differently. Participation and voting rights within IEEE LTSC are based upon individual attendance at meetings, which are open to anyone. ISO/IEC on the other hand is progressed through meetings attended by national delegations, each of which has to agree a common position, which they then take collectively to the meeting. Furthermore, attendance of the meeting is restricted to official members of national delegations and is thus, effectively a closed shop controlled by each head of a national delegation.
In the UK, the British Standards Institute is currently attempting to identify which UK organisations would wish to participate in a UK delegation to SC36. Of these, the BSI also need to decide which would be most suited to heading up the delegation and what subscription charges they would need to raise in order to fund this activity. This UK delegation would be the voice for the official UK position in the international arena on topics related to the activities of SC36.
3.2.7 Dublin Core Education Working Group
[purl.oclc.org/dc/]
The Dublin Core Group has recently announced their intention to set up an Education working group. The Dublin Core elements were originally defined from the data that was perceived to be widely used or common across metadata communities (e.g. libraries, museums, archives, and graphical information systems) and the myriad of metadata schemas in existence (e.g. UKMARC, USMARC, CIMI). These core elements have been widely adopted by various bodies (e.g. European SchoolNet, IEEE/IMS Learning Object Metadata Group, US Gateway to Educational Materials) as the starting point for defining their own metadata to describe online educational resources. Inevitably, as these schemas have evolved, they have diverged somewhat from the original DC concepts and DC itself has changed from its original unqualified, general purpose model to now developing DC qualifiers so that data represented within DC elements can be more accurately interpreted.
This more ambitious role for DC is largely unproven, but given its widespread support and their collaboration with the INDECS project [http://www.indecs.org] working on
Version 0.6 31.10.2000 Page 48
EASEL Requirements Specification EASEL D3
content IPR description and handling, it is the direction favoured by many for achieving cross-domain search capability in the future.
The DC Educational working group will hopefully give a steer on how the educational community should support DC, both in its current form and for the future as DC v2.0 emerges.
3.3. Timelines
3.3.1 Historic Perspective
A brief history of the development of the specifications and standards for learning technologies is:
November, 1994 Educom (now Educause) launch the National Learning Infrastructure Initiative;
December, 1996 IEEE P1484 established. First meeting held in New Jersey, USA;
September, 1997 Educause launch IMS Project;
October, 1997 IEEE 1484 PAPI V2.0 Base Document released;
November, 1997 Department of Defence launch the Advanced Distributed Learning initiative (IMS present at the launch of the ADL);
April, 1998 IMS V0.5 Draft Specifications released;
May, 1998 IEEE 1484 LTSA V4.0 Base Document released;
June, 1998 IEEE 1484 LOM V2.1 Base Document released;
IEEE 1484 Computer managed Instruction V2.1 Base Document released;
September, 1998 IEEE 1484 LOM V2.2 Base Document released;
November, 1998 IEEE 1484 LOM V2.4 Base Document released;
September, 1999 Release of the IMS Metadata Final Specifications V1.0
October, 1999 Establishment of the IMS Question & Test Interoperability team;
CEN/ISSS Workshop on learning Technology held in Brussels;
November, 1999 ISO/IEC JTC1 for Sub-committee 36 on Learning Technology;
Release of the IMS Enterprise Systems Final Specifications V1.0;
December, 1999 Acceptance of the IMS Question & Test Interoperability Base Documents;
IEEE P1484 agree to convene future meetings with the ISO/IEC JTC1/SC36;
IMS launched as a ‘Not-for-Profit’ organisation;
January, 2000 IMS Question & Test Interoperability Princeton skunkworks;
NLII Conference;
February, 2000 IMS Technical Board, Miami, USA;
Acceptance of IMS Q&TI Draft Full Specifications;
Acceptance of IMS C&M Draft Full Specifications;
Version 0.6 31.10.2000 Page 49
EASEL Requirements Specification EASEL D3
AICC meeting, Florida, USA
March, 2000 TechEd 2000 conference;
IEEE 1484 meeting in London, UK;
May, 2000 IMS Technical Board, Darmstadt, Germany;
Acceptance of IMS Q&TI Full Specifications;
Acceptance of IMS C&M Full Specifications;
Acceptance of IMS Profiles & Enterprise V2.0 Base Documents;
AICC meeting, Frankfurt, Germany
Prometheus meeting, Darmstadt, Germany;
For a current update on key IMS Technical Board and other meetings, see
http://www.imsproject.org/calendar.html
3.4. Impact of Standards on Project Areas
A number of draft standards have been identified for validation within EASEL. Some of these relate directly to educational technology and are drawn from the work of the bodies described above. Others are more generic in nature, but nevertheless will be pioneered within EASEL’s developments. The following table identifies the key specifications being used in the project and the areas of development they will most impact.
By their very nature the standards under consideration are in something of a state of flux, given that they are at varying levels of maturity. However, this is the period when a test implementation can have the most impact on a standard and its future evolution. It is a state goal of the project to provide input and feedback to the standards groups, thus ensuring the maximum utility of this global community effort.
Table 2 : Standards Impact on EASEL Developments
Project Area Standards Body/ Industrial Consortia
Specification Targeted Purpose
Adaptive Content at run-time
AICC/IEEE Computer Mediated Instruction - Content API
Run-time interaction between content in the browser and the Learning Management System
Configuration of Adaptive Content
IMS Question & Test Interoperability
Retrieval of learner responses to questions from the content in the browser to the Learning Management System. Used for learner tracking
Metadata for Repository IMS/IEEE Learning Object Metadata
Metadata description of courses and learning resources
Common metadata representation for exchange of metadata via the search gateway
Metadata Implementation
W3C eXtended Mark-up Language
Encoding for all metadata across schemas
Adaptive Content IMS/IEEE IMS Profiles
IEEE Public And Private Information
Common representation of learner models for adaptive content
Semantic Registry ISO/IEC ISO/IEC 11179 Part 6 Semantic Registry
Registry for definition of shared RDF object classes representing schema elements
Version 0.6 31.10.2000 Page 51
EASEL Requirements Specification EASEL D3
4. EASEL Architecture
The EASEL Architecture is depicted in figure 4. There follows a brief description of the components identified.
4.1. Course Constructor Kit
The Course Constructor Kit will be a tool for constructing (from pre-authored resources) learning modules, each of which can be delivered as part of a general programme of learning and offered to any number of students enrolled on that programme. It will also support personalisation of an individual learners programme of study should they chose to add a specific module to their own programme. The Course Constructor Kit will use a sequencing model of the order through which a learner studies the modules so that a constructed programme can be entered into the Learning Environment RDMS, and subsequently delivered to learners.
An existing online learning system will be used and hence this will not be developed by the project, but it will require modification to support sequenced content created using the Course Constructor Kit.
The Course Constructor Kit will allow modules to be constructed from a wide range of resources, both owned by the institution and available remotely over the Internet. For ‘owned’ or local resources, a local query interface will be supported that will interrogate local XML repositories. These are: Learning Resource Metadata Repository - this will hold the metadata descriptions
developed which describe the web-based learning materials brought to the project by the partners. The resources themselves will be stored in the Learning Resource Repository;
Test Bank Metadata Repository - this will hold the metadata descriptions of the interactive test and adaptive modules implemented. The actual modules will be held in the Test Bank Repository.
The Course Constructor Kit will also support interrogation of remote repositories available over the Internet. Descriptions and the URLs for identified resources will be inserted into the appropriate point of a module or programme, guiding the learner to these existing resources. Suitable resources will be identified through the use of a Remote Search Interface that will access an RDF Search Gateway, utilising a commonly understood RDF Schema description for generating queries.
4.2. Distributed Querying
EASEL Distributed Querying services will be constructed from the following components: RDF Search Gateway - this will compose queries using one of the query languages
being explored by the W3C Query Language working group (e.g. XQL, DASL). Upon connecting to a remote repository, it will establish the data elements with which the contents are described and remote searching is supported and then retrieve their definitions from the BSR. This then will determine the fields over which a search can be conducted;
RDF Search Server - this will serve requests for remote searches expressed using an RDF Schema. The RDF Search Server will declare which data elements it will permit remote searching over and identify the data element definitions for these held by the BSR. Thus irrespective of the nature of the remote repository and its local schema structure, remote queries will be defined using RDF Schema. The Search Server will
Version 0.6 31.10.2000 Page 52
EASEL Requirements Specification EASEL D3
then map remote queries to the local repository schema, returning any search results. Note that the local query protocol could be one of a number of variants (e.g. SQL, XQL for an XML repository, whois++, Z39.50) and the Search Server may well provide a portal to a number of repositories shared across a community;
Basic Semantic Repository - The BSR will be implemented according to ISO 11179 and will act as the globally accessible repository for all data element definitions which a Search Server wishes to make searchable remotely.
It is intended that this architecture should provide flexibility in terms of any schema changes at the remote repositories. New data elements accessible for remote searching would be registered with the BSR and thus would automatically become available following registration. However, this approach whilst widely being discussed as a possible route to support web-based, structured remote search, remains unproven and there are a number of issues which require investigation.
By way of example, Dublin Core aims to provide a minimum subset of elements, which will generally be supported by most repositories. Thus when searching over a number of repositories in parallel, the search interface could just present these elements for specifying a query. However, it is possible to construct the search set of elements dynamically, based upon which data elements all of the target repositories have in common. Clearly this may not equate to a DC set. Alternatively, the user could be presented with all of the elements present in one or more of the repositories for the search interface, with each Search Server attempting a best effort search based upon the search criteria given.
Version 0.6 31.10.2000 Page 53
EASEL Requirements Specification EASEL D3
Figure 4: EASEL Architecture
Version 0.6 31.10.2000 Page 54
Course Constructor
Client
Learning Environment
RDMS
Web Gateway
Learning
Environment Web Gateway
Learner
Client
Learning Resource Metadata
Repository
Test Bank
Metadata Repository
Course Constructor Kit
Local
Query Interface
Remote
Search Interface
Basic
Semantic
Registry
LE
Course
Repository
Learning Resource
Repository
Test Bank
Repository
The Global
Directory
The Internet
RDF Search Server
Z39.50 Whois++
XQL SQL
Remote Repositories
RDF
Search Gateway
EASEL Requirements Specification EASEL D3
4.3. Search Gateway Architecture
The basic architecture of the Search Gateway is shown below.
Figure 5: Basic architecture of the Search Gateway
Components and Terminology User: the user of the Gateway, who is searching for Course Components. In the use cases, the user
is referred to as the Tutor.
Web client: the services of the search gateway will be delivered using web-based technology (HTTP).
Web interface: this is responsible for providing a user interface to the search engine.
Coordinator: an application layer on top of the Mediator.
Version 0.6 31.10.2000 55
User Agent
(Web browser)End-user clients
Search gateway
Remote
Resource
Providers
User profilesCoordinator
Mediator
Communicator
Semantic Repository
Provider directory
RDF interface
XML repository
RDF interface
SQL database
RDF interface
Z39-50 gateway
Etc…
HTT
P
RDF/
RDF1.0/
HTTP
RDF/
RDF1.1/
HTTP
RDF/
SOAP/
CORBA
Presenter Web interface
Query engine
Communicator
Gateway coordinator
EASEL Requirements Specification EASEL D3
Mediator or Query Engine: takes users’ queries and delivers them to the remote providers, then combines the results returned.
User Profiles: possibly constructed around some kind of directory service (LDAP or X.500) and capable of storing user preferences (eg, previous searches)
Provider Directory: contains the addresses of remote providers.
Semantic Repository: a dictionary of well-defined semantic units that elements of the schema of a remote provider may be equivalenced to.
Communicator: responsible for the transport of queries and results between the query engine and the remote providers. It is anticipated that most of these transactions will utilise RDF represented in a standard fashion over HTTP; however, it is conceivable that queries and results may be couched in terms of the RDF model but represented and/or transported via a different mechanism (eg, RDF-as-RDF1.1 or RDF-as-SOAP-messages for the representation; CORBA, Java RMI, etc. for the transport) – such a possible arrangement is indicated in the diagram.
RDF Interface: this is responsible for reflecting the underlying metadata repository in terms of the RDF model, for reporting the schema of said repository (including a bridge dictionary between elements of the schema and the semantic repository), and for query translation (from the RDF query to the query language of the underlying repository). In the architecture diagram the RDF interfaces are placed remotely, with the Remote Resource Providers.
Remote Resource Providers: it is envisioned that providers may utilise a number of different technologies to store their metadata.
Course Component: in the context of the Gateway, the Tutor is attempting to locate Course Components. However, the Gateway only deals with the metadata describing these Components – that metadata will include location information to permit the EASEL course constructor to address the actual course components. Nevertheless, we use the term “Course Component” here to refer to both the component itself and the metadata describing it. The context should make clear which use is intended. To resolve ambiguities the term “Course Component Metadata” may be used explicitly.
Note that within EASEL, the Gateway will be searching for Course Component Metadata. The Gateway architecture should be adaptable to other forms of metadata.
The Broker versus Provider distinction. The adjective “Broker” is used to refer to the composite schema (the Broker Schema) and the query as expressed by the Tutor to the Gateway (the Broker Query). This is in contrast to the individual schemas used by each Remote Resource Provider (the Provider Schemas) and the translated queries submitted by the Gateway to an individual Provider (the Provider Query).
Version 0.6 31.10.2000 56
EASEL Requirements Specification EASEL D3
5. EASEL Requirements and Usage Scenarios
In this section the specific requirements for each main component of the EASEL system are staked out, along with use cases in support of the specifications.
5.1. Requirements in Distributed Querying
5.1.1 Requirements of the Search Gateway
The search gateway should: query selected remote RDF repositories for the details of the schemas they support; present this information to the user in a reasonable and non-opaque fashion; permit the user to define his/her requirements (via an interface that is ‘powerful enough’ for the user
to specify their search criteria without being overcomplicated); compose and submit appropriate queries to each of the repositories (in parallel); collect, (optionally: rank), and present the results to the user in a timely manner; allow the scope of the initial query to be modified (broadened/tightened) as appropriate; facilitate viewing of selected course components.
Above all, the search gateway should be fast and easy to use.
5.1.2 Use Cases
Search for Course Component
Short summary The Gateway forwards search requests to the remote providers and collates the results for presentation to the Tutor
Actors involved Tutor, Provider directory, Semantic repository, Remote service provider(s)
Preconditions
Postconditions The Tutor has been offered zero or more course components.
Exceptions
Description The Gateway allows the Tutor to compose a query which defines the Tutor’s requirements for a course component.
This query is then transmitted to each Provider, and the results that each Provider returns collated.
The query results are then presented to the Tutor.
Version 0.6 31.10.2000 57
EASEL Requirements Specification EASEL D3
Compose Broker Schema
Short summary The Gateway acquires the schemas of the Provider(s) and produces a Broker Schema for the Tutor to express their query in. The results of the search will be expressed using this Schema.
Preconditions Each Provider must supply sufficient information to bridge between their Provider Schema and the Semantic Repository.
Postconditions A Broker Schema has been produced with a mapping between it and each of the Providers’ schemas.
Exceptions
Description The Gateway queries each Provider for its schema.
A Provider’s Schema must be augmented with a bridge dictionary to enable the identification of semantic units in terms of those defined in the Semantic Repository.
Although “Search for Course Component” uses “Compose Broker Schema”, there is no need for the process to be repeated for every search the Tutor wishes to make; the results may be cached.
Version 0.6 31.10.2000 58
EASEL Requirements Specification EASEL D3
Locate remote providers
Short summary The Gateway locates remote service Providers
Actors involved Gateway, Provider directory
Preconditions
Postconditions The Gateway has a list of addresses of remote Providers
Exceptions
Description The Gateway interrogates the Provider Directory for the addresses of remove service Providers that it knows about.
Build Broker Query
Short summary The Tutor uses the Broker Schema to compose a query.
Actors involved Tutor, Gateway
Preconditions The Gateway has built the Broker Schema. A mapping between the Broker Schema and the Provider Schema of each Remote Provider has been derived.
Postconditions The Gateway has a query which expresses the Tutor’s intentions.
Exceptions
Description The Gateway uses the mapping between the Broker Schema and each Provider’s Schema to produce a Provider Query
Query Remote Providers
Short summary The Gateway translates and passes the Broker Query to each Remote Provider, collating the results.
Actors involved Gateway, Remote Provider(s)
Preconditions The Gateway has a Broker Query. A mapping between Broker Schema and Provider Schema(s) has been derived.
Postconditions The Gateway has the metadata for zero or more matching Course Components
Exceptions
Description The Gateway uses the schema mapping to produce a Provider Query which it sends to the Remote Provider. This is done for each Remote Provider.
The Provider Result Set (in RDF) is read in and re-expressed using the Broker Schema.
The combined results are pooled to form the Broker Result Set.
Present Results
Short summary The Gateway presents the Broker Result Set to the Tutor.
Actors involved Gateway, Tutor
Version 0.6 31.10.2000 59
EASEL Requirements Specification EASEL D3
Preconditions The Gateway has a Broker Result Set.
Postconditions The Tutor has received the results.
Exceptions
Description The Gateway uses the Tutor’s preferences to rank and present the Broker Results.
Query Remote Providers: Detail
Process Provider Query
Short summary The Provider passes an incoming query to the underlying Metadata Repository
Postconditions The Provider returns zero or more matching metadata elements to the Gateway.
Exceptions
Description The Provider receives a query from the Gateway.
It, in turn, queries the underlying Metadata Repository (by translating the query appropriately) and returns the results in RDF format to the Gateway.
Notes:
Gateway should express the query using RDF-style templates.
Should have support for ‘ranking’ results? - if the underlying Repository supports this feature, then certainly the results should not be lost in the translation.
Map Query
Short summary The Broker Query is split into n Provider Queries
Actors involved Gateway
Preconditions A mapping between the Broker Schema and each Provider Schema has been derived.
Postconditions The Gateway has n Provider Queries.
Exceptions If it can be determined that a Provider can make no reasonable contribution to the result set, a Provider Query may not be supplied for that Provider.
Description The Gateway uses the mapping between schemas to produce Provider Queries.
Post Provider Queries
Short summary The Gateway sends the Provider Queries to the respective Remote
Postconditions The Providers have received the queries.
Exceptions
Description The Gateway should recover gracefully in the event that it cannot contact a Remote Provider.
Provider Result Sets Delivered
Short summary The Gateway receives and collates result sets from each Provider
Actors involved Gateway, Remote Provider(s)
Preconditions A mapping between the Broker Schema and each Provider Schema has been derived.
Postconditions The Gateway has produced the Broker Result Set.
Exceptions In the case that a Provider Result Set is enormous, the Gateway may flag that situation and alert the Tutor that their query may need to be made more specific.
Description Provider Result Sets are translated and collated to form the Broker Result Set.
The Gateway should recover gracefully in the event that a Remote Provider fails to produce a response within a reasonable time.
Use cases at the Remote Provider:
Process Provider Query
Short summary The Provider passes an incoming query to the underlying Metadata Repository
Postconditions The Provider returns zero or more matching metadata elements to the Gateway.
Exceptions
Version 0.6 31.10.2000 61
Gateway Underlying repository
Process Provider Query
EASEL Requirements Specification EASEL D3
Description The Provider receives a query from the Gateway.
It, in turn, queries the underlying Metadata Repository (by translating the query appropriately) and returns the results in RDF format to the Gateway.
Notes:
Gateway should express the query using RDF-style templates.
Should have support for ‘ranking’ results? - if the underlying Repository supports this feature, then certainly the results should not be lost in the translation.
5.2. Requirements in Data Models
The base schemas to be used should be current (May 2000 or later) versions of: the IEEE’s Learning Technologies Standards Committee’s (LTSC) Learning Object Metadata
abstract data model (LOM), which is an expansion of the Dublin Core Metadata abstract data model. DC clearly describes the features needed to identify and cite published material and to give an account of the associated intellectual property.
the IMS QTI and Content Packaging schemas
Each of these is described in other chapters and deliverables. A comparison of DC and other schemas such as CIMI (Consortium for the Computer Interchange of Museum Information) and the GEM Dublin Core Extensions is available at http://www.dlese.org/Metadata/dc_comparisons.htm. A similar comparison of the DC and IMS schemas is available at http://www.dlese.org/Metadata/dc_ims.htm.
Feedback from surveys this year of all major content providers and e-tools vendors serving the college market suggests that this choice of schemas is sufficient to make it possible to describe the gross features of typical learning resources now on offer. The result is to make it feasible to provide those resources (or pointers to them), via a local or distributed database linked to a course construction kit (CCK).
Those resources include “learning objects” (defined as any piece of media, digital or non-digital, used or referenced in technology supported learning) and associated test bank items. If collections of learning resources, such as complete courses, or versions of complete courses, are also described using those schemas, then useful additional information can be provided via the annotation field in LOM. Annotations might include the context in which a particular collection or version has been used, and the suitability of a particular learning resource for a given audience. As a consequence, course creators will be able to identify effective combinations of learning resources and test items, which can aid them in creating new combinations likely to have comparable effectiveness. Also, it may be possible to provide content providers with information on the use made of their material, both for purposes of tracking use of their intellectual property and for research purposes (e.g., marketing intelligence).
The requirements just outlined can be handled using the metadata fields defined within the LOM structure or equivalent IMS structure. These are grouped into nine categories, summarised in the precursor project (GESTALT) as follows: General - Groups all context independent features plus the semantic descriptors for the resource. Lifecycle - Groups the features linked to the lifecycle of the resource. Meta-metadata - Groups the features of the description itself (rather than those of the resource
being described). Technical - Groups the technical features of the resource. Educational - Groups the educational and pedagogic features of the resource.
Version 0.6 31.10.2000 62
EASEL Requirements Specification EASEL D3
Rights Management - Groups the features that depend on the kind of use envisaged for the resource.
Relation - Groups features of the resource that link it to other resources. Annotation - Allows for comments on the educational use of the resource. Classification – Groups together taxonomic pathways that define characteristics of the resource
The metadata elements defined in each of the categories are defined using subschemes - If they are a collection of data elements themselves; data types - If their values are strings, decimals and the like; vocabularies - If their values come from an “fixed” or “best practice” list.
All elements are optional and so it is likely that gaps will exist in the metadata descriptions of some objects. As in GESTALT, when rights metadata is important it should not be held locally with each copy of the material, as seems to be indicated by the IEEE LOM structure. Rather, it should be held as a single instance in some repository so making rights changes, charges, etc simpler to maintain. The INDECS initiative should be followed on this matter.
Much attention is being given elsewhere to structuring learning objects. Some of the learning objects that may be made available for trials of the CCK will use subject-specific vocabularies for the associated metadata elements, matched to the target audience, with semantic mark-up based upon further schema and ontologies. For undergraduate mathematics, for example, we may encounter use of an extended DC scheme, in the form of the Level II classification of the Mathematics Metadata Base Scheme, developed by the AMMTF (American Mathematics Metadata Task Force) at http://mathmedia.org/ammtf/taxonomies. Other schemas we are likely to meet include GEM (Gateway to Educational Materials), referred to above, and Saba’s Universal Learning Format, ULF, available at http://ims.collegis.org/imshp.nsf/dclkup/IMSS-4PAP8V/$File/ulf.pdf. ULF is a modular set of XML-based formats for capturing various kinds of e-learning data, including on-line learning content, catalogues of learning resources, certification libraries, competency libraries and learner information).
Users of the CCK should be able to access that further information, although it is arguably outside the scope of the EASEL CCK. To give some sense of the complexity that will result, the AMMTF scheme includes 21 Resource-type learning objects:
Each such learning object can be described using 29 metadata elements, of which we give full details of just the first one:
Approach (way of treating a mathematical subject, such as inductive, deductive, by construction or classical methods; reference to a mathematical school; reference to a spatial location or temporal period)
The other metadata elements have a small overlap with DC. The full list comprises:
We note that IMS is actively considering ways of making explicit provision for including more detailed information about “play rules” for determining preferred combinations of learning resources and preferred sequences of resources within those combinations. This is an important additional requirement, which is not adequately handled by the relation field in the LOM. The CCK should be capable of taking advantage of any such extension to relevant IMS schema.
Version 0.6 31.10.2000 63
EASEL Requirements Specification EASEL D3
Up to this point, we have accepted as a given that content will continue to be created, and courses will continue to be supplied and consumed, in ways similar to those common today. We have also assumed that future supplier-consumer relationships will stay much as they are today. An example of traditional “course supplier-course consumer” relationships would be asking students to enrol on pre-prepared courses and other courses whose content is determined by the supplier, such are typically found as in the course catalogues of single institutions or the course catalogues of multi-institution brokerages.
Our surveys suggested that major changes are in prospect, in some sectors as early as 2002-2004 (i.e., just within the lifetime of EASEL). This is because of changes in technology and working methods, and changes in expectation.
Examples of changes in technology and working methods include: the move away from up-front creation of completely-specified courses to more skeletal courses,
making heavy use of resource-based learning and links to library resources, via facilities such as SFX (context-sensitive reference linking, http://www.sfxit.com).
the move to using data mining and agent technology. These make it possible for teaching staff to draw upon the experiences of one cohort of students and exploit those experiences in other courses, through such means as quoting from their work. This is an instance of students becoming suppliers.
More speculatively, we have the prospect of increasing use of XML technologies such as XLINK, and the emergence of some form of semantic web, and its exploitation using such approaches as the Darpa Agent Mark Up Language. DAML will be a semantic language that ties the information on a web page to machine-readable semantics (ontology). It will include mechanisms to explicitly capture information not handled well by the above schemas, namely the representation of services, processes and business models, so as to allow non-explicit information (such as encapsulated in programs) to be recognised. DAML may become significant within the lifetime of EASEL and, if so, will require consideration of additional models such as those designed to support software reuse through the deployment of intelligent agents (e.g., see “Intelligent Agents in Software Reuse Repositories”, Barry G. Silverman, Nabil Bedewi and Alfredo Morales, Institute for Artificial Intelligence, George Washington University, Staughton Hall, Room 206, Washington DC 20052).
An example of changes in expectation is the move towards “markets of one”, in which each student can be offered a course created just for them. As yet, this is uncommon outside rich markets such as executive education. A less extreme version of personalised courses will be considered below.
Ideally, EASEL data models should be sufficiently rich to encompass not just the information needs that are inherent in traditional “course supplier-course consumer” relationships, but also other relationships, which should be supportable by extensions to the CCK.
An example of another relationship would be allowing prospective students to determine some or all of the content of their courses, either in advance of beginning their study or while they are studying. This is a fast-growing market sector. Another, less common example would be to allow prospective students to determine how a course will be taught and assessed.
In both cases, it is arguable that students are taking on some aspects of the role of a “course creator”. This term therefore needs to be broadened, to include two main groups: the main audience envisaged for the EASEL CCK (namely, people whose job responsibility
includes creating courses, such as university staff) the main prospective audiences for an extended CCK, namely students who are devising their own
proposed course or selecting resources for a project-based course, a resource-based learning course or other course designed on “constructivist” principles. That secondary audience is potentially very large (e.g., over 500,000 alumni in one consortium alone, comprising, Harvard, Oxford, Stanford and Yale). From 2001, this will create massive demand for software-supported ways of validating and accrediting the bespoke courses those students will create. At present, those people fall into three main groups:
Version 0.6 31.10.2000 64
EASEL Requirements Specification EASEL D3
students entering further and higher education, including students of corporate universities, who are not satisfied with aspects of the courses currently on offer
alumni, who have already graduated and want continuing professional development other “lifelong learners” and independent learners
We emphasise that the needs of that secondary audience are outside the scope of the EASEL project. They could be met by third parties, taking advantage of the use in the CCK of open standards, which facilitate interoperability. What EASEL can do is ensure that the data models are extensible to support additional information, of significance to such secondary audiences, or important when the CCK is used on a large scale or to support a course devised on principles such as resource-based learning.
In large-scale use, it is likely that some learning resources and some assessment items will be significantly more popular than others. The danger then is of over-use (e.g., several courses or examinations in the same institution use the same items, with the risk for the institution that an individual student will receive credit more than once for what is essentially the same topic and the same demonstration of competence). Traditionally, this risk is minimised through the device of setting “excluded combinations” of courses. The CCK needs to provide each subscribing institution with an equivalent facility, to enable records to be kept of the usage being made of each resource within that institution. That meta-meta information on usage and on overlap should not be embedded in the LOM metadata, which only describes content.
In that large-scale use, we assume use of a learning environment (LE) that has a curriculum model that has assessment points (e.g., using the IMS QTI). That LE is assumed to comply with the IMS Content Management specification (http://www.imsproject.org/content/management/cmscope.html) and the IMS LIPX (Learner Information Packaging & Exchange) Information Model Specification (not yet available electronically).
That environment may provide the necessary meta-meta information to track usage and overlap.
The use cases will be refined in coming months. The precise ones chosen will determine what binding to use (Dublin Core separately, or within the LOM). We envisage the following cases: Single repository versus Distributed repository (consider exchanging metadata, including rights
management metadata) Best-fit searches for course components most nearly matching multiple criteria (perhaps using a
simple decision-support tool based upon multiple-attribute utility theory) Ways of dealing with missing fields and other inadequacies in metadata
Version 0.6 31.10.2000 65
EASEL Requirements Specification EASEL D3
5.3. Requirements in Metadata Repositories
5.3.1 Overview
Figure 6: Metadata repositories.
An XML metadata repository will be constructed to store the metadata descriptions for existing web-based resources that will be developed by the content providing partners. One such repository could be used for storing metadata descriptions of passive learning resources (e.g. web-based hypermedia) and another for holding descriptions of adaptive content and interactive assessment resources in a test bank.
A generic architecture for an XML repository will be developed and a query interface for interrogation of the resources described will be implemented. For local searching, the Course Constructor Kit, under development, will be able to access the XML repository query interface directly. For remote access to the XML repository there will be an interface for a remote search via the RDF search gateway.
Version 0.6 31.10.2000 66
EASEL Requirements Specification EASEL D3
5.3.2 Internal Structure
Figure 7: The Internal structure of a metadata Repository
The internal structure of the metadata repository is depicted in Figure 77. The repository should have provision for the following:1. Support multiple metadata schemas. As depicted in Figure 77, the metadata repository should be
able to store different types of metadata schemas. For example, some of the metadata stored might be represented using Learning Object Metadata (LOM), some might use Dublin Core elements. Any such schema should be capable of supporting local extensions;
2. Support proprietary schemas. For example, the Business or the Medical department of a University might develop their own metadata schemas for their content. The metadata repository should be able to facilitate them;
3. Support different versions of the same schema. For example, different Institutes might need to use different extensions to the same initial metadata schema.
5.3.3 Repository’s Interfaces
The repository will provide functions to manage the metadata held (create new record, delete record, edit record, etc.) The repositories will be queried locally from the Course Construction Kit (CCK) and remotely from a RDF search gateway. Therefore, the repository will facilitate the following querying interfaces for interrogation of its resources: A query interface for the local query by the Course Construction Kit. Using that interface the
Course Constructor Kit will be able to access the XML Repository query interface directly; An RDF query interface for interrogation of the repository by a remote RDF search engine, under
development; An Interface that will populate the database with the data available in each XML file.
Version 0.6 31.10.2000 67
EASEL Requirements Specification EASEL D3
The XML repository will accept XML as input and export XML or RDF descriptions when queried.
5.3.4 Underlying Database Requirements
For both types of repository EASEL will use a database to store the XML files. For optimum implementation a fielded free-text indexing and retrieval engine that provides a powerful and flexible information retrieval environment should be used. The retrieval engine should provide an open solution for text and metadata indexing and retrieval, allowing structured information resources to be published into an integrated environment.
Some of the most important features of the system are summarised below: Support record updating - adding, deleting or modifying records without rebuilding the index from
scratch. The update procedure should be tolerant to crashes or hard interrupts during register updating - registers should be reconstructed following a crash.
Support arbitrarily complex records - base input format should be an XML syntax; Support large databases; Support high performance querying; Support high performance indexing and incremental indexing; Index files etc. should be automatically partitioned over multiple disks; Support approximate matching in registers (i.e. spelling mistakes, etc); Supports relevance ranking (free-text) searching as well as full fielded-Boolean queries. Right
truncation and masking in terms should be supported, as well as full regular expressions; Network distribution. The repository should be highly efficient in a wide area networked
environment and provide very high performance across low bandwidth networks, for example the Internet;
Seamless integration of multiple data sets into a single environment. This will allow a common user interface to be provided across multiple data sources;
5.3.5 Publishing the Data-set
Figure 8: Publishing the data
Publishing a data set will consist of four steps: Mount the native data on the target server. Describing the native structure of the data to the indexing system. If the native data is in a non-
standard format then the structure of the data (e.g. field delimiters etc) need to be configured into the systems input filters
Defining the indexing policies to be generated (i.e. which data elements are contained within which indices).
Describing the profile to be published (i.e. which attributes and record syntaxes are to be supported).
Version 0.6 31.10.2000 68
EASEL Requirements Specification EASEL D3
5.3.6 Use Cases for the XML Repositories
Update the Repository
Short Summary The Administrator updates the repository.
Actors Involved Administrator.
Pre-conditions The Administrator must be registered and have login.
An administration interface should be available in the XML Repository.
Post-conditions The repository has been updated with the latest data.
Exceptions
Description The Administrator updates the Repository. Actions permitted are:
Insert new records;
Mark obsolete records as no longer available and if they are superseded by new record point to them;
Modify existing data.
Search the Repository
Short Summary The XML Repository is queried either locally or remotely.
Actors Involved CCK, RDF Gateway.
Pre-conditions If the CCK queries the XML Repository then both the XML Repository and the CCK should have an interface for that communication;
If the RDF Gateway queries the XML Repository then both the XML Repository and RDF Gateway should have an interface for that communication.
Post-conditions None or more content metadata descriptions and content locators have been found.
Exceptions
Description The XML Repository receives a query either from its interface with the CCK or from its interface with the RDF Gateway.
The XML repository processes the query and none or more content metadata descriptions and content locators are found.
Return Results
Short Summary The query results are returned to the CCK or the RDF Gateway.
Actors Involved CCK, RDF Gateway.
Pre-conditions If the query results have to be returned to the CCK then both the XML Repository and the CCK should have an interface for that communication;
If the query results have to be returned to the RDF Gateway then
Version 0.6 31.10.2000 69
EASEL Requirements Specification EASEL D3
both the XML Repository and the RDF Gateway should have an interface for that communication;
Post-conditions None or more content metadata descriptions and content locators have been returned.
Exceptions
Description The XML Repository will return the results of the query to the initiator of the query that is the CCK or the RDF Gateway.
5.4. Requirements in LE Content Interworking And Packaging
5.4.1 Introduction
A definition for content interworking between EASEL’s endorsed learning materials and the LE system is necessary for: Consistent launching and running of learning content within LE; Consistent gathering and reporting of assessment data back to LE database; Monitoring of the consumption and usage of the learning content.
The following sections cover the interworking between learning products and the Learning Environment (LE). More specifically they cover: the scenarios of use of different learning content; mechanisms of interaction between online learning content and the LE; data which could be transferred between online learning content and the LE; mechanisms of data transfer between online learning content and LE.
5.4.2 Educational Goals of Interworking
The rise in computers in the work place, at college and in the home has lead to a rise in the use of computers in the realm of education. Computers and computer-based systems are increasingly used to deliver learning materials to a wide and varied audience.
Computer based learning materials can be delivered to learners from CD-ROMs as stand alone executable files on an isolated stand alone computer or on a machine that is part of a network via LAN based delivery, a company intranet, or on the internet via a web browser. Whatever mechanism is used for their delivery it is done so more effectively from within a managed environment, a Computer Managed Instruction (CMI) system or Learning Environment (LE). The CMI or the LE manage the delivery of Computer Based Training (CBT) or learning materials to the learner and provide facilities for the tracking of the learners progress, both for the benefit of the learner and for the tutor / instructor. In addition further support for the learner can be provided through the provision of communication facilities that allow the learner to communicate with their peers and tutors. The integrated whole establishes a supportive framework within which learners can increase their knowledge and skills base.
The audience of these learning materials is not passive but active learners, being provided with and demanding interactivity. This interactivity now includes many features of multimedia technology and the use of question and test based assessments embedded within the learning materials. These assessments create stages in the learning materials that enable a learner to test and assess their knowledge acquisition. The assessments not only give valuable feedback to the learner on their progress but also help learners reflect upon and re-internalise the learning materials they have progressed through up to that point. Where the tutor or instructor is privy to the results of the test they can monitor the progress of the learner and give guidance, help or advice where needed and tailor the
Version 0.6 31.10.2000 70
EASEL Requirements Specification EASEL D3
learning materials used by the learner if that is necessary. The results from the tests may also count towards a final qualification or award.
In addition to the test and assessment information it is useful for an organisation to understand how the learning materials were actually used. How long did it take for learners to complete a segment of the material? How many attempts were made on a particular problem?
A number of learning resources could be delivered through the supported environment of the EASEL LE. For relevant information to be recorded and transferred back to the LE database the content should operate in a standard fashion. The data recorded must be the same, the way that the data is encoded and the way that it is transferred must be the same for each item of learning material.
5.4.3 ‘Standards’ for Learning Content Interworking
In order for the EASEL to fully utilise the expected potential, it needs to be able to source and deliver high quality pedagogically sound learning materials that have been designed for delivery via online mechanisms. Much of the learning material that is needed by EASEL will need to be specifically written. For maximum benefit the material should be written in a manner that interworks with EASEL’s Learning Environment. So that the widest possible range of learning materials is available to the EASEL’s learners the content and the LE are to be developed using where possible open, internationally recognised and adopted standards. The major organisations and work activities currently taking place in the area of online learning are already discussed in Section 3. The adoption of open standards in the development of the whole system will enable ease of use of learning content within the EASEL system whatever its point of origin and for ease of exchange of data from the content to the LE and vice versa and between different items of content where that is appropriate.
There are three main organisations / activities that the EASEL content providers partners need to be aware of in the development of open and interworkable learning content. The EASEL LE system will follow the core recommendations and specifications of the IMS, AICC and IEEE where appropriate. The standards in development by these bodies are not yet a fully mature set of standards and so some divergence from the specifications may be necessary for the early period of the EASEL project. As the proposed standards develop towards a full mature specification set, the EASEL LE will adopt these. Adoption of industry wide recognised standards will exposed to the EASEL a vast range of compatible and interworkable learning materials with which to supply registered learners.
The Standard Bodies and Activities of interest for implementing the learning content Interworking within EASEL are fully described in Section 3 and briefly listed below: AICC - Aviation Industry CBT Committee [AICC] ; CEN/ISSS LT - European Community Standardisation Support Initiative for Learning Technology
Of the standards and proposed standards that have been described above the EASEL LE will adopt, where appropriate, those standards of the AICC, IEEE and the IMS. In particular there are three specific areas of content interworking that are covered by the work of the three standards bodies mentioned. The three areas covered are: The tagging of the learning content with metadata to facilitate efficient and targeted search and
The mechanism of transfer of learner generated data to the LE from the learning content and initialisation information from the LE to the learning content;
And related to the point above the data description of assessments and the questions used to construct those assessments.
The IEEE have produced an XML based data representation for the description of metadata tags with which to describe learning content. The IEEE LOM (Learning Objects Metadata) describes a minimum set of metadata tags for the description of learning objects. Learning content produced for EASEL should include metadata information on that content using the IEEE LOM tag set. The tagging of course material with consistent metadata information makes possible easier search and retrieval of learning content resources. This is important when online material is sought with which to construct a course on a particular topic. Details of the IEEE LOM can to be found in [LOM2.5]
With input from the ADL the AICC have developed a JavaScript based API that deals specifically with the communication of data from web based learning content to web based learning management systems and from the learning management systems to content. It is the responsibility of the LE to provide the JavaScript API. The content providers do not need to know the details of the API only the functions calls that are exposed by the API [APIW].
Much of the learning content to be delivered online by EASEL will include assessments. These assessments will be used by the learner to gauge their own progress during their learning and by the tutors to gauge how well a learner is progressing. For consistent display and action of question types and for consistent reporting of learner results back to the LE the questions and assessments used in the content should use the IMS Q&T (question and test) specifications. The Q&T specs describe a data model for the description of question types and the data representation language is XML. The Q&T specifications allow assessments to be assembled together from banks of questions in an interoperable manner. The tests and assessments assembled will be portable to other learning management systems designed to be compliant with the IMS standards [QTIS].
Adoption of the standards described above enable comprehensive and high quality courses to be constructed using learning materials from different EASEL partners combined in such a way that it is transparent to the learner that the components of the course are of different origins. In addition, the reporting of learner progress back to the LE providing monitoring and accreditation information can be done in a consistent manner. With standardisation these ‘pick-and-mix’ courses will be able to run within any learning management system that is itself compliant to the same standards.
5.4.5 Summary of Interworking Process
The major focus for content interworking is on the delivery and interworking of online content via LE.
There are two main aspects to the learning content interworking process. How the learning content is launched and run within and from LE. How the learning content transfers assessment data and other learner progress reported data back to
the LE database and in what form the learning environment receives that data.
Content Launching and RunningLearning content used by the EASEL CCK must interact with the Learning Environment in such a way that when learners move from one piece of learning content to another different piece of learning content, produced by the same or different partner, the interface of interaction between the content and the learning environment is consistent and predictable. Differences in navigational structures between the learning content and LE for different learning packages must be kept to a minimum.
Data TransferThere will be data transfer between online learning content and the LE. The data needed to be transferred to the LE are:
Version 0.6 31.10.2000 72
EASEL Requirements Specification EASEL D3
learner self assessment results; other tracking data necessary to assess how the learner is progressing during their learning and to
assess how the learning content itself is being used.
Data will be transferred between the content and the LE via a JavaScript API based on the API for Web implementation of AICC/IEEE CMI standards [APIW]. Where the content is unable to take advantage of the JavaScript API data will be transferred via a client side ActiveX DLL (AppleScript file for MacOS). The data model to be used with the API will be specified.
5.4.6 Main Interworking Scenarios
EASEL envisages delivering an online model for learning content delivered via the Internet to EASEL registered learners through the LE. Learners using purely online content will be using that learning content through a web browser (Netscape v4+ or Internet Explorer v4). There are three ways in which the content can be displayed by the browser online: 1. HTML based web pages containing text, images, audio and video displayed within the main
browser window or a frame of;2. Learning content invoked from the browser window as a result of a web page being downloaded
that contains embedded executable content that plays within a Java Applet, ActiveX component or with the use of a browser plug-in. This content can run within the main browser window (or frame of) or within a secondary window that is opened specifically for that content to run within;
3. Learning content that is launched via a URL in a displayed web page within LE but is launched from a local file on the learner’s machine. Either an executable file on the learners hard drive or on a CD, or DVD. The local file on users hard drive may have been installed from a CD or DVD or previously downloaded from the web site, unpacked and installed automatically. This method has two possible problems: The installation process must put the content files in the correct place for the web URL to find
and launch. Possibility of user accidentally (or otherwise) moving files necessitating a reinstall. Not portable, i.e. content can only be used on that machine unless it is installed again for use on a
different machine.
Due to the limitations of the third solution, EASEL will use the first two ways to display content online via the browser.
A typical online learning session that may occur for a registered EASEL learner is described below:
LE presents selection of learning content for learning opportunity the learner has enrolled upon.
Learner selects learning opportunity and section of learning content to interact with.
LE launches content.
LE displays web pages with learning content in.
Learner interacts with content.
Gets to an assessment point and completes test
Version 0.6 31.10.2000 73
EASEL Requirements Specification EASEL D3
Completed test results sent to LE and logged in EASEL database.
LE logs assessment in EASEL database
Learner continues learning
Learner selects page which contains embedded plug-in driven content
LE displays content and plug-in driven content is displayed in its own (secondary) window
Learner interacts with plug-in content
Comes to the end of a section and does an assessment.
Content sends assessment results back to LE
LE logs assessment results in EASEL database
Tutor informed by LE of completion of assessment by learner
Finally learner has enough and exits
Learner closes plug-in content
Learner logs out of LE
End of session event stored in EASEL database
Records position learner reached in content as bookmark in EASEL database
Next time learner logs into LE
LE retrieves position of learner within the content and goes there at the request of the user.
5.4.7 Summary of Information to be Interchanged
The information that may need to be interchanged between the LE and the learning content include:
Identification of the content being used, when the learning session started and when the session ended;
Test and other assessment data, including: Test taken; Questions presented; Questions attempted; Result of answer attempts; No of attempts at answering the question, where applicable; Score for each question; Maximum possible score for the test; Overall learner score; Pass/fail status; Whether the test attempted was completed (i.e. completed, timed out, or aborted).
A DTD will be created for the data that must be transferred between the learning content and the LE. The DTD will be based on the IMS Question and Test draft specification [QTIS] but will be modified to better fulfil the requirements of data to be returned.
There are different levels of granularity that may be represented in the test data that is sent back to the LE database:
Version 0.6 31.10.2000 74
EASEL Requirements Specification EASEL D3
the basic level of data that can be sent back is an overall measure of how the learner performed in particular test. Basic information would include learning content used, test taken, maximum possible score for test, overall score achieved, pass or fail.
the second level of granularity is a breakdown of the questions answered. For example, which were answered correctly, how many attempts needed, which were not answered correctly, what is the overall score.
the third level of granularity is a breakdown of what answer was actually given for the question answered. Information needed would include in addition to that above, possible answers for each question, responses given by learner whether correct or incorrect, score achieved for each question.
All of the possible levels of detail described above can be represented with a data schema and XML representation.
The LE will only associate one set of test results per learner for each resource available from within the LE. This implies that for each learning resource accessible online via LE there should be only one test.
5.4.8 Data Representation Language
The proposed data representation language for the transfer of data from the learning content to the LE database is XML. This is an emerging standard for data encoded that is reaching wide acclaim for its ability to represent structured data in an interoperable, transportable and extensible way.
Using XML together with the relevant DTD some verification of the data is possible before it is transferred to the LE database.
The XML formatted data will follow an XML schema that provides a description of all elements and attributes in the DTD.
5.4.9 Mechanisms of Interworking
There are two mechanisms of interworking that need to be considered:
The interaction of the content with the LE web browser interface The transfer of data from the content back to the LE database.
Content / LE InteractionOnline learning content can include: HTML based web pages; ActiveX controls; Java applets; Plug-in run content.
HTML Pages
Learning Content that is presented in HTML pages as text, images, graphics, audio and video will be displayed and treated as standard HTML. Where those HTML pages include online tests or assessments they must be written so that they take advantage of the LE JavaScript based API.
Some questions within online assessments, displayed as HTML forms, will entail more interactivity. For instance questions which allow the learner a number of attempts may present the learner with a hint after a certain number of attempts. This hint message may get more explicit the more attempts the learner has, until a point is reached at which the learner is deemed to have failed to answer the question correctly (the point at which the maximum number of attempts has been reached). For these types of questions the learner response will need to be submitted to LE at each attempt in order to retrieve the appropriate information to display to the learner. Alternatively this level of interactivity can be provided through JavaScript (ECMAScript) and kept entirely on the client machine. This will reduce
Version 0.6 31.10.2000 75
EASEL Requirements Specification EASEL D3
client / server rounds trips and subsequent load on the network. However to prevent web savvy learners from peeking at the JavaScript (ECMAScript) code and discerning the correct answer the JavaScript (ECMAScript) code containing the evaluative functions will need to be contained in a .js file referenced to within the page by the SRC attribute of the SCRIPT HTML tag.
The content may need to run in a secondary browser window that completely obscures the view of the primary LE window. In this case attention needs to be paid to window management. Naïve users may not think to pull down the Window or Communicator menu item to select the background window to come to the fore (the LE primary browser window). This appearance of a secondary window when the user is expecting the next page to appear in the main window can be very disorientating. Fortunately there exists a JavaScript (ECMAScript) function that enables easy window management at the click of a button. Therefore, where learning content needs to be displayed in a secondary browser window, that obscures the primary LE window, a button must be provided in the content. The function of the button would be to bring back to the foreground the primary LE window. To achieve this the partners providing content can use a button with the call below included in its JavaScript (ECMAScript) function Window.opener.focus. This button must be visible to the learner at all times during their learning episode with that content so that they may easily call back the primary window.
If a secondary window does exist a corresponding configurable button will appear in the LE primary window to bring back to the fore the secondary window containing the content.
Java Applets, ActiveX controls and Plug-in driven content
Where the learning content is run with the aid of a browser plug-in or other embedded type content (ActiveX control, Java applet etc), and that content runs completely obscuring the primary window, there must be a similar mechanism for a button in the content to bring the primary window to the foreground without necessarily closing the learning content.
Data TransferThere are three mechanisms by which the learning content may communicate with the LE and transfer learner related data: JavaScript based API. Client side ActiveX DLL. Client side JavaScript and HTTP post method.
JavaScript Based API
HTML pages and other browser based content that is able to call JavaScript functions can use the LE JavaScript based API defined by the LE. The API is exposed through the browser window used to display the content or the parent window from which the content is launched and is included in the page containing the content itself as an .js script file referenced to with the <SCRIPT> tag. e.g.
The content does not need to have any knowledge of the API other than the function calls needed to work with the API. The LE API will be based on the AICC/IEEE Web implementation standards [APIW]. The API may be used in one of the following:
the content may utilise the API LMSSetValue() call to set the values of each of the relevant elements of the data model. The accumulated values of each element set with LMSSetValue are cached until the content submit mechanism is activated. The content submit mechanism will use the LMSCommit() function which initiates transfer of the data via HTTP forms post method to the server side submit page for processing into the LE database;
Version 0.6 31.10.2000 76
EASEL Requirements Specification EASEL D3
the content may process the accumulated data itself and package it as XML formatted data in accordance with the selected DTD. The content would need to call a LMSSendXML() function to submit the XML data to the server. This call is part of the LE API but is not part of the AICC specifications. Validation of the XML will take place server side and a success or error message is sent back accordingly.
Client side ActiveX DLL
Windows Based PC’s The client side LE DLL provides an interface for content that cannot utilise the JavaScript based
API in the browser window. This could refer to content that is launched from the browser but does not run in a browser window or runs in a browser window but is not able to use JavaScript.
The client DLL is a COM component that exposes the same function calls as the LE API. The content will need to create the COM object using standard COM object creation methodology before using the function calls exposed. The DLL will cache the data from LMSSetValue() function calls until the content submit mechanism is invoked whereupon the LMSCommit() call initiates the submission of the data to the server side submission page for processing.
As with the LE API above the content may wish to package up the data into XML formatted data according to the selected DTD and using the LMSSendXML() call submit this data to the DLL. The DLL will check the XML data for validity and report any errors which the content will need to treat accordingly. If successfully checked the DLL will then post the data to the server side submission page using a second HTTP stream, as depicted below.
Figure 9: Data transfer between learning content and LE utilising the LE JavaScript API or the client side DLL.
MacOS Based PC’s The MacOS does not support client side COM components or COM calls. Because of this, two
possible options may exist for building the client side LE component on the Mac: to build a visual basic application in REALBasic based on the ActiveX COM component for the PC as above specifically for use with the MacOS or to use a compiled AppleScript component to do the same
Version 0.6 31.10.2000 77
EASEL Requirements Specification EASEL D3
job. Option two is favoured as AppleScript is a comparatively easy to use high level scripting language able to take advantage of existing scriptable and (where specific scripting addition files are used) non-scriptable applications for the MacOS to bring about a high degree of automation and inter-application operation.
The architecture for the mechanism of interworking for the Mac is similar to that of the Wintel PC but the components change due to the nature of the MacOS and it’s current incompatibility with client side COM components and COM based function calls. For this reason AppleScript will be used to receive and process the XML formatted data from the learning content.
Non API based JavaScript Data Transfer Method
An alternative Javascript method for sending back learner inputted assessment results to the LE database without using a JavaScript API (referenced to in an external .js include file) is to use client side JavaScript and the post method of HTML based forms. This simpler mechanism (described below) of data transfer between learning content and the LE is envisaged as an interim method suitable for HTML forms based learner assessments that uses standard HTML type data input fields, those being:
Text (including textarea) Radio buttons Checkboxes Selection lists
This could be implemented as an interim solution until the other more complex mechanisms described above are fully tested and operational. This will enable possible existing suitable material to be quickly adapted to interwork with the LE.
On completing an HTML form based assessment when submit button is clicked the learner inputted answers are checked and collated by javaScript functions included in the content pages written by the content provider. The final function of which is to concatenate all of the learner answers as a string into one hidden field. That field is submitted to a processing ASP (Active Server Page) page that parses the hidden field data and inserts it into the correct places into the LE database.
It is not necessary for the LE ASP processing page to know the name of the containing form field but there must be only one form per page.
Summary of Content Providers ResponsibilitiesLearning content authors are responsible for the following to ensure full interworking with the EASEL LE: Where content is displayed in a secondary browser window, obscuring the primary LE window, a
button must be place in the content. The button must be common to all areas so that the primary window may be called to the front without necessarily closing the content;
HTML forms in content submit data back to LE by means of HTTP POST method; Learning content to use LE JavaScript API or Client side DLL where appropriate for data transfer.
5.4.10 Content Packaging
For storage of structured content in the repository, some form of content packaging standards are required. IMS Content Packaging standards will be used, preferably at the latest ratified level. It is proposed that all content, even that with a simple structure, should be stored in this format in the repository and that a loader facility is provided to assist this process for simple, non-packaged files. Microsoft provides an LRN packager which can package more complex structures, essentially to IMS Content Packaging 1.0 standards, though with limited content metadata.
The CCK and the LE Content Interworking implementation should accommodate content packaging as necessary.
Version 0.6 31.10.2000 78
EASEL Requirements Specification EASEL D3
5.5. Requirements in the Course Constructor Kit
Figure 10: Course Construction Kit
The Course Constructor Kit will be a tool for constructing (from pre-authored resources) learning modules, each of which can be delivered as part of a general programme of learning and offered to any number of students enrolled on that programme. It will support personalisation of an individual learner’s programme of study should they chose to add a specific module to their own programme.
The Course Constructor Kit will use a sequencing model of the order through which a learner studies the modules. The constructed programme will be entered into the Learning Environment and subsequently delivered to learners. An existing online learning system will be used, that will not be developed by the project, but it will require modification to support sequenced content created using the Course Constructor Kit.
The Course Constructor Kit will allow courses to be constructed from a wide range of resources, both owned by the institution and available remotely over the Internet. For 'owned' or local resources, a local query interface will be supported that will interrogate local XML repositories developed.
The Course Constructor Kit will also support interrogation of remote repositories available over the Internet. Descriptions and the URLs for identified resources will be inserted into the appropriate point of a module or programme, guiding the learner to these existing resources. Suitable resources will be identified through the use of a Remote Search Interface which will access an RDF Search Gateway, utilising a commonly understood RDF Schema description for generating queries.
A content preview facility will be available in the Course Constructor Kit. The preview function will allow the course constructor to check the quality of the content and ensure that the selected content is appropriate for the module he is assembling.
The Course Construction Kit functions can be summarised to the following: Provide a user interface for the course constructor/tutor to assemble the course. That Interface will
be an HTML web page with a query form to enter the data; Initiate the querying of the XML repositories and display the results back to the user interface;
Local XML repositories will be queried directly; Remote XML repositories will be queried via the RDF search gateway;
Provide an interface for communication with the RDF gateway. That interface will be developed in collaboration with ILRT;
Provide a preview option for the course constructor to be able to preview the content before proceeding in selecting it for the particular module;
Store the selected contents temporarily while the course is under construction; Add the selected content to the course under construction and proceed in selecting the next content; Communicate with the Learning Environment and store the created course in the LE.
Version 0.6 31.10.2000 79
EASEL Requirements Specification EASEL D3
5.5.1 Use Cases for the Course Constructor Kit
The figure below depicts the actions and roles involved when a tutor uses the Course Constructor Kit (CCK) to find relevant content, preview the content, retrieve the content, add it to the course under construction, or store the created course.
Search
Short Summary The CCK Search function searches on behalf of a Tutor for metadata description of relevant content.
Actors Involved Tutor, XML Repository(s), RDF Gateway.
Pre-conditions The Tutor must be registered and have login.
Post-conditions None or more content metadata descriptions and content locators have been found.
Exceptions
Description The CCK Search function takes as input a query from the tutor, which defines his/her course requirements.
The CCK queries on behalf of the Tutor
The local metadata repositories;
The remote metadata repositories using the RDF Gateway
for the content metadata description and location of content relevant to the tutors enquiry.
Present Results
Short Summary The search results will be presented to the Tutor
Actors Involved Tutor.
Pre-conditions The Tutor must be registered and have login.
The CCK Search was successful (none or more content locators have been found).
Post-conditions The Tutor has been presented with the results.
Exceptions
Description The CCK presents to the Tutor the outcome of its search to the local or/and the remote repositories.
Preview Content
Short Summary The Tutor previews the content that might be of interest.
Actors Involved Tutor, Content Repository.
Pre-conditions The Tutor must be registered and have login.
The search should have provided one or more results.
Version 0.6 31.10.2000 80
EASEL Requirements Specification EASEL D3
The content preview material must be available in the Content Repository.
Post-conditions The Tutor has previewed the content.
Exceptions
Description The Tutor selects which content he/she wants to preview.
The CCK contacts the Content Repository to retrieve the content preview material.
The preview material is displayed to the Tutor.
The Tutor goes though the content preview material and examines if it is appropriate for the course under construction.
Retrieve Content
Short Summary The Tutor selects which content wants to be retrieved and the CCK contacts the Content Repository it is stored in and retrieves it.
Actors Involved Tutor, Content Repository.
Pre-conditions The Tutor must be registered and have login.
The content must be available in the Content Repository.
Post-conditions The content has been retrieved from the Content Repository it was stored in.
Exceptions
Description The Tutor selects which content he/she wants to add to the course.
The CCK contacts the Content Repository and based on the requirement of the Content Repository system, makes payment, accepts IPR agreement and finally retrieves the content.
Add Content to Course
Short Summary The CCK added the retrieved content to the course on behalf of the Tutor.
Actors Involved Tutor.
Pre-conditions The Tutor must be registered and have login.
The content has been retrieved from the Content Repository.
Post-conditions The content has been added to the course under construction.
Exceptions
Description The Tutor acknowledges that he wants the retrieved content to be added to the course.
The CCK adds the retrieved content to the course.
Version 0.6 31.10.2000 81
EASEL Requirements Specification EASEL D3
Store Course
Short Summary The Tutor finishes the course and the course is stored in the LE system by the CCK.
Actors Involved Tutor, LE RDBMS.
Pre-conditions The Tutor must be registered and have login.
The course must be finished.
Post-conditions The content has been stored in the LE system.
Exceptions
Description The Tutor finishes with the course construction and requests from the CCK to save the course. The CCK contacts the LE RDBMS and stores the course.
5.6. Other Content Issues And Pedagogical Content
5.6.1 Courseware Re-engineering for Flexibility and Re-use
The work in both WP4 and WP5 will be concentrated in re-engineering material originally developed for stand-alone use in view of two requirements, starting from the fact that Computer-Based Learning and Computer Networking can co-operate in providing a flexible and cost-effective approach to all levels education & training. The first requirement is to allow the re-use of the same material for different pedagogical scenarios. The second is to make the courseware suitable for delivery in a computer network, optimising telematic resources use. In the document we describe also the material to be provided by the different partners involved in the dedicated workpackages
The concept of Pedagogical DocumentThe target of the work to be carried out in WP 4 is to create or re-engineer content to allow its re-use for different pedagogical scenarios (courses, curricula and teachers) and to optimise telematics resources use and improve didactic effectiveness.
To allow re-use, the learning material needs to be segmented. We define a “Pedagogical Document” (PD) as a logically indivisible segment of courseware, represented by a file or a set of files, that introduces some kind of knowledge. For example, a PD may be a theorem, a series of definitions, a pedagogical animation or simulation, a worked example. Proper combinations of PD’s may produce different courses ranging from simple hands-on sessions, all the way to a formal treatment of a given discipline. The main issues related to PD’s construction are: content; granularity (physical and pedagogical); linking.
As far as content is concerned, the general definition of PD given above it is not always easy to apply because the identification of isolated units of knowledge in the original continuous stream of courseware is somewhat arbitrary. In practice, segmentation is carried on using as a guide the teacher’s pedagogical experience and thinking to possible re-use scenarios.
Version 0.6 31.10.2000 82
EASEL Requirements Specification EASEL D3
Figure 11: Re-use of “passive” segmented material for different pedagogical scenarios.
The term physical granularity refers to the average file size of segmented material. Per se, this parameter is not relevant for the definition of the PD, which deals only with the content. File size, though, must be taken into consideration for practical reasons. Fine granularity increases total courseware memory occupation because each PD must replicate features that were common before segmentation, such as backgrounds and book scripts. For example we have noticed that, dealing with ToolBook files, the highest subdivision level we have experimented with, i.e. “single page” PD, practically doubles overall size of the material. However, small PD’s obviously increase the courseware flexibility, at the cost of a more complex linking system.
While discussing the granularity of the PD, we have to take into consideration mainly three factors: the reusability/flexibility of the re-engineered course (as a set of PDs); the reliability and time of transfer of PD over the network; the pedagogical meaning of the isolated PD (defined as the number and quality of explanations of a
new concept).
These issues are obviously correlated (as roughly shown below). The degree of reusability of the PD decrease while its size increase, because it is difficult to build a large PD that could be used, as it is, in different scenarios and for different pedagogical purposes. Instead, a very small isolated PD could be easily put in a number of situations. The network delivery reliability and time has a very similar behaviour; in fact the transfer over the network of small PD (i.e. 70-100 KB) is easier and faster (and therefore more effective) than of large multimedia documents. On the contrary, the pedagogical value of the single PD has a completely different shape. Small PDs have in fact a very limited pedagogical value, that increases according to the growing of the PD.
Version 0.6 31.10.2000 83
Size of PD
High
Low Reusability
Network delivery
Pedagogical
meaningBasic multimedia asset
EASEL Requirements Specification EASEL D3
Figure 12: Granularity of pedagogical documents and related issues.
After segmentation, the Computer-based Learning (CBL) material cannot be used directly by students as it was before, because of the lack of a formative path. It is therefore necessary to make segmentation transparent to final users: they should not notice a loss of continuity between the different components of the courseware, while they should appreciate the improved overall performances for on-line consultation.
The segmented material becomes a heterogeneous set of PD’s that are not interconnected. At this point, each PD is independent from the others and completely re-usable. Only a subset of links is still valid: these are called “internal” links because each of them points within its own PD: these links will be used for the implementation of the EASEL “adaptive content”. Nevertheless it’s important to find a way to re-build “external” links without modifying the PD’s to guarantee their re-usability, because “external” links are crucial features for courseware flexibility and pedagogical approach. This problem is studied in a general way in the framework of the EASEL project, where specific tools and standards assembling together pedagogical documents into courses, are being implemented.
Courseware Delivery on NetworkThe second target of the work is to make the learning material suitable for delivery in a computer network, where a different organisation is necessary to optimise network resources. Ideally, network delivery would imply on-line courseware consultation, reducing to a minimum the storage necessity at student’s end and taking maximum advantage of a network server as a controlled and always up-to-date repository of all the courseware. The local situation of networking services does not allow a full implementation of this feature, for two orders of reasons: data transfer limitations and lack of proper courseware.
On-line execution is not always feasible for material developed for stand-alone usage. An obvious solution is the use of Internet File Transfer Protocol (FTP) to download educational material for off-line use. Stand-alone use of learning material is, anyway, a mode of operation that reduces connection costs and it is most suitable for frequently consulted material. Another possibility is the transformation of expositive courseware into HTML documents, gaining the advantage of on-line consultation, and all the other features beyond simple hypertext (such as animations and simulations), into JAVA applets.
An HTML file may provide a more effective structure for simple consultation, while multimedia-based PD’s may be linked when interactive explanations are required. The combination of HTML and multimedia files (i.e. QuickTime Movies, Flash animations, ToolBook files) is therefore an interesting solution, because allows a very convenient network access, while providing to the learner the option of obtaining a pedagogical information from files linked to HTML.
Version 0.6 31.10.2000 84
EASEL Requirements Specification EASEL D3
5.6.2 Pedagogical Contents
In this section each partner involved in the workpackages WP 4 and WP 5, dedicated to the re-engineering and description (metadata creation) of CBL material originally developed for stand-alone use and to the development of new material, describes the pedagogical material that will be provided or produced for EASEL experimentation. In order to use a co-ordinated approach, each partner will describe its materials using a common form.
Description of the FormThe model form proposed in the following pages has been conceived for collecting preliminary and rough data about the contents to be used in EASEL This “collection process” is of course ongoing and it will be completed for all content/metadata by the time that component development starts in project month 6 (i.e. August 2000). The compilation of the forms will continue under WP03. Even if the proposed form is “inspired” by the metadata that will be officially adopted in the EASEL framework, the collection and compilation of the real metadata will be made in the WP4.
This paragraph traces some guidelines (mainly taken from the Dublin Core definitions) to help the partners to properly fill each field in the form.
Content title:In this field you have to write the name given to the resource. If a known title does not exist, you have to use a term or phrase that is sufficiently descriptive to allow a user to judge relevancy.
Author:The people or organisation primarily responsible for creating the intellectual content of the resource.
Owned by or Copyright to:The entity responsible for making the resource available in its present form, such as a publishing house, a university department or a corporate entity. This field identifies the entity that provides access to the resource and that holds the copyrights and/or the IPR.
Description of content:A brief textual description of the content of the resource.
Structure of content:A brief textual description of how the content is structured: for example if it is hierarchically structured in “units, lessons and steps” or with a “encyclopaedia/reference” model or in some other way.
Language:The language of the content of the resource. This is the language that the final user must understand to properly use the resource.
Discipline:The knowledge field in the context of which the content is to take place in the ordinary sense.
Main concepts, keywords:This field indicates the main concepts explained by the resource. In general you have to choose the most significant words to best identify the arguments treated in the resource.
Version 0.6 31.10.2000 85
EASEL Requirements Specification EASEL D3
Learning objectives:A brief list of the objectives of the content. The learning goals to be fulfilled (or even profiles to be reached) by means of the content
Learning methodologies:In this field you have to indicate the kind of pedagogical methodologies/approach adopted. Examples of methodologies: expositive, simulation, questionnaire, problem-solving, learning by doing…
You can also identify other low-level features of the content, choosing between expositive and/or active content. In a expositive resource there isn’t interaction with the user (video, text,..), whereas in an active resource the user have to made some interaction with the content (exercise, test sessions,….)
Target population:A description of the different kind of users expected for the resource. You can indicate here, for example, the age or the educational level required or other relevant parameters.
Storage size requirement for the content:The rough dimension of the content (in Megabytes) and the expected number of PD that will be generated and then indexed.
Physical support – medium:Typically the data format and/or the physical support of the content (ex. CD-ROM, book…). This field is used to identify the software and hardware that might be needed to display or operate the resource.
Type of learning material:In this field you’ve to specify if the content is passive or adaptive (as defined by EASEL documents).
Comments:Additional information that you think could be useful and that doesn’t match the previous fields.
Version 0.6 31.10.2000 86
EASEL Requirements Specification EASEL D3
GIUNTI Interactive Labs
Content title Teletraining (La Teleformazione)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The aim of the course is to provide a general introduction about distance learning and teletraining tools, methodologies and contents.
The course is conceived for both the trainer/teacher and the trainee/student involved in distance learning activities.
Structure of content Units already conceived and produced as PD
Language English, Italian
Discipline Information processing
Main concepts, keywords Distance Learning, teletraining
Learning objectives Awareness
Learning methodologies Expositive
Target population Graduate people, users of distance learning systems
Storage size requirement for the content
Expected: about 500 MB???
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs - 1
Version 0.6 31.10.2000 87
EASEL Requirements Specification EASEL D3
Content title Quality for the Small & Medium Enterprises (Qualità per le Piccole e Medie Imprese)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The target of the course is to provide a general introduction and fundamental training about the methodologies to be applied in order to get the quality assurance in products and services according to international standards (ex. ISO9000).
The course makes specific reference to managerial issues and production processes.
Structure of content Units already conceived and produced as PD
Language English, Italian
Discipline Economy / Management
Main concepts, keywords Quality assurance, quality management, process, standard, ISO9000
Learning objectives Awareness
Learning methodologies Expositive
Target population Graduate people, managers, quality managers
Storage size requirement for the content
Expected: about 400 MB
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs - 2
Version 0.6 31.10.2000 88
EASEL Requirements Specification EASEL D3
Content title Entrepreneurs Training (Formazione per imprenditori)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The course is conceived for the entrepreneurs of especially Small and Medium Enterprises. The course provides basic elements and concepts to properly understand and define the need and the way of re-styling, updating or converting the enterprise.
Structure of content Units designed and produced as PD
Language English and Italian
Discipline Economy / Management
Main concepts, keywords Enterprise updating, Entrepreneur, SME
Learning objectives Awareness
Learning methodologies Expositive
Target population Entrepreneurs
Storage size requirement for the content
Expected: about 400 MB
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs - 3
Version 0.6 31.10.2000 89
EASEL Requirements Specification EASEL D3
Content title Training of teletraining operators (Formazione operatori della teleformazione)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The target of the course is to explain in detail how to design, develop and manage a course for distance learning platform. The course introduces also the management of a teletraining system.
Structure of content Units designed and produced as PD
Language English and Italian
Discipline Information Processing
Main concepts, keywords Distance learning, teletraining, management of distance learning
Learning objectives Awareness
Learning methodologies Expositive
Target population Graduate people, teletraining operators
Storage size requirement for the content
Expected: about 400MB
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs - 4
Version 0.6 31.10.2000 90
EASEL Requirements Specification EASEL D3
Content title Training for telework (Formazione al telelavoro)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The course is targeted to the people involved in distance working or teleworking activities.
The course explains how to use proper communication and working tools finalised to satisfy the needs of the employees working at home, with a special attention to disabled people
Structure of content Units designed and produced as PD
Language Italian and English
Discipline Information Processing
Main concepts, keywords Distance working, communication tools
Learning objectives Awareness
Learning methodologies Expositive
Target population Graduate people, employees, disabled people, teleworkers
Storage size requirement for the content
Expected: about 200 MB
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs - 5
Version 0.6 31.10.2000 91
EASEL Requirements Specification EASEL D3
Content title Innovative Management of SME (Gestione innovativa delle PMI)
Author Various
Owned by or Copyright to Tuscany Region
Description of content The target of the course is the training of the entrepreneurs and other management of the Small and Medium Enterprises in the field of the financial management
Structure of content Units designed and produced as PD
Language Italian and English
Discipline Economy Management
Main concepts, keywords Small and Medium Enterprises Management, financial management
Learning objectives Awareness
Learning methodologies Expositive
Target population Entrepeneurs, managing directors
Storage size requirement for the content
Expected: about 300 MB
Physical support – medium CD-ROM with web-based content
Type of learning material Passive
Comments Given that the definition phase of this content is still in progress, for the time being it's impossible to precisely describe part of the information requested.
GIUNTI Interactive Labs – 6
University of Naples
The content descriptions of University of Naples have not been determined yet.
Version 0.6 31.10.2000 92
EASEL Requirements Specification EASEL D3
South Bank University
Content title Digitisation in European libraries
Author Rosalind Johnson, LIC; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 118 Pages: 56-60
Throughout Europe, institutions in the cultural heritage sector (libraries, archives, museums and galleries) have been taking steps towards making available their collections in digital form for education, research and the general public. These initiatives range from small-scale projects involving one department within an institution and no external funding, through medium-scale national projects with public or private funding, to large-scale collaborative projects involving partners from several European states, and funding at a European level. This paper describes some of current and recent research in this area, with a particular emphasis on pan-European initiatives and future directions.
Structure of content Unit
Language English
Discipline Library information technology
Main concepts, keywords Digital culture
Collaborative projects
Pan European initiatives
Libraries, galleries, museums, archives
Education, research
Learning objectives Awareness of future developments/resources
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
5 pages A4 (165Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University -1
Version 0.6 31.10.2000 93
EASEL Requirements Specification EASEL D3
Content title Reading images
Author George Pitcher, Napier University; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 118 Pages: 39-41
Optical Character Recognition (OCR) is the digitisation of printed pages into editable and searchable computer readable texts. OCR software analyses patterns in an electronic image of the page to work out which letters and words are in the document. A major issue is quality. Even 99% accuracy would give 2 errors every 3 lines. One form of quality control is proof reading, but this is expensive. An alternative is Adobe Capture which replaces suspect reads with a 'bitmap', a picture of the original.
Structure of content Chapter Unit
Language English
Discipline Library information technology
Main concepts, keywords Optical character recognition, OCR
Quality issues
Accuracy
Computer readable texts
Adobe capture
Learning objectives Awareness of pitfalls
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
3 pages A4 (99Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University - 2
Version 0.6 31.10.2000 94
EASEL Requirements Specification EASEL D3
Content title Licensing digitisation
Author Edward Burrow, CLA ; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 118 Pages: 22-36
In January 1998, CLA announced that it had the support of rightsholders’ groups to develop licensing schemes for the digitisation of printed material. However, strict conditions were imposed. After extensive consultation, the first scheme covering the Higher Education community is now available. New schemes are being developed to cover other sectors, but in the long term digitisation is inevitably a transitional technology.
Structure of content Chapter Unit
Language English
Discipline Library information technology
Main concepts, keywords CLA, Copyright Licensing Agency
Learning objectives Awareness of IPR
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
5 pages A4 (165Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University - 3
Version 0.6 31.10.2000 95
EASEL Requirements Specification EASEL D3
Content title Higher Education Resources ON demand - the HERON service
Author Lisa McRory and Sally Curry; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 118, Pages: 35-38
The demand for heavily used materials has led to Universities creating short loan collections and course readers - both have their problems, possibly soluble through digitisation. But the eLib On Demand/ Electronic Reserve impact study made it clear that the economics of rights clearance and digitisation necessitated a cooperative approach. Addressing this the eLib project, HERON, Higher Education Resources ON demand, is developing software and procedures to streamline rights clearance and digitisation and make it easier to check if texts have already been digitised.
The operation of the software from pack building to copyright clearance, purchasing and fufilment is described. HERON will be a self supporting commercial service by 2001.
Structure of content Chapter Unit
Language English
Discipline Library information technology
Main concepts, keywords HERON,
Higher Education Resources ON demand
Copyright clearance
Course packs
Elib
Electronic reserve
UK HE Collaborative project
Learning objectives Awareness
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
4 pages A4 (132Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University - 4
Version 0.6 31.10.2000 96
EASEL Requirements Specification EASEL D3
Content title Metadata in Denmark
Author Leif Andresen, Danish National Library Authority; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 117 Pages: 18-23
A new Danish legal deposit act has facilitated co-operation in creation of a common application
form for Danish Dublin Core including the basic fifteen elements and four sub elements. The form
is used for creation of metadata in government publications and as an application form for legal
deposit and inclusion in the national bibliography
Structure of content Chapter Unit
Language English
Discipline Library information technology
Main concepts, keywords Legal deposit
Dublin Core metadata
Government publications
National bibliography
Learning objectives Awareness
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
6 pages A4 (198Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University - 5
Version 0.6 31.10.2000 97
EASEL Requirements Specification EASEL D3
Content title 'Stuff' about 'Stuff' - the differing meaning of 'metadata'
Author Matthew Dovey of Oxford University, Libraries Automation Service; SBU
Owned by or Copyright to South Bank University 2000
Description of content VINE 116 Pages: 6-13
Metadata is a complex subject, and many of its complexities are extremely subtle. To further
complicate matters, “metadata” has become an overloaded term, and is often used in different
contexts by different communities with different motivations. It is very easy to overlook this
diversity of motivation since these communities share many of their tools and problems. This paper identifies three different such “schools” of metadata and discusses their history and motivations.
Structure of content Chapter Unit
Language English
Discipline Library information technology
Main concepts, keywords Metadata issues
Schools of metadata: cataloguing, structuralist, data-structure
History of metadata
Dublin Core
XML
Learning objectives Awareness
Learning methodologies Expositive
Target population Postgraduate
Storage size requirement for the content
8 pages A4 (264Kb)
Physical support – medium Journal
Type of learning material Passive resource
Comments
South Bank University - 6
Version 0.6 31.10.2000 98
EASEL Requirements Specification EASEL D3
Trinity College Dublin
Content title Introduction to SQL – Relational Query Language
Author Vincent Wade
Owned by or Copyright to Vincent Wade and Trinity College, Dublin
Description of content The courseware topics cover –
Database Concepts
Creating a Database
Populating a Database
Database Retrieval
Database Applications
The course also contains a case study and self-assessment assignments.
Structure of content The courseware is structured in a –
Main topic
Sub-topic
Content
hierarchy.
Language English
Discipline Computer Science – Data Engineering - Databases
Main concepts, keywords Databases, relational, design, querying, DML, SQL
Learning objectives Students should be able to design, populate, query and optimise relational databases using SQL.
Learning methodologies Learning by doing, expositive, problem-solving
Target population Final Year full-time and part-time Computing Degree Students
Storage size requirement for the content
Approximately 30 PDs at ~6KB each (~0.3 MB in total including images)
Physical support – medium Web-based content
Type of learning material Adaptive content
Comments
Trinity College Dublin - 1
Version 0.6 31.10.2000 99
EASEL Requirements Specification EASEL D3
The Open University
Content title Taking Stock : Taking Action
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to assess their knowledge and their business circumstances and take appropriate action
Structure of content Sequential - 20 sections
Language English
Discipline Management
Main concepts, keywords SWOT, STEP, Human Resource Development, Training needs, Physical resources, Human resources, Financial resources, Competitor analysis, Market analysis
Learning objectives To enable users (Small Business Managers) to:
evaluate their business
formulate their plans
identify their training needs
Learning methodologies Structured open learning (self-study based on a model of learning as involving conversations and reflection, using exposition, simulation, questionnaires and learning by doing)
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
10 megabytes
1650 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 1
Version 0.6 31.10.2000 100
EASEL Requirements Specification EASEL D3
Content title Costing Activities
Author LSSB Team
Owned by or Copyright to Open University
Description of content The module covers the basic features of how to cost activities. This is part of management accounting. It is useful for day-to-day management of a business, and for longer-term decision making.
Structure of content Sequential - 9 sections
Language English
Discipline Management
Main concepts, keywords Fixed costs, Variable costs, Direct costs, Indirect costs, Linearity, Relevant range, Committed costs, Managed costs
Learning objectives To enable students to recognise and make use of different definitions of costs and explain why they can be useful.
Learning methodologies Exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
1.5 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 2
Version 0.6 31.10.2000 101
EASEL Requirements Specification EASEL D3
Content title Leadership
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers to persuade others to do what is required to achieve the goals of their business, as set out in its business plan and its mission statement.
Structure of content Sequential - 7 sections
Language English
Discipline Management
Main concepts, keywords Human Resource Development, Motivation, Communication, Leadership style, Personal style, Team spirit
Learning objectives To enable Managers to:
persuade others to do what you want
harness the different skills in a team
direct the team towards your goals
communicate these goals effectively to your team
Learning methodologies Structured open learning (exposition, questionnaires)
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
1 megabyte
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 3
Version 0.6 31.10.2000 102
EASEL Requirements Specification EASEL D3
Content title Improving staff performance
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to improve the performance of their staff
Structure of content Sequential - 4 sections
Language English
Discipline Management
Main concepts, keywords Human Resource Development, Training needs, Performance, Appraisal
Learning objectives To enable users (Small Business Managers) to create staff objectives that
Are clear and understandable to staff
Lead to results that are obvious to staff
Are attainable by staff
Learning methodologies exposition, questionnaires, learning by doing
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
1 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 4
Version 0.6 31.10.2000 103
EASEL Requirements Specification EASEL D3
Content title Developing services and products
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to decide whether they need new services and products and, if so, to take appropriate action
Structure of content Sequential - 3 sections
Language English
Discipline Management
Main concepts, keywords Products, Services, Market analysis, Wants, Needs, Benefits
Learning objectives To enable users (Small Business Managers) to:
evaluate their current products and services in terms of wants, needs and benefits
identify appropriate actions
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
0.5 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 5
Version 0.6 31.10.2000 104
EASEL Requirements Specification EASEL D3
Content title Selecting staff
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to improve their procedures for recruitment and selection
Structure of content Sequential - 4 sections
Language English
Discipline Management
Main concepts, keywords Products, Services, Market analysis, Wants, Needs, Benefits
Learning objectives To enable users (Small Business Managers) to develop a system for recruitment that meets four objectives:
A higher profit contribution per employee
Enhanced company image
A low and stable labour turnover
A sound investment in the future
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
0.5 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 6
Version 0.6 31.10.2000 105
EASEL Requirements Specification EASEL D3
Content title Budgeting
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to establish and control budgets
Structure of content Sequential - 6 sections
Language English
Discipline Management
Main concepts, keywords Budgetary control
Learning objectives To enable users (Small Business Managers) to:
Explain to others why it is necessary to budget
Control budgets
Put a budget together
Modify a budget to reflect changed circumstances
Review a budget
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
100 megabytes
500 users
Physical support – medium web-based content, audio, video
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 7
Version 0.6 31.10.2000 106
EASEL Requirements Specification EASEL D3
Content title Selling
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help people in business to increase their sales by understanding the selling process and improving their sales techniques
Structure of content Sequential - 8 sections
Language English
Discipline Management
Main concepts, keywords Sales process, Customer analysis, Market reach, Sales techniques, Selling benefits, Overcoming objections, Closing the sale
Learning objectives To enable users to:
Understand the sales process from the buyer's viewpoint and therefore adapt your sales approach to different situations whether you are selling a service or a product, and whether you are selling to individuals or to companies
Use your knowledge of the sales process to reach the key decision-makers and provide them with the information they need to help you make the sale
Segment your potential and existing customers into significant groups and tailor your sales approach to improve your chances of selling to them
Reach your customers more cost-effectively
Obtain more sales interviews
Develop your techniques for opening the sales interview, selling benefits, overcoming objections, closing the sale.
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
10 megabytes
500 users
Physical support – medium web-based content, video
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 8
Version 0.6 31.10.2000 107
EASEL Requirements Specification EASEL D3
Content title Financial decisions
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help people in business to quantify the effects of a business decision on the costs and profit of a business, and to help them to understand how costs and profit vary with different levels of activity.
Structure of content Sequential - 5 sections
Language English
Discipline Management
Main concepts, keywords Sales process, Customer analysis, Market reach, Sales techniques, Selling benefits, Overcoming objections, Closing the sale
Learning objectives To enable users to:
understand how costs and profits vary with changes in the level of activity of your business
understand and work out the breakeven point and contribution margin for your business
be able to relate these important financial variables to the key elements in running your business
understand how different costs affect the financial risk that your business faces
understand how financial information may be used to help you to make business decisions
work out the cost of particular products, service or departments.
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
3 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 9
Version 0.6 31.10.2000 108
EASEL Requirements Specification EASEL D3
Content title Production Management
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help people in business to better appreciate the following:
The production problems of growth
The nature of the production task
The role of the production manager
The nature of the production process
The implications of process choice
The span of process
How to determine capacity requirements
The nature of product development and its impact on production
How to review production management.
Structure of content Sequential - 10 sections
Language English
Discipline Management
Main concepts, keywords Growth, Production management, Process choice, Span, Capacity, Product development
Learning objectives To enable users to:
appreciate the importance of managing the production processes within your business
understand the problems arising from mismatches between business objectives and production capability
develop your own approach to analysing production issues and product development in your business
identify ways in which your choice of production process can be used to strengthen your competitive position and help to achieve your business objectives.
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
10 megabytes
500 users
Physical support – medium web-based content
Version 0.6 31.10.2000 109
EASEL Requirements Specification EASEL D3
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University - 10
Version 0.6 31.10.2000 110
EASEL Requirements Specification EASEL D3
Content title Organising people
Author LSSB Team
Owned by or Copyright to Open University
Description of content Self-study material to help managers and owners of small businesses to examine their management role so that they are better able to organise people
Learning objectives To enable users (Small Business Managers) to:
evaluate their current products and services in terms of wants, needs and benefits
identify appropriate actions
Learning methodologies exposition, questionnaires
Target population Age 18+
educational level Open entry (no prerequisites)
training sector Manufacturing industry
Storage size requirement for the content
0.5 megabytes
500 users
Physical support – medium web-based content
Type of learning material adaptive content
Comments Part of the Learning Support for Small Business series
The Open University – 11
Version 0.6 31.10.2000 111
EASEL Requirements Specification EASEL D3
University of Graz
Content title Mechanik
Author
Owned by or Copyright to Technikum Joanneum and Joanneum Research, Graz, Austria
Description of content Elementary mechanics: kinetics, dynamics, and energy.
Structure of content The course is structured in lessons, sections, and learning objects. Currently, there are 34 learning objects within three lessons.
Language German
Discipline Physics
Main concepts, keywords Velocity, acceleration, force, energy
Learning objectives Learning and applying the aforementioned concepts.
Learning methodologies Text, simulated experiments, video, test and training problems.
Target population College students of engineering, first year.
Storage size requirement for the content
Most files about 50KB; movies about 200-400KB
Physical support – medium CD-ROM
Type of learning material Adaptive content
Comments Licence is under negotiation; adaptivity would be introduced into course by UoG within EASEL; restructuring might be necessary.
University of Graz - 1
Version 0.6 31.10.2000 112
EASEL Requirements Specification EASEL D3
6. Conclusions
A key task of the EASEL project has been completed in this deliverable D3, with the drawing up of specifications for the EASEL demonstrator in the light of the respective expertise areas of the project partners and current rapidly advancing international developments.
An extensive State of the Art section covered requirements developed by key related projects and initiatives such as the IMS project, a US initiative, and major international standards initiatives including the IEEE LOM both of which are attracting a lot of attention worldwide. A number of online learning resources and initiatives including those newly launched by Microsoft and IBM were identified and an attempt was made to assess their relevance to the Learning Environment, the resource discovery, the metadata specification, and adaptivity. This assessment will be ongoing, via EASEL partner attendance and participation at relevant fora and the monitoring of project websites. A test implimentation of standards in the demonstrator will have a significant impact on the evolution of that standard. This review process was done in the setting of the EASEL architecture, which can be found in section 4.
Adaptivity is a key issue in EASEL, and, concluding a comprehensive survey of the many kinds of pedagogical adaptivity, it is suggested that one indicator of the success of EASEL will be its ability to identify objects that can be reused in many contexts, and so can be used to satisfy many learning objectives. Demonstrating the reusability of learning modules in a variety of contexts is a key aim of EASEL.
The foregoing study influenced the selection process to derive the most appropriate requirements that will drive the design phase of the project. This selection process was enhanced by the identification of suitable use cases and scenarios that stem out of the architecture and experience of the EASEL partners and help clarify and focus the drafting of the requirements. Use case scenarios identify relevant criteria that the system will have to satisfy and they go through the steps of executing such scenarios. As part of the building of the cases, the ‘actors’ involved were identified and any pre/post conditions and exceptions were set. In setting the stage in such a structured way and going through the motions of stepping through scenarios, which the demonstrator is expected to execute, the most important and useful requirements were thus identified. The use of use cases is best demonstrated in the learning environment dialog of the LE Content Interworking specification, and in the Course Constructor Kit requirement. In a later phase, use cases will be valuable in the validation of the design of the demonstrator against these requirements and are expected to be under continual review during the progress of the project. It is desirable that every feature of the demonstrator is supported by one or more use cases, but equally that no feature is included which is not supported by a use case.
The LE (Learning Environment) content interworking requirements revolve around the needs of the educator, course director or tutor, and ultimately the end user, the learner. These needs dictate that the LE should provide various capabilities in searching, assessment, creating and maintaining learning modules, handling of modifications, management of access rights etc. However, enrolment, course availability enquiries, tailored curriculum are beyond the scope of EASEL and were dealt with in the earlier GESTALT project. Requirements are addressed for interfacing and exchanging information with other environments, for ease of use, for robustness, scalability, openness, security and others.
The metadata requirements laid out in section 5 draw on earlier experience and use cases for updating, searching and delivery of results. Key elements include an RDF query interface and the use of XML to store metadata descriptions of passive and adaptive content, in a generic XML repository architecture, supporting multiple or proprietary schemas and variants with local extensions. The Course Constructor Kit will query the repository locally, and remote queries for pre-authored course content modules will be supported by an RDF search gateway. Preliminary metadata for a range of learning objects offered
Version 0.6 31.10.2000 113
EASEL Requirements Specification EASEL D3
to the project by partners are included in 5.6. These descriptions will be added to in the next phase of the project.
Finally, as advances in the technologies and standards applied to the learning environment proceeding rapidly, the EASEL consortium will track these areas, utilising relevant and affordable results that develop. The issues of cost/benefit and assessment criteria for the EASEL demonstrator are addressed in a parallel deliverable D4.
Version 0.6 31.10.2000 114
EASEL Requirements Specification EASEL D3
7. References
A) General References (Notes: Single papers on websites are included in this section, whereas project websites are included under titles in the body of D3 or in B), below)
[Albe, 94] Albert, Dietrich (1994). Knowledge Structures. Heidelberg, Germany: Springer.
[Albe, 99] Albert, Dietrich & Lukas, Josef (1999). Knowledge Spaces: Theories, empirical Research, and Applications. Mahwah, NJ: Lawrence Erlbaum.
[Alsc, 00] Alschular, Liora Schema Repositories – What is at Stake? http://www.xml.com/print/2000/01/26/feature/index.html
[APA, 97] APA (1997). Learner-Centered Psychological Principles: A Framework for School Reform and Redesign. Online available at http://www.apa.org/ed/lcp2/homepage.html.
[Ande, 98] Anderson, John R., Reder, L. M., & Simon, H. A. (1998). Applications and Misapplica-tions of Cognitive Psychology to Mathematics Education. Online available at http://act.psy.cmu.edu/personal/ja/misapplied.html.
[Brus, 96a] Brusilovsky, P., Schwarz, E., Weber, G., “ELM-ART: An Intelligent
Tutoring System on the World Wide Web” in Proceedings of the Third International
Conference, ITS, 1996.
[Brus, 98a] Brusilovsky, Peter & DeBra, Paul (1998). Second Workshop on Adaptive Hypertext and Hypermedia. Eindhoven University of Technology, NL. Online available at http://wwwis.win.tue.nl/ah98/Proceedings.html.
[Brus, 99] Brusilovsky, Peter & DeBra, Paul (1999). Second Workshop on Adaptive Systems and User Modeling on the World Wide Web. Eindhoven University of Technology, NL. Online available at http://wwwis.win.tue.nl/asum99/contents.html.
[Conk, 87] Conklin, Jeff (1987). Hypertext: An Introduction and Survey. IEEE Computer, 20(9), 17-41.
[Cort, 96] De Corte, Erik & Weinert, Franz E. (1996) International Encyclopedia of Developmental and Instructional Psychology. Oxford, UK: Elsevier.
[Cumm, 99] Cumming, Geoff, Okamoto, Toshio, & Gomez, Louis (1999). Advanced Research in Computers and Communications in Education. Amsterdam: IOS Press.
[Dove, 00] Dovey, Michael ‘Stuff about Stuff – the different meanings of ’metadata’ VINE 116, 2000 pp 6-13
[EC, 98] European Commission – Fifth Framework Programme, Information SocietyProgramme Technologies for Knowledge and Skills Acquisition, 1998 http://www2.echo.lu/telematics/education/en/interact/bul_5th2.html
[Eklu, 95] Eklund, J., “Cognitive models for structuring Hypermedia and implications for learning from the world wide web” in Proceedings of AusWeb, 1995.
[Eklu, 98] Eklund, J., Brusilovsky, P., “The Value of Adaptivity in Hypermedia Learning Environments: A Short Review of Empirical Evidence”, http://wwwis.win.tue.nl/ah98/Eklund.html, 1998
[Elli, 96] Elliott, Stephen N., Kratochwill,, Thomas R., Littlefield, Joan, & Travers, John F. (1996). Educational Psychology: Effective Teaching - Effective Learning. Madison: Brown & Benchmark.
[Espi, 95] Espinoza F., Hook K., “An Interactive interface to an Adaptive Information System” in Proceedings of the User Modelling for Information on the World Wide Web, a mini-workshop at the Fifth International Conference on User Modelling, 1995.
[GEST, 99] “Getting Educational Systems Talking Across Leading Edge Technologies”, Work Package 3, D0301 Design and Specification of the RDS (Resource Discovery Service), 1999.
[Gill, 99] Gilliland-Swetland, Defining Metadat,a Anne J. Department of Library and Information Science, University of California, Los Angeles
[Hela, 97] Helander, Martin G., Landauer, Thomas K., & Prabhu, Prasad V (1997). Handbook of Human-Computer Interaction, 2nd edition. Amsterdam, NL: Elsevier.
[IEEE, 97] Keeping Pace with an Information Society: A virtual roundtable, IEEE, Computer, November 1997, pp46-59
[Kear, 99] Kearsley, Greg (1999). Explorations in Learning & Instruction: The Theory Into Practice Database. Online available at http://www.gwu.edu/~tip/.
[Marc, 00] Marco, D. Building and Managing the Metadata Repository, April 2000 John Wiley Sons 0-471-35523-2 Paperback 416 pages; CD included.
[Mill 99] Miller, E. (ed) Paul Miller, Dan Brickley Guidance on Expressing the Dublin Core within the Resource Description Framework (RDF)) Section 3. Enriching the Dublin Core July 1999
[OPEN, 96] Open Learning Technology (1996). Learning with Software: Pedagogies and Practice. Online available at http://www.educationau.edu.au/archives/cp/.
[Ottm, 98] Ottmann, Thomas & Tomek, Ivan (1998). Proceedings of ED-MEDIA/ED-TELECOM 98 - World conference on Educational Multimedia and Hypermedia & World Conference on Educaitonal Telecommunications. Charlottesville, VA: Association for the Advancement of Computers in Education (AACE).
[Paol, 98] Paolucci, R.,“Hypermedia and Learning: The Relationship of Cognitive Style and Knowledge Structure” in Proceedings of Edmedia, 1998.
[PAPI, 98] Farance, F., Schoening, J., “Public and Private Information (PAPI) Specification”, Version 5.00, 1998
[QTIS] Question and Test Interoperability Specification V0.1 – Draft, Tan Boon Tee, IMS Asia Centre, 8/03/99;
[Spec, 98] Specht, Marcus (1998). Adaptive Methoden in computerbasierten Lehr-/Lernsystemen. PhD thesis, Universität Trier, Germany.
[Toch, 99] Tochtermann, Klaus, Westbomke, Jörg, Wiil, Uffe K., & Legget, John J. (1999). Hy-pertext'99: Returning to Our Diverse Roots. New York: ACM
B) Website References in the text (Note: These are generally project sites with multiple references of some relevance to EASEL)
[AICC] AICC - Aviation Industry CBT Committee, http://www.aicc.org/;
[APIW] API for Web Implementation of AICC/IEEE CMI Standards, LTSC committee, 17/08/99, http://ltsc.ieee.org/doc/wg11/CMI100.doc;
[COGP] CogPrints: Cognitive Science E-Print Archive. Online available at http://cogprints.soton.ac.uk/.
NIST National Institute of Standards and Technology
OASIS Organization for Application of Structured Information Standards
OIM Open Information Model
PD Pedagogical Document
QTI Question & Test Interoperability
RDF Resource Description Framework
Version 0.6 31.10.2000 121
EASEL Requirements Specification EASEL D3
SOAP Simple Object Access Protocol
SQL Structured Query Language
Use Case ‘Vignette’ that illuminate the ways in which users ought to be able to use (software) systems to get what they want. A use case is intended to accomplish some tactical objective of an 'actor', or to aid in accomplishing a tactical objective. The use case concept focuses attention on the user’s viewpoint about what the system is supposed to give back in response to the user’s input. That is, it is supposed to give back a response or output, and that output will have value relative to a hierarchy of tactical and strategic objectives and goals.
Put simply, if it's not in the use cases it shouldn't be in the system, and if its in the use cases it had better be in the system.
