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
J:\Workpacks\wp02\D3\Submission\D03.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
Date
14.11.2000
Status
Draft
Version 0.6 31.10.2000
Page 1
EASEL Requirements Specification
EASEL D3
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.
Keywords:
Requirements; online education; architecture; standards; viewpoints; use cases;
interoperability, learning environment; adaptive learning, adaptivity, resource
discovery; metadata; QTI, LOM, LTSC, IEEE, OASIS, RDF, IMS, Dublin Core
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 FretwellDowning Education.
Version 0.6 31.10.2000
Page 2
EASEL Requirements Specification
EASEL D3
CONTENTS
EXECUTIVE SUMMARY .................................................................................................................... 5
1. INTRODUCTION .............................................................................................................................. 6
1.1. OVERVIEW ..................................................................................................................................... 6
1.2. OBJECTIVES ................................................................................................................................... 7
2. STATE OF THE ART ...................................................................................................................... 10
2.1. STATE OF THE ART IN DISTRIBUTED QUERYING ......................................................................... 10
2.2. STATE OF THE ART IN METADATA REPOSITORIES ....................................................................... 15
2.3. STATE OF THE ART IN ADAPTIVE LEARNING TECHNIQUES........................................................... 23
2.4. STATE OF THE ART IN MODELLING LEARNERS .......................................................................... 37
3. STATUS OF CANDIDATE STANDARDS .................................................................................... 42
3.1. OVERVIEW ................................................................................................................................... 42
3.2. THE RELEVANT FORA .................................................................................................................. 42
3.3. TIMELINES ................................................................................................................................... 49
3.4. IMPACT OF STANDARDS ON PROJECT AREAS ............................................................................... 50
4. EASEL ARCHITECTURE ............................................................................................................. 52
4.1. COURSE CONSTRUCTOR KIT ........................................................................................................ 52
4.2. DISTRIBUTED QUERYING ............................................................................................................. 52
4.3. SEARCH GATEWAY ARCHITECTURE............................................................................................. 55
5. EASEL REQUIREMENTS AND USAGE SCENARIOS ............................................................. 57
5.1. REQUIREMENTS IN DISTRIBUTED QUERYING ............................................................................... 57
5.2. REQUIREMENTS IN DATA MODELS............................................................................................... 62
5.3. REQUIREMENTS IN METADATA REPOSITORIES ............................................................................. 66
5.4. REQUIREMENTS IN LE CONTENT INTERWORKING AND PACKAGING............................................ 70
5.5. REQUIREMENTS IN THE COURSE CONSTRUCTOR KIT ................................................................... 79
5.6. OTHER CONTENT ISSUES AND PEDAGOGICAL CONTENT ............................................................. 82
6. CONCLUSIONS ............................................................................................................................ 113
7. REFERENCES .............................................................................................................................. 115
8. GLOSSARY OF TERMS AND ACRONYMS ............................................................................ 121
Version 0.6 31.10.2000
Page 3
EASEL Requirements Specification
EASEL D3
TABLE OF FIGURES
FIGURE 1: MEMORY STRUCTURES IN THE ACT* MODEL ......................................................................... 24
FIGURE 2: CONTENT AND PERFORMANCE IN COMPONENT DISPLAY THEORY .......................................... 26
FIGURE 3: KNOWLEDGE SPACE AND LEARNING PATH .............................................................................. 31
FIGURE 4: EASEL ARCHITECTURE ......................................................................................................... 54
FIGURE 5: BASIC ARCHITECTURE OF THE SEARCH GATEWAY ................................................................. 55
FIGURE 6: METADATA REPOSITORIES. ..................................................................................................... 66
FIGURE 7: THE INTERNAL STRUCTURE OF A METADATA REPOSITORY ..................................................... 67
FIGURE 8: PUBLISHING THE DATA ........................................................................................................... 68
FIGURE 9: DATA TRANSFER BETWEEN LEARNING CONTENT AND LE UTILISING THE LE JAVASCRIPT API
OR THE CLIENT SIDE DLL. .............................................................................................................. 77
FIGURE 10: COURSE CONSTRUCTION KIT ................................................................................................ 79
FIGURE 11: RE-USE OF “PASSIVE” SEGMENTED MATERIAL FOR DIFFERENT PEDAGOGICAL SCENARIOS. .. 83
FIGURE 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
learning objects can be combined to address the needs of the course
constructor/educator.
Version 0.6 31.10.2000
Page 7
EASEL Requirements Specification
EASEL D3
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
model and their association. The use cases that are also presented in this deliverable will
Version 0.6 31.10.2000
Page 8
EASEL Requirements Specification
EASEL D3
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].
2.1.2.3 Cycic Friends Network
[http://www.cs.umbc.edu/~cikm/iia/submitted/viewing/mayfield/]
At the extreme end of distributed querying, the Cycic Friends Network utilises KQML
(Knowledge Query and Manipulation Language) to pass partial proof trees between cooperating 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.)
A recent paper on annotation is available at
[http://www.objs.com/survey/annotations-hicss.doc].
The “Epinions” service
[http://www.epinions.com/]
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 welldefined 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.
2.1.6.1 HotOIL
[http://www.dstc.edu.au/Products/Resource_Discovery/HotOil/hotoil_intro.html]
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.
2.1.6.3 Europagate
[europagate.dtv.dk/cgi-bin/egwcgi/egwirtcl/mtargets.egw]
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 reentered 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 SQLbased 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.
2.2.2 TAMINO Repositor
[http://www.softwareag.com/tamino/technical/description.htm]
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 performanceenhancing 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.
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).
Version 0.6 31.10.2000
Page 18
EASEL Requirements Specification
EASEL D3
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/]
2.2.4 POET XML Repository
[http://www.poet.com/products/cms/white_papers/xml/repository.html]
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:
scalability,
language support,
ease of programming and
embeddability.
Version 0.6 31.10.2000
Page 19
EASEL Requirements Specification
EASEL D3
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 enterprisewide 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.
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
Version 0.6 31.10.2000
Page 20
EASEL Requirements Specification
EASEL D3
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 fieldlevel 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.
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—
Version 0.6 31.10.2000
Page 21
EASEL Requirements Specification
EASEL D3
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.
“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
Version 0.6 31.10.2000
Page 22
EASEL Requirements Specification
EASEL D3
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].
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
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
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.
Active Learning (Activity Theory)
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
Version 0.6 31.10.2000
Page 24
EASEL Requirements Specification
EASEL D3
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 selfdirected, 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
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
Version 0.6 31.10.2000
Page 25
EASEL Requirements Specification
EASEL D3
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
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
Version 0.6 31.10.2000
Page 26
EASEL Requirements Specification
EASEL D3
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
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
Version 0.6 31.10.2000
Page 27
EASEL Requirements Specification
EASEL D3
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 are
1. It is learner-centred rather than institution-centred.
2. It provides a means of equipping adults for self-directed learning.
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.
Version 0.6 31.10.2000
Page 28
EASEL Requirements Specification
EASEL D3
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. Selfdirected 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
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
Version 0.6 31.10.2000
Page 29
EASEL Requirements Specification
EASEL D3
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
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
Version 0.6 31.10.2000
Page 30
EASEL Requirements Specification
EASEL D3
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-orgraph 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.
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
Version 0.6 31.10.2000
Page 31
EASEL Requirements Specification
EASEL D3
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].
Adaptivity to Learner’s Preferences
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,
Version 0.6 31.10.2000
Page 32
EASEL Requirements Specification
EASEL D3
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.
Version 0.6 31.10.2000
Page 33
EASEL Requirements Specification
EASEL D3
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
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.
Version 0.6 31.10.2000
Page 34
EASEL Requirements Specification
EASEL D3
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
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.
Version 0.6 31.10.2000
Page 35
EASEL Requirements Specification
EASEL D3
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 Webbased 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/.
Version 0.6 31.10.2000
Page 36
EASEL Requirements Specification
EASEL D3

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.
2.4. State Of The Art In Modelling Learners
2.4.1 Approaches For Modelling the Learner
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
Version 0.6 31.10.2000
Page 37
EASEL Requirements Specification
EASEL D3
student can understand and relate to. There are several techniques for modelling the
student and honing this model.
The Stereotype Model
Creating 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 Model
The 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 Model
The 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.
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.
Objective
The 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
Version 0.6 31.10.2000
Page 38
EASEL Requirements Specification
EASEL D3
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.
Preknowledge
The 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 Style
The 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 Style
The 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].
Maturity
Hypermedia 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 Ability
The 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
Version 0.6 31.10.2000
Page 39
EASEL Requirements Specification
EASEL D3
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.
Confidence
Users 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].
Motivation
Sources 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.
Preferences
Users 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.
Background
The 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.
2.4.4 Metadata Standards for User Modelling
PAPI
PAPI [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
Version 0.6 31.10.2000
Page 40
EASEL Requirements Specification
EASEL D3
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.
GESTALT
GESTALT (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:
 IEEE Learning Technology Standardisation Committee (P1484)
 CEN/ISSS Learning Technology Workshop (European CEN/CENELEC activity)
 ISO/IEC Joint Technical Committee 1, Sub-Committee 36 - Learning Technology
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 nonparticipants[IEEE, 97].
There also exist a number of consortia (each generally either industry or education sectorbased) 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.
3.2.1 IMS (originally Instructional Management Systems)
[http://www.imsproject.org]
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.
3.2.2 IEEE Learning Technology Standardisation Committee
[http://www.manta.ieee.org/p1484]
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 Knowledge
Management (study group)
WG20 - Competency Definitions (study group)
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 reengineering 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
Configuration of
Content via the Course
IMS
Content Management
Part 1 covers packaging of content along
with its various descriptive schemas (e.g.
Version 0.6 31.10.2000
Page 50
EASEL Requirements Specification
EASEL D3
Constructor Kit
LOM, QTI, CMI CSF, Dublin Core)
Distributed Querying
W3C
Resource Description
Framework Schema
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
Common representation of learner models
for adaptive content
IEEE Public And Private
Information
Semantic Registry
Version 0.6 31.10.2000
ISO/IEC
ISO/IEC 11179 Part 6
Semantic Registry
Registry for definition of shared RDF
object classes representing schema
elements
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
Course
Constructor
Client
Basic
Learner
Client
Semantic
Learning
Registry
Web
Gateway
LE
The
The
Internet
Global
Course
Course Constructor Kit
Directory
RDF Search Server
Z39.50
Whois+
+
XQL
Environment Web
Gateway
Remote
Local
Search
Interface
Query
Interface
SQL
RDF
Learning
Environment
RDMS
Repository
Learning
Resource
Learning Resource
Metadata
Repository
Repository
Test Bank
Test Bank
Metadata
Repository
Repository
Search
Gateway
Remote Repositories
Version 0.6 31.10.2000
Page 54
EASEL Requirements Specification
EASEL D3
4.3. Search Gateway Architecture
The basic architecture of the Search Gateway is shown below.
User Agent
(Web browser)
HTTP
End-user
clients
Search
gateway
Presenter
Web interface
Coordinator
Gateway
coordinator
User profiles
Query engine
Mediator
Semantic
Repository
Communicator
Provider
directory
Communicator
Remote
Resource
Providers
RDF/
RDF/
RDF/
RDF1.0/
RDF1.1/
SOAP/
HTTP
HTTP
CORBA
RDF
interface
RDF
interface
RDF
interface
XML
repository
SQL
database
Z39-50
gateway
Etc…
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
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-asRDF1.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
Locate
Remote
Providers
Provider
Directory
Compose
Broker
Schema
Semantic
repository
Search For
Course
Build
Broker Query
Component
Tutor
Query Remote Providers
Remote
Providers
Present
Results
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.
Actors involved
Gateway, Provider(s), Semantic repository
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
Preconditions
The Gateway has a Broker Result Set.
Postconditions
The Tutor has received the results.
EASEL D3
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
Actors involved
Gateway, Provider, underlying Metadata Repository
Preconditions
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
Version 0.6 31.10.2000
The Gateway sends the Provider Queries to the respective Remote
60
EASEL Requirements Specification
EASEL D3
Providers
Actors involved
Gateway, Remote Resource Provider(s)
Preconditions
The Provider Queries are available.
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.
Process
Provider
Query
Underlying
repository
Gateway
Use cases at the Remote Provider:
Process Provider Query
Short summary
The Provider passes an incoming query to the underlying
Metadata Repository
Actors involved
Gateway, Provider, underlying Metadata Repository
Preconditions
Postconditions
The Provider returns zero or more matching metadata elements to
the Gateway.
Exceptions
Version 0.6 31.10.2000
61
EASEL Requirements Specification
Description
EASEL D3
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.
Rights Management - Groups the features that depend on the kind of use envisaged for the resource.
Version 0.6 31.10.2000
62
EASEL Requirements Specification
EASEL D3
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 XMLbased 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:
Definition; Example (example-of); Lemma (consequence-of); Theorem (consequence-of); Proof
(proof-of); Corollary (consequence-of); Theory; Axiom (axiom-of); Postulate; Thesis; Method;
Rule; Criterion; Open Question; Paradoxon; Narrative Text; Figure (subtype); Exercise;
Solution (solution-of); Application Program Interface (input-specification, output-specification);
Simulation.
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:
approach (see above); axiom-of; classification; consequence-of; contributor; creator; crossreference; date; description; document-identifier; educational; example-of; format; inputspecification; language; number; output-specification; proof-of; publisher; rights; skeletonposition; solution-of; source-locator; source-reference; subject; subtype; text; title; type.
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
Course Construction Kit
Remote
Search
Interface
RDF Search
Gateway
Learning
Resource
Metadata
Repository
Test Bank
Metadata
Repository
Learning
Resource
Repository
Test Bank
Repository
Local
Query
Interface
Learning
Resource
Metadata
Repository
Test Bank
Metadata
Repository
Learning
Resource
Repository
Test Bank
Repository
Figure 6: Metadata repositories.
An XML metadata repository will be constructed to store the metadata descriptions for existing webbased 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
Input
Input
Store
Store
Output
Output
X1
LOM
X2
X3
RDF
Y1
DC
Y2
XML
L1
Business
L2
XML
Z1
Medical
Z2
Z3
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.
The XML repository will accept XML as input and export XML or RDF descriptions when queried.
Version 0.6 31.10.2000
67
EASEL Requirements Specification
EASEL D3
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
1
Mount Native
Data on Server
2
3
4
Configure Input
Filters, Indexing
Policies &
Required Profiles
Index Native Data
Start Quering
Server
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
[GENI];
DC Education - Dublin Core [DCED];
IEEE LTSC - IEEE Learning Technology Standards Committee, [IEEE];
IMS - Instructional Management System Project [IMS].
5.4.4 Context - How This Fits In With EASEL
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
discovery of resources;
Version 0.6 31.10.2000
71
EASEL Requirements Specification
EASEL D3
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 Running
Learning 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 Transfer
There 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:
Learner


Learning Environment
Enrolled learner logs onto Learning
Environment (LE)

LE asks learner for authentication.

LE writes session start event to LE database

LE presents selection of learning content for
learning opportunity the learner has enrolled upon.

LE launches content.

LE displays web pages with learning content in.
Learner selects learning opportunity and
section of learning content to interact with.

Learner interacts with content.

Gets to an assessment point and completes test
Version 0.6 31.10.2000
73
EASEL Requirements Specification

Learner continues learning

Learner selects page which contains
embedded plug-in driven content

Learner interacts with plug-in content

Comes to the end of a section and does an
assessment.

Finally learner has enough and exits

Learner closes plug-in content

Learner logs out of LE
EASEL D3

Completed test results sent to LE and logged in
EASEL database.

LE logs assessment in EASEL database

LE displays content and plug-in driven content is
displayed in its own (secondary) window

Content sends assessment results back to LE

LE logs assessment results in EASEL database

Tutor informed by LE of completion of assessment
by learner

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 Interaction
Online 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 Transfer
There 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.
<script language=’Javascript1.2’ src=’ServerPath/lseapi.js’></script>
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;
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
Version 0.6 31.10.2000
76
EASEL Requirements Specification
EASEL D3
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.
Web Server
Content
1st HTTP
Submission
Page
2nd HTTP
Internet / Intranet
1st HTTP
2nd HTTP
form
form
Browser
HTML
page
Content
submission
DLL
3rd party
application
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
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
Version 0.6 31.10.2000
77
EASEL Requirements Specification
EASEL D3
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 Responsibilities
Learning 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
Learning
Environment
RDMS
Course Construction Kit
Remote
Search
Interface
Local
Query
Interface
Learning
Resource
Repository
RDF Search
Gateway
LE Course
Repository
Learning
Resource
Metadata
Repository
Test Bank
Repository
Test Bank
Metadata
Repository
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 ComputerBased 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 Document
The 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.
High
Version 0.6 31.10.2000
Network
delivery
reliability
83
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 Network
The 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 reengineering 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 Form
The 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 Expected: about 500 MB???
the content
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 Expected: about 400 MB
the content
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 Expected: about 400 MB
the content
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 Expected: about 400MB
the content
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 Expected: about 200 MB
the content
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 Expected: about 300 MB
the content
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 mediumscale national projects with public or private funding, to largescale 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 5 pages A4 (165Kb)
the content
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 3 pages A4 (99Kb)
the content
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 5 pages A4 (165Kb)
the content
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 4 pages A4 (132Kb)
the content
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 6 pages A4 (198Kb)
the content
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 8 pages A4 (264Kb)
the content
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 Approximately 30 PDs at ~6KB each (~0.3 MB in total including
images)
the content
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 10 megabytes
the content
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 1.5 megabytes
the content
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 1 megabyte
the content
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 1 megabytes
the content
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 0.5 megabytes
the content
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 0.5 megabytes
the content
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 100 megabytes
the content
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 decisionmakers 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 10 megabytes
the content
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 3 megabytes
the content
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 10 megabytes
the content
500 users
Physical support – medium
Version 0.6 31.10.2000
web-based content
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
Structure of content
Sequential - 4 sections
Language
English
Discipline
Management
Main concepts, keywords
Performance, Management style, Staff problems, Change
management, Directive management
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 0.5 megabytes
the content
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 Most files about 50KB; movies about 200-400KB
the content
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 Misapplications 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, 98b] Brusilovsky, Peter, Kobsa, Alfred, & Vassileva, Julita (1998). Adaptive Hypertext and
Hypermedia. Dordrecht, NL: Kluwer Academic Publishers.
[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.
Version 0.6 31.10.2000
115
EASEL Requirements Specification
EASEL D3
Dao, 98] Dao, Dr. K., Parent L., “Adaptive Learning Model for Workplace Environmental Learning” in
Proceedings of Edmedia, 1998.
[Doig, 99] Doignon, Jean-Paul & Falmagne, Jean-Claude (1999). Knowledge Spaces. Berlin:
Springer Verlag.
[Dove, 00] Dovey, Michael ‘Stuff about Stuff – the different meanings of ’metadata’
2000 pp 6-13
VINE 116,
[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
http://www.ukoln.ac.uk/metadata/resources/dc/datamodel/WD-dc-rdf/
Version 0.6 31.10.2000
116
EASEL Requirements Specification
EASEL D3
[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
Question and Test Interoperability Specification V0.1 – Draft, Tan Boon Tee, IMS Asia
Centre, 8/03/99;
[QTIS]
[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). Hypertext'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/.
[COND] CONDRINET http://www2.echo.lu/condrinet/Data/Eng/Chapters/En_Ch_1.htm
[DCED] DC Education - Dublin Core, http://purl.oclc.org/metadata/dublin_core/
Version 0.6 31.10.2000
117
EASEL Requirements Specification
EASEL D3
[EDUC] EDUCAUSE http://www.educause.edu
[ENCY] Encyclopedia of Psychology. Online available at http://www.psychology.org/links/.
[FSLS] Functional Specification - Learning Support Environment V1, Bob Banks, FDE, 26/08/99.
[GENI] CEN/ISSS LT - European Community Standardisation Support Initiative for Learning
Technology, http://www.cenorm.be/isss/Workshop;
[ICPI] IMS Content Packaging Information model v0.91,16/2/00,
http://www.imsproject.com/content/index.html;
[IEEE] IEEE LTSC - IEEE Learning Technology Standards Committee,
http://www.manta.ieee.org/p1484/;
[OLE] Online Learning Exchange, OLE http://www.educause.edu/nlii/news.html
[EMTF] Educational Multimedia Task Force http://www2.echo.lu/emtf/index.html
[IIMS] IMS - Instructional Management System Project, http://www.imsproject.com
[IMSG] IMS Global Learning Consortium , Metadata Specification v1
http://www.imsproject.org/metadata/specificationdownload.html
[LOM2.5] (LTSC) Learning Object Metadata (LOM) V2.5 – Draft, IEEE Learning Technology
Standards Committee, 12/12/98, http://ltsc.ieee.org/doc/wg12/LOMdoc2_5A.DOC
[SUPP] SupportGate (SkillsSoft and ActiveEducation) http://www.supportgate.com/home.html
[SOCR] SOCRATES Programme (1995-1999) Co-operation in the field of education
http://europa.eu.int/en/comm/dg22/socrates.html
C) Other web sites relevant to the subject area
KEY CONTENT
SITE
Learning Objects
http://www.edna.edu.au/edna/aboutedna/metadata/analysis/LOM.ht
m
IMS standards
http://www.imsproject.org/metadata/
Version 0.6 31.10.2000
118
EASEL Requirements Specification
EASEL D3
IMS Content Packaging
http://www.imsproject.com/content/index.html
Metadata
http://www.fdgroup.co.uk/gestalt/metadata.html
Dublin Core
http://purl.org/dc/
DCMI scope
http://purl.oclc.org/dc/about/DCMIStructure-19990531.htm
Metadata overview
http://somunix.uafsom.alaska.edu/~john/papers/budapest.html
MS learning resources
interchange (LRI) tools
Lotus LS, WebCT etc reviews
http://www.microsoft.com/elearn/
MODELS 11 workshop –
Terminalogical Control
E-learning advances WOLCE)
http://www.ariadne.ac.uk/issue23/
ARIADNE Educational
Metadata Recommendation
Microsoft Repository
http://ariadne.unil.ch/Metadata/ariadne_metadata_v3final1.htm
Informatica – Metadata
Exchange
Australian MetaWeb (Debbie
Campbell)
NewsAgent alerting for LIS
http://www.metadataexchange.com/irc.htm
HARVEST web indexing
extraction s/w
http://www.trinity.edu/rjensen/245soft1.htm
http://www.distancelearning.co.uk/
http://msdn.microsoft.com/repository/default.asp
http://www.nla.gov.au/nla/staffpaper/dcampbell1.html
http://www.sbu.ac.uk/litc/newsagent/overview.html
http://harvest.cs.colorado.edu
HERON – HE Resources ON
demand
CANDLE – Controlled Access
to Network Digital Libraries in
Europe
PRIDE – People & Resources
Identification for Distributed
Environments
XML
Repository White Paper –
POET
Distributed Systems Technology
Centre reports
Phoenix on-demand publishing
http://www.sbu.ac.uk/litc/heron
COSE Virtual Learning
Environment
http://www.staffs.ac.uk/COSE
Version 0.6 31.10.2000
http://www.sbu.ac.uk/litc/candleathens/
http://www.explit-lib.org/issue1/pride
http://www.poet.com/products/cms/white_papers/xml/repositor.html
http://archive.dstc.edu.au/RDU/
http://www.hud.ac.uk/schools/phoenix/pages/homepage.htm
119
EASEL Requirements Specification
EASEL D3
PROMETEUS
http://prometeus.org/press.release.html
Cick2Learn – Toolbook II Asst
http://www.asymetrix.com/products
Technology for Learning links
http://www.trainingsupersite.com/publications/newsletters/tfl/article
s
WebCT library
http://about.webct.com/library
Lotus LS & other courseware
Evaluation
http://snow.utoronto.ca/best/crseval.html
D) Email Lists monitored (* Mailbase lists via http://www.mailbase.ac.uk/)
LIST
Scope/Topics/Owner
*Lis-dc-education
UKOLN (Paul Miller)
*Lis-dc-pedagogy
Learning science
Lis-rdf-interest
*Lis-interoperability
Lis-european-programmes
W3C (repl lis-rdf-dev)
Z39.50 debate
IST info
*Lis-ufi-lifelonglearning
‘Learndirect’
discussion
ISSS-ML-MMI-DC
European DC
workshop, CENORM
http://www.cenorm.be/isss/Workshop/MMIDC/applic_form.htm
Version 0.6 31.10.2000
120
EASEL Requirements Specification
EASEL D3
8. GLOSSARY OF TERMS and ACRONYMS
Term or Acronym
Definition
ADL
Advanced Distributed Learning (US Dept of Defense)
ANSI
American National Standards Institute
API
Application Programme Interface
BSR
Basic Semantic Repository
CEN
Centre for European Normalization
DNS
Digital Nervous System (Microsoft Repository term)
DTD
The XML document type declaration contains or points to markup
declarations that provide a grammar for a class of documents. This
grammar is known as a document type definition, or DTD.
The DTD for a document consists of both internal and external
subsets taken together.
DW
Data Warehousing
EASEL
Educator Access to Services in the Electronic Landscape
GESTALT
Getting Educational Systems Talking Across Leading Edge
Technologies
Institute of Electrical and Electronics Engineers
IEEE
InfIII
IMS
Instru Instructional Management System (originally)
ISO
International Organization for Standardization
ISSS
Information Society Standardization Service
LOM
Learning Object Metadata
LTSC
Learning Technology Standardization Committee (IEEE)
MRSS
Metadata Repository & Search System
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
Simple Object Access Protocol
Structured Query Language
SOAP
SQL
‘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.
Use Case
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.
use
W3C
World Wide Web Consortium
XML
eXtensible Markup Language
Version 0.6 31.10.2000
122