LTSA Specification
Learning Technology Systems Architecture

Date: 1998-05-21
From: Frank Farance, Joshua Tonkel
Title: Learning Technology Systems Architecture (LTSA) Specification
Version: 4.00
URL: http://www.edutool.com/ltsa
Phone: +1 212 486 4700
Fax: +1 212 759 1605
E-mail: frank@farance.com, tonkel@farance.com

Notice: This document and its contents are Copyright © 1998 Farance Inc., Edutool Division

ABSTRACT

This Architecture Specification describes the high-level system design and the components of the Learning Technology Systems Architecture (LTSA). The LTSA specification covers a wide range of systems, commonly known as learning technology, computer-based training, electronic performance support systems, computer assisted instruction, intelligent tutoring, education and training technology, metadata, etc.. The LTSA specification is pedagogically neutral, content-neutral, and platform-neutral. The LTSA specification (1) provides a framework for understanding existing and future systems, (2) promotes interoperability and portability by identifying critical system interfaces, (3) incorporates a technical horizon (applicability) of a least 5-10 years while remaining adaptable to new technologies and learning technology systems. Many systems can comply with the LTSA specification (see section 10, Conformance) although they don't provide all the components, nor do they have the same organization.

Each section of this document begins with an Overview that provides a summary from the perspectives of: developer, administrator, teacher, and student. Section 1.3, Road Map, and the Index provide a directory of topics of interest. Section 11.2, Glossary, should be consulted for any unfamiliar or ambiguous terminology.

This document is being developed. The intended audience is: information technology, learning technology, and education. This the LTSA draft 4.00. Please return all comments to Frank Farance by Friday, 1998-07-03 21:00 UTC. See Section 12.2, Release notes for this document, and Section 12.5, Comments on this document, for instructions on delivering comments. This document is being developed in IEEE 1484 Learning Technology Standards Committee (LTSC) in close collaboration with Educom's Instructional Management (IMS) Project, the Aviation Industry CBT Committee (AICC), and the Department of Defense Advanced Distributed Learning (ADL) project.

TABLE OF CONTENTS

This document presents the Learning Technology Systems Architecture (LTSA). The LTSA is a high level systems architecture and layering for learning technology systems, known as learning technology, computer-based training, electronic performance support systems, computer assisted instruction, intelligent tutoring, education and training technology, and so on. This document is a proposed architecture specification for the IEEE 1484 Learning Technology Standards Committee (LTSC) subject areas: reference model, learner model standards, learning objects, task model, course sequencing, tools/agent communication, ontologies, data interchange, course management, metadata, student identifiers.

This specification does not address the development systems (e.g., languages, authoring tools, operating systems) necessary to create the LTSA components.

The LTSA specification is pedagogically neutral, content-neutral, and platform-neutral.

(To the reader: The main points have been highlighted with green or underlining.)

The beginning of each section is an Overview that summarizes the section from the perspective of the developer (creates software and learning content), administrator (purchases systems, manages institutions and systems), teacher, and student.

This document is summarized by: purpose, process, results, key points, disclaimers.

This document is an architecture specification: the technical details can be used to specify systems as well as detailed systems components. Conformance to this architecture specification is non-exclusive: a system that conforms to the LTSA can also conform to other generic, cross-industry, industry-specific, national, regional, government, institutional, community, or standard specifications.

In general, the purpose of developing systems architectures is to discover high-level frameworks for understanding certain kinds of systems, their subsystems, and their interactions with related systems. An architecture isn't a blue print for designing a single system, but a framework for designing a range of systems over time, and for the analysis and comparison of these systems. By revealing the shared components of different systems at the right level of generality, an architecture promotes the design and implementation of components and subsystems that are reusable, cost-effective and adaptable.

The process used to develop this architecture consists of six steps:

Step #1: Gather requirements and desirables from all stakeholders.

Step #2: Gather all features, opportunities, and constraints from existing and emerging systems, products, services, and so on.

Step #3: Create abstractions (conceptual understandings) of the subject area. For example, a system that has three levels of abstraction might be constructed by (1) taking raw information and creating a low-level abstraction; (2) taking the low-level and creating a mid-level abstraction; (3) taking the mid-level and creating a high-level abstraction.

Step #4: Create higher abstractions until the number of components is reduced to a handful (e.g., 3-7 components). The number of abstraction levels equals the number of steps required to reduce the system to a handful of components.

At this point, the system has assumed the form of a candidate for a systems architecture.

Step #5: Re-implement the system downward from the highest level abstraction (most general concepts) based solely on the system's specifications and recreate its functionality, interfaces, and capabilities at the next lower level. From the example above: take the high-level abstraction and now re-implement the mid-level abstraction.

To be precise, the mid-level abstracted and generalized is the high-level; the high-level implemented via constraints is the mid-level, and so on. Note: "abstraction" and "implementation" are inverse operations.

Step #6: Incrementally and successively re-implement each lower level based on the level above.

The system has now been re-implemented based solely upon the candidate architecture and the implementation constraints. If the re-implemented system does not meet all the requirements and desirables, or does not encompass the existing and emerging systems (step #2), then the candidate architecture is not a systems architecture (go back to step #3), or the existing and emerging systems need to be re-evaluated (go back to step #2), or the requirements and desirables need to be re-evaluated (go back to step #1).

Otherwise, if the candidate architecture meets all requirements and desirables, and encompasses existing and emerging systems, then the candidate architecture is A systems architecture, not necessarily THE systems architecture -- there may exist several applicable systems architectures.

Figure 1. Summary of five LTSA layers.

The result of the architecting process: a new framework for understanding the system, with the important, common components and interfaces identified while still maintaining the system's functionality, capabilities, and connections to related systems. In other words, the new system behaves in the same way as the original system. This new conceptual framework, an architecture, allows for:

• the most efficient implementation of the system because the common components and interfaces are only implemented once, i.e., reveals commonality.
• adaptation to technology changes because the adaptation is only incremental change when viewed at the right of level of abstraction, i.e., helps manage change and reduce technical risk.

Thus, an architecture serves as a useful, general guide to understanding systems (e.g., learning technology systems) that are widely applicable and adapt over time.

The following are key points in the Learning Technology System Architecture:

• The specification is being developed in IEEE 1484 Learning Technology Standards Committee (LTSC) in close collaboration with Educom's Instructional Management (IMS) Project, the Aviation Industry CBT Committee (AICC), and the Department of Defense Advanced Distributed Learning (ADL) project.
• The LTSA uses several technical methodologies, including Yourdon, systems, bus, and text.
• Design issues are organized by granularity: from coarse detail (high level) issues to fine detail (low level) issues.
• The groupings of design issue granularities are called abstraction-implementation layers.
• There are five (abstraction-implementation) layers of description in the LTSA.
• The top layer, Learner and Environment Interactions, decomposes the system into the Environment, Interactions, and the Learner.
• Collaboration among students is internal to the Learner, i.e., the Learner represents a collection of students that collaborate among themselves.
• The LTSA approach to collaboration greatly simplifies the architecture and design of learning technology systems.
• The human-centered features are the most critical and have the highest design risk. Thus, human-centered features have high design priority (LTSA layer 2) in the abstraction-implementation layers.
• There are five features of human-centered learning: humans use multimedia (aural, visual, other senses, physical interactions) for information exchange; humans are unreliable receivers of information; humans are nomadic and frequently change teachers and institutions over a lifetime of learning; humans are diverse, learn differently, and learn differently over time; humans are self-aware and can give advice about better learning methods.
• The five human-centered features solely generate the LTSA system components -- there are no extra components outside the ones required for human-centered features.
• The LTSA system components consist of Learner, Learning Style, Behavior, Evaluation, Performance information, Assessment information, Records Database, System Coach, Query Index, Content Index, Locator Index, Knowledge Library, Learning Content, Delivery, Multimedia.
• The LTSA system components map to virtually all learning technology systems. Several popular system have been mapped in this specification.
• There are at least 40 stakeholders in learning technology systems. Each stakeholder can have different concerns (represented by selection of a subset of LTSA system components) and can have different priorities (represented by primary and secondary design issues).
• The stakeholders' incompatible concerns and design priorities are obstacles to building consensus in learning technology systems. The presentation of 40+ stakeholders can build consensus because each stakeholder can verify that their concerns are being addressed in LTSA.
• Distance learning and distributed learning are precisely defined from a technical perspective: the flows among the LTSA system components are the primary design priority and the processes and stores are the secondary design priority.
• Actual systems and interoperability are described by operational components (e.g., protocols, formats, functions, services, etc.). The LTSA provides a common method for analyzing and describing these operational components.
• Products, services, and systems can conform to the LTSA specifications, and these products, services, and systems can be tested for conformance.

Learning Technology Systems Architecture is not a white paper because (1) it is much more detailed than a typical white paper, and (2) a white paper is not used as a specification -- this specification can be used to measure conformance.

IMPORTANT: Many key terms appearing in this specification have currency in multiple areas of research and are subject to a variety of divergent interpretations. There is much overlapping and conflicting terminology in research on education, learning technology, and information technology. Thus, throughout this document key terms are to be understood solely as defined and used contextually, not as defined and used elsewhere. This document will be improved as terminology converges.

This specification consists of twelve major sections. The following is an overview of each section.

• Section 1.  Introduction: background information and a high-level summary of the features of the Learning Technology Systems Architecture specification.
• Section 2.  Methodology: the process used to develop this architecture specification.
• Section 3.  Architecture: an overview of the architecture described in terms of refinement layers. Each layer is summarized.
• Section 4.  Learner and environment interactions: the top refinement layer of the architecture. This section describes the learning experience as interactions between the learner and his/her environment. This layer only applies to information technology -- no pedagogy is implied.
• Section 5.  Human-centered features: the next refinement layer, learning systems implemented and adapted for humans.
• Section 6.  System components: the next refinement layer, the system components identified in human-centered features.
• Section 7.  Stakeholder perspectives: the next refinement layer, learning systems from a variety of perspectives.
• Section 8.  Operational components: the bottom refinement layer, generic components and building blocks of computer-based systems.
• Section 9.  Miscellaneous: additional requirements and features not covered elsewhere.
• Section 10.  Conformance: measuring implementations' compliance with this specification.
• Section 11.  References: pointers to related documentation and a glossary of terms.
• Section 12.  Specification development: a revision history and list of all outstanding issues with respect to this document.

This document proposes, from an architecture and engineering viewpoint, five layers of architectural description that can be applied, widely and generally, to learning technology systems. This document is a proposed starting point for discussion, refinement, and acceptance of a standard architecture for learning technology systems. It is hoped that a refined, standard, interdisciplinary architecture will enable rapid, further development of:

• industry-wide standards for learning technology systems architectures
• common, interoperable tools used for developing learning systems
• a rich, searchable library of interoperable, plug-compatible learning content
• common methods for locating, accessing, and retrieving learning content
• standardized, portable learner histories that can be transferred with the learner over time

The Learning Technology Systems Architecture has origins and inputs from several projects, which are listed in alphabetical order:

• ADL (DoD Advanced Distributed Learning): a US Department of Defense organization, including industry and institutions, that is defining learning technology requirements. See also:

  http://www.adlnet.org

• AICC (Aviation Industry Computer-Based Training (CBT) Committee): a consortium of users and vendors in the aviation industry that has developed specifications for computer-based training. See also:

  http://www.aicc.org

• ANSI IISP (American National Standards Institute, Information Infrastructure Standards Panel): a panel of standards committees, consortia, companies, institutions, and government agencies that identifies cross-industry standards needs in the Global Information Infrastructure (GII) and Global Information Society (GIS). See also:

  http://www.ansi.org/iisp

• "Architecture Abstraction Hierarchy Reference Model", by Frank Belz, Dan Suthers, Tom Wheeler. See also:

  http://advlearn.lrdc.pitt.edu/its-arch/p1484/ARM.html

• ARIADNE Project of European Union: a European Union project on web search visualization and collaborative web browsing. See also:

  http://ariadne.unil.ch

• CMU (Carnegie Mellon University), "Tool/Agent Communication", by Steven Ritter. See also:

  http://domino.psy.cmu.edu/ieee/tooltutorspec.html

• CORBAMED (Common Object Request Broker Architecture of Object Management Group (OMG), Medical Infomatics): Domain Task Force on the healthcare industry. See also:

  http://www.omg.org/corbamed

• EOE (Apple Computer's Educational Object Economy): an NSF-funded program for the authoring and development of small units of learning content implemented in the Java programming language. See also:

  http://trp.research.apple.com/

• IEEE P1484 LTSC (Institute of Electrical and Electronic Engineers, Project 1484, Learning Technology Standards Committee): an accredited standards committee. LTSC working groups are developing standards and guidelines for: architecture and reference model (P1484.1), learner model (P1484.2), glossary (P1484.3), task model (P1484.4), course sequencing (P1484.6), tool/agent communication (P1484.7), CBT interchange language (P1484.10), computer managed instruction (P1484.11), learning objects and metadata (P1484.12), student identifiers (P1484.13). See also:

  http://www.manta.ieee.org/p1484

• IMS (Educom's Instructional Management Systems) Project: a cooperative of commercial, institutional, and government organizations that are developing technology for the education industry. IMS will submit its specifications to IEEE P1484.l. See also:

  http://www.imsproject.org

• ISO-IEC JTC1 BT-EC (International Standards Organization - International Electrotechnical Committee, Joint Technical Committee 1 -- Information Technology, Business Team on Electronic Commerce): develops work items and collaboration for international electronic commerce. See also:

  http://www.din.de/ni/aktuell/j1btechtml

• ISO-IEC JTC1 GII (Global Information Infrastructure) Standards Roadmap: a catalogue and analysis of GII standards. See also:

  http://www.GlobalCollaboration.ORG/jtc1/gii-roadmap

• ISO-IEC JTC1 CAW (Cultural Adaptability Workshop): develops standards work items for internationalization, localization, and cultural adaptation of information technology systems. See also:

  http://www.itscj.ipsj.or.jp/caw

• ISO-IEC JTC1 SORT (Standards Operations Roundtable): cross-standards collaboration. See also:

  http://www.GlobalCollaboration.ORG/

The authors thank the following people for providing substantial input and comments on present and previous versions of this document: Frank Belz, Brant Cheikes, Chris Dabrowski, Andy DiRienzo, Eddy Forte, Steve Griffin, Peter G. Hayes, Joe I. Holbrook, Mary Holland, Jack Hyde, William A. Imbriale, Mike Kendall, Keith Knightson, Bill McDonald, Tom Murray, Errol Naiman, Denis Newman, Neal Nored, Claude Ostyn, Mike Petit, Mark Resmer, Tyde Richards, Steve Ritter, William Rugolsky, Jim Schoening, Udo Schuermann, Kathy Sinitsa, Jim Spohrer, Bob Spengler, Dan Suthers, Peter Waegemann, David S. Warren, Dina Warren, Tom Wason, Tom Wheeler, Steve White.

The authors also thank the following organizations for their assistance: ADL, AICC, Educom, IEEE, IMS.

This chapter explains the methods and techniques used for analysis, synthesis, and refinement (i.e., development) of the Learning Technology Systems Architecture (LTSA). The section is not a tutorial -- there are many books and materials on systems engineering and architecture. This section is meant to be a brief overview of the process.

Developer overview

The methodology used to develop this architecture and its layering is based on the Yourdon systems analysis methodology. Text description, system notation, bus notation, and combinations are used to describe each of the layers.

Administrator, teacher, and student overview

The purpose of outlining the methodology is to reveal the rigorous development process in use -- this work was not "created in a vacuum". The methodology used to develop this architecture is based on common techniques used in software engineering for twenty years and for tens of thousands of systems. The methodology is "tried and true". At times, the methodology requires the application of "judgement calls", based on the experience of the architects and engineers.

Information is gathered on the topic (in this case, learning technology systems). There are three types of raw information:

• Information that supports the main theme and provides good examples ("What is in the scope of the system?"). Information and examples of this kind will be used in the main description of the topic.
• Information that is somewhat supportive of the main theme, but does not provide the best examples for inclusion in a specification ("What is a borderline case?"). This information will be best used to determine the boundaries of the concepts.
• Information that doesn't support the main theme ("What is outside the scope of the system?"). This information will be used to identify topics that are inapplicable, unrelated, or outside the scope of the specification. In some cases, it may be easier to describe what is "outside" than what is "inside".

Figure 2. Organize raw details into good examples, borderline examples, and bad examples.

When organizing information at a particular level of detail, it may be important to exclude certain information at that level. For example, when discussing the architecture of a house, it might be distracting and counterproductive to attend to plumbing issues; but plumbing issues might need to be addressed when drawing up blueprints.

Information exclusion might be better addressed by asking the question: what details obscure the main focus or main theme? A cartographer does not include all details when creating a map -- his/her judgement is based on the purpose and use of the map being created. This point may be illustrated by considering the diagramming of a web browser and web server as it is integrated into a larger system.

Figure 3. Essential vs. non-essential details for web browsers and servers. The choice of which details to include/exclude is dependent on context and use.

In #1, the web browser and web server are diagrammed simply as: the web server transferring web content to the web browser. Of course, there are more details to this transaction, such as who initiated the transfer (#2, #3) and the source of files and programs (#4) that are served up to the client. But are these details necessary? If the analysis requires addressing those details now (e.g., incorporation of "push" and "pull" technology) then it may be appropriate to include those details. However, if the diagram can still be understood without the details, then the details should be excluded.

Excluding non-essential details greatly improves the readability, interpretation, analysis, and acceptance of diagrams.

IMPORTANT: Throughout the LTSA specification, the authors have made certain "judgement calls" on what to include and exclude for the sake of clarity, utility, and consensus.

Once the raw information is collected, the information is organized by levels of detail or "granularity". Information of coarser granularity (lesser detail) is organized as "abstractions" while information of finer granularity (greater detail) is organized as "implementations". There may be a need to identify several "refinement layers", i.e., not just an abstraction level and an implementation level but levels in between.

Information at the same level of detail is organized into function groupings called subsystems.

Miscellaneous information that is important, but does not describe a system boundary, a system interface, or system functionality ("what it does"), is kept separately and called "implementation constraints". For example, in a computer networking system the main purpose of the system is to transfer information, but cost and security might be implementation constraints.

Implementation-implementation boundary

For information at the same level of detail, each subsystem that is identified must have a clearly defined boundary. Subsystem boundaries are called "implementation-implementation" boundaries, e.g., an interface between two subsystems.

Abstraction-implementation boundary

For information at different levels, each refinement layer must have a clearly defined boundary between its abstraction above and its implementation below. Refinement boundaries are called "abstraction-implementation" boundaries.

(NOTE: "abstraction-abstraction" boundaries refer to two abstractions that point to the same implementation. Currently, this technique is not necessary for this architecture specification.)

Three primary notation conventions are used throughout the LTSA: text description, system notation, and bus notation. The choice of notation is dependent on the nature of the subject. System notation is useful when there are a handful of subsystems, the functions or roles of each subsystem is well-defined, and the connections between subsystems are established and unchanging (see LTSA layers 1, 3, 4). Bus notation is useful when there are a large number of subsystems, the functions or roles are undefined or changing over time, and the connections between subsystems are dynamic or on-demand (see LTSA layer 5). Text description is useful when the subsystem boundaries are unclear, the subsystem boundaries are overlapping, or the system and bus notations are impractical (see LTSA layers 2 and 4).

The subsystems at the same level of detail are described via text description rather than a diagrammatic notation. Diagrammatic notations, typically, require firm subsystem boundaries and non-overlapping subsystems. If the boundaries of a subsystem are not well-defined, a textual description might be a useful placeholder until the boundaries are defined. If well-defined boundaries are not possible, a text description might be the only technique for describing the layer.

The LTSA layer 2, Human-Centered Features, uses a textual description.

The LTSA layer 4, Stakeholder Perspectives, uses a combination of systems notation and text description.

For subsystems at the same level of detail, each subsystem is connected, as appropriate, to other related subsystems. These connections define the flows between subsystems. Subsystem and flow analysis has been described in many good books, including several by Ed Yourdon. The following is a very brief summary of the notation.

The LTSA layer 1, Learner and Environment Interactions, uses system notation. Layer 1 consists of 2 processes and 1 data flow. One of the processes (learner) actually represents several subsystems (multiple students represent the collective learner).

The LTSA layer 3, System Components, uses system notation. Layer 3 consists of 4 processes, 2 data stores, and 10 one-way data flows, and 1 two-way data flow.

Figure 4. System notation uses components: process, stores, and flows. Processes can manipulate data information, control information, or both. Stores can hold data or control information. Flows can transfer data or control information. Flows can be one-way or two-way.

Processes are represented by ovals. A subsystem is a (generic) process, i.e., something that is "alive" and able to transform its inputs into outputs. For example, a data transformation process transforms data inputs into data outputs. A data transformation process is represented by an oval drawn with a solid line. Information technology systems are mostly data transformation processes. Some information technology systems are called real-time systems. Real-time systems include both data transformations and control transformations. A control transformation process transforms control inputs into control outputs. A control transformation process is represented by an oval drawn with a dashed line. In practice, many processors combine a mixture of control inputs, control outputs, data inputs, and data outputs. A transformation that operates on a mix of both data and control is represented as a data transformation process, i.e., an oval drawn with a solid line.

Arrows are used to represent connections between the subsystems of the whole system. The arrows represent the flow of information, data or control, between subsystems.

Information that flows in a single direction from one subsystem to another is called a one-way flow. In the case of connecting multiple subsystems, a one-way flow has a single source (origin) OR a single sink (destination); a single source with multiple sinks or a single sink with multiple sources is considered a one-way flow. In considering data flows, it is important to distinguish between the direction of data transfer (data flow) and the person or system who initiated the data transfer (control flow). For example, when a person uses a web browser to call up a page from a web server, this transaction is notated as a data flow going from the server to the browser, i.e., a data output from the server connected to a data input of the browser, even though the person (browser) initiated the request. In other words, for web "push" and "pull" technology, the data flow is the same (i.e., a one-way flow from server to browser), but "pull" technology emphasizes the control flow (e.g., initiating the request) from browser to server, while "push" technology emphasizes the control flow from server to browser.

Information that flows in both directions between subsystems is called a two-way flow, e.g., telephone calls (two-way data flow), video conferencing (two-way data flow), network routing information (two-way control flow). In many cases, a protocol is used to organize the two-way flow of information between two subsystems.

A special case concerns the "updating" of information in a data store (e.g., a database) or a control store (e.g., event history). For example, when a record is updated in a database, typically, the record is retrieved, modified, and then stored. For notational purposes, there is no distinction between the creation of the original database record and its subsequent update (the modification of only certain fields): both creation and updating are notated as one-way flows into the data store.

The most common flow is the data flow, which represents data moving among two or more subsystems. A data flow connected to a subsystem represents data input (a one-way flow), data output (a one-way flow) or both (a two-way flow). Data is the unit of information, relative to the level of descriptive detail, that represents the main processing of the whole system (see Data vs. Control below). For example, in a subsystem that adds numbers (a calculator), the flow that supplies the numbers to be added (data entry) might be a data input flow; while the flow that emits the result of the calculation (output display) might be a data output flow. Data transferred in both directions is a data input/output (a two-way flow), e.g., data transferred over a modem.

The control flow represents inputs and/or outputs that control the processing of data among two or more subsystems. A control flow can be a control input (a one-way flow), a control output (a one-way flow), or both (a two-way flow). In the example above of the calculator subsystem that adds numbers, the signal to start calculating the sum (the ADD or "=" key) is a control input, and the signal to indicate that a calculation has overflowed (the ERROR light) is a control output. Control transferred in both directions is a control input/output (a two-way flow), e.g., the signaling that negotiates modem speed and quality when modems connect.

The choice of calling information data or control is somewhat arbitrary. For example, establishing a connection between a web browser and a web server might be described as control information from the perspective of web applications, but would be described as data information from the perspective of network routers. A guideline might be that if the information in question is involved in the main purpose of the system or the main inputs and outputs, it would be labeled as data information; if the information changes the processing of information, starts or stops processing, or starts or stops the flow of information, it would be labeled as control information.

A store holds information. A data store holds data information, e.g., a database. A control store holds control information, e.g., an event history.

Bus notation is used when the number of components is large, the functionality of the components is not pre-defined, or the connections between components is dynamic. Bus notation features: common naming, common control flow, non-homogenous data flow, and dynamic, on-demand connection.

The following diagrams illustrate bus notation.

Figure 5. An information bus uses a common namespace.

Each member of the bus has a unique name within the namespace of the bus. A "bus" implies a common, shared namespace.

Figure 6. An information bus uses a common control flow protocol among bus elements.

Each member of the bus uses the same protocol to request or respond to transactions. A "bus" implies a common control flow mechanism, e.g., starting and stopping transactions and/or the flow of information.

Figure 7. Data flows on information busses vary depending on sender and receiver.

The members of a bus can use different data flow protocols, but they use a common control flow protocols. A "bus" does not imply a common data protocol. Example: On the "internet bus", applications use IP (internet protocol) to initiate transactions and transfer data, but the data protocols can vary (e.g., HTTP over TCP, FTP over TCP, NFS over UDP).

Figure 8. Bus notation is used to represent dynamic, on-demand connections.

A bus is used to represent and implement dynamic, on-demand connections among the members of the bus. A bus does not imply "fixes" connections between specific members. Each transaction represents a dynamic connection among bus members.

Figure 9. Abstracting raw details to higher level abstractions. This diagram shows three layers but, typically, there are more (the LTSA has five). The abstraction process continues until the system is reduced to roughly 3-7 components.

Once information has been gathered, the conceptual understanding is described using one of more of the techniques above (other notations are possible, too). For example, a useful architecture for a given system may require three levels of abstraction: (1) take raw information and create a low-level abstraction; (2) take the low-level and create a mid-level abstraction; (3) take the mid-level and create a high-level abstraction, i.e., the architecture.

After each cycle of abstraction, a new, higher level abstraction is produced. Another output from the abstraction technique is a set of implementation constraints, i.e., features of the implementation (e.g., cost, performance) that are not represented in the functionality ("what it does") of the abstraction.

The abstraction technique (creating higher level abstractions, based on implementations and/or lower level abstractions) is repeated until the system is reduced to a handful of components, e.g., 3-7 components. The number of abstraction levels equals the number of steps required to reduce the system to a handful of components.

Other description techniques include the Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers, Wheeler.

Figure 10. Re-implementing the system. Each abstraction creates an implementation via constraints. The system is re-implemented but architectures (high level abstractions) may reveal new structures and/or create new systems not previously conceived.

Once the highest-level abstraction is reached (the architecture specification), the system is then re-implemented on the basis of that abstraction (most general concepts). Re-implementing the system consists of implementing each abstraction layer in the context of implementation constraints. In other words, the system is built solely based on the specification. An "implementation" doesn't imply a functioning, physical system: an implementation might be a more detailed description of a higher level abstraction (concept).

If the newly implemented system (e.g., a high-level abstraction now built as a mid-level implementation) produces the same functionality, interfaces, services, and qualities (implementation constraints) as the original mid-level specification, then the iterative implementation process continues (success). If the newly implemented system does not match the requirements of the original mid-level specification, then the higher-level abstraction is incorrect or the implementation constraints are poorly defined (failure: go back and correct a previous step).

The iterative implementation process is continued until the last (lowest level) abstraction is implemented successfully, i.e., matches the original requirements and desirables of the existing and emerging systems in the data gathering step.

The purpose of re-implementing the system is to verify the correctness of the abstractions and the implementation constraints. When completed, this process validates the highest-level abstraction -- the architecture specification. In practice, an architecture specification is not completely re-implemented, but only the high-risk portions are prototyped. What is essential is the satisfaction of critical functional requirements (e.g., Is the high-level system still a learning technology system?) and/or important implementation constraints (e.g., Can the multimedia be delivered over the Internet? Can the student collaborate cost-effectively with other students?).

Figure 11. Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers, and Wheeler.

One architecture analysis technique is to group technical issues into well-known information technology categories. The diagram above maps the LTSA, IEEE, IMS, AICC, and ARIADNE to the Architecture Abstraction Hierarchy Reference Model (ARM) of Belz, Suthers, and Wheeler. The ARM can be useful for architecture analysis in areas outside of learning technology.

The methodology is merely a guideline -- sometimes there is no clear "right answer". Some "judgement calls" are required, based on the experience of the architects and engineers. The following are examples of "judgement calls" in the development of the LTSA. (See also 2.1 Information inclusion, and 2.2 Information exclusion.)

Example #1

The Environment's affect on the Learning is shown by a one-way arrow, but why isn't the Learner's affect on the environment show (e.g., two-way arrow)? Learners do have an effect on their environment, e.g., a Learner's effect on a student teacher; the effect of the Learner's research that addresses the state of the art. While the Learner's affect on his/her Environment might be a part of the learning experience (e.g., teacher training, graduate school), these details are less important to the main theme of applying learning technology to learning experiences.

Example #2

In the LTSA system components, the Locator Index is shown between System Coach and Delivery process, but the Locator Index is not shown between Delivery process and the Knowledge Library, and the Locator Index is required for retrieving Learning Content. Creating and emitting a Locator Index is a significant design issue and a significant "result" of the System Coach processing; thus, the System Coach is shown emitting a Locator Index. However, the Delivery system views the Knowledge Library simply as a database, so "requests" are not diagrammed -- only the "responses" to the requests are diagrammed.

Example #3

In the LTSA system components, the flow between Delivery and Knowledge Library is one way, but clearly information flows both ways. The primary theme is the flow of Learning Content to the Delivery Process. The above paragraph identified one type of information (Locator Index) not diagrammed that flows in the opposite direction. There may be other information, too (e.g., electronic commerce, intellectual property rights management), but the one-way arrow still represents the main theme. IMPORTANT: A one-way arrow does not prohibit flow in the opposite direction or two-way flows at lower abstraction-implementation layers.

Example #4

In the LTSA system components, both the "queries" (Query Indexes) to the Knowledge Library and their "responses" (Content Indexes) are diagrammed, but the "queries" to the Records Database are not diagrammed -- only the "responses" (System Coach extracting Learner's history) are diagrammed. Like above, there generation of Query Indexes is a significant step of the System Coach processing. The extraction of Learner's history is not a significant design issue for the System Coach so only the "responses" are diagrammed.

Abstracting, architecting, and implementing a system involves many iterations of "trying concepts" (abstractions) and "building them to verify that the abstractions work" (implementations). Many abstractions and implementations are possible. There is no single right answer, but there are wrong answers. Architectures are high-level abstractions that represent a range of systems, not a single system at a single point in time: architectures are general solutions that are adaptable over time.

Five refinement layers of architecture are proposed. They are applicable to a broad range of learning scenarios. These refinement layers are called, from highest to lowest levels:

• Learner and environment interactions: Addresses the learner's acquisition, transfer, exchange, formulation, discovery, etc. of knowledge and/or information through interaction with the environment.
• Human-centered features: Addresses the human aspects of learning technology systems.
• System components: Describes the components identified in human-centered features.
• Stakeholder perspectives: Describes learning systems from a variety of perspectives by reference to subsets of the system components layer.
• Operational components: Identifies the generic "plug-n-play" components, protocols, and interfaces of a computer-based learning technology architecture, as identified in the stakeholder perspectives.

Figure 12. LTSA abstraction-implementation layers.

Developer overview

The five abstraction-implementation layers identify design priorities, i.e., the ordering of most to least important. Intuitively, developers understand that, for example, the human features of learning technology systems (layer 2) have a more pervasive effect on system design than, for example, the particular multimedia format (layer 5) -- a localized, "swappable" feature. This section explains how the methodology was applied.

Administrator overview

The five layers represent five independent areas of technical analysis. For example, it is possible to discuss an abstraction, e.g., the LTSA system components (layer 3), independently of an implementation, e.g., the bus protocols of an actual implementation (layer 5). In other words, even though layer 3 contains components such as "Evaluation" and "System Coach", there is no requirement for separable, identifiable components called "Evaluation" and "System Coach" in actual implementations.

Teacher and student overview

The five layers of the LTSA help separate the "big picture" from the "details". The use of layers helps understand the problem "step by step".

The Learning Technology Systems Architecture is described in five successive refinement layers from highest to lowest. Each layer describes a system at a different level. The lower layers are implementations of the higher layers. The higher layers are abstractions of the lower layers.

This refinement layer focuses on the highest level functionality from an information technology perspective: the learner has new or different knowledge after a learning experience. In information technology, this is diagramed as one subsystem (environment) transferring information to the other subsystem (learner), i.e., interaction. The learner and environment interactions diagram is not intended to represent current theories of learning or a learning process. It represents the information technology issues of learning technology systems and is useful for common, well-understood software engineering analysis and design techniques. For the purposes of this architecture specification, the primary focus is information technology.

This refinement layer concerns the five most important design issues that result from involving human learners:

1. Humans require sensory input and/or physical interaction.
2. Humans are unreliable learners.
3. Humans are nomadic learners.
4. Humans are diverse and unpredictable learners, and change over time.
5. Humans are self-aware and can have insight into their best learning strategies.

Human learners receive information via sensory inputs and/or physical interactions. Multimedia includes aural, visual, other sensory inputs, and physical interactions.

Human learners are unreliable in the sense that errors or limitations on the learner's part might delay or thwart the intended outcome of the learning experience (e.g., the learner forgets what was learned, learns the wrong thing, etc.). This motivates the need for some type of "feedback loop" that "drives" or "coaches" the learning experience. The "driver" of this feedback loop is responsible for improving the learning experience: maximizing desirable (intended) outcomes, minimizing undesirable (unintended) outcomes. The driver (System Coach) might be any combination of: student (see Glossary for distinction between student and learner in this context), parent, teacher, mentor, employer, institution, courseware developer, and so on.

Human learners are nomadic: they move from teacher to teacher (e.g., K-12), from institution to institution. A learner has more than one teacher over a lifetime of learning experience, so there is a need to transfer information about the learner, e.g., performance history and learning objectives, from one teacher to another (or, if the learner moves, from one institution to another). In addition, discovering the "best" learning strategy may require much investigation and analysis of the learner's performance over long periods of time. Inferences drawn from the analysis are used to influence the decision-making for adapting to the best learning style. Thus, the need to maintain a learner's performance history in a records database.

Human learners are unpredictable by virtue of their individual differences: unsurprisingly, there might be no "best" learning strategy for all. Nor is it surprising that human learners learn differently over time. This motivates the need for more than one strategy for "feedback loops". The ability to transfer learners (via common learner records database formats) from one teacher to another (or institution to another) makes a wider variety of learning strategies available to the learner and, thus, minimizes the effect of the unpredictable nature of human learners. A rich knowledge library helps support a wider variety of learning strategies, too, because the learner, student ("student" in contrast to "learner", see Glossary), parent, teacher, mentor, institution, etc., are able to pool a large library of knowledge so as best to serve the learner's needs.

Human learners can be aware of their own "best" learning styles. An learner does not always respond best to the same learning strategy over his/her lifetime of learning experience. Thus, learning styles may be varied to serve the learner's (or teacher's, or institution's) needs. It may be impractical or inefficient for the teacher (or institution) to dictate the "best" learning style, even if the teacher (or institution) has detailed records of the learner's performance. In some cases, the learner might be able to provide better insight on the style or strategy that works best for him or her. Likewise, the learner shouldn't always dictate the style or strategy. Thus, provision should be made to enable learners and other stakeholders (parents, teachers, mentors, employers, institutions, etc.) to negotiate (two-way communication) the optimum style or strategy so that the learning experience can best adapt over time.

In summary: Human learners require sensory input and/or physical interactions to receive information. The unreliability of human learners motivates the need for a "feedback loop" to maximize desirable learning experiences and minimize undesirable learning experiences. A history of learner performance is required because the best learning strategies may only be discovered after long periods of observing the learner's behavior. Also, learner performance information is necessary to support the transition of learners though different institutions, courses, teachers, and so on. A wide and rich knowledge library is required to support many learning strategies and to accommodate the differing needs of individuals (some learners learn best by reading, some by discovery, some by collaboration, some via tutors, etc.). Negotiated learning styles allow all participants and stakeholders to adapt to the needs of the learner, student ("student" in contrast to "learner"), parent, teacher, institution, employer, etc., because the "best" learning style can vary over time for the participants and stakeholders.

The LTSA identifies four processes: Learner, Evaluation, System Coach, and Delivery process; two stores: Records Database and Knowledge Library; and seven information flows among the components: Behavioral observations, Assessment information, Performance information, Query Index, Content Index, Locator Index, Learning Content, Multimedia, Learning Style.

Briefly, the overall flow has the following form: (1) the learning style or strategy is negotiated among the learner and other stakeholders; (2) the learner is observed and evaluated; (3) the evaluation produces assessments and/or performance information; (4) the performance information is stored in the learner history database; (5) the system coach reviews the learner's assessment, past performance history, and, possibly, future learning objectives; (6) the system coach searches the knowledge library, via query and content indexes, for appropriate learning content; (7) the system coach extracts the locator indexes from the available content indexes and passes the locator indexes to the delivery process, e.g., a lesson plan; (8) the delivery process extracts the learning content from the knowledge library, based on locator indexes, transforms the learning content to an interactive multimedia presentation to the learner.

In a given learning situation, there is not necessarily a one-to-one correspondence between system components and individuals. An individual might represent more that one system component in a given learning situation, e.g., the individual who represents the Learner might also represent the System Coach in a self-paced learning environment. Likewise, more than one individual might represent a single system component in a given learning situation, e.g., the Learner might be represented by several individuals learning collaboratively or as a team.

Although a single set of components is described, there might be several different kinds of learning experiences occurring simultaneously in a given learning situation. For example, a course offered jointly by the mathematics and computer science departments may foster two different kinds of learning experience, yet there is only one "physical" course that the learner attends. Another example would be the student teacher in the classroom: the "learners" are learning (through their own learning experiences), and the teacher is a "learner", too (a different learning experience).

In Section 4, over forty stakeholder perspectives are formulated and reviewed from the standpoint of the LTSA. The list of perspectives isn't exhaustive. The goal is (1) to verify the validity of the LTSA components in significant systems, stakeholders, or industries, (2) to discover which LTSA components are emphasized and de-emphasized in different systems, and, (3) to determine priorities among lower-level design issues.

The stakeholder perspectives require a separate refinement layer because this layer of granularity addresses the design issue: which perspective, view, or subset is relevant to the lower-level design.

The major areas of operational components are identified via bus notation and information busses: protocols, interchange methods, processes, data stores, control flow, and human interfaces. Knowing which busses and protocols are in use can help increase the understandability of a system, but common busses and protocols don't imply interoperability, e.g., just because applications use TCP/IP or XML, it does not mean that they can interoperate among themselves.

The top refinement layer of the LTSA is a very generalized architecture refinement layer called "Learner-Environment Interactions" (see below). IMPORTANT: There is often much confusion about this level of abstraction. The aim at this level is to view the system from an information technology perspective (e.g., in terms of the flow of information). Many readers misread this refinement layer as a description of a theory of learning. This is not a diagram of any theory of learning. The purpose of describing learning technology at this level of abstraction is to relate it to the software engineering methodology to create lower levels of abstraction.

Developer overview

The top layer describes the basic purpose of learning technology systems: learning experiences that involve learners interacting with their environment.

Administrator, teacher, and student

For the non-engineer reader, it is best to skip this section. This section is necessary for technical analysis: there must be some starting point for abstraction-implementation layers. However, the diagrams and notation often confuse non-engineers because they believe these diagrams represent pedagogy, theories of learning, etc. -- they don't. The diagrams are helpful for simply answering the engineering analysis question: what is the main information flow?

Figure 13. The learner's perspective of the learning environment.

The Learner-Environment Interactions diagram only represents the Learner and the Environment from a systems engineering perspective of information technology, i.e., this diagram doesn't portray current research on theories of learning. The reason for using this diagramming technique is to simplify certain engineering aspects of technology design. For example, one theory of learning might consider the learner in an environment that causes changes in the learner's mental states that result in the learner having new or different knowledge. This is analogous to computer networks: data doesn't actually flow from system to system, but events occur (network protocols) that cause changes in the computer system's state (i.e., the computer is an event driven state machine that has subcomponents organized as smaller state machines, e.g., a process or a database server), and these changes in the system's state result in its having new or different data. Thus for this part of the problem, the focus is on the overall view of information flow and the system is diagramed as a one-way arrow (flow) of Interactions from the Environment to the Learner. Of course, the implementations of concepts (lower level abstractions or systems themselves) will focus on pedagogical or other technical issues.

Figure 14. Learner-Environment Interaction System diagram. Note: Collaboration among the students is internal to the collective Leaner.

The Learner (process) represents an abstract learner, e.g., a student, several students working collaboratively, or members of a team operating in different roles.

IMPORTANT: Collaboration among students is internal to the collective Learner. An analogy is a distributed database system: several individual databases "collaborate" to give the appearance of a single database. The LTSA notion of student collaboration, i.e., internal to the Learner rather than as a separate component, is an important simplifying feature of the LTSA.

The Environment (process) represents the environment that the Learner interacts with. The Learning Interactions (flow) represents the learning experiences.

This refinement layer represents the significant design issues of implementing a Learning-Environment Interaction System involving human Learners. From an information technology perspective, human learners impose significant design constraints -- their effects are pervasive. For example, humans are unreliable and unpredictable receivers of information. Had computers been the receivers of information, the unreliability effects could be localized (via error detection and correction), the unpredictable effects might be non-existent, and the design priority of the features of this layer would be much lower in the abstraction-implementation layers.

Developer overview

The human-centered features have a pervasive effect on the design. Thus, human-centered features become one of the higher abstraction-implementation layers.

Administrator, teacher, and student

The high priority given to human-centered features, their explicit layering, and notation are probably not familiar to non-engineering readers. Simply put, humans are not computers and every design issue concerning humans adds more "design risk" to the system. An analogy is building a house on unstable ground: typically foundation design is not a difficult or risky task for house building (i.e., a lower design priority), but for complex foundations the design risk is higher so the design priority should be higher -- in fact, if the design risk is high enough, the design of the rest of the house may be affected by the design of the foundation. The same is true for learning technology systems: the nature of human learning has significant "design risk" (it affects the design of the rest of the system) so human-centered features should have high design priority (LTSA layer 2).

Figure 15. Learner is a "faulty" information receiver. Learner in not a computer.

The most significant features of designing a learning technology system for humans are:

• Humans receive information via sensory input and/or physical interactions. For learning technology systems, information transfer is via multimedia. Multimedia typically includes sound and vision, but may include other sensory and/or physical systems.
• Humans aren't reliable receivers of information. Learners sometimes forget what they are taught. Learners sometimes learn things other than what they are taught.
• Humans are diverse and are unpredictable receivers of information. Effective teachers require more than one strategy or style.
• Humans are nomadic -- they learn at different places and learn differently over time. In K-12, Learners, typically, change teachers every year (nomadic Learner). Learning technology systems must be customizable, configurable, and adaptable to the needs of learners, students (in contrast to learner, see Glossary), teachers, institutions, and other stakeholders as their needs vary over time.
• Humans are self-aware and can give advice on themselves. A Learner may provide good advice on the best learning style for him/her.

An important feature, but not a design issue at this level, is that a single human can play several roles (e.g., in addition to the role as Learner, the student can also perform Evaluation and the student can be the Records Database) and several humans can play a single role (e.g., several students collaborating as a collective Learner; the parent and teacher suggesting Learning Styles on behalf of the Learner).

Another important feature is that several learning experiences may be occurring simultaneously, even though a single set of components is described. For more information, see section 7.6, Multiple, parallel, and/or recursive components.

Figure 16. Transferring information to the Learner via sensory input and/or physical interactions.

The starting point of the LTSA is the Delivery of information, via multimedia, to the Learner. Typically, multimedia includes aural and visual information, but multimedia may include other sensory information and/or physical interactions. Note: From this perspective, this portion of learning technology systems is no different than entertainment systems. The difference between entertainment systems and learning technology systems is the coaching and "feedback loop" that measures (Behavior and Evaluation) the effect of the experience (e.g., Delivery of Multimedia) and chooses appropriate learning content (System Coach, Query Index, Content Index, Knowledge Library, Locator Index) based on this measurement (Assessment and Performance information) for future learning experiences (e.g., Delivery of Multimedia).

Figure 17. The feedback and coaching loop.

Feedback, coaching, and Learner interaction are necessary to maximize desirable learning experiences and minimize undesirable learning experiences. Learner interaction may be desirable for other reasons, such as making the learning experience more enjoyable, motivating the Learner, and improving the teacher's skills.

The Behavior of the Learner, the Evaluation of that Behavior, and the Assessment that is produced determine where the student "is at". This is similar to feedback control systems where the system coach needs to know the current position (absolute position or relative to a desired position) of the object being controlled.

The System Coach determines "current position" from the Assessment. Based on the "current position", the System Coach determines the appropriate "action" (Delivery of Learning Content, etc.) to achieve the desired "target" (pedagogical objectives). The System Coach sends Locator Indexes (references to lessons, experimentation tools, suggestions, etc.) to the Delivery system.

Feedback loops can recover for errors (in this case, in human response to the learning experience) or can coach, motivate, and direct towards targets and goals. Of course, this oversimplifies many learning technology systems (and human learning itself), but feedback loops represent significant portions of learning experiences, determining what the Learner has learned and changing the Delivery of Learning Content (e.g., lesson plan) to achieve the desired objective.

Figure 18. Records Database is necessary for a lifetime of learning.

Learners are nomadic and, typically, change teachers frequently, i.e., a single Learner does not have a single teacher for his/her lifetime of learning. A primary reason for a Records Database is "handing off" Learners to other teachers and/or institutions.

Another significant design issue is that Learners learn over long periods of time. It may take long periods of interaction with the Learner to determine the best strategy. Typically, there will be more than one teacher associated with a Learner's lifetime of learning experience, so Performance information is stored in Records Databases for the purpose of communicating to other teachers so that each can "pick up where the last left off", i.e., the next teacher minimizes the amount of observation (of Behavior) and Evaluation needed to determine where the student "is at". Of course, Learners, students (in contrast to Learners, see Glossary), parents, and employers are interested in Performance information of their history (Records Database) because they can influence the learning experience, too.

In summary, a Records Database containing Performance information supports the long-term analysis of student performance and supports better "hand-offs" from one teacher (or learning technology system) to another. A Records Database is commonly used to store information about the past (Learner history), but the Records Database may be used to store information about the present (e.g., Assessments, current position) and the future (e.g., Learner or employer objectives).

Figure 19. A rich Knowledge Library is necessary for varying Learners.

A Knowledge Library is necessary to support diverse learning capabilities, strategies, and styles. If a Learner is having problems with a particular lesson, an alternate lesson plan may be used to meet the Learner's needs. If the lesson is going "too fast", going slower might suffice, while other problems are best solved by varying the style of presentation of the material or by varying the material itself, e.g. adjusting the degree of difficulty. In this case, the Knowledge Library supports different learning capabilities by having a variety o choices of Learning Content to meet the varying needs of Learners. With detailed Performance information, a sophisticated Records Database, inference systems and a rich Knowledge Library, the System Coach has a wide range of learning experiences, i.e., Learning Content, to choose from, such as lessons, interactions, suggestions, tutors, experiments, resources, and so on.

In summary, the unpredictability of the learning experience requires a significant Knowledge Library to support varying learning styles and strategies.

Figure 20. Both Learner and system may have insight to best learning experience.

The Learner himself/herself may interact with the System Coach to communicate Learning Styles. The negotiation may be one-way (also known as an "assertion" or an "inquiry", e.g., Learner has sole responsibility for advising, or the System Coach has sole responsibility for directing), two-way (e.g. Learner selects choices from those presented by System Coach), or involve other participants, such as parent, employer, mentor, institution, or courseware developer. Depending on the role, the parent, employer, or institution may act on behalf of the Learner or the System Coach.

The following diagrams review the five steps to developing the LTSA system components. The LTSA system components are solely based on the human-centered features.

Note: The development of the LTSA system components is based solely on the "axioms" of human-centered learning: the five human-centered features. There are no additional components added outside the ones required for human-centered learning, thus, the LTSA is a minimalist approach to system architecture.

Figure 21. Step #1: Transferring information to Learner via sensory input and/or physical interactions.

Figure 22. Step #2: Humans are unreliable Learners so feedback and coaching loops are necessary.

Figure 23. Step #3: Records Databases are necessary for a lifetime of learning and long-term analysis of Learner history.

Figure 24. Step #4: Rich Knowledge Library for diverse and unpredictable capabilities of Learners.

Figure 25. Step #5: Learner has insight into his/her learning capabilities.

Humans can play one or more simultaneous roles in a learning technology system, i.e., not all components are completely automated. Additionally, infrastructure may have multiple purposes. The following is a brief sampling of some possible mappings:

• Student (an individual): Learner (process), Evaluation (process), Records Database (data store), System Coach (process), Knowledge Library (data store), Delivery (process).
• Other students: collaboration as a collective Learner (process), role playing in team learning as a collective Learner (process).
• Parent: Learner (process) via collaboration or mentoring, Evaluation (process), System Coach (process).
• Teacher: Learner (process) via collaboration or mentoring, Evaluation (process), System Coach (process), Knowledge Library (data store), Records Database (data store), Delivery (process).
• Mentor: Learner (process) via collaboration or mentoring, Evaluation (process), System Coach (process), Knowledge Library (data store).
• Institution: Evaluation (process), Records Database (data store), System Coach (process), Knowledge Library (data store), Delivery (process).
• Library: Knowledge Library (data store).
• Librarian: Index (data flow), Knowledge Library (data store).
• Classroom: Knowledge Library (data store) via experimentation and discovery, Delivery (process).
• Web Browser: Delivery (process), observable Behavior (data flow), Multimedia (data flow), Index (data flow) via search engines and web retrieval.

The learner and environment interactions, as represented by the Learner-Environment Interactions System abstraction (concept) and implemented via the constraints of human-centered systems, result in a system that reflects important design constraints of human learning:

• Humans require sensory input and/or physical interaction for information exchange. Interactive Multimedia is used for information exchange.
• Humans aren't reliable receivers of information. Learners sometimes forget what they are taught. Learners sometimes learn things other than what they are taught. Thus, feedback systems are required. Feedback systems are designed for (1) position determination (observing Behavior, Evaluation, and Assessment), (2) target determination and control (System Coach achieving pedagogical objectives), and (3) action (Learning Content: lessons, experimentation, discovery, collaboration, etc.).
• Humans are diverse and are unpredictable receivers of information. Since different individuals have different learning needs, effective teachers require more than one strategy or style. Thus, recordkeeping and a rich knowledge library must be integrated into the feedback system. The recordkeeping (Performance information and Records Database) supports the Learner's transition through many teachers or learning technology systems over the Learner's lifetime of the learning experience. The recordkeeping supports better decision-making (inferences made by the System Coach via queries to the Records Database and Knowledge Library) for selecting different learning strategies and styles (Delivery of appropriate Learning Content as, say, Multimedia) to accommodate the unpredictable nature of human learning. A richer knowledge library supports a wider range of effective learning technology systems.
• Humans are nomadic -- they learn at different places and learn differently over time. Learning technology systems must handle nomadic Learners -- they frequently change teachers and institutions.
• Humans can give advice about their own learning. Learning technology systems must be customizable, configurable, and adaptable to the needs of changing needs of Learners, teachers, institutions, and other stakeholders. Thus, provision should me made to enable Learners, parents, teachers, employers, institutions, and others to participate in the negotiation of learning styles, strategies, preferences, and so forth. A direct interaction between Learner and System Coach is important for effective communication and negotiation among the stakeholders in the Learner's learning experience.

All LTSA components (Learner, Behavior, Evaluation, Assessment, Performance information, Records Database, Learning Content, Query Indexes, Content Indexes, Locator Indexes, Knowledge Library, Delivery system, interactive Multimedia, Learning Styles) reflect the design constraints of implementing a human-centered learning technology system.

This section describes the processes, flows, and stores of the Learning Technology Systems Architecture. Processes are described in terms of boundaries, inputs, process (functionality), and outputs. Flows are described in terms of connectivity (one-way, two-way, static connections, dynamic connections, etc.) and the type of information across the flow. Stores are described by the type of information stored, and by search, retrieval, and updating methods.

As elsewhere in this specification, the descriptions are to be understood as specifying general components, and the purpose of the notation is to identify generic features. Most actual, physical implementations of learning technology systems will not fit these component boundaries exactly, but represent implementation variations. For example, many commercial courseware delivery systems combine portions of the Evaluation, Delivery, and System Coach processes into a single session presentation tool. This combination is an implementation efficiency, but conceptually, the components are separate, and some implementations keep the components separate. In this respect these systems resemble automobiles, in which the steering and power management are located together in front of the driver, but are conceptually separate; and some implementations separate the components (e.g., long fire trucks).

Developer overview

Each LTSA system component is described. Processes and stores are described by their functionality and their interfaces. Flows are described by their connectivity (the components they connect) and the protocols or formats of information across the flow.

Administrator overview

Each LTSA system component is described. This section contains the technical describe of the critical interfaces for learning technology systems. System and component interoperability is greatly enhanced by the identification and establishment of the critical interfaces.

Teacher and student overview

This section describes the technical details of each LTSA system component. This section is necessary for precise technical specification, but the teacher and student readers may skip this section.

Figure 26. The LTSA system components.

The LTSA system components are:

• Processes: Learner, Evaluation, System Coach, Delivery process.
• Flows: Behavior, Assessment, Performance, Query Index, Content Index, Locator Index, Learning Content, Multimedia, Learning Style.
• Stores: Records Database, Knowledge Library.

Throughout this specification the names of the LTSA components will be capitalized in order to distinguish them from the corresponding generic nouns, e.g., "Learner" (LTSA) vs. "learner" (generic). In some cases, the word "process", "flow", or "store" will be used to clarify the usage of the term (e.g., "Evaluation process" versus "evaluation").

Figure 27. Learner (process): The abstraction of the human student.

The Learner process is an abstraction of a human student. The Learner may represent a single student, a group of students learning individually, a group of students learning collaboratively, a group of students learning in different roles, and so on.

The Learner receives a Multimedia presentation and their Behavior is observed. At this level of abstraction, the Multimedia presentation and observable Behavior are diagramed separately. However, actual implementations will usually combine these features into one or more Human Interface modules (e.g., windowing systems), Session Presentation modules (e.g., web browser), tutoring tools (e.g., specialized applications), experimentation and discovery laboratories, and so forth.

The Learning Style is negotiated with the System Coach.

Figure 28. Learning Styles (data flow): All interested parties contribute to learning style.

The Learner, the System Coach, and their surrogates negotiate Learning Styles. In addition to the Learner (student), the parent, teacher, mentor, employer, and/or institution may participate in the negotiation of learning style.

Learning Styles negotiation has much similarity and commonality with cultural adaptation and accessibility for people with physical (e.g., blind, deaf) and cognitive limitations.

Figure 29. Behavior (data flow): The coding and encoding of Learner's actions.

The Behavior flow is a transmission of Learner behavior, coded then encoded, from the Learner to the Evaluation process. At the Evaluation process, the Behavior is framed in the appropriate context by matching the Learning Content to the range of Behavioral responses.

Behavior coding is how Behavior information is organized, e.g., key clicks, mouse clicks, voice response, choices, written responses. Codings represent the Learner's behavior independently of Learning Content. For example, a "control wheel" (a rounded wheel) might be used for airplane flight simulation and automobile driving simulation. A common behavior coding might be the number of degrees that the wheel moved. However, the wheel moving X degrees has a substantially different meaning in flight simulation than in driving simulation.

Behavior encoding is how Behavior information is represented as bits and bytes. For example, a behavior coding such as key clicks might have several encodings: ASCII octets or scan codes might be different encodings. A single encoding such as ASCII might be used for different codings: written responses and mouse clicks both might be encoded in ASCII.

Figure 39. Evaluation (process): The processing of Behavior to produce Assessment and Performance information.

The Learner's observable Behavior is an input to the Evaluation process. The Evaluation process produces Assessment information ("where the Learner is at") and sends the Assessment information to the System Coach. The Evaluation process creates Performance information that is stored in the Records Database.

The Evaluation process uses the Learning Content to provide context to the Learner's Behavior to determine the appropriate Evaluation. For example, a Learner is expected to select from a multiple choice question and the correct answer is "#2", but the Evaluation process has no context that the keystrokes "2" (or "#2" or "two") are the correct answer -- the Learner Content provides the context ("the correct answer is #2") to correlate the correct Behavior (e.g., the keystroke "2").

Figure 31. Performance (data flow): Output from Evaluation, to be stored as Learner history information in Records Database.

The Evaluation process sends Performance information to the Records Database, e.g., "question 17, answered correctly, 85 seconds elapsed". The granularity is unspecified for the emitted Performance information, e.g., the Evaluation process can emit Performance information as much as every mouse click or as little as every semester.

Figure 32. Records Database (data store): Storage and retrieval of Performance information of the past (history), present (bookmarks, current Assessment), and future (objectives).

The Records Database stores Performance information. Performance information can come from both the Evaluation process (e.g., grades on lessons) and the System Coach (e.g., certifications). The Records Database holds information about the past (e.g., Learner history records), but can also hold information about the present (e.g., current Assessments for suspending and resuming sessions) and the future (e.g., pedagogy, Learner, or employer objectives).

Figure 33. Performance (data flow): System Coach retrieves Learner's Records, returned as Performance information.

The System Coach requests and receives Performance information from the Records Database. Typically, historical information is retrieved, but current information (e.g., "bookmarks" for resuming sessions) and future information (e.g., template of future academic objectives) may be retrieved.

Figure 34. Performance information (data flow): System Coach stores Assessments and certifications in Learner's Records Database.

The System Coach stores Performance information, such as Assessments and certifications, in the Records Database. The System Coach may store "bookmarks" as Performance information for saving the Learner's session and resumption at some future time.

Figure 35. Assessment (data store): Output from Evaluation, represents Learner's "current state".

Assessments are emitted from the Evaluation process and describe "where the Learner is at". The System Coach receives Assessments and uses them to determine or suggest, in part, future learning experiences.

Figure 36. System Coach (process), Part 1: Negotiates Learning Style for optimum learning experience.

Step #1: The System Coach negotiates the Learning Style with the Learner. A learning style is chosen by either the Learner (one-way negotiation, i.e., an assertion or inquiry), the System Coach (one-way negotiation, i.e., an assertion or inquiry), both the Learner and System Coach (two-way negotiation), or an external authority (e.g., parent, teacher, institution, courseware developer).

Figure 37. System Coach (process), Parts 2 and 3: Receives current Assessment from Evaluation. Searches and retrieves Performance information relevant to the current learning experience.

Steps #2 and #3: The System Coach receives the current Assessment from the Evaluation process and Performance information from the Records Database to support the decision-making process.

Figure 38. System Coach (process), Part 4: Searches Knowledge Library via Query Indexes for appropriate Learning Content. Knowledge Library returns "found" Content Indexes (metadata) that match the Query Index.

Step #4: Based on the current Assessment and historical Performance information, the System Coach sends Query Indexes to the Knowledge Library to search for appropriate learning materials. The Knowledge Library returns Content Indexes, i.e., a list of Locator Indexes that match the search query.

Figure 39. System Coach (process), Part 5: Extracts the Locator Indexes (e.g., URLs) from the "found" Content Indexes (metadata). Sends the Locator Indexes to the Delivery process to direct the learning experience.

Step #5: The appropriate Locator Indexes (e.g., a lesson plan) are sent to the Delivery process.

Figure 40. Query Indexes (data flow): The "search request" when looking for appropriate Learning Content in the Knowledge Library.

The System Coach sends Query Indexes to the Knowledge Library to search for content that is appropriate for the Learner. The Query Indexes specify search criteria based on, in part, Learning Style, Assessment, and Performance information.

Figure 41. Knowledge Library (data store): A database that represents the "knowledge" of the learning experiences. The "knowledge" is represented as presentations, tutorials, experiments, etc..

The Knowledge Library stores knowledge, presentations, tutorials, tutors, tools, experiments, laboratories, and other learning materials as resources for the learning experience. The Knowledge Library may be searched by Query Indexes. The matching information is returned as Content Indexes, i.e., a set of content tags that are, conceptually, "card catalog" entries (also known as "metadata"). The locator Indexes (conceptually, "call numbers" on the bindings of the "books in the digital library", e.g., URLs) are extracted from the content indexes. The locator Indexes are used by the Delivery process to retrieve Learning Content. It is unspecified who initiates the transfer of Learning Content (e.g., the Learner, the System Coach, or the Delivery process). For example, a query on a topic in chemistry (specified as a Query Index) might return a set of Content Indexes that include a laboratory experiment simulating the behavior of solids, liquids, and gases, a presentation on Boyle's Law, a bibliography or related materials, a tutorial, a chemistry tutor in the same city as the Learner, and an ontology (a conceptual model of the subject represented as generic Learning Content) for temperature.

Figure 42. Content Index (data flow): Represents "card catalog" information about Learning Content in the Knowledge Library. Content Indexes are also known as "metadata".

Content Indexes are the result of searches of the Knowledge Library, as directed by Query Indexes. The Content Indexes are also known as metadata. Metadata is best known in web content for facilitating searches. However, web content metadata is inadequate for learning content because learning content requires more search criteria (e.g., pre-requisites, co-requisites, learning style) than what is provided for web content (e.g., title, subject, author, keywords).

Content Indexes are similar to "card catalog" entries in a public library.

Figure 43. Locator Index (data flow): Represents the "call number" of the Learning Content in the Knowledge Library. Web-based systems use URLs for Locator Indexes.

Locator Indexes identify or point to Learning Content. Using the public library analogy, Locator Indexes are similar to "call numbers" in a card catalog system. Web URLs are examples of Locator Indexes.

For some learning technology systems, Locator Indexes can be implicit because the Learning Content can be retrieved along with the Content Index returned by the Query Index search.

Figure 44. Learning Content received by Delivery (data flow): The coding of the "knowledge" from the Knowledge Library. Learning Content is lessons, presentations, tutorials, tutors, experiments, etc..

Learning Content is the coded representation of the learning experience, identified by the Locator Index, retrieved by the Knowledge Library, and transformed by the Delivery system into a interactive multimedia learning experience.

Figure 45. Delivery (process): Retrieves Learning Content from the Knowledge Library based on the Locator Index. Transforms the Learning Content into a Multimedia presentation.

The Delivery process receives locator Indexes from the System Coach and retrieves Learning Content from the Knowledge Library. The Delivery process transforms the Learning Content into a Multimedia presentation for the Learner. The Delivery mechanisms can vary widely, e.g., presentation and questions, an intelligent tutoring system, video conferencing with a human tutor, transforming an ontology (a conceptual model of the subject represented as generic Learning Content) into a presentation, among many other possibilities. The Delivery process may be implemented with the Evaluation process to achieve the tight coupling necessary for responsive, interactive learning experiences.

6.18 Learning content sent by delivery

Figure 46. Learning Content sent by Delivery (data flow): Learning Content is sent to Evaluation to correlate Multimedia presentations with Behavior responses.

When the Delivery process sends Multimedia to the Learner, the Evaluation process is expecting some Behavioral response to the Multimedia. The Evaluation process is unable to interpret the Behavior without context, so the Delivery process sends the Learning Content to the Evaluation process to understand the context of the Learner's response, e.g., the Learner is expected to select from a multiple choice question and the correct answer is "#2".

Figure 47. Multimedia (data flow): The audio, video, graphics, text, etc., of information sent to the Learner.

Multimedia is the simultaneous delivery of several types of media, such as video, audio, and graphics. The Delivery system transforms the Learning Content into an interactive Multimedia presentation to the Learner.

In some learning technology systems, the implementation of the Multimedia data flow is closely tied to the implementation of the Behavior flow to improve the responsiveness of the learning technology system.

An critical feature of the LTSA is the mapping of the "conceptual" system to the "actual" system. Actual systems, typically, are not organized as the individual LTSA components -- there are commercial, business, and technical reasons for combinations of components. This is no different than the "architecture" of stereo component systems, e.g., a tuner, pre-amplifier, and amplifier are separate components but, typically, they are manufactured together as a "stereo receiver".

The following diagrams show sample mappings and groupings of the LTSA system components (conceptual) to actual systems.

Note: Not all groupings are the same for each sample system.

Note: These diagrams summarize the mappings. More detailed system decomposition and mappings would add precision to the diagrams.

A web-based learning technology system maps to the LTSA system components. The following diagrams show the mapping in two parts. In Part 1, the Human is mapped to the LTSA Learner, the Courseware Database is mapped to the LTSA Knowledge Library, and Student Records are mapped to the LTSA Records Database.

Figure 48. Web-based implementation of LTSA, Part 1: Shows human (Learner), courseware database (Knowledge Library), and student records database (Records Database).

In Part 2, the web browser is mapped to (an implementation of) the LTSA Evaluation, Assessment, System Coach, Locator Index, and Delivery components. The Human Interface (e.g., X Windows or Microsoft Windows) is mapped to the LTSA Behavior and Multimedia components.

Figure 49. Web-based implementation of LTSA, Part 2: Shows human graphical user interface (Multimedia, Behavior) and web-browser as a presentation tool (Evaluation, Assessment, System Coach, Locator Index, Delivery).

The collaboration of a Pilot, Flight Instructor, and Flight Simulator can be mapped to LTSA components. The Flight Simulator is implemented as a tight integration of the LTSA System Coach (portion), Indexes (Content, Query, and Locator), Knowledge Library, Learning Content, Delivery, and Multimedia components. The Flight Instructor is represented as the LTSA Behavior, Evaluation, Performance, Assessment, and System Coach (portion) components. The Pilot's Logbook is the LTSA Records Database component.

Note: The Behavior is represented as part of the Flight Instructor and not shared with the Flight Simulator. The may seem counterintuitive at first because the Pilot "flies" the simulator, but the Flight Simulator does not evaluate the Pilot -- the Pilot only interacts with the Flight Simulator. Thus, the only Behavior of interest is the Pilot's Behavior observed by the Flight Instructor because only the Flight Instructor does Evaluation.

Figure 50. Example of a flight simulator, flight instructor, and pilot. Shows automated Delivery (flight simulator) combined with human Evaluation (flight instructor) and shared System Coach. Pilot maintains Learner's Records Database in his/her logbook.

A non-electronic, traditional classroom can map to the LTSA system components. While mapping LTSA system components to a system void of technology might seem purposeless, this mapping is important because it addresses the "limiting case" of technology, i.e., no learning technology. Since LTSA is applicable in the "limiting case", the LTSA is applicable in a wide spectrum from low technology (e.g., classroom) to high technology (e.g., flight simulator and intelligent tutor).

Figure 51. A traditional classroom (teacher, student, library, report cards) mapped to LTSA system components. The LTSA can be used in non-electronic scenarios.

The home study or self-paced course can map to the LTSA system components. This example is important because the student represents many LTSA components: Learner, Behavior, Evaluation, Assessment, Performance, Records Database (portion), and System Coach.

Figure 52. A home study or self-paced course. The school provides the study materials and, possibly, maintains some of the student's grades and certification. The student progresses as his/her own pace. The student "directs" his/her own learning.

This section identifies many perspectives from different stakeholders in learning technology systems. The main aim of this section is to show how each perspective is represented and included in the Learning Technology Systems Architecture (LTSA).

An important observation: each perspective is represented by a diagram employing a subset of the LTSA components, each with its own EM and de-EM on particular components. The EM and de-EM (primary, secondary, and other design issues) reflect the technology issues, not the pedagogy.

Note: Primary design priorities are shown in red or bold. Secondary priorities are shown in blue or dashed lines. LTSA components that are not primary or secondary, or are not applicable are shown without distinction (normal weight, green fill).

Overview

Each stakeholder has an important, legitimate perspective. However, each stakeholder has a different perception of learning technology systems. The purpose of this section is to show how each stakeholder's perspective is included in the LTSA.

First, the generic stakeholders are presented in order of complexity (isolated, overlapping, parallel). Second, the work of various standards and specification development organizations is presented as stakeholder perspectives.

Figure 53. LTSA system components (the abstraction) are implemented as various stakeholder perspectives.

The LTSA system components are an abstraction that is implemented in various stakeholder perspectives. The stakeholders perspective (layer 4) is a subset of LTSA system components that represents an implementation of the LTSA layer 3.

Building consensus among such a large group of diverse stakeholders is difficult. The authors' have benefited from working experience within the Global Information Infrastructure that spans many diverse industries (e.g., information and communication technologies). One recent discovery has been the limitations of technical analysis itself, as applied to cross-industry solutions: it some cases technical consensus may be impossible due to conflicting business priorities. For example, one group may require high security while another requires high usability -- typically, security and usability are conflicting requirements. In a single organization or enterprise it may be possible to strike a compromise -- all organizational structures provides a common manager, executive, or board to resolve disputes. However, the scope of the LTSA spans many organizations and many stakeholders.

The purpose of identifying primary and secondary design issues is to clarify the business priorities -- typically, different among stakeholders that share the same subset of LTSA system components.

Consensus is built by identifying the stakeholders perspective (LTSA layer 4) and identifying the interoperability and/or interchange protocols that meet the stakeholders' needs (LTSA layer 5).

Stakeholders and divided into three categories: isolated, overlapping, and parallel.

The "isolated" stakeholders have relatively simple features concern isolated and neighboring LTSA system components. The "isolated" stakeholders (1) have little overlap with other "isolated" stakeholders, and (2) can make use of isolated "component" standards. The best examples of "simple" stakeholders are Records, Metadata, Multimedia.

The "overlapping" stakeholders concern many, most, or all LTSA system components. The "overlapping" stakeholders are complex because they (1) overlap with other stakeholders, (2) have differing, possibly conflicting, design priorities that can make standards and interoperability difficult. The best examples of "overlapping" stakeholders are Experimentation, Intelligent Tutoring Tools, and Distance Learning.

The "parallel" stakeholders concern the integration of multiple, active sessions of LTSA system components. The "parallel" stakeholders (1) must synchronize, start, and stop multiple sessions, (2) must integrate, collaborate, and synchronize the feedback, coaching, and user interfacing, (3) may have recursive design. The best example of a "parallel" stakeholder is the Student Teacher.

The differing and conflicting design priorities make standards setting difficult. Architectures (like LTSA) can help resolve that conflict. The best examples of conflict priorities, yet similar LTSA components, are: Metadata and Ontologies.

The "isolated" stakeholders are characterized by addressing few and/or isolated LTSA system components. The "isolated" stakeholders, usually, can make good use of "component" standards for interacting with other LTSA system components, e.g., such as data interchange formats, protocols, application programming interfaces, and object-based components.

The following are the "isolated" stakeholders:

• Learner-Centered: The learner, learner-maintained recordkeeping, learner-motivated coaching.
• Assessment-Centered: Educational standards, assessment, and recordkeeping.
• Records, Certifications: Recordkeeping and creating, maintaining, and validating certifications.
• Task Model, School-To-Work: Task descriptions to make learners more attractive to employers and school-to-work programs.
• Institution-Centered: K-12 and higher education learning environments, recordkeeping, large teaching staff, large student bodies.
• Content-Centered: Designers, developers, and producers of learning content.
• Metadata: Cataloging, searching, and indexing learning content.
• Ontologies, Expert Systems: Knowledge organization, engineering, and coding for retrieval as learning content.
• Learning Objects: Learning content integrated with course structure and sequencing.
• Multimedia: Aural, visual, and sensory information and other physical interactions.
• Collaboration, Asynchronous Learning: Students (of the collective Learner) operating as teams where students have similar roles. Students may access the learning environment and/or collaborate at different times.
• Multiple Role Learning, Team Learning: Students (of the collective Learner) operating as teams where students have different roles.

The best examples of "isolated" stakeholders are Records, Metadata, and Multimedia -- all are characterized by addressing an isolated subset of LTSA system components.

Figure 54. Design priorities for learner-centered stakeholders.

Primary Focus (non-LTSA)

• The student keeps his/her records.
• The student has influence on his/her learning style.

Primary Design Issues (LTSA)

• The interface to the Learner.
• The protocol for communicating the Learning Style.
• The functionality of the System Coach as it supports the Learner's objectives.
• The protocol and format of the Performance information.
• The ability of the Learner to maintain his/her Records Database.

Secondary Focus (non-LTSA)

• Assessment as feedback on the student's progress.
• Performance information as the student's history.

Secondary Design Issues (LTSA)

• The protocol and format of Assessment information.

Other Design Issues

• Nomadic (disconnected) access to Learner's Records Database by the Evaluation process and System Coach.
• Distributed (separated) access to Learner's Records Database by the Evaluation process and System Coach.

Figure 55. Design priorities for assessment-centered stakeholders.

Primary Focus (non-LTSA)

• Evaluation and assessment of students.
• Education standards.
• Maintenance of students records.
• Reporting systems.

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The standards, procedures, methods, protocols, and formats of student Behavior observation.
• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.

Secondary Focus (non-LTSA)

• Adapting the system teaching methods based on the assessment of the student body.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The interface to the Learner.

Other Design Issues

• Aggregation of Learner's comprehensive Records Database and other records.

Figure 56. Design priorities for implementers of Records Databases, and for stakeholders focused on certifications and credentials.

Primary Focus (non-LTSA)

• Learner's records storage and management.

Primary Design Issues (LTSA)

• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.

Secondary Focus (non-LTSA)

• Common semantics and formats for generation and use of assessment and grades.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.

Other Design Issues

• Common reporting tools for Performance information.

Figure 57. Design priorities for technology supporting school-to-work programs, and for task bidding (job bidding), task buying, and task selling.

Primary Focus (non-LTSA)

• Accessing the learner's history database for qualified learners that meet the needs of some employer, project, or "task".

Primary Design Issues (LTSA)

• The formats, indexing, storage, and retrieval of information in the Records Database.

Secondary Focus (non-LTSA)

• Common and interoperable formats for distributed database.

Secondary Design Issues (LTSA)

• The protocols and formats of the Performance information.

Other Design Issues

• The semantics of matching students' skills and capabilities to the needs of employers, projects, and/or "tasks".
• Security methods to control access to the Learner's history.

Figure 58. Design priorities for institution-centered stakeholders.

Primary Focus (non-LTSA)

• The institution is responsible for recordkeeping and reporting.
• The institution has strong interest in selecting and negotiating learning styles.
• The institution is has thorough integration of learning styles, control of course delivery and pacing, records format, common (not necessarily centralized) recordkeeping.

Primary Design Issues (LTSA)

• The protocol and format of Learning Styles.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.

Secondary Focus (non-LTSA)

• The institution must serve a large student body.
• The infrastructure to support course delivery, evaluation, assessment, and grading.

Secondary Design Issues (LTSA)

• The standards, procedures, methods, protocols, and formats of student Behavior observation.
• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.

Other Design Issues

• Common security systems to maintain confidentiality and integrity.

Figure 59. Design priorities for content developers and content delivery systems. The content development process is not depicted in LTSA, only the finished product: learning content.

Primary Focus (non-LTSA)

• The delivery of diverse, interactive multimedia to the student.
• Invocation or initiation of multimedia delivery.

Primary Design Issues (LTSA)

• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The transformation methods used to convert Learning Content to Multimedia.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocols and formats of the Locator Indexes of Learning Content.

Secondary Focus (non-LTSA)

• Cataloging, searching, and retrieving learning content.
• Correlation of learning content to multimedia presentations and behavior responses.
• Assessment of learner.

Secondary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Query Indexes of the Knowledge Library, e.g., a digital library of Learning Content.
• The protocols and formats of Learning Content generated from the Knowledge Library.

Other Design Issues

• Intellectual property rights management (IPRM), including copy-protection, security, usage billing.
• Close coupling of the Delivery process with the Evaluation process for responsive, interactive learning experiences.

Figure 60. Design priorities of metadata systems, metadata tagging, and metadata search.

Primary Focus (non-LTSA)

• Searching, locating, and creating a lesson plan of appropriate learning materials in a large, distributed library.

Primary Design Issues (LTSA)

• The protocols and formats of the Query Indexes, Content Indexes, and Locator Indexes of the Knowledge Library of learning materials.

Secondary Focus (non-LTSA)

• The protocols, semantics, and formats of learning content and learning materials.

Secondary Design Issues (LTSA)

• The protocols and formats of Learning Content generated from the Knowledge Library.

Other Design Issues

• A common method of invoking, initiating, or starting learning content, e.g., starting an intelligent tutoring system will probably be different than calling up a web page.
• Distributed and nomadic Knowledge Libraries.

Figure 61. Design priorities of ontologies, knowledge engineering, and expert systems.

Primary Focus (non-LTSA)

• Ontologies to support learning content derived from knowledge libraries.
• Knowledge systems and knowledge libraries that represent expert knowledge.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of ontologies and knowledge systems.
• The protocols and formats of Learning Content generated from the Knowledge Library.

Secondary Focus (non-LTSA)

• The methods used to search and retrieve appropriate ontologies.

Secondary Design Issues (LTSA)

• The protocols and formats of the Query Indexes, Content Indexes, and Locator Indexes of the Knowledge Library ontologies, expert systems, and knowledge systems.

Other Design Issues

• Coordination and combination of various knowledge systems.

Figure 62. Design priorities of learning objects.

Primary Focus (non-LTSA)

• A rich, diverse knowledge library of learning materials.
• The methods for searching for appropriate learning materials.
• The creation of lessons with a diverse knowledge library.

Primary Design Issues (LTSA)

• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library, e.g., a digital library of learning content.
• The protocols and formats of Learning Content generated from the Knowledge Library.
• The organization and structure of units of knowledge, as organized by the Knowledge Library.

Secondary Focus (non-LTSA)

• The infrastructure to support the learner's progress through a large digital library of learning materials.
• The integration of the learning materials into a course structure and/or sequencing system.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The scope, functionality, and interfaces of the System Coach.

Other Design Issues

• Methods for determining pre-requisites and co-requisites of learning materials.

Figure 63. Design priorities of multimedia and related systems.

Primary Focus (non-LTSA)

• Delivery of multimedia across networks of varying capabilities.
• Multimedia presented on hardware with varying capabilities.
• Locating and referencing multimedia lessons and learning content.

Primary Design Issues (LTSA)

• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library, e.g., a digital library of learning materials.
• The protocols and formats of the Locator Indexes of Learning Content.

Secondary Focus (non-LTSA)

• Controlling multimedia presentations by the system coach as determined by the learner's observable behavior.
• Seamless access to a large digital library of multimedia.
• Common presentation of varying multimedia lessons and learning content.
• Correlation of multimedia in the context of learning content to the evaluation of behavior.

Secondary Design Issues (LTSA)

• The transformation methods used to convert Learning Content to Multimedia.
• The protocols and formats of correlating Multimedia in the context of Learning Content to the Evaluation of Behavior.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The standards, procedures, methods, protocols, and formats of Learner's observable Behavior.

Other Design Issues

• Interaction, integration, and close coupling among observing Behavior and presenting Multimedia.

Figure 64. Design priorities of collaboration tools among the students of the collective "Learner". The student each have similar roles. Compare to "multiple role, team learning" stakeholder.

Primary Focus (non-LTSA)

• Collaboration among the students that represent the Learner.
• Collaboration among students of different "time zones" or asynchronous access.

Primary Design Issues (LTSA)

• The interface to the Learner.
• The communication among the students that represent the collective Learner.
• The support tools accessible through the Delivery process and sent via Multimedia.

Secondary Focus (non-LTSA)

• Controlling and/or assisting the learning experience by some coordinator.
• Using delivery tools to support N-way communication.

Secondary Design Issues (LTSA)

• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.

Other Design Issues

• Security: Who can participate? Who can control? Who can speak? Who can listen?
• Logging and/or recording of a collaborative session.

Figure 65. Design priorities of collaboration tools among the students of the collective "Learner". The student each have different roles. Compare to "collaboration" stakeholder.

Primary Focus (non-LTSA)

• Interactions among students, but students have different roles (e.g., captain, first officer, flight engineer).
• Collectively, the students function as a single, conceptual Learner.
• Parallel learning environments are operating simultaneously, so student plays (at least) two roles: (1) part of the collective Learner that represents the team, (2) an individual Learner that has his/her own learning environment.
• Collaboration among students of different "time zones" or asynchronous access.

Primary Design Issues (LTSA)

• The interface to the Learner.
• The communication among the students that represent the collective Learner.
• The support tools accessible through the Delivery process and sent via Multimedia.

Secondary Focus (non-LTSA)

• A coordinator interacting with the System Coach to lead the team learning.
• The communication of multiple Delivery processes to the Learner.

Secondary Design Issues (LTSA)

• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.

Other Design Issues

• The communication among the simultaneous learning environments between each of the members of the team (students) as they interact and represent the collective team "Learner".

The "overlapping" stakeholders are characterized by addressing many and/or overlapping LTSA system components. The "overlapping" stakeholders, usually, have differing and conflicting design priorities that can make standards development and interoperability difficult or impossible. The "overlapping" stakeholders, typically, have difficulty defining internal boundaries (reduces the applicability of component standards) and have differing system design priorities.

Significant, enterprise-wide, object-oriented solutions become impractical or difficult to integrate for "overlapping" stakeholders because object "inheritance" is closely tied to consensus of technical design priorities (there are differing design priorities), which is tied to common, shared business and political issues (no political, business, or technical consensus).

The following are the "overlapping" stakeholders:

• Mentoring: Human and automated coaching of the learner.
• Interactive Environment: Interactive tools and content.
• Simulation: Creating virtual worlds for training, experimentation, and instruction.
• Learning Tool-To-Tool Communication: Agents and tools communicating with each other in the learner's environment.
• Sequencing, Pre-Requisites, Co-Requisites: Course structure and sequencing of modules and learning experiences.
• Experimentation, Discovery: Learning experiences based on learner-directed experiments and discovery.
• Intelligent Tutoring Tools: Specialized tools for specific subject areas that tutor and coach learners.
• Distance Learning, Distributed Learning: Learning experiences and environments distributed over space (distance learning) and time (asynchronous learning).

The best examples of "overlapping" stakeholders are Experimentation, Intelligent, Tutoring Tools, and Distance Learning -- all address most LTSA system components and have much overlap with other stakeholders.

Figure 66. Design priorities of mentoring tools and related systems.

Primary Focus (non-LTSA)

• The student and the mentor jointly evaluate the learner.
• The student and the mentor collaborate on the student's learning and the student's direction.

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The standards, procedures, methods, protocols, and formats of Learner's observable Behavior.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The interface to the Learner.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.

Secondary Focus (non-LTSA)

• The tools to support mentoring and experimentation.
• The delivery mechanisms to support mentoring, collaboration, and experimentation.

Secondary Design Issues (LTSA)

• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of the Locator Indexes of available knowledge, tools, and learning environments.

Other Design Issues

• The Knowledge Library must be rich enough to support the needs of the student and mentor.

Figure 67. Design priorities of generic interactive environments applied to learning technology.

Primary Focus (non-LTSA)

• The learner has influence over the style of learning.
• The interaction among the learner and the human-machine interface is very responsive (response times less than 3 seconds).
• Strong coupling among evaluation, system control, and multimedia delivery.

Primary Design Issues (LTSA)

• The interface to the Learner.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.
• The protocol and format of Learning Styles.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.

Secondary Focus (non-LTSA)

• Responsive (quick) evaluation and assessment of student.
• Responsive (quick) direction of learning experience.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.

Other Design Issues

• Interaction, integration, and close coupling among Behavior observations, Evaluation process, System Coach, and Delivery process, and Multimedia.

Figure 68. Design priorities of simulation systems, simulators, and related systems.

Primary Focus (non-LTSA)

• Responsive, dynamic, and realistic evaluation of students actions and their affects on the simulation environment.
• Hardware limitations to simulation.
• Limitations to the simulation environment, e.g., what happens to the learner when he/she "crashes" a flight simulator?

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Secondary Focus (non-LTSA)

• Integrating student's actions, usually in fine granularity, within the simulation environment.
• Recording and analyzing student behavior for real-time and post-session analysis.

Secondary Design Issues (LTSA)

• The standards, procedures, methods, protocols, and formats of student Behavior observation.
• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.

Other Design Issues

• Interaction, integration, and close coupling among Behavior observation, Evaluation process, System Coach, and Delivery process, and Multimedia.

Figure 69. Design priorities for communication among tools and between tools and agents.

Primary Focus (non-LTSA)

• A strong coupling of evaluation, assessment, system coach, query and planning of learning content, and delivery.
• Common communication among the various tools and learning materials.

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library, e.g., a digital library of tools, laboratories, tutors, and other learning materials.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Secondary Focus (non-LTSA)

• Access to decision-support information: the learner's history and the available knowledge library.
• The learner's access and control over the tools to support various learning styles.
• Network performance to support varying degrees of multimedia presentation.

Secondary Design Issues (LTSA)

• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocol and format of Learning Styles.
• The organization and structure of units of knowledge, as organized by the Knowledge Library.

Other Design Issues

• The communication among the tools, laboratories, tutors, and other learning materials of the Knowledge Library.

Figure 70. Design priorities for course sequencing and course structure, including pre-requisites and co-requisites.

Primary Focus (non-LTSA)

• Common methods for controlling the sequencing and flow of learning materials.

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Secondary Focus (non-LTSA)

• Access to the student records database to support appropriate course sequencing.
• Access to the learning styles and negotiation with the student -- supports appropriate course sequencing.

Secondary Design Issues (LTSA)

• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The protocol and format of Learning Styles.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Other Design Issues

• Determining the granularity of the learning material that is sequenced.

Figure 71. Design priorities for systems supporting experimentation and discovery environments for the Learner.

Primary Focus (non-LTSA)

• Permitting an environment that allows the student to learn by experimentation and discovery.
• Support "what if" exploration by allowing access to wide range of experimentation and discovery environments (laboratories).

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The interface to the Learner.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library, e.g., a digital library of experimentation and discovery laboratories.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.

Secondary Focus (non-LTSA)

• Learner does self-evaluation and assessment.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The standards, procedures, methods, protocols, and formats of Learner's observable Behavior.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of the Locator Indexes of available laboratories.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Other Design Issues

• Collaboration and mentoring features to support experimentation and discovery.
• The Knowledge Library must be rich enough to support experimentation and discovery.

Figure 72. Design priorities for intelligent tutoring tools.

Primary Focus (non-LTSA)

• Learner chooses direction, discovery, experimentation.
• Tutoring tools are specialized to for specific subject areas.
• Learners learn by using tools.

Primary Design Issues (LTSA)

• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocol and format of Learning Styles.
• The interface to the Learner.
• The protocols and formats of the Query Indexes of the Knowledge Library, e.g., a digital library of tutoring tools.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Secondary Focus (non-LTSA)

• Tutoring tools perform specialized behavior observation, evaluation, assessment, delivery.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The standards, procedures, methods, protocols, and formats of Learner Behavior observation.
• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Performance information.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of the Locator Indexes of tutoring tools.

Other Design Issues

• The protocols, semantics, and formats of communication among tutoring tools.
• The tutoring support must support a deep and/or rich Knowledge Library.

Figure 73. Design priorities for distance learning and distributed learning.

Primary Focus (non-LTSA)

• Nomadic (disconnected) communication of Behavior, Assessment, Performance information, Query Index, Content Index, Locator Index, Multimedia, Learning Style.
• Distributed (separated) communication of Behavior, Assessment, Performance information, Query Index, Content Index, Locator Index, Multimedia, Learning Style.

Primary Design Issues (LTSA)

• The standards, procedures, methods, protocols, and formats of student Behavior observation.
• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Performance information.
• The protocol and format of Learning Styles.
• The protocol and formats of Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of learning materials.
• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Secondary Focus (non-LTSA)

• Nomadic (disconnected) operation of the Evaluation process, Records Database, System Coach, Knowledge Library, Delivery process.
• Distributed (separated) operation of the Evaluation process, Records Database, System Coach, Knowledge Library, Delivery process.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• Security in a nomadic and distributed environment.
• Student identification in a nomadic and distributed environment.
• Student collaboration in a nomadic and distributed environment.
• NOTE: Distance learning is a special and interest stakeholder because its primary concern is the design and implementation of the flows (of the LTSA system components), while its secondary concern is the design and implementation of the processes and stores.

The "parallel" stakeholders are characterized by the integration of multiple, active sessions of LTSA system components. The "parallel" stakeholders must synchronize, start, and stop multiple sessions. The "parallel" stakeholders must integrate, collaborate, and synchronize the feedback, coaching, and user interfacing. The LTSA components may be recursive by having one Learner play the role of a "non-Learner" (e.g., System Coach) for another Learner.

The following are the "parallel" stakeholders:

• Parallel Sessions for the Same Learner: Multiple, simultaneous learning experiences.
• Student Teacher: Student teacher in his/her role as both "teacher" (one learning experience) and "student" (another learning experience).
• Multi-Tiered Process Improvement: Multiple learning experiences, evaluations, assessments, coaching, and delivery processes operating among the student, teacher, principal, and school board as the student, teacher, and principal improve their performance via substantially different learning technology environments.

The best example of a "parallel" stakeholder is the Student Teacher -- dual, simultaneous learning experiences as the student teacher is the "teacher" and the student teacher is the "student". The best example of LTSA recursion is the Multi-Tiered Process Improvement: the school board is a System Coach to the principal as a Learner; the principal also plays the role as a System Coach to the teacher as a Learner; the teacher also plays the role of System Coach to the student as a Learner.

Figure 74. Multiple, simultaneous learning experiences with multiple flows of behavior, learning style, and multimedia. Multiple sets of LTSA components support the parallel LTSA sessions.

Primary Focus (non-LTSA)

• Multiple, simultaneous learning experiences.
• Multiple flows of behavior, learning style, and multimedia.

Primary Design Issues (LTSA)

• The integration of multiple Behavior, Learning Style, and Multimedia components.
• The Learner user interface to support parallel LTSA sessions.

Secondary Focus (non-LTSA)

• Multiple evaluation, system coach, and delivery processes.

Secondary Design Issues (LTSA)

• The integration of multiple Evaluation, System Coach, and Delivery processes.

Other Design Issues

• Correlation of Learner performance among the parallel LTSA sessions.

Figure 75. Student teacher as a "teacher" and as a "student".

Primary Focus (non-LTSA)

• Student teacher as a "teacher".

Primary Design Issues (LTSA)

• Synchronizing the Behavior, Evaluation, Performance, Records Database, Assessment, System Coach, Locator Index, Delivery, and Multimedia of both learning experiences.

Secondary Focus (non-LTSA)

• Student teacher as a "student".

Secondary Design Issues (LTSA)

• Integration of Evaluation, Assessment, Record Database, and System Coach as one learning experience (e.g., student performance) affects the other learning experience (e.g., evaluation of teacher's teaching capabilities).

Other Design Issues

• The correlation of aggregate performance to the teacher's teaching abilities.

Figure 76. A recursive application of LTSA components. The school board is a System Coach to the principal as a Learner. The principal also plays the role as a System Coach to the teacher as a Learner. The teacher also plays the role of System Coach to the student as a Learner.

Primary Focus (non-LTSA)

• Multiple learning experiences, evaluations, assessments, coaching, and delivery processes operating among the student, teacher, principal, and school board
• Student is evaluated by teacher, teacher coaches student.
• Teacher is evaluated by principal, principal coaches teacher .
• Principal is evaluated by school board, school board coaches principal.

Primary Design Issues (LTSA)

• Synchronizing the Behavior, Evaluation, Performance, Records Database, Assessment, System Coach, Locator Index, Delivery, and Multimedia of the multiple learning experiences.

Secondary Focus (non-LTSA)

• Student, teacher, and principal improve their performance via substantially different performance objectives and learning technology environments.

Secondary Design Issues (LTSA)

• Integration of Evaluation, Assessment, Record Database, and System Coach as one learning experience (e.g., aggregate student performance) affects another learning experience (e.g., evaluation of teacher's teaching capabilities or principal's administrative capabilities).

Other Design Issues

• The number, type, and scope of "process improvement" (learning experience) feedback loops and coaching situations.
• The methods of aggregating the performance of one set of Learners (e.g., student's performance) and correlating them to the performance of another set of Learners (e.g., teacher's abilities).

Figure 77. Related Standards and Specification Development Organizations.

The following is the relationship among the standards and specification development organizations:

• ADL (Advanced Distributed Learning): Provides requirements to both AICC and IMS.
• AICC (Aviation Industry CBT Committee): A consortium of the aviation industry. AICC develops specifications for their industry. AICC is submitting its specifications to IEEE 1484 for formal standardization. AICC has roughly twenty specifications and technical reports.
• IMS (Educom's Instructional Management Systems): A consortium of universities, institutions, commercial companies, and government agencies. IMS is developing technology among industry participants, stabilizing the technology via "sample implementations", and submitting specifications to IEEE 1484.
• ARIADNE Project (European Union): Participants of the European Union that are developing and extending metadata for learning content. ARIADNE is working closely with IMS on metadata specifications.
• IEEE 1484 (also known as LTSC - Learning Technology Standards Committee): Accredited standards committee for developing technical standards in learning technology. AICC, IMS, and ARIADNE supply specifications to IEEE 1484 for standardization.
• ANSI (American National Standards Institute): After the IEEE 1484 standards have been approved, they may be submitted for fast-tracking in ANSI.
• ISO (International Standards Organization): The US may submit the national standards for fast-tracking in ISO or may start a working group to develop international consensus.

The IEEE 1484 Learning Technology Standards Committee (LTSC) has roughly a dozen working groups (WGs) and study groups (SGs) developing accredited standards for learning technology.

Not all LTSA components are candidates for standardization within LTSC. The following are reasons for excluding work in LTSC:

• Applications are not standardized. Technical committees standardize specifications, not applications. Example: delivery systems.
• Technology or specifications have not stabilized. Commercial products may exist, but standards might not yet be appropriate. Example: collaboration methods (learner).
• Cross-industry standards. The scope of LTSC is industry-specific (learning technology). Examples: multimedia, cultural adaptation (negotiated learning style).
• Outside technical standards. The specifications are not technical specifications. Examples: education standards (knowledge library), evaluation methods.

The main deliverables of IEEE 1484 are: accredited standards and technical reports.

For more information, see:

http://www.manta.ieee.org/p1484

Figure 78. LTSA components addressed by IEEE 1484.1, Architecture and Reference Model WG.

Primary Focus (non-LTSA)

• Architecture of learning technology systems.
• Reference model for architecture methodology.
• Conformance specification.
• Wide applicability.
• Long technology horizon.

Primary Design Issues (LTSA)

• All LTSA components.

Secondary Focus (non-LTSA)

• Compatibility with other learning technology specifications.

Secondary Design Issues (LTSA)

• None represented in LTSA.

Other Design Issues

• Mapping to other IEEE 1484 working groups.

Figure 79. LTSA components addressed by IEEE 1484.2, Learner Model WG

Primary Focus (non-LTSA)

• Models of the learner to be used for course sequencing, planning, and scheduling of learning experiences.
• Assessment as feedback on the student's progress.
• Performance information as the student's history.

Primary Design Issues (LTSA)

• The protocol for communicating the Learning Style.
• The protocol and format of Assessment information.
• The protocol and format of the Performance information.
• The ability of the Learner to maintain his/her Records Database.
• The functionality and protocols of the Records Database.
• The functionality of the System Coach as it supports the Learner's objectives.

Secondary Focus (non-LTSA)

• Coding behavior observations.

Secondary Design Issues (LTSA)

• The protocol and format of Behavior observations.

Other Design Issues

• Security and integrity of the Records Database.

Figure 80. LTSA components addressed by IEEE 1484.3, Glossary WG

Primary Focus (non-LTSA)

• No primary design focus.

Primary Design Issues (LTSA)

• None.

Secondary Focus (non-LTSA)

• Common terminology for IEEE 1484 standards.

Secondary Design Issues (LTSA)

• Common meanings of terminology across LTSA components.

Other Design Issues

• None.

Figure 81. LTSA components addressed by IEEE 1484.4, Task Model WG

Primary Focus (non-LTSA)

• Accessing the student history database for qualified students that meet the needs of some employer, project, or "task".
• Common query methods for the records database.

Primary Design Issues (LTSA)

• The formats, indexing, storage, and retrieval of information in the Records Database.

Secondary Focus (non-LTSA)

• Common and interoperable formats for distributed database.

Secondary Design Issues (LTSA)

• The protocols and formats of the Performance information.

Other Design Issues

• The semantics of matching students' skills and capabilities to the needs of employers, projects, and/or "tasks".

Figure 82. LTSA components addressed by IEEE 1484.6, Course Sequencing WG

Primary Focus (non-LTSA)

• The environment of course sequencing "programs", as implemented in the programming language of IEEE 1484.10.
• Library functions for accessing the learner records database.
• Library functions for querying the knowledge database of available learning content.
• Library functions for sending locator indexes to the delivery system.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Secondary Focus (non-LTSA)

• The language of the course sequencing "programs", in contrast to the environment.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The functionality and protocols of the Records Database.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• Binding of libraries to the "programming language" of IEEE 1484.10.

Figure 83. LTSA components addressed by IEEE 1484.7, Tool/Agent Communication WG

Primary Focus (non-LTSA)

• Data interchange, control and invocation, and interoperability among active tools and agents in a learning experience.

Primary Design Issues (LTSA)

• The standards, procedures, methods, protocols, and formats of student Behavior observation.
• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.

Secondary Focus (non-LTSA)

• Integration with Query Indexes, Indexes, and the Knowledge Library.
• Integration with the Delivery process.

Secondary Design Issues (LTSA)

• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• Communication among nomadic and/or distributed tools and agents.

Figure 84. LTSA components addressed by IEEE 1484.9, Task Ontology WG

Primary Focus (non-LTSA)

• Coding and representation of "ontologies" -- conceptual representations of units of knowledge.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of ontologies and knowledge systems.
• The protocols and formats of Learning Content generated from the Knowledge Library.

Secondary Focus (non-LTSA)

• The methods used to search and retrieve appropriate ontologies.

Secondary Design Issues (LTSA)

• The protocols and formats of the Query Indexes, Content Indexes, and Locator Indexes of the Knowledge Library ontologies and knowledge systems.

Other Design Issues

• Integration with IEEE 1484.12 learning objects metadata.

Figure 85. LTSA components addressed by IEEE 1484.10, CBT Data Interchange WG

Primary Focus (non-LTSA)

• The language of course sequencing "programs", as implemented in the programming language of IEEE 1484.6.
• Control features to select sequencing and motion of the learner.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.

Secondary Focus (non-LTSA)

• The environment of the course sequencing "programs", in contrast to the language.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The functionality and protocols of the Records Database.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• The mechanism for creating and linking libraries.

Figure 86. LTSA components addressed by IEEE 1484.11, Computer Managed Instruction WG

Primary Focus (non-LTSA)

• Table-driven course sequencing and pre-requisites.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.

Secondary Focus (non-LTSA)

• The language, library, and the environment of the course sequencing "programs".

Secondary Design Issues (LTSA)

• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The scope, functionality, and interfaces of the Evaluation process.
• The functionality and protocols of the Records Database.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• Compatibility and integration with IEEE 1484.10 "programming language" and IEEE 1484.6 "libraries and environment".

Figure 87. LTSA components addressed by IEEE 1484.12, Learning Objects Metadata WG

Primary Focus (non-LTSA)

• Searching, locating, and requesting learning content in a large, distributed library.

Primary Design Issues (LTSA)

• The protocols and formats of the Query Indexes, Content Indexes, and Locator Indexes of the Knowledge Library of learning materials.

Secondary Focus (non-LTSA)

• The protocols, semantics, and formats of learning content and learning materials.

Secondary Design Issues (LTSA)

• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The structure, design, and organization of the Knowledge Libraries, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• The System Coach authenticating student identifiers.
• Usability of student identifiers for the Learner.
• Distributed and nomadic Knowledge Libraries.
• Integration with IEEE 1484.6, IEEE 1484.9, IEEE 1484.10.

Figure 88. LTSA components addressed by IEEE 1484.13, Student Identifiers SG

Primary Focus (non-LTSA)

• Common identifiers (e.g., login names) for students.

Primary Design Issues (LTSA)

• The protocol and format of the Performance information.
• The ability of the Learner to maintain his/her Records Database.
• The functionality and protocols of the Records Database.

Secondary Focus (non-LTSA)

• Authentication of identifiers (validates user identities).

Secondary Design Issues (LTSA)

• The System Coach authenticating student identifiers.
• Usability of student identifiers for the Learner.

Other Design Issues

• Resolution of identifiers (uniqueness, validity, location).

The Educom Instructional Management Systems (IMS) Project is developing technology for the education industry. IMS is a consortium of roughly 30 universities, institutions, commercial companies, and government agencies. The IMS Project is developing technology for the education industry via publicly available specifications and publicly available "sample implementations". The IMS Project has identified five main technology areas:

• Metadata. Developing specifications for extending the metadata of web content to satisfy the needs of web-based learning content.
• Content Server. Developing specifications and technology for (learning) content objects and delivery.
• Management System. Developing specifications and technology for the necessary administration features of web-based delivery systems.
• Profile Server. Developing specifications and technology for learning records, personal information, preference information, and performance information.
• External Services. Developing specifications and technology to interface with the institutions' back office.

The IMS project receives requirements from the DoD Advanced Distributed Learning (ADL) initiative and from universities, institutions, commercial companies, and government agencies. Additionally, IMS collaborates with national and international institutions.

The main deliverables of the IMS Project are: specifications and "sample implementations" that validate the specifications.

For more information, see:

http://www.imsproject.org

Figure 89. LTSA components addressed by IMS Metadata.

Primary Focus (non-LTSA)

• Searching and locating learning objects.

Primary Design Issues (LTSA)

• The protocols and formats of the Content Indexes of the Knowledge Libraries of learning materials.

Secondary Focus (non-LTSA)

• Searching for and activating learning content.

Secondary Design Issues (LTSA)

• The protocols and formats of the Query Indexes and Locator Indexes of the Knowledge Library of learning materials.

Other Design Issues

• A common method of invoking or starting certain lessons, e.g., starting an intelligent tutoring system will probably be different than calling up a web page.
• Distributed and nomadic Knowledge Libraries.

Figure 90. LTSA components addressed by IMS Content Objects.

Primary Focus (non-LTSA)

• Searching, locating, and invoking learning objects.

Primary Design Issues (LTSA)

• The protocols and formats of the Content Indexes (metadata) of the Knowledge Library of learning materials.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The structure, semantics, and syntax of Learning Content.

Secondary Focus (non-LTSA)

• Searching for and activating learning content.

Secondary Design Issues (LTSA)

• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The scope, functionality, and interfaces of the Evaluation process.
• The protocols and formats of Assessment information.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The protocols and formats of the Locator Indexes of the Knowledge Library of learning materials.
• The protocol and format of the Learning Content to correlate the Multimedia to the Behavior for the Evaluation process.

Other Design Issues

• A common method of invoking or starting certain lessons, e.g., starting an intelligent tutoring system will probably be different than calling up a web page.
• Distributed and nomadic Knowledge Libraries.

Figure 91. LTSA components addressed by IMS Management System.

Primary Focus (non-LTSA)

• Coaching and initiating delivery of learning content.
• Reporting systems.

Primary Design Issues (LTSA)

• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The protocols and formats of the Query Indexes and Locator Indexes of the Knowledge Library of learning materials.
• The Learner's user interface.
• The formats, indexing, storage, and retrieval of Performance information.

Secondary Focus (non-LTSA)

• Searching for and activating learning content.

Secondary Design Issues (LTSA)

• The functionality and protocols of the Records Database.
• The protocols and formats of the Content Indexes of the Knowledge Library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.
• The protocols and formats of the Query Indexes and Locator Indexes of the Knowledge Library of learning materials.

Other Design Issues

• A common method of invoking or starting certain lessons, e.g., starting an intelligent tutoring system will probably be different than calling up a web page.
• Distributed and nomadic Knowledge Libraries.

Figure 92. LTSA components addressed by IMS Profiles.

Primary Focus (non-LTSA)

• Searching and retrieving information about the Learner.

Primary Design Issues (LTSA)

• The formats, indexing, storage, and retrieval of Performance information.
• The functionality and protocols of the Records Database.

Secondary Focus (non-LTSA)

• The evaluation, assessments, and advancing the learner through courses.

Secondary Design Issues (LTSA)

• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The scope, functionality, and interfaces of the Evaluation process.
• The protocols, semantics, and formats of Assessment.

Other Design Issues

• Distributed and nomadic Records Database.

Figure 93. LTSA components addressed by IMS External Services.

Primary Focus (non-LTSA)

• Interfacing an IMS system to external institutional services, such as the registrar.

Primary Design Issues (LTSA)

• The functionality and protocols of the Records Database.
• The identification and authentication of the Learner and his/her relationship to institutional services.

Secondary Focus (non-LTSA)

• Correlation of Learner to Performance and non-Performance information.

Secondary Design Issues (LTSA)

• The formats, indexing, storage, and retrieval of Performance information.

Other Design Issues

• Distributed and nomadic Records Databases.

The Aviation Industry CBT Committee (AICC) is a consortium of airplane manufactures, airlines, systems developers, learning content developers, and users. The AICC has developed the following technical reports and specifications.

AICC Guidelines and Recommendations (AGRs)

• AGR001 - AICC Publications
• AGR002 - Courseware Delivery Stations
• AGR003 - Digital Audio
• AGR004 - Operating Windowing System
• AGR005 - CBT Peripheral Devices
• AGR006 - Computer Managed Instruction (CMI)
• AGR007 - Courseware Interchange
• AGR008 - Digital Video
• AGR009 - Icon Standards

AICC White Papers And Technical Reports

• AUD001 - AICC Extensions to the IMA Recommended Practices
• AUD001 - Digital Audio Portability Guidelines
• AUD003 - Plug & Play Guidelines for AICC CBT drivers
• CMI001 - AICC/CMI Guidelines For Interoperability
• COM002 - Documentation Guidelines for AICC non-AGR Publications
• CRS002 - Glossary of Terms Related to Computer Based Training (CBT)
• CRS003 - Hierarchy of CBT terms for AICC Publications
• CRS004 - Guidelines for CBT Courseware Interchange
• CRS005 - Bitmap Graphic File Format
• MPD005 - Part Task Trainer Interfacing
• MPD006 - AICC Audio and the Migration to Windows
• MPD011 - The Use of Digital Video in Computer Based Training (CBT)

For more information, see:

http://www.aicc.org

Figure 94. LTSA components addressed by AICC AGR003 Digital Audio.

Primary Focus (non-LTSA)

• Delivery of digital audio to CBT systems.
• Multimedia presented on hardware with varying capabilities.

Primary Design Issues (LTSA)

• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of Multimedia.

Secondary Focus (non-LTSA)

• Sending digital audio to the CBT workstation.

Secondary Design Issues (LTSA)

• The Delivery of the Multimedia.

Other Design Issues

• Compatibility with audio peripherals.

Figure 95. LTSA components addressed by AICC AGR005 CBT Peripheral Devices.

Primary Focus (non-LTSA)

• Hardware and driver interface of peripheral devices.

Primary Design Issues (LTSA)

• The protocols and formats of Multimedia.
• The protocols and formats of Behavior.
• The functionality and interface to the Delivery system.

Secondary Focus (non-LTSA)

• User interface of peripheral devices.

Secondary Design Issues (LTSA)

• User interface to the Learner.

Other Design Issues

• Integration with other operating system components.

Figure 96. LTSA components addressed by AGR006 Computer Managed Instruction.

Primary Focus (non-LTSA)

• Table-driven course sequencing and pre-requisites use by CBT workstations.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.

Secondary Focus (non-LTSA)

• Student information recorded with each lesson.
• The overall structure of the modules of a course.

Secondary Design Issues (LTSA)

• The functionality and protocols of the System Coach.
• The scope, functionality, and interfaces of the Evaluation process.
• The functionality and protocols of the Records Database.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• Levels of conformance and compatibility among CBT systems.

Figure 97. LTSA components addressed by AICC AGR007 Courseware Interchange.

Primary Focus (non-LTSA)

• Methods for interchanging components and data embedded in courseware.

Primary Design Issues (LTSA)

• The protocols, semantics, and formats of Assessment.
• The scope, functionality, and interfaces of the System Coach.
• The protocols and formats of the System Coach.
• The certification and motion protocols the System Coach uses to advance the Learner through learning materials.
• The protocols and formats of the Query Indexes and Content Indexes of the Knowledge Library.
• The protocols and formats of the Locator Indexes of Learning Content from the Knowledge Library.

Secondary Focus (non-LTSA)

• Courseware paradigms for interacting with the learner.

Secondary Design Issues (LTSA)

• The scope, functionality, and interfaces of the Evaluation process.
• The functionality and protocols of the Records Database.
• The formats, indexing, storage, and retrieval of information in the Records Database.
• The structure, design, and organization of the Knowledge Library, e.g., a digital library of learning materials.
• The scope, functionality, user interface, and control inputs and outputs to the Delivery process.

Other Design Issues

• The long-term compatibility and interoperability of courseware information.

Figure 98. LTSA components addressed by AICC AGR008 Digital Video.

Primary Focus (non-LTSA)

• Delivery of digital video to CBT systems.
• Multimedia presented on hardware with varying capabilities.

Primary Design Issues (LTSA)

• The quality of service (bandwidth, delay, connectivity, etc.) of Multimedia connections.
• The protocols and formats of Multimedia.

Secondary Focus (non-LTSA)

• Sending digital video to the CBT workstation.

Secondary Design Issues (LTSA)

• The Delivery of the Multimedia.

Other Design Issues

• Compatibility with video display systems.

Figure 99. LTSA components addressed by AICC ARG009 Icon Standards.

Primary Focus (non-LTSA)

• Icons that have common meanings.

Primary Design Issues (LTSA)

• Functionality and usability of interface to Learner.
• Formats of Learning Content.

Secondary Focus (non-LTSA)

• Sending digital audio to the CBT workstation.

Secondary Design Issues (LTSA)

• The protocols and formats of Multimedia.
• The Delivery system's use of icons.

Other Design Issues

• Compatibility with other industries' practices for icon usage.

Figure 100. LTSA components addressed by AICC CRS002 Glossary of Terms Related to CBT.

Primary Focus (non-LTSA)

• No primary design focus.

Primary Design Issues (LTSA)

• None.

Secondary Focus (non-LTSA)

• Common terminology for AICC guidelines and recommendations.

Secondary Design Issues (LTSA)

• Common meanings of terminology across LTSA components.

Other Design Issues

• None.

The Department of Defense Advanced Distributed Learning (ADL) initiative is coordinating research and development activities in learning technology. The primary focus of ADL is:

• Promote widespread collaboration.
• Exploit Internet technologies.
• Develop next generation learning technologies.
• Create reusable content, and lower costs, with object-based tools.

The main deliverables of ADL are: requirement specifications. These requirements are passed to the IMS Project for the development of the IMS Specifications.

For more information, see:

http://www.adlnet.org

Figure 101. LTSA components address by DoD Advanced Distributed Learning collaboration and requirements.

Primary Focus (non-LTSA)

• Collaboration among learning technologies.
• Developing requirements for distributed learning systems.

Primary Design Issues (LTSA)

• All LTSA components, as requirements issues.

Secondary Focus (non-LTSA)

• None.

Secondary Design Issues (LTSA)

• None.

Other Design Issues

• Collaboration with other learning technology organizations.

The European Union has created the ARIADNE project for researching and developing collaborative browsing. ARIADNE is collaborating with Educom's IMS Project to create learning technology metadata (metadata for learning technology) that extends the metadata of web content.

For more information, see:

http://ariadne.unil.ch

Figure 102. LTSA components addressed by the ARIADNE Project.

Primary Focus (non-LTSA)

• Searching and locating learning objects.

Primary Design Issues (LTSA)

• The protocols and formats of the Content Indexes of the Knowledge Library of learning materials.

Secondary Focus (non-LTSA)

• Searching for and activating learning content.

Secondary Design Issues (LTSA)

• The protocols and formats of the Query Indexes and Locator Indexes of the Knowledge Library of learning materials.

Other Design Issues

• A common method of invoking or starting certain lessons.

All of the stakeholders' perspectives can be represented via the LTSA system components with varying EM, de-EM, and prioritization of specific LTSA system components.

In summary, the LTSA system component organization represents a common abstraction of the various stakeholder perspectives. Thus, the LTSA system component organization is a good framework for architecting and engineering learning technology systems. Using the automobile analogy again, the LTSA system components are similar to an automobile component architecture: depending upon the perspective of the stakeholder, certain components are emphasized (various automobile perspectives: power, maneuverability, maintainability, style, fuel efficiency, payload, configurability, ruggedness, number of passengers, etc.), but most cars have similar components.

This section identifies the main operational components that are common to many learning technology systems, such as protocols, interchange specifications, processes, stores (databases), control flows, and human interfaces. Not all protocols are incorporated into all learning technology systems.

Developer and Administrator Overview

In an actual LTSA system, knowing all the protocols and interfaces is necessary but not sufficient. Several other compatibility features are required, such as connectivity, security, nomadicity, and administration. However, the LTSA provides a framework for analyzing of and planning for integrated, interoperable systems.

Teacher and Student Overview

The operational components identified at this level represents the subsystems, protocols, etc., of actual systems. Having common functionality does not guarantee interoperability: cell phones and walkie-talkies have similar functionality but do not interoperate. Likewise, having interoperable interfaces does not imply functionality: two systems can use the internet TCP/IP protocols, but they may be disconnected from each other so there is no functionality. Thus, a complete description of functions, protocols, interfaces, etc., is necessary.

Figure 103. Stakeholder perspectives (abstraction) implemented as busses in various domains, e.g.: protocols, human interfaces, clients, servers, namespaces.

Although there are varying perspectives of the stakeholders, there are common operational components within each of the stakeholders' systems.

The common interoperability components of actual systems are defined via information busses. An actual learning technology system consists of many components. Although actual learning technology systems contain "virtual" LTSA system components, the actual components are, typically, not the same as the LTSA system components for technical, performance, usability, regulatory, commercial, and other reasons.

The interoperability of actual systems is dependent on these information busses. An information bus might only communicate among two, well-defined components, but the information bus is useful notation for representing the general case.

The following examples demonstrate the information bus.

Figure 104. Example #1: Internet client-server, client perspective.

An internet client-server protocol may be viewed from the clients perspective: the client communicates with several servers. The client-server protocol is the information bus that clients and servers attach to.

Figure 105. Example #2: Internet client-server, server perspective.

An internet client-server protocol may be viewed from the server side is still an information bus that clients and servers attach to.

Figure 106. Example #3: Combining and/or bridging two busses.

An internet web browser bridges the windowing system bus to the "web bus" of the internet. The "web bus" of the internet represents all the web browsers (clients) and web servers that are able to communicate among each themselves.

Figure 107. Example #4: Combining and/or bridging three busses.

A web server and a chat server operate on different "busses" (the "web bus" of HTTP and the "chat bus" of IRC) even though they may both use TCP/IP. However, the web browser and chat client sit on the windowing system application bus, e.g., the web browser and chat client may communicate via cut, copy, and paste of the windowing system "clipboard".

The following are common information busses used in learning technology:

• Two-way protocols: HTTP, FTP, TELNET, SMTP, TCP, CORBA, DCOM.
• One-way protocols: HTML, MIME, MPEG, JPEG, WAV.
• Data storage: Z39.50, URL, SQL, ODBC
• Control flow: throw/catch, fork/exec, threads, generic remote procedures calls, event handling, TCP session applications.
• Processes: objects, libraries, processes, transactions, virtual machines.
• Human interfaces: X, Windows 95, Motif, AWT, Tcl/Tk, humans factors standard.

There are no specific requirements for bus protocols in the LTSA Like the ISO OSI 7-layer network architecture, the LTSA provides framework for choosing and identifying protocols but does not specify protocols.

This section is a collection of miscellaneous topics related to the LTSA. There are no specific requirements for LTSA conforming systems, but the information is presented because it addresses common interoperability and integration issues once the learning technology systems have reached sufficient size and maturity.

Interoperability is a quality and feature of selecting appropriate interfaces, protocols, services, and such. The LTSA promotes interoperability by identifying the critical interfaces of a learning technology system: the functionality of the processes and stores, and the protocols and formats of the flows.

Actual systems can be interoperable even though the number and grouping of components differs from the LTSA. An analogy is a "boom box" stereo system: all components are built-in and tightly integrated, but the user may replace the cassette player with his/her own by using the "auxiliary in" and "auxiliary out" connections on the "boom box". It is expected that actual system conforming to LTSA will be tightly integrated but will allow interoperability by providing appropriate "hooks".

The following Global Information Infrastructure issues have been identified as generic and cross-industry in nature. For more information on GII issues, see ANSI IISP at:

http://www.ansi.org/iisp

and the ISO JTC1 GII standards roadmap at:

http://www.GlobalCollaboration.ORG/jtc1/gii-roadmap

Security is a generic issue across all LTSA system components. Security is not specifically address in LTSA because security, in general, does not "fit" in any specific layer (of any layering diagram). Security measures are necessary to address the security risk associated with the physical (in contrast to conceptual) implementation of a system.

An important concern when addressing security measures is the distinction between policy (e.g., privacy) and technique (e.g., confidentiality). Security measures should be first analyzed by functionality (e.g., preventing in-bound threats or out-bound threats) and then by mechanism (e.g., encryption) because some mechanisms can serve more than one purpose. For example, digital signatures can be used for non-repudiation (one type of security function) and for preventing tampering (another type of security function).

The following web paper addresses over 60 security needs in the GII.

http://web.ansi.org/public/iisp/docs/97-0257.html

Distributed learning and distance learning systems have at least one component that is "distributed" (not it one location). Data, process, and system distribution are pervasive design issues -- they aren't specific to a particular LTSA system component or a particular LTSA layer.

Nomadic users, systems, data, programs, etc., are a relatively new concept in the GII. The main feature of nomadic systems is the "appearance" of continuous access (connectivity) across space and time. The following web papers define and identify nomadic systems and standards needs.

http://web.ansi.org/public/iisp/docs/96-0174.html

http://web.ansi.org/public/iisp/docs/96-0175.html

Quality of service (QoS) concerns the bandwidth, delay, error rate, etc. of communication networks. QoS may apply to any LTSA system flow or internally within an LTSA system process or store. The QoS features allow applications to control the amount of network resource available.

Cultural adaptation methods are used in information technology systems to adapt, typically, the system to the cultural needs of the user. An obvious example is the use of an automated teller machine in a foreign country -- hopefully, it will adapt to speak the user's native language. The cultural adaptation techniques directly apply to learning technology because the same protocols used for cultural adaptation are also used to communicate Learning Style. For example, learning technology systems could adapt to the needs of the deaf or blind by using culture adaptation protocols to cause the systems to adapt.

The following web page points to 30 papers on information technology standards issues for cultural adaptation.

http://www.itscj.ipsj.or.jp/caw

Students, teachers, schools, courses, content, coaches, systems, peripherals, etc., will all need identifiers. The namespace should be global to support collaboration on a global scale. Directory systems will be needed to locate these identifiers. Content indexes (metadata) are used to organize the Knowledge Library, but similar mechanisms (and their administration) will be necessary in large systems for identifiers outside of Learning Content, e.g., student IDs.

The ANSI IISP GII standards needs have a strong relationship to LTSA system components. The complete list of IISP needs is available at:

http://web.ansi.org/public/iisp/std_need/needlist.html

The following refers to mapping of LTSA system components to specific needs from the IISP list.

• IISP Need #18 – Directory Services
• IISP Need #22 – User Preference Profile - ids
• IISP Need #23 – Constant User Environment
• IISP Need #45 – Application to Device Requirement: Integration of Graphics I/O
• IISP Need #46 – Application to Device Requirement: Specialized Keyboard Input
• IISP Need #91 – Nomadicity: Unique and Anonymous IDs
• IISP Need #95 – Nomadicity: Persona Management
• IISP Need #157 – Security: Identity Authentication Protocols
• IISP Need #161 – Human Computer (User) Interface: Enabling Accessibility for Users with Disabilities

• IISP Need #22 – User Preference Profile - ids
• IISP Need #23 – Constant User Environment
• IISP Need #161 – Human Computer (User) Interface: Enabling Accessibility for Users with Disabilities

• IISP Need #20 – Network to Network Interface - Quality of Service (QOS)
• IISP Need #42 – Application to Device Requirement: Appliance Control Language
• IISP Need #44 – Application to Device Requirement: Graphics Input Access
• IISP Need #45 – Application to Device Requirement: Integration of Graphics I/O
• IISP Need #46 – Application to Device Requirement: Specialized Keyboard Input
• IISP Need #47 – Application to Device Requirement: Device Configuration
• IISP Need #51 – Remote Control / Mousing
• IISP Need #84 – Human Computer (User) Interface Requirement: Functions and Characters of Remote Control Devices
• IISP Need #88 – Nomadicity: Device Coordination
• IISP Need #94 – Nomadicity: Dynamic Service Allocation
• IISP Need #160 – Application to Device Requirement: Virtual Reality Inputs, Outputs and Protocols

• IISP Need #40 – Application to Application Requirement: Application Management
• IISP Need #42 – Application to Device Requirement: Appliance Control Language
• IISP Need #44 – Application to Device Requirement: Graphics Input Access
• IISP Need #45 – Application to Device Requirement: Integration of Graphics I/O
• IISP Need #46 – Application to Device Requirement: Specialized Keyboard Input
• IISP Need #47 – Application to Device Requirement: Device Configuration
• IISP Need #70 – Application to Application Requirement: Application Communications

• IISP Need #22 – User Preference Profile - ids
• IISP Need #23 – Constant User Environment
• IISP Need #24 – Document Delivery Function, Structures and Formats
• IISP Need #133 – Security: De-identification of Personal Information
• IISP Need #143 – Security: Methods for Ensuring Quality of Personal Information
• IISP Need #148 – Security: Digital Signatures
• IISP Need #159 – Security: Retrieval/Validation of Digitally Signed Documents

• IISP Need #133 – Security: De-identification of Personal Information
• IISP Need #142 – Security: Personal System Access
• IISP Need #143 – Security: Methods for Ensuring Quality of Personal Information
• IISP Need #148 – Security: Digital Signatures
• IISP Need #159 – Security: Retrieval/Validation of Digitally Signed Documents

• IISP Need #34 – Billing and Payment
• IISP Need #40 – Application to Application Requirement: Application Management
• IISP Need #70 – Application to Application Requirement: Application Communications

• IISP Need #27 – Preservation Architecture of Online Material
• IISP Need #32 – Authentication of Content
• IISP Need #37 – Application to Application Requirement: Intelligent Agents for Object Parsing (Full Search)
• IISP Need #49 – Search Protocols / Interfaces to Search Engine Software
• IISP Need #69 – Application to Application Requirement: Archival Management
• IISP Need #85 – Image Based Search
• IISP Need #135 – Security: Anonymous Database/Information Search

• IISP Need #24 – Document Delivery Function, Structures and Formats
• IISP Need #27 – Preservation Architecture of Online Material
• IISP Need #30 – Document Delivery Organized Around Use (Workflow) of Documents
• IISP Need #33 – Control Enforcement
• IISP Need #37 – Application to Application Requirement: Intelligent Agents for Object Parsing (Full Search)
• IISP Need #49 – Search Protocols / Interfaces to Search Engine Software
• IISP Need #85 – Image Based Search

• IISP Need #15 – Specification of Information Objects
• IISP Need #17 – Addressing
• IISP Need #18 – Directory Services
• IISP Need #26 – Standard Uniform File Identifier
• IISP Need #27 – Preservation Architecture of Online Material
• IISP Need #29 – Defined Location of Files and Address Resources
• IISP Need #36 – Application to Application Requirement: Generational Management (what's most new, which me is current, name management)
• IISP Need #48 – Application to Device Requirement: Device/File Input/Output/Navigation Service
• IISP Need #75 – Application to Application Requirement: Naming Conventions

• IISP Need #27 – Preservation Architecture of Online Material
• IISP Need #28 – Color Document Interchange
• IISP Need #30 – Document Delivery Organized Around Use (Workflow) of Documents
• IISP Need #31 – Containers or Secure Packaging
• IISP Need #32 – Authentication of Content
• IISP Need #33 – Control Enforcement
• IISP Need #35 – Reporting
• IISP Need #36 – Application to Application Requirement: Generational Management (what's most new, which me is current, name management)
• IISP Need #37 – Application to Application Requirement: Intelligent Agents for Object Parsing (Full Search)
• IISP Need #38 – Application to Application Requirement: Virtual Database Linking
• IISP Need #39 – Application to Application Requirement: Intelligent Watermark or Comparable Mechanism
• IISP Need #48 – Application to Device Requirement: Device/File Input/Output/Navigation Service
• IISP Need #69 – Application to Application Requirement: Archival Management
• IISP Need #71 – Application to Application Requirement: Compression
• IISP Need #72 – Application to Application Requirement: Packaging and Containerization Services
• IISP Need #110 – Security: Secure Payment Protocols
• IISP Need #134 – Security: Anonymous Data Transfer

• IISP Need #24 – Document Delivery Function, Structures and Formats
• IISP Need #25 – Portable Document Delivery Format
• IISP Need #27 – Preservation Architecture of Online Material
• IISP Need #28 – Color Document Interchange
• IISP Need #30 – Document Delivery Organized Around Use (Workflow) of Documents
• IISP Need #31 – Containers or Secure Packaging
• IISP Need #32 – Authentication of Content
• IISP Need #33 – Control Enforcement
• IISP Need #38 – Application to Application Requirement: Virtual Database Linking
• IISP Need #39 – Application to Application Requirement: Intelligent Watermark or Comparable Mechanism
• IISP Need #50 – Presentation Format - Hierarchical Presentation
• IISP Need #71 – Application to Application Requirement: Compression
• IISP Need #72 – Application to Application Requirement: Packaging and Containerization Services

• IISP Need #28 – Color Document Interchange
• IISP Need #31 – Containers or Secure Packaging
• IISP Need #32 – Authentication of Content
• IISP Need #33 – Control Enforcement
• IISP Need #34 – Billing and Payment
• IISP Need #35 – Reporting
• IISP Need #40 – Application to Application Requirement: Application Management
• IISP Need #42 – Application to Device Requirement: Appliance Control Language
• IISP Need #43 – Application to Device Requirement: Graphics Output Access
• IISP Need #45 – Application to Device Requirement: Integration of Graphics I/O
• IISP Need #47 – Application to Device Requirement: Device Configuration
• IISP Need #48 – Application to Device Requirement: Device/File Input/Output/Navigation Service
• IISP Need #70 – Application to Application Requirement: Application Communications

• IISP Need #20 – Network to Network Interface - Quality of Service (QOS)
• IISP Need #28 – Color Document Interchange
• IISP Need #42 – Application to Device Requirement: Appliance Control Language
• IISP Need #43 – Application to Device Requirement: Graphics Output Access
• IISP Need #45 – Application to Device Requirement: Integration of Graphics I/O
• IISP Need #47 – Application to Device Requirement: Device Configuration
• IISP Need #48 – Application to Device Requirement: Device/File Input/Output/Navigation Service
• IISP Need #71 – Application to Application Requirement: Compression
• IISP Need #88 – Nomadicity: Device Coordination
• IISP Need #94 – Nomadicity: Dynamic Service Allocation
• IISP Need #160 – Application to Device Requirement: Virtual Reality Inputs, Outputs and Protocols

The following are issues related to the business aspects of learning technology systems.

Of course, LTSA system components and, especially, Learning Content must be developed. The LTSA does not address the development aspects of LTSA system components nor Learning Content.

Versioning is the feature of distributing and maintain multiple releases of software or Learning Content. For example, there might 1996, 1997, and 1998 editions of some Learning Content. The LTSA does not address this directly. It is expected that different editions would be "callable" via different Locator Indexes, but there would be no specific provision for any generic "versioning" syntax in a Locator Index.

Several databases and formats must be consistent and interoperable over long periods (at least 10-15 years). The LTSA system components Performance, Assessment, Records Database, Knowledge Library, and Learning Content require this longevity.

Both Performance and Assessment information must be verifiable and tamper-proof.

The royalty payments for use of intellectual property must be incorporated into any real, production system. Because the methods, techniques, charging, and billing vary significantly, IPRM has not yet been incorporated into the LTSA.

Electronic commerce methods can be used for payment of services (e.g., course fee, lab fee) and IPRM royalty payments among other uses. Electronic commerce is not directly incorporated into the LTSA because the business models vary. For more information on standards activity in electronic commerce, see:

http://www.din.de/ni/aktuell/j1btechtml

The LTSA specifies, effectively, a generic process used in learning technology. The following issues concern the application of the LTSA process to actual systems.

Some LTSA applications may be recursive, e.g., student, teacher, principal, school board. Recursive systems can pose certain scenarios that are outside the LTSA application (e.g., what happens when the principal is directly involved in the performance of the student -- skipping the teacher?).

A single learner might be participating in several learning experiences simultaneously. A significant integration issue is: coordinating the successes and failures of one "feedback and coaching loop" with the successes and failures of another loop.

The LTSA specification can be used to measure conformance of learning technology systems. The system under test is called the "implementation under test". A system that conforms to the LTSA specification is called a "conforming implementation".

• Layer 1 conformance. The implementation under test shall identify the boundaries of the Environment, the flows of Interactions, and the Learner. The implementation under test shall identify the Learner's relationship to human students (e.g., is the learner represented by more than one student?; is there collaboration among the students?).
• Layer 2 conformance. The implementation under test shall identify the methods for addressing the human-centered features: unreliable learners, unpredictable learners, nomadic learners, diverse learners.
• Layer 3 conformance. The implementation under test shall identify the available LTSA system components: Learner, Learning Style, Behavior, Evaluation, Performance, Records Database, Assessment, System Coach, Query Index, Content Index, Locator Index, Knowledge Library, Learning Content, Delivery, Multimedia.
• Layer 4 conformance. The implementation under test shall identify the subset of applicable LTSA system components. The implementation under test shall identify the boundaries and mapping of LTSA system components.
• Layer 5 conformance. The implementation under test shall identify the information busses in use, their namespace, control protocols, and mapping to LTSA system components.

A conforming implementation shall conform to all five layers.

This section points to related documents and a glossary. The index has been moved to the end of the specification.

The following are related printed and web documents. See section 1.4, Background Information, for additional information.

• http://www.ansi.org/iisp, American National Standards Institute, Information Infrastructure Standards Panel (ANSI IISP)
• http://trp.research.apple.com/, Apple Computer's Educational Object Economy (EOE)
• http://advlearn.lrdc.pitt.edu/its-arch/p1484/ARM.html, "Architecture Abstraction Hierarchy Reference Model", by Frank Belz, Dan Suthers, Tom Wheeler
• http://ariadne.unil.ch, ARIADNE Project of European Union
• http://www.aicc.org, Aviation Industry Computer-Based Training (CBT) Committee (AICC)
• http://www.omg.org/corbamed, Common Object Request Broker Architecture of Object Management Group (OMG), Medical Infomatics (CORBAMED)
• http://www.adlnet.org, DoD Advanced Distributed Learning (ADL)
• http://www.imsproject.org, Educom's Instructional Management Systems Project (IMS)
• http://www.edutool.com, Farance/Edutool specifications and documents on learning technology infrastructure
• http://www.manta.ieee.org/p1484, Institute of Electrical and Electronic Engineers, Project 1484, Learning Technology Standards Committee (IEEE P1484 LTSC)
• http://www.din.de/ni/aktuell/j1btechtml, International Standards Organization - International Electrotechnical Committee, Joint Technical Committee 1 -- Information Technology, Business Team on Electronic Commerce (ISO-IEC JTC1 BT-EC)
• http://www.itscj.ipsj.or.jp/caw, International Standards Organization - International Electrotechnical Committee, Joint Technical Committee 1 -- Cultural Adaptability Workshop (CAW)
• http://www.GlobalCollaboration.ORG/jtc1/gii-roadmap, International Standards Organization - International Electrotechnical Committee, Joint Technical Committee 1 -- Global Information Infrastructure Standards Roadmap (ISO-IEC JTC1 GII)
• http://www.GlobalCollaboration.ORG/, International Standards Organization - International Electrotechnical Committee, Joint Technical Committee 1 -- Standards Operations Roundtable (SORT):
• http://domino.psy.cmu.edu/ieee/tooltutorspec.html, "Tool/Agent Communication", by Steven Ritter, Carnegie Mellon University

The following is brief glossary of terms used in this specification. There are many other better, more complete glossaries. This glossary serves the purpose of defining certain key terms within the context of this specification. This specification will be improved as terminology in education research, learning technology, and information technology converges.

• Abstraction. A generalization (of an implementation). Higher level (coarser granularity) of detail. Compare to Implementation.
• Abstraction-Implementation Boundary. The mapping of an abstraction to an implementation and vice versa The boundary between different levels of detail.
• Abstraction-Implementation Layer. A grouping of details at a particular level of granularity.
• Actual Implementation. A physical implementation of an (LTSA) abstraction, not just a lower level abstraction.
• Administrator. A person responsible for purchasing systems, managing systems, and/or managing institutions.
• Advise (from Learner). The Learner's suggestions, requests, and/or information about the optimal Learning Style.
• Assessment (data flow). A representation of "where the learner is at", e.g., an inventory of skills, knowledge, or progress. The assessment may have wide scope (e.g., complete inventory) or narrow scope (e.g., only enough information to determine what Learning Content is next). The purpose of the Assessment information to support the decision-making of the System Coach within the context of the Learning Style.
• Behavior (data flow). The Learner's behavior represented in some form (e.g., raw information). Behavior observations may be objective or subjective.
• Bus. A collection of subsystems that communicate with a common control protocol within a common namespace but, possibly, varying data protocols among members.
• Bus Control Flow Protocol. The Control Protocol used on a Bus among the members of the Bus.
• Bus Data Flow Protocol. The Data Protocol used on a Bus among the members of the Bus.
• Bus Notation. A descriptive technique that decomposes systems into members (subsystems) connected to a Bus. Bus Notation is useful when the are a large number of subsystems, the functions or roles are undefined or changing over time, and the connections between subsystems are Dynamic Connections or on-demand connections. Compare to System Notation, Text Description.
• Coaching. Supporting, assisting, hinting, directing, etc., the Learner during a Learning Experience.
• Coding. For information interchange, the structure of information.
• Collaboration. The communication among the Students of the collective Learner.
• Compliance. Satisfying the specifications of involuntary standards (e.g., laws, regulations). Compare to Conformance.
• Conformance. Satisfying the specifications of voluntary standards. Compare to Compliance.
• Certification. The acknowledgement of some competency by some authority.
• Conforming System. An Implementation Under Test that conforms to a specification, e.g., the LTSA specification.
• Content Index (data flow). Also known as metadata. See Index.
• Control Flow. Inputs and/or outputs that control the processing of data among two or more subsystems. An information flow that starts, stops, or changes processing. Compare to Data Flow.
• Control Process. Transforms control inputs into control outputs. Compare to Data Process.
• Control Protocol. The actions, responses, information, and processing states for starting and stopping the flow of information.
• Control Transformation Process. See Control Process.
• Control Store. An information store for control information. For example, an event log is a Control Store.
• Data Flow. Data moving among two or more subsystems. An information flow that represents the main inputs and/or outputs of a subsystem.
• Data Process. Transforms data inputs into data outputs, or transforms a mix of data and control inputs into data and control outputs. Compare to Control Process.
• Data Protocol. The actions, responses, information, and processing states for the flow of information among subsystems.
• Data Transformation Process. See Data Process.
• Data Store. An information store for data information. For example, a database is a Data Store.
• Delivery (process). The mechanism for transforming the Learning Content into a Multimedia presentation. The Delivery may be static, interactive, collaborative, or involve experiments and discovery. Many Delivery processes are implemented as tightly coupled Delivery and Evaluation tools because of the close coupling of Learning Content presentation followed by Behavior observation and Evaluation.
• Design Priority. The ranking of technical design issues from largest effect to smallest effect. See also Primary Design Issue, Secondary Design Issue.
• Developer. The creator of learning content and/or software.
• Distributed Systems. The appearance of several, geographically diverse components acting as a single system.
• Dynamic Connection. A connection between systems that is short-term and/or not predetermined. See also Bus Notation.
• Encoding. For information interchange, the bit and byte representation of the information.
• Environment. The information, knowledge, experiences, features, etc. that are external to the Learner.
• Evaluation (process). The process of organizing and analyzing Behavior observations for the purpose of creating Assessments and Performance information (measurements).
• Feedback Loop. A system that "senses" the "current state", determines an appropriate "action", and directs the system via the action toward the "desired outcome". A Feedback Loop, typically, continuously monitors the "state" of the system, determines "action", and directs towards "desired outcome".
• Flow. The transfer of information from one system component to another. See also Control Flow, Data Flow.
• Human-Centered. The nature, qualities, capabilities, limitations, etc., of humans the become the primary theme or focus of a topic.
• Implementation. An example (of an abstraction). Lower level (finer granularity) of detail. Compare to Abstraction.
• Implementation Under Test. In conformance testing, the system that is being tested.
• Index (data). A reference to information. A Query Index may be used to search for learning materials (knowledge, presentations, lessons, tools, experiments, etc.). The search may return a list of Content Indexes that match the search query. Locator Indexes are extracted from the resultant Content Indexes. The Locator Indexes are used by the Delivery process to point to the desired Learning Content and other resources.
• Information Bus. See Bus.
• Information Store. See Store.
• Intelligent Tutoring System. One type of Learning Content.
• Interaction. The physical events of the leaner (e.g., actions, sight, sound, etc.) during a Learning Experience.
• Knowledge Library (data store). The learning materials available to the learner. The knowledge library may be searched for appropriate learning materials. The Query Index specifies what to look for; the Content Index lists the learning materials (one or more Locator Indexes) available that match the search. The learning materials may be retrieved as Learning Content by specifying a Locator Index to the Knowledge Library.
• Learning Content (data flow). The learning materials, requested by Locator Index, retrieved from the Knowledge Library, and transferred the to Delivery process. Examples: a presentation with questions, a set of experiments with tools, a collaborative project with background information, a set ontologies that describe concepts. It is unspecified who initiates the Less (e.g., the Learner, the System Coach, or the Delivery process).
• Learner (human process). One or more humans who are increasing of changing their knowledge. Examples: The Learner may represent a single student, a group of students learning individually, a group of students learning collaboratively, a group of students learning via different roles.
• Learning Experience. The events surrounding the Learner while he/she in Learning. Because the nature of learning is complex. it may be difficult or impossible to identify all the events that comprise a Learning Experience.
• Learning Styles (data flow). The information communicated in a two-way negotiation between the Learner and the System Coach. The negotiation is used to determine the appropriate style of learning. Examples: the Learner chooses a style (one-way negotiation), the System Coach chooses a style (one-way negotiation), both the Learner and System Coach choose a style (two-way negotiation), an external authority (e.g., parent, teacher, institution, courseware developer) chooses the style.
• Lesson. One type of Learning Content.
• Locator Index (data flow). A reference to Learning Content, e.g., web URLs. See Index.
• Metadata. Also known as Content Index.
• Multimedia (data flow). The encoding and transfer of audio, video, graphics, and other input/output media.
• Namespace. The set of used and available names (identifiers) for a set of components.
• Nomadic Learner. Learners move and migrate, e.g., a learner may have a different teacher every year of school.
• Nomadicity. The appearance of continuity over space and time while actually disconnected at times.
• One-Way Flow. Information that flows in a single direction from one subsystem to another. In the case of connecting multiple subsystems, a One-Way Flow has a single source (origin) OR a single sink (destination).
• Parent. A surrogate for the Learner and/or System Coach. A Parent may perform other functions of other LTSA system components (e.g., Evaluation, Delivery).
• Performance (data flow). A record the student's abilities as measured by the Evaluation process (e.g., grades on tests) and determined by the System Coach (e.g., certification of completion). Performance information in the past represents the student's history. Performance information in the present can represent Assessment information or a "bookmark" of an incomplete session. Performance information in the future represent the student's objectives.
• Primary Design Issue. The main focus of technical design that has the largest effect on the nature of the design.
• Process. An active system component that transforms its inputs to its outputs.
• Query Index (data flow). A search request for Learning Content. See Index.
• Secondary Design Issue. After the Primary Design Issues, the next significant focus of technical design.
• Stakeholder. Any person or organization that has material interest. Each LTSA stakeholder is associated with a stakeholder perspective.
• Static Connection. A connection between systems that is fixed and/or predetermined. See also System Notation.
• Store. An inactive system component used for storing and/or retrieving information. See also Control Store, Data Store.
• Student. A human learner. Several Students may comprise a collective Learner.
• System Coach (process). Negotiates the Learning Style with the Learner. The Assessment information (current position), the Learner's Performance information (past history, future objectives), and the available learning materials (searched and retrieved via Index) are all combined to determine the appropriate Learning Content (e.g., current lesson, schedule of lessons). The Learning Content is conveyed to the Delivery process via Locator Indexes (references to learning materials, tools, suggestions, etc.).
• System Component. In System Notation, a Process, Store, or Flow.
• System Notation. A descriptive technique that decomposes systems into subsystems of Processes and Stores connected by Flows. System Notation is useful when there are a handful of subsystems, the functions or roles of each subsystem is well-defined, and the connections between subsystems are established and unchanging, and the connections between subsystems are Static Connections. Compare to Bus Notation and Text Description.
• Teacher. The facilitator and/or mediator of students' learning experiences.
• Text Description. A descriptive technique that uses text. Text Descriptions are useful if the boundaries of a subsystem are not well-defined. Compare to Bus Notation, System Notation.
• Two-Way Flow. Information that flows in both directions between subsystems.
• Unreliable Learner. As receivers of information, learners are unreliable when compared to computers (as receivers of information), e.g., learners may see, hear, etc., incorrectly because they can perceive information in error (or not perceive at all).
• Unpredictable Learner. As receivers of information, learners are unpredictable when compared to computers (as receivers of information), e.g., knowing that a learner has perceived information does not predict the effects of that perception on the learner.

See end of specification after section 12.

This section concerns the development of this document. The past (revision history, resolved issues), present (release notes, comment returns), and future (open issues) releases of this document are identified here.

The following are the revisions of the document and summary information for each revision:

• Release 1.00, 1996-12-05, initial draft. Presentation at the 1996-12 meeting of IEEE P1484.
• Release 2.00, 1997-01-28, second draft. The initial draft of the top three refinement layers. This release was largely incomplete, but was intended to give the reader a first glance at the work in progress.
• Release 3.00, 1997-09-23, third draft. Combined presentation and paper. Completed top four refinement layers: knowledge exchange, human-centered features, system components, stakeholder perspectives. Initial draft of operational components.
• Release 4.00, 1998-05-21, current draft. Completed operational components and conformance sections. Updated diagrams. Rewrote text for lay audience (college level, non-technical).

The following notes apply to these release of this document.

• This document is ready for review among standards committees and fora.

The following issues have been resolved:

1. The sections comparing several learning issues (intentional vs. non-intentional, organic vs. inorganic) have been removed since they are not important for presenting the main technical discussion and rationale.
2. Diagrams have been added to clarify the system and component organization.
3. The "knowledge exchange" layer has been substantially rewritten and relabeled as "learner-environment interactions".
4. Missing sections have been completed.
5. Graphics have been completely redesigned.
6. A flow has been added between the Delivery and Evaluation components to provide context to the Evaluation process for each "lesson" of the Delivery process.

The following are open, unresolved, and/or outstanding issues for this specification:

1. Examples of conformance should be included.
2. A conformance "label" should be specified.

All comments are appreciated. Please return all comments on this release of this document by Friday, 1997-07-03 21:00 UTC. Deliver all comments to Frank Farance at any one of the following:

Telephone: +1 212 486 4700
Fax: +1 212 759 1605
E-mail: frank@farance.com
 
Frank Farance
Farance/Edutool
Island Box 256
New York, NY
10044-0205
USA

This document and its contents are Copyright © 1998 Farance Inc., Edutool division.