IEEE LTSC (P1484)
Learning Technology Standards Committee
Work Program and Process, 1999-12 Plenary
http://ltsc.ieee.org
(Note: This presentation is regularly updated and presented
at each quarterly plenary meeting of the LTSC
— The intended audience is the participants of the LTSC)
Frank Farance, LTSC Vice Chair
+1 212 486 4700, frank@farance.com
Edutool.Com, a division of Farance Inc.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
1
Overview
• Standards Process Overview
• IEEE LTSC (P1484) and other organizations
• Applying/using LTSC standards in learning
technology systems
• Summary of LTSC working/study groups
– Extended presentations for 1484.1, 1484.2,
1484.6, 1484.11, 1484.12, 1484.14, 1484.17
• Contact information
• Future meeting schedule
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
2
IEEE LTSC (P1484)
Learning Technology Standards Committee
• Formed in 1996-09; currently 20 working
groups
• Chair: Jim Schoening, US Army (CECOM)
• Vice-Chair: Frank Farance, Edutool.Com
• IEEE: accredited standards development org.
• LTSC is part of IEEE Computer Society:
>100,000 members
• Sponsor Executive Committee (SEC) is
comprised of all WG chairs, makes decisions
for LTSC
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
3
IEEE is an Accredited
Standards Development Organization
Development
Review
1999-12-08
Consensus
Building
Maintenance
The Standards Process
• Accreditation affords
consistent process
• Committees don’t reinvent
wheel
• Choosing a “process” can
take years itself
• Accredited process is welltested and “off the shelf”
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
4
Standards vs. Specifications [2/3]
• Standards:
– developed by accredited standards bodies
• Features:
–
–
–
–
Open forum
Due process, fairness
Specification development and maintenance
Membership for:
•
•
•
•
individuals
non-profit
small/medium enterprises (SMEs)
large companies
– Voluntary standards vs. involuntary standards
– Treaty organization vs. non-treaty organization
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
5
Standards vs. Specifications [3/3]
• Specifications:
– developed by non-accredited organizations
• Features:
– Membership: open or closed?
– Due process: fair conflict resolution methods?
– Specifications, reference models, conformance
tests, branding, products, etc.
– May/may not operate like standards body
• Both specifications and standards are useful
• Collectively: standards and specification
development organizations (SSDOs)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
6
Goals of Standards Process
• Standards that are well-defined:
– Consistent implementations, high interoperability
– Coherent functionality
• Commercial viability:
– Standards allow range of implementations
– Commercial products are possible:
• All conforming products interoperate, yet ...
• Different “bells and whistles”
• Consumer can choose from range of conforming systems
• Wide acceptance and adoption
• Few bugs:
– Consistent requests for interpretation (RFIs)
– Low number of defect reports (DRs)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
7
Standards are Developed In Working Groups
Developing Standards
Development
• Source: “from scratch” or
“base documents”
• Create “standards wording”
(normative and informative),
rationale for decisions
• Technical committee: inperson or electronic
collaboration
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
8
The Working/Study Groups of IEEE LTSC
General Activities
Data and Metadata
1484.1 Architecture and Reference Model
1484.3 Glossary
1484.12 Learning Objects Metadata
1484.9 Localization
1484.14 Semantics and Exchange
Bindings
1484.15 Data Interchange Protocols
1484.16 HTTP Bindings
Learner-Related Activities
1484.2 Learner Model
1484.4 Task Model
1484.13 Student Identifiers
1484.5 User Interfaces
1484.19 Quality System for Life-Long
Learning
1484.20 Competency Definitions
Content-Related Activities
1484.10 CBT Data Interchange
1484.6 Course Sequencing
1484.17 Content Packaging
1999-12-08
Mgmt. Systems & Applications
1484.11 Computer Managed
Instruction
1484.18 Platform and Media Profiles
1484.7 Tool/Agent Comm.
1484.8 Enterprise Interfaces
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
9
Formal and Informal Consensus-Building Among
Standards and Specification Development Orgs
Consensus-Building Steps
Development
Consensus
Building
• Collaboration, harmonization
with other organizations
• Public reviews as soon as
possible
• Public comments
• Resolution of comments
• Approval stages (refinement):
–
–
–
–
1999-12-08
Working Draft
Committee Draft
Draft Standard
Approved Standard
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
10
OLD: Related Standards/Specification Development
Orgs In Education & Learning Technology
IEEE, ANSI, ISO: Accredited Standards
LTSC
(P1484)
Specs submitted by Consortia/Fora
Stds/
Specs
Sampling of
Organizations
1999-12-08
GESTALT
GEM
PROMETEUS
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
11
NEW: Related Standards/Specification Development
Orgs In Education & Learning Technology
LTSC & JTC1/SC36: Close Collaboration
LTSC
(P1484)
ISO/IEC
JTC1/SC36
Current, existing
Future possibilities
Sampling of
Organizations
1999-12-08
GESTALT
GEM
PROMETEUS
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
12
URLs For Accredited
Standards Development Organizations
• ISO: International Standards Organization
http://www.iso.ch
• ISO/IEC Joint Technology Committee 1,
Information Technology, http://www.jtc1.org
• ANSI: American National Standards Institute,
http://www.ansi.org
• IEEE: Institute for Electrical and Electronic
Engineers, http://www.ieee.org
• IEEE LTSC (P1484): Learning Technology
Standards Committee, http://ltsc.ieee.org
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
13
URLs For Related
SDOs/Consortia/Fora/Orgs
• European Committee for Standardization
(CEN), Information Society Standardization
System (ISSS), Learning Technology (LT)
Workshop http://www.cenorm.be/isss/workshop/lt
• AICC: Aviation Industry CBT Committee,
http://www.aicc.org
• IMS: Educause’s Instructional Management
Systems Project, http://www.imsproject.org
• ARIADNE: Alliance of Remote Instructional
Authoring and Distribution Networks of Europe
http://ariadne.unil.ch
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
14
Standards vs. Specifications [1/3]
• A standard is a specification produced by an
accredited standards development organization
• Difference between standards and specifications:
accredited vs. non-accredited
• Non-accredited organizations: consortia, fora, trade
organizations, user groups
• Accreditation doesn’t imply quality or usefulness, but
implies process
• Accredited process is important for Requests for
Interpretation (consistency) and antitrust
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
15
URLs For Related Consortia/Fora/Orgs
• PROmoting Multimedia access to Education
and Training in EUropean Society
http://www.prometeus.org
• GESTALT: Getting Educational Systems
Talking Across Leading-edge Technologies
http://www.fdgroup.co.uk/gestalt
• GEM Project: Gateway to Education Materials
http://www.geminfo.org
• ADL: DoD Advanced Distributed Learning
http://www.adlnet.org
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
16
JTC1 (Joint Technical Committee 1)
— Information Technology
IEC
International Electrotechnical Commission
ISO
International Organization for Standardization
TC1
Screw Threads
TC2
Fasteners
JTC1 (Joint Technical Committee 1)
Information Technology
TCnnn
...
SC02
Coded Character Sets
SC35
User Interfaces
SC22
Programming Languages & Environments
SC22/WG20
Internationalization
SC31
Automatic Identification and Data Capture
SC17
Cards and Personal Identification
SC32
Data Management and Interchange
SC34
Document Description/Processing Languages
SC11
Flexible Magnetic Media for Digital Data
SC23
Optical Disk Cartridges
SC29
Coding of Audio/Picture/Multimedia/Hypermedia
SC24
Computer Graphics and Image Processing
SC28
Office Equipment
SC27
IT Security Techniques
SC07
Software Engineering
SC36
Learning Technology
CAI-RG
Conformity Assessment and Interoperability
IIT-RG
Implementing Information Technology
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
17
JTC1/SC36 and LTSC Will Collaborate Closely
— Co-Located Meetings Will Help Significantly
LTSC & JTC1/SC36: Close Collaboration
LTSC
(P1484)
ISO/IEC
JTC1/SC36
Current, existing
Future possibilities
Sampling of
Organizations
1999-12-08
GESTALT
GEM
PROMETEUS
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
18
Collaboration Within JTC1
• Direct collaboration/liaison with ISO stds:
–
–
–
–
–
SC2: character sets
SC22: programming languages
SC24: computer graphics and image processing
SC27: security
SC29: coding of audio, picture, multimedia and
hypermedia
– SC32: database and metadata
– SC34: document description and processing
languages
– SC35: cultural adaptation
• Widespread international participation
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
19
Liaisons To/From JTC1
• Direct liaison with:
– Object Management Group (OMG)
– Internet Engineering Task Force (IETF)
– World Wide Web Consortium (W3C)
– Digital Audio Video Council (DAVIC)
– VRML Consortium
– VESA Consortium
– The Open Group
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
20
Life Cycle:
Maintenance Phase
Development
Consensus
Building
Maintenance of Standards
• Requests for Interpretation (RFIs)
• Defect Reports (DRs) and
Record of Responses (RRs)
• Amendments (AMs) and
Technical Corrigenda (TCs)
Maintenance
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
21
Conformance Testing: Insures Interoperability
Note: Conformance testing involves:
(1) interpretation of standards
(2) development of test suites
(3) testing vendor products/services
DITT: Conformance Testing for
approved standards
ISO/IEC
JTC1/SC36
LTSC
(P1484)
ADL: Conformance Testing for AICC
CMI Learning Management Systems
GESTALT
GEM
PROMETEUS
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
22
Assertion, Inquiry, Negotiation, and Testing (AINT):
Documents that transform Standards words to specific tests
Development
3
1
Interpretation
Users
LTSC
(Public) AINT
Document
Vendors
Standards
(specifications)
Test
Developer
Test
4 Creation
2 Consensus
Other
Test Suite
“AINT documents are
critical for uniform and
thorough testing”
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
23
(Proposed) LTSC Testing Process:
Advice, Certification, Testing, and Branding
LTSC
NIST
2
IEEE/ISTO
4
Vendor
5
IEEE Proc.
Admin.
1
NIST Lab
Certification
Advisory
Board
Dispute
Resolution
Vendor
Products
Test Lab
(DITT)
LTSC Branding
Authorization
Test Suite
Results
6
Branding
3
Test Suite
1999-12-08
DITT: Test
Developer
Test Suite
Licensed To Vendors
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
Licensed
Test Suite
24 
End Of Standards Life Cycle
Review Cycle: Revise, Reaffirm, Withdraw
Development
Consensus
Building
Review Cycle:
• Revise: new work item,
incorporate new technology
• Reaffirm: no changes, stable
technology
• Withdraw: little use, obsolete
technology
• Typically: 5 year cycle
Review
1999-12-08
Maintenance
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
25
Typical Usage Scenarios
• Market adoption is necessary for standards ...
– Standards are withdrawn if little or no market
adoption
– Standards are withdrawn if technology is obsolete
• Following scenarios are expected, typical use
of LTSC standards
• Note: All characters are fictional
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
26
Typical Usage Scenario: The Student
• Kris is working at home today. In
school he uses a Macintosh, but at
home he uses an IBM PC.
1484.17
Macintosh
1484.18
• His learning content is available in a
portable format (1484.10)
1484.10
IBM PC
1484.18
1999-12-08
• Kris operates on both platforms
because he uses a “standard” learning
technology web browser (1484.18).
• The content is sent to his workstation
in a portable “packaging” format
(1484.17).
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
27
Typical Usage Scenario: The Student
Sequencing
1484.6
•
Kris’ learning progresses via a “learning
management system” (1484.11), also
known as an “LMS”.
•
The LMS moves him through lessons
based on optimal sequencing (1484.6).
Learning
Management
System
1484.11
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
28
Typical Usage Scenario: The Employee
• Kirsten is interested in a better job.
1484.2
Student Records,
Transcripts, Portfolio
• Kirsten collects her transcript and
portfolio (1484.2).
• Kirsten publishes it so that employers
may discover her skills and work
experience (1484.4).
1484.4
Employers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
29
Typical Usage Scenario: The Employee
1484.2
Student Records,
Transcripts, Portfolio
1484.19
• While searching for job opportunities,
Kirsten discovers a job opportunity
that requires certain skills and
competencies (1484.20).
• As a life long learner she keeps track
her “learning quality” (1484.19) and
adjusts for her strengths and weaknesses to meet the new learning
objectives
1484.20
Learner’s
Self-Maintained
History
1999-12-08
Job Opportunities
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
30
Typical Usage Scenario: The Researcher
1484.12
English
French
1484.2
Russian
1484.9
Kathy
• Kathy is working on research that
correlates student performance to
specific types of learning materials.
• Although Kathy speaks Russian, she
is able to search and discover learning
materials in a variety of languages
(1484.12) and correlate the metadata
to terms that are familiar in her
Ukrainian culture (1484.9).
• Kathy works with institutions to extract
the de-identified student records and
results (1484.2) so research continues
without any privacy concerns.
Researcher
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
31
Typical Usage Scenario: The Developer
New, Authored
Materials
1484.6
1484.10
• Erik wants to develop a course.
• Erik bases the course on some new
material he authors (1484.6, 1484.10).
• Additionally, Erik incorporates existing
material found on the web (1484.12).
A New Course
Erik
1484.12
1999-12-08
Existing Material &
Cataloging Info
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
32
Typical Usage Scenario: The Developer
• With the newly created course, Erik
wants use the existing tools (1484.7)
on the user’s workstation, such as the
word processor, spreadsheet.
• Erik incorporates the user’s preferred
learning-specific icons (1484.5).
Erik
Existing Tools
On Workstation
1484.5
1484.7
Learning-Specific Icons
The New Course
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
33
Typical Usage Scenario: The Developer
• Erik creates a small JavaScript
application that:
Erik
– determines if the prerequisites have
been met (1484.14, 1484.2)
– then launches the content (1484.11)
– and interacts with the tools (1484.7).
1484.2
1484.14
1484.7
1484.11
Launching Content
Query Student Records,
Determine If Prerequisites
Have Been Met
Interact With
Existing Tools
On Workstation
Learning Content
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
34
Typical Usage Scenario: Institutional Admin
Geoff
1484.13
1484.14
Assign
Student
Identifiers
• Geoff wants to make sure that his
students have registered and are
assigned classes (1484.8).
• Geoff assigns student IDs (1484.13) to
registered students.
• Before starting a lesson, the
courseware checks for tuition payment
(1484.14, 1484.8).
1484.8
Launching Content
Verify Enrollment
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
35
Typical Usage Scenario: Institutional Admin
• Geoff exchanges records among
campuses using one protocol
(1484.15, 1484.2).
1484.15
1484.2
• Geoff exchanges records outside his
state-wide college using web-based
technology (1484.16, 1484.2).
1484.16
1484.2
1484.15
1484.2
Inter-Campus Exchange
1999-12-08
Other Campus
Records Exchange
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
36
Typical Timeline Of Standards
Development
Summary of Standards Process
Consensus
Building
•
•
•
•
•
Review
1999-12-08
Maintenance
•
Development Phase: 12-48 months
Consensus Phase: 9-24 months
Maintenance Phase: 3-6 years
Review Cycle: revise, reaffirm, or
withdraw — every 5 years
Typical time: from committee formed
to approved standard: 18-48 months
Realistic schedule ==>
Good results
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
37
Approximate Timeline/Schedule of LTSC
•
•
•
•
•
1996, new projects (LTSC formed): .1 .2
1997, new projects: .3 .4 .6 .7 .10 .11 .12
1998, new projects: .9 .13 .14
1999, new projects: .5 .8 .15 .16 .17 .18 .19 .20
2000, draft standards approved:
– .1 (LTSA), .2 (PAPI), .3 (Glossary), .11 (CMI),
.12 (LOM), .13 (SID)
• 2001, draft standards approved:
– .6 (SEQ), .8 (EI), .10 (TCL), .14 (SDA), .15 (DCTP),
.16 (HTTP), .17 (Packaging), .18 (PMP)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
38
LTSC WG Details
• Scope:
– What’s in
– What’s out
• Highlights of LTSC working groups
– WGs are independent of each other
– WGs are complementary
– Collectively, WGs have fairly complete
functionality
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
39
“The IEEE LTSC (P1484) Roadmap”
Scoping Statement
• IEEE LTSC (P1484) working groups (WGs) and study
groups (SGs) each involve certain areas of learning
technology
• Some learning technology components/features
should not be standardized, e.g., evaluation
methods, delivery systems, applications
• Some learning technology components/features
should be standardized outside LTSC (P1484), e.g.,
multimedia, education standards, cultural adaptation
• Strategy: Standardize smallest, useful, doable
specification that has technically feasibility,
commercial viability, and widespread adoption
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
40 
Learning Technology That Should Not Be Standardized
Example: Evaluation
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
•
Evaluation should not be standardized because:
•
However ... inputs and outputs should be standardized:
Performance
(current)
Learner
Records
– Process/methods are not well-defined or agreed upon
– Value-added feature of learning technology systems
–
–
–
–
Behavior coding methods
Learning content formats
Performance information
Assessment information
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
41 
Learning Technology That Should Not Be Standardized
Example: Delivery
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
•
Delivery should not be standardized because:
•
However ... inputs and outputs should be standardized:
Performance
(current)
Learner
Records
– Value-added feature of learning technology systems
– Commercial vendors provide “implementation quality” with delivery systems
–
–
–
–
Multimedia formats
Learning content format
Locator index and launch methods
Standards profiles for browsers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
42 
Learning Technology Should Be Standardized Outside LTSC
Example: Multimedia Formats
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
•
Multimedia formats should be standardized outside LTSC because:
•
However ... standards “profiles” (collections) should be identified:
– Not specific to learning technology
– Other committees have more expertise
– Can point to collections of existing standards, e.g., JPEG, GIF, MPEG
– Don’t lock into a single format to allow varying “implementation quality”
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
43 
Learning Technology Should Be Standardized Outside LTSC
Example: Education Standards
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
•
Education standards should be standardized outside LTSC because:
•
However ... education stds should build on learning technology using:
– Not technology standards
– Highly political process
– Local, national, and regional preferences ... unable to build consensus
– Common indexes (query, content, locator) for search/retrieval
– Common formats for exchanging assessment/performance info
– Common learning content structures for prerequisites and content aggregation
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
44 
Learning Technology Should Be Standardized Outside LTSC
Example: Cultural Adaptation
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
•
Cultural adaptation should be standardized outside LTSC because:
•
However ... learning preferences can be identified independently, e.g.:
•
And ... LTSC should collaborate with cultural adaptation committees
– Not specific to learning technology, e.g., color blindness, language preference
– Other committees have more expertise, e.g., ISO/IEC JTC1 SC35
– Local, national, and regional preferences ... unable to build consensus
– Learning styles
– Mentoring/coaching/hinting preferences
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
45 
LTSC Guidelines for Working Groups
• Choosing a new working group (WG):
–
–
–
–
•
•
•
•
smallest, useful, doable specification
technically feasibility
commercial viability
widespread adoption
LTSA describes technology, not WG structure
No “grand framework” for new WGs (not ISO OSI)
Large number of WGs, but many “small” standards
Quick schedule: WG formation  draft standard
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
46
IEEE LTSC (P1484) Working/Study Groups
General Activities
Data and Metadata
1484.1 Architecture and Reference Model **
1484.3 Glossary
1484.12 Learning Objects Metadata **
1484.9 Localization
1484.14 Semantics and Exchange
Bindings **
1484.15 Data Interchange Protocols
1484.16 HTTP Bindings
Learner-Related Activities
1484.2 Learner Model **
1484.4 Task Model
1484.13 Student Identifiers
1484.5 User Interfaces
1484.19 Quality System for Life-Long
Learning
1484.20 Competency Definitions
Content-Related Activities
1484.10 CBT Data Interchange
1484.6 Course Sequencing **
1484.17 Content Packaging **
Mgmt. Systems & Applications
1484.11 Computer Managed
Instruction **
1484.18 Platform and Media Profiles
1484.7 Tool/Agent Comm.
1484.8 Enterprise Interfaces
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
47
IEEE LTSC (P1484)
General Activities
• IEEE 1484.1 Architecture and Reference Model **
• IEEE 1484.3 Glossary
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
48
IEEE 1484.1:
Architecture and Reference Model WG
•
•
•
•
Chair: Mike Collett, Education Online
Technical Editor: Frank Farance, Edutool.Com
URL: http://ltsc.ieee.org/wg1
Documents:
– “Learning Technology Systems Architecture (LTSA)”
http://edutool.com/ltsa
– Status: Base Document 1998-06
– Summary: Component architecture
– Target: Draft Standard by 2000Q2
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
49
IEEE 1484.1:
Technical Summary
• Excerpt from LTSA 5.0, http://edutool.com/ltsa
• “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.”
 More than one architecture is possible
• “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.”
 Architecture used for analysis and communication
• “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.”
 Critical interoperability interfaces/services identified
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
50 
Summary of Five LTSA
Abstraction-Implementation Layers
Layer 1
Learner/
Environment
Interactions
Learner
Entity
Environment
L
L
L
Interactions
Layer 2
Human-Centered/Pervasive Features
LE
M
Layer 3
LTSA
System
Components
D
LC
L
LR
B
IC
L
CI
LP
C
E
A
PP
Q
P
R
Layer 4
120+ Stakeholder Perspectives/Priorities
Layer 5
Requirements  Functionality  Conceptual Model  Semantics



APIs Codings Protocols



Calling Data
Comm.
Conv. Formats Layers
1999-12-08
APIs,
Codings,
& Protocols
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
51 
Learning Technology Systems Architecture (LTSA)
Layer 3: System Components
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
•
•
•
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
Processes: Learner Entity, Evaluation, Coach, Delivery
Stores: Learner Records, Learning Resources
Flows: Behavior, Assessment, Performance/Preferences (past, present, future),
Query, Catalog Info, Locator, Learning Content, Multimedia, Interaction Context,
Learning Preferences
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
52
LTSA Layer 3 Analogy:
Stereo Component Architecture
• Well-defined components: tuner, CD-player, tape
loop, pre-amp, amplifier, speakers
• Well-defined critical interfaces: media, phono
jacks, unbalanced inputs, 4-16 ohm outputs
• Not all components need exist, e.g., stereo system
without a CD-player
• Engineering/business rationale for highly
integrated subsets (receivers, “boom box”), yet all
have interoperability at critical interfaces, e.g., aux
inputs, speakers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
53
Example Mapping #1: Web-Based Learning
Demonstrates Tightly Integrated Components
* Note: Other mappings may co-exist.
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Abstraction
Implementation
Human
1999-12-08
Human
Interface
e.g., X Windows
Win95
Presentation
Tool
(browser)
Performance
(current)
Learner
Records
Student
Records
(database)
Courseware
Database
IEEE LTSC Work Program/Process, F. Farance
(web servers)
©1999 Edutool.Com
54 
Example Mapping #2: Flight Simulator, Flight Instructor
Demonstrates Shared Component Responsibility: Coach
* Note: Other mappings may co-exist.
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Abstraction
Implementation
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Flight
Instructor
Learner
Records
Pilot’s
Logbook
Flight
Simulator
Pilot
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
55 
Example Mapping #3: Home Study Course
Demonstrates Student Can Have Multiple Roles/Responsibilities
* Note: Other mappings may co-exist.
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
Abstraction
Implementation
School
1999-12-08
Home
Study
Course
Student
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
56 
Example Mapping #4: Non-Electronic, Traditional Classroom
Limiting Case: No Technology Involved
* Note: Other mappings may co-exist.
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
Abstraction
Implementation
Student
Student Uses
Library
Teacher Points Student To
Books (A Locator)
School
Library
1999-12-08
Teacher
Grades
Retrieves Teaching
Materials
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
Report
Cards,
Transcript
57 
LTSA Layer 4: Stakeholder Perspectives
• Each stakeholder has a view, but not complete
picture
• Show each stakeholder perspective within LTSA
• Stakeholder perspectives used to validate views and
subsets of LTSA components
• 120+ stakeholders analyzed and incorporated
• “It’s in there!” (if not, let us know!)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
58
LTSA Layer 4: Stakeholder Perspectives
Global Information Infrastructure (GII) Experience
• Common technology does not imply common
architecture
• Stakeholder perspectives analyzed by:
– Primary design issues: LTSA components that greatly
affect design and implementation for stake holder (shown as
red/bold)
– Secondary design issues: LTSA components that affect
design and implementation of stake-holder, but not critical
(shown as blue/dash ---)
– Other LTSA components: insignificant design issue or not
applicable (no highlight/green fill)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
59
LTSA Layer 4: Stakeholder Perspectives
Consensus-Building
• Stakeholders, typically, have different and/or
incompatible priorities
• Differing priorities: obstacles to consensus
• Non-technical (political, business) issues just as
important as technical issues
• Recognizing technical/business/political priorities
AND common technology can lead to common
architecture
• Cataloging stakeholder perspectives is critical for
building consensus
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
60
LTSA Layer 4: Stakeholder Perspectives
A Sampling of Stakeholders
“Isolated” stakeholders
“Overlapping” stakeholders
Learner-Centered, Institution-Centered,
Assessment-Centered, Records,
Certifications, Task Model, School-to-Work,
Content-Centered, Content Developers,
Metadata, Ontologies, Expert Systems,
Digital Libraries, Learning Objects,
Multimedia Search/Retrieval,
Collaboration, Peripheral Devices,
Asynchronous Learning, Multiple Role,
Team Learning, Icon Conventions
Mentoring, Coaching,
Electronic Performance Support
Interactive Environment, Simulation
Tool-to-Tool Communication,
Sequencing, Pre-Requisites,
Curriculum-Centered,
Experimentation, Discovery,
Intelligent Tutoring Tools,
Distance/Distributed/Nomadic Learning
Related Industries
“Parallel” stakeholders
Parallel Sessions/Same Learner
Student-Teacher
Multi-Tier Process Improvement:
principal  teacher  student
1999-12-08
Human Factors/User Interfaces,
Data Collection/Analysis,
IT Decision-Support Applications,
Expert Systems/Intelligent Systems,
Entertainment/Multimedia Industry,
Control/Feedback Systems
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
61
LTSA Layer 4: Stakeholder Perspectives
A Sampling of Stakeholders
• Same technology scope, differing priorities: stakeholders
have common technology but differing design priorities
– #1 Metadata vs. Ontologies (demonstrates GII consensus issues)
• “Isolated” stakeholders: simple, limited scope
– #2 Assessment-Centered; #3 Records, Certifications;
#4 Multimedia Search/Retrieval
• “Overlapping” stakeholders: complex, large scope
– #5 Experimentation, Discovery; #6 Intelligent Tutoring Tools;
#7 Distance Learning, Distributed Learning
• “Parallel” stakeholders: multiple applications of LTSA
– #8 Parallel Sessions; #9 Student Teachers;
#10 Multi-Tiered Process Improvement
• “Related Industries” stakeholders: similar technology, overlap
– #11 Human Factors/User Interfaces; #12 IT Decision-Support Apps;
#13 Entertainment and Multimedia; #14 Control/Feedback Systems
• Counterintuitive: isolated stakeholders are better starting point
for developing architecture; overlapping stakeholders are a poor
starting point
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
62 
“Same Technology Scope, Differing Design Priorities”
Example #1: Metadata (compare next slide)
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: query, catalog info (metadata), locator index
(e.g., URLs), and associating locator indexes with catalog info
• Secondary design issues: knowledge organization, learning content
(presentation)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
63
“Same Technology Scope, Differing Design Priorities”
Example #1: Ontologies, Expert Systems (compare prior slide)
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: knowledge design and knowledge
representation in learning resources, learning content (presentation)
• Secondary design issues: query, catalog info (metadata), and
locator index (e.g., URLs)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
64
“Isolated” Stakeholder
Example #2: Assessment-Centered
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: educational standards, behavior, evaluation,
assessment records, learner records reporting
• Secondary design issues: learning preferences, learner, system
control (adaptive administration)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
65
“Isolated” Stakeholder
Example #3: Records, Certifications
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner records, performance info,
assessment info
• Secondary design issues: evaluation, coach
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
66
“Isolated” Stakeholder
Example #4: Multimedia Search/Retrieval
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: delivery, multimedia, query, catalog info
(metadata), locator index (e.g., URLs), hardware limitations
• Secondary design issues: coach, learning resources, learning
content format, behavior
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
67
“Overlapping” Stakeholder
Example #5: Experimentation, Discovery
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner chooses direction, acquires
knowledge during experimentation, learner, coach, query, catalog
info (metadata)
• Secondary design issues: learner does self evaluation, tools and
delivery support experimentation, behavior, assessment info,
locator index (e.g., URLs), delivery, multimedia
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
68
“Overlapping” Stakeholder
Example #6: Intelligent Tutoring Tools
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner/tutor choose direction, acquires
knowledge during use of tutoring tool, learning resources may be
implicit (not explicitly defined) in tutor
• Secondary design issues: tutor does evaluation, tools and delivery
support experimentation
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
69
“Overlapping” Stakeholder
Example #7: Distance/Distributed/Nomadic Learning
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: distributed and nomadic communication of
all “flows” (behavior, performance, multimedia, etc.)
• Secondary design issues: processes and stores components
• NOTE: Take note of primary design issues (red/bold)
– How does this slide differ from all others?
– Answer: All flows are primary, everything else is secondary
– A technical definition of distance/distributed learning: primary design
issues concern “flows”, all other LTSA components are secondary
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
70 
“Parallel” Stakeholder
Example #8: Parallel Sessions for Same Learner
Example: Aviate
Example: Navigate
Example: Communicate
•
•
•
Primary design issues: multiple, simultaneous learning experiences;
multiple flows of behavior, learning preferences, multimedia
Secondary design issues: multiple evaluation, coach, and delivery
processes
Example: flight simulator — simultaneous training of flying skills, navigation
skills, communication skills, cockpit resource management
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
71 
“Parallel” Stakeholder
Example #9: Student Teacher
Student
Teacher
• Primary design issues: student teacher as a teacher
• Secondary design issues: student teacher as a learner entity
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
72 
“Parallel” Stakeholder
Example #10: Multi-Tiered Process Improvement
Student
Teacher
Principal
•
•
•
•
•
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
Teacher is also evaluated by performance of his/her students
Principal is also evaluated by performance of his/her students
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
73 
“Related Industries” Stakeholder — “The LTSA Top Half”
Example #11: Human Factors/User Interfaces
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: human interfaces, human inputs (behavior),
systems that interpret human inputs (evaluation), machine outputs
(multimedia), systems that generate machine output (delivery)
• Secondary design issues: responsiveness (interaction context),
adaptation (learning preferences)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
74
“Related Industries” Stakeholder — “The LTSA Bottom Half”
Example #12: IT Decision-Support Applications
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: processing of information (coach), supporting
databases (learner records, learning resources), information formats
and their storage/retrieval (learning preferences, assessment info,
performance info, preference info, query, catalog info, locator)
• Secondary design issues: front-end, back-end, second-tier, and agent
processing (evaluation, delivery, learning content)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
75
“Related Industries” Stakeholder — “The LTSA Left Half”
Example #13: Entertainment and Multimedia
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: content (learning resources, learning
content), delivery stream (delivery, multimedia)
• Secondary design issues: content selection (query, catalog info,
locator), user/viewer/subscriber (learner entity)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
76
“Related Industries” Stakeholder — “The LTSA Center”
Example #14: Control/Feedback Systems
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: system (learner entity), sensor (behavior,
evaluation, assessment info), controller (coach), actuator (locator,
delivery, multimedia)
• Secondary design issues: second-order/alternative feedback
(interaction context, learning preferences)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
77
LTSA Layer 4: Stakeholder Perspectives
A Sampling of Stakeholders Outside LTSC
CEN/ISSS/LT activities
AICC activities
Reusability and Interoperability,
Metadata, Taxonomies, Vocabularies,
Bindings, Profiles, Internationalization,
Structure of Learning Resources,
Architectures, Rights Management,
Data Protection and Privacy,
Accreditation and Access
Digital Audio/Video, Icon Standards,
CBT Peripheral Devices, Glossary,
Computer Managed Instruction,
Courseware Interchange,
Digital Electronic Library, Smart Graphics
PROMETEUS activities
Interchange/Reusability/Portability,
Corporate/Higher Ed/Cooperative/Open/
Distance/Broadcast-Based Learning,
Primary/Secondary School Environments
ARIADNE activities
Metadata, Content Packaging,
Profiles, Question/Test Interoperability,
Enterprise Interfaces
GESTALT activities
LOM and PAPI Implementations
GEM activities
Cataloging and Tools
Metadata, Multi-Cultural Metadata, Tools
For Remote Authoring/Teaching/Learning
1999-12-08
IMS Project activities
ADL activities
Sharable Course Objects Ref. Model
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
78
LTSA Layer 4: Stakeholder Perspectives
IEEE LTSC (P1484) Working/Study Groups
General activities
Data and metadata
1484.1 Architecture and Reference Model
1484.3 Glossary
1484.12 Learning Objects Metadata
1484.9 Localization
1484.14 Semantics and Exchange
Bindings
1484.15 Data Interchange Protocols
1484.16 HTTP Bindings
Learner-related activities
1484.2 Learner Model
1484.4 Task Model
1484.13 Student Identifiers
1484.5 User Interfaces
1484.19 Quality System for Life-Long
Learning
1484.20 Competency Definitions
Content-related activities
1484.10 CBT Data Interchange
1484.6 Course Sequencing
1484.17 Content Packaging
1999-12-08
Mgmt. systems & applications
1484.11 Computer Managed
Instruction
1484.18 Platform and Media Profiles
1484.7 Tool/Agent Comm.
1484.8 Enterprise Interfaces
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
79
Sampling of Collaborations Among Orgs
Metadata: IEEE 1484.12 LOM  IMS Metadata 
ARIADNE Metadata  GEM  NCITS L8 
ISO-IEC/JTC1/SC32
Computer Managed Instruction: IEEE 1484.11  AICC
AGR006
PAPI/Student Profiles: IEEE 1484.2  IMS
Student/Patient Identifiers: IEEE 1484.13  OMG CORBAMED
Platform Profiles: IEEE 1484.18  ADL
CBT Data Interchange: IEEE 1484.10  AICC AGR007
Content Packaging: IEEE 1484.17  IMS
Course Sequencing: IEEE 1484.6  IMS Question/Test Interop.
Tool/Agent Communication: IEEE 1484.7  DoD DMSO HLA
User Interfaces: IEEE 1484.5  AICC AGR009
Glossary: IEEE 1484.3  ISO-IEC/JTC1/SC1
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
80
IEEE 1484.1:
Architecture and Reference Model WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: all components
• Secondary design issues: none
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
81
IEEE 1484.3:
Glossary WG
•
•
•
•
Chair: Katherine Sinitsa, IRTC ITS UNESCO/IIP
Technical Editor: Joshua Tonkel
URL: http://ltsc.ieee.org/wg3
Documents:
– Glossary (check above URL for latest draft)
– Status: Working Draft, 1998-09
– Summary: Glossary of terms for learning technology
standardization
– Target: Draft Standard by 2000Q2
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
82
IEEE 1484.3:
Glossary WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: none
• Secondary design issues: all components
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
83
IEEE 1484.3:
Sampling of Glossary Terms
• abstraction
• abstractionimplementation
boundary
• abstractionimplementation layer
• actual implementation
• assignable unit
• computer managed
instruction
1999-12-08
•
•
•
•
•
•
•
•
course
course content
course pre-requisite
course structure
courseware
curriculum
implementation
instructional objective
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
84
IEEE 1484.3:
Sampling of Glossary Terms
•
•
•
•
•
•
•
learner
learner history
learning objective
lesson
lesson sequencing
metadata
performance
information
• personal information
• portfolio information
1999-12-08
•
•
•
•
•
•
•
•
•
•
preference information
prerequisite
refinement layer
router
score
session
student
test
training objective
transcript
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
85
IEEE LTSC (P1484)
Learner-Related Activities
•
•
•
•
•
IEEE 1484.2 Learner Model **
IEEE 1484.4 Task Model
IEEE 1484.13 Student Identifiers
IEEE 1484.5 User Interfaces
IEEE 1484.19 Quality System for Life-Long
Learning
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
86
IEEE 1484.2:
Learner Model WG
• Co-Chairs: Frank Linton and Brad Goodman,
MITRE Corporation
• Technical Editor: Frank Farance, Edutool.Com
• URL: http://ltsc.ieee.org/wg2
• Documents:
– “Public and Private Information (PAPI)”
http://edutool.com/papi
– Status: Base Document 1997-09
– Summary: Portable student records
– Target: Draft Standard by 2000Q2
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
87
IEEE 1484.2:
Learner Model WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner entity, learning preferences,
evaluation, performance info, assessment info, coach
• Secondary design issues: behavior
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
88
Learner/Profile Information
— PAPI Spec and Extensions
— Data Repositories
General Learning Technology Information
Learner Information
PAPI Learner Performance
Learner Relations Info
Extensions
Learner Performance Info
PAPI Learner Relations
Extensions
PAPI Learner Security
Extensions
Learner Security Info
Learner Portfolio Info
PAPI Learner Portfolio
Learner Profile
Information
Learner Personal Info
Extensions
PAPI Learner Preference
Extensions
Learner Preference Info
PAPI Learner Personal
Extensions
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
89 
Profile Information in Distance/Distributed Learning
Content Delivery vs. Records Exchange
Home / Home Campus
Learner
User
Interface,
Browser
Content Delivery (e.g. via web)
Records Exchange
Via PAPI
Profile
Server
Remote Campus
Content/
Mgmt.
Server
Learning
Content
* Ad Hoc Notation
Profile
Server
Back
Office
1999-12-08
Back
Office
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
90 
Types Of Profile Information and Their Movement
(Conceptual Model)
Home / Home Campus
Legend /
Mnemonic:
Learner
User
Interface,
Browser
N = Personal
M
R
Info (e.g., Name,
NS
2
1
address)
M
S = Security Info
R = Relations Info
NSR
Profile
M = Preference Info
Server
N S
(e.g., My config.)
R
G =Performance
W
4
Info (e.g., Grades)
Back
G
Grades can
W =Portfolio
Office G
be sent to back
Info (e.g., Works)
office (e.g., registrar)
1999-12-08
Remote Campus
Content/
Mgmt.
Server
Learning
Content
3
M
Requests performance
history from its (remote)
profile server and
M
other (home, etc.)
profile servers
Profile
G
Server
G
5
Portfolio: links to G
work/accomplishments
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
Back
Office
91 
Records Exchange:
Scales to Multiple Tier Campus
Tier 1:
Learner at Home
Learner
User
Interface,
Browser
Tier 2:
Main Campus
Content/
Mgmt.
Server
Tier 3:
Remote Campus
Content/
Mgmt.
Server
Learning
Content
Both main campus
and remote campus
can serve content
Profile
Server
Profile
Server
Back
Office
* Ad Hoc Notation
1999-12-08
Main campus may
“front end” content
for remote campus
Profile
Server
Performance:
stored, forwarded,
retrieved on all
profile servers
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
Back
Office
92 
Compilation of Profile Information Flows
Schematic of PAPI Learner Data Flows and Uses
NOTATION: X,N,S,R,M,G,W
Out of Scope Info (X)
Learner
PAPI Info Within
Conceptual Model
PAPI Info Outside
Conceptual Model
Content/
Mgmt Server
Browser, User
Interface
Learning
Content, free
Learning
Content, pay
Learning
Content, etc.
Back Office
Internet
Profile
Server
Secure Local/Home Intranet
1999-12-08
Profile
Server
Back Office
Secure Remote Intranet
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
93
IEEE 1484.4:
Task Model WG
•
•
•
•
Chair: Tom Probert, US Dept. of Labor
Technical Editor: To Be Assigned
URL: http://ltsc.ieee.org/wg4
Documents:
–
–
–
–
Various presentations
Expect submission by 2001-06
Status: Reorganization under new chair
Summary: Information technology for searchable
resumes
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
94
IEEE 1484.4:
Problem Statement [1/2]
• With stored learner model records, how do
organizations find students/employees with
specific skills?
• How do students/employees discover available
jobs, projects, and micro assignments?
• How do employers know records have not been
changed?
• How can students/employees “advertise” their
skills?
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
95
IEEE 1484.4:
Problem Statement [2/2]
• Technical problem: general taxonomies of
skills
• Solutions feed into 1484.2 Learner Model WG
and 1484.20 Competency Definitions
• What is relationship to 1484.2 & 1484.20?
• Are these Learner Model (PAPI) queries?
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
96
IEEE 1484.4:
Task Model WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner records, performance info (history)
• Secondary design issues: performance info (current, new)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
97
IEEE 1484.13:
Student Identifiers (SID) WG
•
•
•
•
Chair: Mike Collett, Education Online
Technical Editor: Frank Farance Edutool.Com
URL: http://ltsc.ieee.org/wg13
Documents:
– “Simple Identifiers (SID)”
http://edutool.com/sid
– Status: expect SID submission by, 1999-12
– Summary: Formats and data typing for student IDs
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
98
IEEE 1484.13:
Problem Statement
• Need common method for identifying students
• Need identifier that can be entered by humans
• Identifiers are key for linking several types of
learner information
• Social security numbers — problem: both
identity and authentication
• Old thinking: need common, singular student
identifier
• New thinking: need unique identifier, students
may have multiple identifiers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
99
IEEE 1484.13:
Technical Constraints
• Identifiers are strings with limited character
set for wide compatibility
• Identifiers support international character sets
• Identifiers can be embedded in filenames
• Identifiers can be embedded in URLs
• Identifiers can be embedded in E-mail
addresses
• Identifiers might be embedded in domains
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
100
IEEE 1484.13:
Student Identifiers (SID) WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, learner records
• Secondary design issues: learner, coach
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
101
IEEE 1484.13: “Simple Identifiers”
Strings With Limited Character Set
• Identifiers may include the following characters:
A
N
a
n
0
_
B
O
b
o
1
-
C
P
c
p
2
.
D
Q
d
q
3
%
E
R
e
r
4
F
S
f
s
5
G
T
g
t
6
H
U
h
u
7
I
V
I
v
8
J
W
j
w
9
K
X
k
x
L
Y
l
y
M
Z
m
z
• Example: “john.doe.ps217.nyc.ny.us” or “id6374980”
• International characters are based on ISO 10646
name and described as 8-, 16-, or 32-bits:
8-bit characters: %hh
16-bit characters: %uhhhh
32-bit characters: %Uhhhhhhhh
• Allows any international character, example:
“Côté” ==> C%e2t%dc
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
102
Embedding Simple Identifiers
In Other Namespaces
• Compatibility with other namespaces is critical for
widespread adoption
• Binding to OMG CORBAMED PIDS spec
• Filename example:
/home/C%e2t%dc
• URL example:
http://www.xyz.edu/users/C%e2t%dc
• E-mail example:
mailto:C%e2t%dc@xyz.edu
• Domain example:
C%e2t%dc.users.xyz.edu
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
103
IEEE 1484.5:
User Interfaces WG
•
•
•
•
Chair: Ian Wright, Vega (UK)
Technical Editor: To Be Assigned
URL: http://ltsc.ieee.org/wg5
Documents:
– AICC AGR009 “Icon Guidelines”
http://www.aicc.org/docs/AGRs/agr009.zip
– Status: Reforming with new PAR and chair
– Summary: Catalog of common icons
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
104
IEEE 1484.5:
User Interfaces WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: multimedia, behavior
• Secondary design issues: learner entity, learning preferences
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
105
IEEE 1484.5:
A Sampling of User Icons
Forward
arrow
Backward
arrow
MENU
Menu
Close
CLOSE
PAUSE
EXIT
Pause
Exit
1999-12-08
Audio on
AUDIO
REPEAT
Audio off
AUDIO
AUDIO
CONTROL
VIDEO
TEXT
TEXT
PROGRESS
Audio
ctl panel
Video
ctl panel
Text on
Text off
?
HELP
OPTIONS
A
B
GLOSSARY
COMMENTS
Based on
AICC AGR009
Repeat
sequence
Progress
indication
Help
button
Audio Panel
AUDIO
REPEAT
PAUSE
VOLUME
ON
Modify
options
Access
glossary
Video Panel
Student
comments
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
VIDEO
REPEAT
PAUSE
106
IEEE 1484.19: Quality System
For Life-Long Learning WG
•
•
•
•
Chair: Jim Schoening, US Army
Technical Editor: Maja Pivec
URL: http://ltsc.ieee.org/wg19
Documents:
– Expect submission by 2000-03
– Status: WG is forming
– Summary: A traditional quality standard focused
on the process of technology-based, life-long
learning
– Target: not a standard, but a “recommended
practice”
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
107
IEEE 1484.19: Project Authorization
Request (PAR), Scope
• This will be a typical quality standard. It will focus on
the learner-centered processes of life-long learning.
• It will specify the required elements of a usercentered quality system (e.g. goal-setting, planning,
execution, tracking, documentation, continuous
process improvement, etc.) for life-long learning.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
108
IEEE 1484.19: Quality System For
Life-Long Learning WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learner entity, evaluation, performance info,
assessment info
• Secondary design issues: learning preferences, coach, learner
records
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
109
IEEE 1484.19: Project Authorization
Request (PAR), Purpose [1/3]
• This Recommended Practice will help the following
stakeholders in the following ways:
– It will help students, employees, and other types of learners
improve their learning performance, whether they are part of
institutional learning or in a self-directed mode.
– It will provide structural guidance for learners to assume
primary responsibility for their own learning progress.
– It will help prepare K-12 learners for the post-secondary
world of work/continuous education.
– It will enable learners to provide proof of their track-record in
life-long learning to prospective employers or follow-on
schools.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
110
IEEE 1484.19: Project Authorization
Request (PAR), Purpose [2/3]
– Employers and schools will be able to assess an applicant's
potential for continued life-long learning, based on his or her
documented system and past performance.
– It will help schools help their students become life-long
learners.
– It will prompt managers of learning programs to focus
performance assessment of their programs on self-learning
and life-long learning outcomes.
– It will help learner guardians (instructors, parents, trainers) to
monitor the learning progress and provide assistance for
continuous improvement.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
111
IEEE 1484.19: Project Authorization
Request (PAR), Purpose [3/3]
– It will help employers support the life-long learning of
employees.
– It will help developers of learner-centered management
systems provide quality products to learners, either directly
or through schools or employers.
– It will help assessors and evaluators of learner-centered
management systems develop analytical tools for measuring
self-learning and life-long learning progress.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
112
IEEE 1484.20:
Competency Definitions WG
•
•
•
•
Chair: Claude Ostyn, Click2Learn.com
Technical Editor: Not yet assigned
URL: http://ltsc.ieee.org/wg20
Documents:
– None
– Status: WG is forming
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
113
IEEE 1484.20: Project Authorization
Request (PAR), Scope [1/5]
• This standard shall specify the mandatory
and optional data elements that constitute a
Competency Definition as used in a Learning
Management System, or referenced in a
Competency Profile. This standard is
intended to satisfy the following objectives:
– Provide a standardized data model for reusable
Competency Definition records that can be
exchanged or reused in one or more compatible
systems
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
114
IEEE 1484.20: Project Authorization
Request (PAR), Scope [2/5]
– Reconcile various existing and emerging data
models into a widely acceptable model
– Provide a standardized way to identify the type
and precision of a Competency Definition
– Provide a unique identifier as the means to
unambiguously reference a reusable Competency
Definition regardless of the setting in which this
Competency Definition is stored, found, retrieved,
or used. For example, metadata that describe
learning content may contain a reference to one or
more Competency Definition records that describe
the learning objectives for the content.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
115
IEEE 1484.20: Project Authorization
Request (PAR), Scope [3/5]
– Provide a standardized data model for additional
information about a Competency Definition, such
as a title, description, and source, compatible with
other emerging learning asset metadata standards
– Provide a controlled vocabulary to express how
competency definitions are semantically related
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
116
IEEE 1484.20: Project Authorization
Request (PAR), Scope [4/5]
• This standard specifically does not cover:
– A data format, bindings or coding, except as minimally
required for the purpose of exchange between
compliant implementations
– Quality and accuracy in the data itself, although it will
describe recommended best practices. For example,
this standard does not cover the quality or validation of
the various parts of a learning objective statement.
– A competency model, or a taxonomy of competencies.
– How the relationships between competencies are
stored in a database or learning management system.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
117
IEEE 1484.20: Project Authorization
Request (PAR), Scope [5/5]
– Certification data models. However, Certification records
can reference Competency Definitions. For example, an
accredited authority may grant certificates that
acknowledge that an individual meets the requirements
for a particular competency.
– Individual competency records, as would be found in the
competency profiles of individuals or groups. However,
such records can include references to specific
Competency Definitions. For example, a competency
profile for an individual may include a collection of
certificates which in turn reference Competency
Definitions, as well as a collection of references to the
definitions for competencies to be acquired.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
118
IEEE 1484.20:
Competency Definitions WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, assessment info, learner
records
• Secondary design issues: learner entity, learning preferences,
evaluation, coach
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
119
IEEE 1484.20: Project Authorization
Request (PAR), Purpose [1/4]
• The purpose of this standard is to define a
universally acceptable Competency Definition
model to allow the creation, exchange and
reuse of Competency Definition in
applications such as Learning Management
Systems, Competency or Skill Gap Analysis,
Learner and other Competency profiles, etc.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
120
IEEE 1484.20: Project Authorization
Request (PAR), Purpose [2/4]
• The standard is needed because there are
currently many definitions of the terms "Learning
Objective", "Competency" and "Skill", and very
little agreement between how those definitions
can be used to define reusable data models.
• This standard uses a general definition that can
be semantically "tightened" or "loosened" in the
data itself, while conserving the same data
model regardless of how strictly a particular
organization or institution requires the data to be
formulated.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
121
IEEE 1484.20: Project Authorization
Request (PAR), Purpose [3/4]
• This standard also addresses the following needs:
– A common data model that allows the building of various
competency models, hierarchies and maps (however,
the definitions for such applications are outside the
scope of this standard).
– A standard that allows persistent, long lived Competency
Definitions to be created, exchanged among systems,
and maintained.
– A standard method by which Competency Definitions
can be identified as globally unique among compliant
systems and repositories.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
122
IEEE 1484.20: Project Authorization
Request (PAR), Purpose [4/4]
– A standard method to mark a superseded or
obsolete Competency Definition, and to point to a
more current Competency Definition.
– A common data model for the metadata that give a
reusable Competency Definition its value in a
reuse environment, such as the source of the
Competency Definition, validation information, and
other meta-information useful to locate an
objective in a repository or collection.
– Correspondence with the Learning Objects
Metadata Standard developed by a parallel group.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
123
IEEE LTSC (P1484)
Content-Related Activities
• IEEE 1484.10 CBT Data Interchange
• IEEE 1484.6 Course Sequencing **
• IEEE 1484.17 Content Packaging **
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
124
IEEE 1484.10:
CBT Data Interchange WG
•
•
•
•
Chair: Bill McDonald, FlightSafetyBoeing
Technical Editor: Frank Farance, Edutool.Com
URL: http://ltsc.ieee.org/wg10
Documents:
– Various presentations
– Status: expect Tcl syntax submission by 1999-12
– Summary: Text-based data interchange to facilitate
courseware transfer
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
125
IEEE 1484.10:
Problem Statement
• As described by an airplane manufacturer:
“We have planes that last 30 years, but
technology for our training systems lasts only
5-7 years”
• Describe learning content in a text-based
format to facilitate use, reuse, import, and
export.
• Comparison to word processing: “the RTF of
learning content and authoring systems”
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
126
IEEE 1484.10:
CBT Data Interchange WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: coach, performance info, assessment info,
query, catalog info (metadata), locator index (e.g., URLs),
invocation of learning content
• Secondary design issues: learning preferences, behavior, learner
records, learning resources, learning content, delivery
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
127
IEEE 1484.10: Tcl as CBT Data
Interchange Language — Why Tcl?
• Tcl is a very simple syntax: words separated by
spaces with braces {} for grouping
• Tcl’s syntax greatly facilitates import/export tools
• Has execution support on all platforms, can be
embedded in C/C++ code, browser plug-ins
See http://www.tcltk.com
• XML can provide equivalent, but different coding
• Both should be used
• Currently, only XML parsers but no semantics, thus
Tcl is currently a better choice
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
128
Tcl Sample
set w .puzzle
catch {destroy $w}
toplevel $w
wm title $w "15-Puzzle Demonstration"
wm iconname $w "15-Puzzle"
positionWindow $w
label $w.msg -font $font -wraplength 4i -justify left text "A 15-puzzle appears below as a collection of
buttons. Click on any of the pieces next to the
space, and that piece will slide over the space.
Continue this until the pieces are arranged in
numerical order from upper-left to lower-right."
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
129
Tcl Sample
pack $w.msg -side top
frame $w.buttons
pack $w.buttons -side bottom -fill x -pady 2m
button $w.buttons.dismiss -text Dismiss -command
"destroy $w"
button $w.buttons.code -text "See Code" -command
"showCode $w"
pack $w.buttons.dismiss $w.buttons.code -side left expand 1
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
130
IEEE 1484.6:
Course Sequencing WG
•
•
•
•
Chair: Jim Schoening, US Army (CECOM)
Technical Editor: Frank Farance, Edutool.Com
URL: http://ltsc.ieee.org/wg6
Documents:
– Various presentations
– Status: expect submissions by 1999-12
– Summary: Library services for courseware and
content sequencing, based on work of IEEE 1484.10
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
131
IEEE 1484.6:
Pedagogical Sequencing
Content
Internal
Sequencing
Content Retrieve
(metadata)
Learning
Resources
Content
Sequencer
System
External
Sequencing
History
Content Search
• Sequencing systems, examples:
–
–
–
–
Type #1: Content is linked via pre-requisites and co-requisites
Type #2: Simple navigation algorithm
Type #3: Rule-based
Type #4: Programming/scripting language
• Sequencing may be internal (embedded) or external (attached)
• For internal sequencing, method to extract sequencing component
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
132 
IEEE 1484.6:
Course Sequencing WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: coach, performance info, assessment info,
query, catalog info (metadata), locator index (e.g., URLs),
invocation of learning content
• Secondary design issues: learning preferences, learner records,
learning resources, delivery, learning content
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
133
IEEE 1484.6: Sampling Of
Common Sequencing Features
•
•
•
•
•
•
Page turning
Linear sequence
Motion algorithms
Prerequisites
Embedded code
Object-based (hidden
implementation)
• Ontology-based
• Add missing knowledge
1999-12-08
•
•
•
•
•
•
•
•
Multiple choice
Fill in blank
Choose M of N
True-false
Write sentences
Submit project
Randomized content
Content templates
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
134
IEEE 1484.6: Sequencing Is
Independent Of Granularity
• Sequencing can be used at any granularity
level:
–
–
–
–
–
–
–
Sequencing among “courses”
Sequencing among “blocks”
Sequencing among “modules”
Sequencing among “lessons”
Sequencing among “assignable units”
Sequencing within “assignable units”
Page turning
• Sequencing can vary among levels, among
“units” within a level
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
135
IEEE 1484.6: Sampling of Sequencing
Methods At Various Granularities
Sample Course Sequencing: Coarse granularity (e.g., prerequisites) sequencing for
medium granularity components; medium granularity sequencing (e.g., motion
algorithms, ontologies, embedded code) for fine granularity components; and so on ...
Granularity
Sequencing Types
Coarse
Medium
Fine
Page turner, linear
Motion algorithm
Prerequisites
Low-level template
Ontologies (Add
missing knowledge)
Embedded Code
(“Are you ready?”)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
136 
IEEE 1484.17:
Content Packaging WG
•
•
•
•
Chair: Mike Fore, US Army (ATSC)
Technical Editor: Thor Anderson, IMS Project
URL: http://ltsc.ieee.org/wg17
Documents:
– Various presentations
– Status: expect submissions by 2000-03
– Summary: Content aggregation/disaggregation
based on extending JAR files with learning object
manifests
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
137
IEEE 1484.17: Scope
• This standard will describe the packaging of learning
content.
• Learning content, typically, is a collection of
components that a copied, transmitted, purchased,
executed, and used as a single unit. Units may be
combined to make larger units.
• This standard will describe the format, coding,
encoding, environment, attributes, and interactions of
this content.
• This standard will not describe portable content, but
will describe a portable method for packaging
content.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
138
IEEE 1484.17:
Content Packaging WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learning content, catalog info (metadata)
• Secondary design issues: coach, locator index (e.g., URLs),
delivery, learning resources
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
139
IEEE 1484.17: Purpose [1/2]
• The nature of web-based learning, internet
delivery, intellectual property rights, and
electronic commerce motivate the need for a
single unit of transmission for these learning
systems.
• A single unit would allow, for example, a
simple click of a URL in a browser to activate
learning content.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
140
IEEE 1484.17: Purpose [2/2]
• This packaging format would allow the
compilation of not only media components
(text, graphics, audio, video), but would
support the common packaging of metadata,
attributes, and supporting materials — all
within a single transmission unit.
• Higher quality would be possible because the
user or system is no longer responsible for
piecing the components together — the
common packaging format would eliminate
mistakes and would increase interoperability.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
141
IEEE 1484.17:
Technical Requirements
• The packaging file format must be widely known and
supported, across platform boundaries.
• The structure of the package shall be determined solely by
the manifest, not by an implied directory or nesting offered
in some manner by the package file format.
• Deeply nested metadata and content does not require
recursive extraction, i.e. resources for extraction of specific
elements from a package are kept to a minimum.
• Metadata, organizational data, and other types of related
information must be enclosed in a package such that the
associations between these are properly maintained.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
142
IEEE 1484.17: Packaging and Interchange
• Interoperable method of packaging and shipping content
• Bundles content elements, meta data and supporting
materials in the same package
• Exposes both physical and logical structure of content
package
Package
Content Web pages, etc.
Installation
Programs
1999-12-08
Content
Maps
Media JPEG, etc
Metadata
Manifest
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
143
IEEE 1484.17:
Sample Packaging Manifest Info [1/2]
<?xml version="1.0"?>
<!doctype manifest system
"http://www.imsproject.org/dtd/manifest.dtd">
<manifest id="0"/>
<metad> <meta type="ims" name="0009.md" size="17050"/>
<meta type="install" name="000C.md" size="8500"/>
<meta type="launch" name="000d.md" size="9700"/>
</metad>
<corg> <tocr ref="0" type="alphabetical" title="An alphabetical
overview" name="000A.md"
size="510" sourcename="index.md" default/> </corg>
<pack id="1">
<metad> <meta type="ims" name="0008.md" size="16002"/> </metad>
<corg> <tocr ref="1" type="natural" title="Natural progression"
name="000B.md” size="582"/> </corg>
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
144
IEEE 1484.17:
Sample Packaging Manifest Info [2/2]
<pack id="2">
<data name="index.html" size="4133"/>
<metad> <meta type="ims" name="0004.md" size="922"/>
<meta type="x-osd" name="0005.md" size="12920"/> </metad>
</pack>
<pack id="3">
<data name="penguin.gif" size="10968"/>
<metad> <meta type="ims" name="0006.md" size="424"/>
<meta type="X-osd" name="0007.md" size="98572"/> </metad>
</pack>
</pack>
<pack id="4">
<data name="license.txt" size"307"/>
<metad> <meta type="ims" name="0001.md" size="876"/>
<meta type="x-osd" name="0002.md" size="14741"/>
<meta type="X-Bb" name="0003.md" size="768"/> </metad>
</pack>
</manifest>
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
145
IEEE LTSC (P1484)
Data and Metadata Activities
• IEEE 1484.12 Learning Objects Metadata **
• IEEE 1484.9 Localization
• IEEE 1484.14 Semantics and Exchange
Bindings **
• IEEE 1484.15 Data Interchange Protocols
• IEEE 1484.16 HTTP Bindings
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
146
IEEE 1484.12:
Learning Objects Metadata (LOM) WG
• Chair: Wayne Hodgins, Autodesk
• Technical Editor: Erik Duval, ARIADNE
• Tech Leads: Tom Wason, IMS;
Erik Duval, ARIADNE
• URL: http://ltsc.ieee.org/wg12
• Documents:
–
–
–
–
“Learning Objects Metadata (LOM), Draft 2.5”
Status: Working Draft #2, 1999-01
Summary: Search/cataloging information
Target: Draft Standard by 2000Q1
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
147
Metadata, What Is It? [1/5]
• Literally, “data about data”
– Literal definition applies to most data
• In practice:
– many definitions ... some conflicting
– many systems overlap usage, e.g., “metadata”
describes both attributes and search/retrieval info
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
148 
Metadata, What Is It? [2/5]
• Definition #1: “Metadata is a description of elements
that comprise an aggregate type”
• Example:
An address label contains: name, address, city, state, zip.
The metadata is: five elements, the first is a string of maximal
length 20, …, the fourth is a two character string from a limited
set of values, the fifth is string of exactly five numeric characters.
• Metadata is the type, not the values or instances
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
149 
Metadata, What Is It? [3/5]
• Definition #2: “Metadata is the elements that
comprise an aggregate”
• Example:
An address label contains: name, address, city, state, zip.
The metadata is: name: “John Doe”, address: “123 Main Street”,
city: “Anytown”, state: “DC”, zip: “20000”.
• Metadata is the data elements
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
150 
Metadata, What Is It? [4/5]
• Definition #3: “Metadata is information that helps or
facilitates search and retrieval”
• Example:
An address label contains: name, address, city, state, zip.
The metadata might feature a “personal” or “business” attribute
(many address labels might share); or “home” or “office” (only
one address label associated with each).
• Metadata is info that facilitates search/retrieval
• This definition describes IEEE 1484.12 usage
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
151 
Metadata, What Is It? [5/5]
• Definition #4: “Metadata is information that is
associated with an object”
• Example:
An address label contains: name, address, city, state, zip.
The metadata might be features such as access permissions,
last modified date, internal references.
• Metadata is the set of associated attributes
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
152 
Learning Objects, What Are They? [1/5]
• In practice:
– many definitions ... some conflicting
– many systems overlap usage, e.g., “learning
objects” describes both reuse and containerization
• Work still ... refining definitions
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
153 
Learning Objects, What Are They? [2/5]
• Related definitions, courtesy Claude Ostyn,
Asymetrix Learning Systems:
• Learning Asset (LA)
– Reusable learning resource
(e.g. course, course module, test item, document, tool, etc.)
• Learning Object Metadata (LOM)
– Data that describes a Learning Asset
– Is the metadata component of a Learning Object
• Learning Object (LO)
–
–
–
–
Conceptual, not a concrete object
What you get when LOM is associated with LA
Not an object as defined in Object Oriented Programming
May be represented by an OOP object in an implementation
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
154 
Learning Objects, What Are They? [3/5]
• A Learning Asset encapsulates data or behaviors.
– May be portable (e.g. HTML)
– May be implementation or system dependent
(e.g. a Windows ToolBook module, a Quicktime file)
– Different LOMs may reference the same learning Asset
– Different LOMs may use the same learning Asset in
different ways
– May be very small or very large
– A learning Asset may be off-line (person, physical book)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
155 
Learning Objects, What Are They? [4/5]
• Other “Learning Object” definitions, courtesy
Frank Farance, Edutool.Com:
• Definition #1: [reusability]
– “Learning Object” means “focus on reuse”
– Designing for use in multiple contexts
– Common launch/parameterization
• Definition #2: [containerization]
– “Learning Object” means “focus on containerization,
separation”
– Copy/transmit an object — black box
– Labeling, metadata, attributes
– Electronic commerces
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
156 
Learning Objects, What Are They? [5/5]
• Definition #3: [goals]
– “Learning Object” means “focus on instructional objective”
– Describing objectives, goals, knowledge, achievements,
accomplishments
• Definition #4:
– “Learning Object” means “things that learn”
– Not in common use
• Definition #5: [separation]
– “Learning Object” means “media-only, not course structure”
– Connecting/associating/embedding structure and content
– Other associated attributes (metadata)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
157 
Learning Objects Metadata 
Learning Content Cataloging Information
• learning content: information that is intended to be
rendered as a multimedia in a learning experience
• learning content cataloging information:
information associated with learning content
• learning object metadata: see “learning content
cataloging information”
[Definitions courtesy F. Farance.]
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
158
IEEE 1484.12:
Learning Objects Metadata (LOM) WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: query, catalog info (metadata), locator index
(e.g., URLs)
• Secondary design issues: coach, learning resources, learning
content, delivery
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
159
Metadata, Where Is It?
•
•
•
•
•
•
Metadata may be embedded
Metadata may be attached
Metadata may have storage
Metadata may be generated on demand
Metadata may be static
Metadata may be dynamic
• Implementation features, not functional
features
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
160
IEEE 1484.12:
Metadata Embedded/Attached
Locator is “peeled” from
Catalog Info (metadata)
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Content
Content
Embedded
Metadata
Attached
Metadata
• Information technology issues:
– How is metadata embedded in content?
– How is metadata attached to content?
– How is a locator peeled from metadata (catalog info)?
• Learning content issues:
– How is the metadata specification applied to learning content?
– How does metadata support pedagogy alternatives?
– Intellectual property rights management (IPRM)?
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
161 
IEEE 1484.12:
Locator Index, Resource (e.g., URL)
To User
Locator is used to
launch/identify content
Delivery
Learning Locator
Content
• Related issues:
–
–
–
–
What is the locator index syntax? Only URLs/URIs?
How are locators extended for navigation? Example: lessons 1-3 and 5
How is content invoked/launch? What are the semantics of “invoke/launch”?
What is the “information category”? Examples: help message, presentation,
simulation, practice environment, coaching
– What is the “type” of the Learning Content? Examples: applet, HTML, XML,
executable, tutor, script
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
162 
IEEE 1484.12: Learning Object Metadata
Mapping of Dublin Core Elements [1/2]
DC.Identifier  1.1 General.Identifier
DC.Title  1.2 General.Title
DC.Language  1.4 General.Language
DC.Description  1.5 General.Description
DC.Subject  1.6 General.Keywords and
9.1 Classification.Purpose
• DC.Coverage  1.7 General.Coverage
• DC.Type  5.2 Educational.
LearningResourceType
•
•
•
•
•
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
163
IEEE 1484.12: Learning Object Metadata
Mapping of Dublin Core Elements [2/2]
•
•
•
•
•
•
•
•
DC.Date  2.3.3 LifeCycle.Contribute.Date
DC.Creator  2.3.2 LifeCycle.Contribute.Entity
DC.OtherCreator  2.3.2 LifeCycle.Contribute.Entity
DC.Publisher  2.3.2 LifeCycle.Contribute.Entity
DC.Format  4.1 Technical.Format
DC.Rights  6 Rights
DC.Relation  7 Relation
DC.Source  7 Relation.Resource
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
164
IEEE 1484.12: Learning Object Metadata
“General” Elements
• General
– Identifier
– Title
– Catalog Entry
• Catalogue
• Entry
–
–
–
–
–
–
Language
Description
Keywords
Coverage
Structure
AggregationLevel
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
165
IEEE 1484.12: Learning Object Metadata
“Life Cycle” Elements
• Version
• Status
• Create
– Contribute
• Role
• Entity
• Date
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
166
IEEE 1484.12: Learning Object Metadata
“Meta-Metadata” Elements
• Identifier
• CatalogEntry
– Catalogue
– Entry
• Contribute
– Role
– Entity
– Date
• MetadataScheme
• Language
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
167
IEEE 1484.12: Learning Object Metadata
“Technical” Elements
•
•
•
•
Format
Size
Location
Requirements
–
–
–
–
Type
Name
MinimumVersion
MaximumVersion
• InstallationRemarks
• OtherPlatformRequirements
• Duration
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
168
IEEE 1484.12: Learning Object Metadata
“Educational” Elements
•
•
•
•
•
•
•
•
•
•
•
InteractivityType
LearningResourceType
InteractivityLevel
SemanticDensity
IntendedEndUserRole
Context
TypicalAgeRange
Difficulty
TypicalLearningTime
Description
Language
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
169
IEEE 1484.12: Learning Object Metadata
“Rights Management” Elements
• Cost
• CopyrightAndOtherRestrictions
• Description
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
170
IEEE 1484.12: Learning Object Metadata
“Relation” Elements
• Kind
• Resource
– Identifier
– Description
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
171
IEEE 1484.12: Learning Object Metadata
“Annotation” Elements
• Person
• Date
• Description
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
172
IEEE 1484.12: Learning Object Metadata
“Classification” Elements
• Purpose
• TaxonPath
– Source
– Taxon
• Identifier
• Entry
• Description
• Keywords
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
173
IEEE 1484.9:
Localization SG
•
•
•
•
Chair: Erik Duval, Katholieke Universiteit Leuven
Technical Editor: To Be Assigned
URL: http://ltsc.ieee.org/wg9
Documents:
– None
– Status: Not yet formed, PAR not yet approved
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
174
IEEE 1484.9:
Problem Statement
• Areas of internationalization (I18N)
–
–
–
–
Metadata
Vocabularies
Taxonomies
Performance information
• Example: internationalize for use in
languages other than US English (or US
culture/institution dependencies)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
175
IEEE 1484.9:
Localization WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: query, catalog info (metadata), locator index
(e.g., URLs)
• Secondary design issues: coach, learning resources, learning
content, delivery
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
176
IEEE 1484.14: Semantics And
Exchange Bindings (SXB) WG
•
•
•
•
Chair: Tyde Richards, Macromedia
Technical Editor: Not yet assigned
URL: http://ltsc.ieee.org/wg14
Documents:
– Various presentations
– Status: expect submissions by 1999-12
– Summary: APIs and XML bindings of data
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
177
IEEE 1484.14:
Problem Statement
• Define common APIs and codings for use
across LTSC working groups
• Provide XML bindings with concentrated XML
expertise in Working Group
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
178
IEEE 1484.14:
Semantics and Exchange Bindings (SXB) WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, assessment info, catalog
info, query
• Secondary design issues: evaluation, learner records, coach,
learning resources
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
179
IEEE 1484.14:
APIs and XML Bindings
• IEEE LTSC working groups that collaborate with
IEEE 1484.14 on API and XML work:
–
–
–
–
–
–
–
–
–
IEEE 1484.2 Portable student records (PAPI)
IEEE 1484.4 Task Model
IEEE 1484.6 Course Sequencing
IEEE 1484.7 Tool/Agent Communication
IEEE 1484.8 Enterprise Systems
IEEE 1484.10 CBT Data Interchange
IEEE 1484.11 Computer Managed Instruction (CMI)
IEEE 1484.12 Learning Objects Metadata (LOM)
IEEE 1484.17 Content Packaging
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
180
1484.X Methodology: Work Flow
And Progressive Deliverables
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings: Calling
Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
181
1484.X Requirements: Needs and Desirables
Of Users, Institutions, Developers, etc.
• Informative, not part of
standard => only
conform to
interoperability
• Examples:
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
– Search digital libraries
– Learning content access
to student info
– Validate student
enrollment
– Search for employee
qualifications
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
182
1484.X Requirements:
Sources and Influences
Related Industries
Edu-Related
Other Sources
Requirements
Requirements
Functionality
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
183
1484.X Functionality: What It Does
• Partition into functional
areas
• Examples:
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
– Partition into personal,
preference, performance,
portfolio info
– Session definition for
intellectual property
usage
– Get/put values/records
– Describe learning content
– Partition into senderreceiver, client-server,
publisher-subscriber
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
184
1484.X Functionality:
Sources and Influences
Requirements
Related Industries
Edu-Related
Other Sources
Functionality
Requirements
Functionality
Conceptual Model
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
185
1484.X Conceptual Model:
How A Virtual Implementation Works
• “Theory of Operation”
• Examples:
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
– Application opens
repository
– Authentication
– Scan/search for data
– Read/write data
– Perform database and
E-commerce transactions
– Multiple open sessions
– Close sessions
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
186
1484.X Conceptual Model:
Sources and Influences
Functionality
Data Interchange
Related Specs
Related Stds
Conceptual Model
Requirements
Functionality
Semantics
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
187
1484.X Semantics: Detailed Meaning
Of Operations/Transactions
• Assertions: sentences
using shall, should, or
may
• Inquiries: range of
values
• Negotiations: heuristics
• Examples:
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
– Data model element X uses
closed vocabulary Y
– PutValue: replaces old
object, in place
– Search: scans all records
and returns those matching
regular expressions
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
188
1484.X Semantics:
Sources and Influences
Conceptual Model
Language-Related
Protocols
Related Stds
Semantics
Requirements
Functionality
Bindings: APIs
Conceptual Model
Bindings: Codings
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
Bindings: Protocols
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
189
APIs, Codings, Protocols —
All Three Are Required [1/6]
• Semantics are “bound” to APIs, codings, and
protocols
• Designing for all three produces more
coherent, harmonized design
• Different stakeholders have different foci:
–
–
–
–
some want only APIs
some want only codings
some want only protocols
some want a combination
• APIs, codings, and protocols can “re-use”,
“re-target”, or “re-apply” existing standards
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
190
APIs, Codings, Protocols —
All Three Are Required [2/6]
• Motivation for not standardizing APIs:
– Only interested in system-to-system
interoperability, i.e., focus is on codings or
protocols
• What happens if APIs are not standardized?
– Each application develops its own “libraries”
– Code and application reusability is greatly
decreased because no common API or API
framework
– Much effort is spent “reinventing the wheel” by
building low-level subsystems that provide
services normally supplied by APIs
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
191
APIs, Codings, Protocols —
All Three Are Required [3/6]
• Motivation for not standardizing codings:
– Programmers only use (standard) APIs
– Codings are not necessary because databases are
proprietary
– Too hard: vendor, user, institutional variants/extensions
• What happens if codings are not standardized?
– Each application develops its own data model and
representation
– Exchanging data among systems becomes impractical
because of data model incompatibilities
– Data representation incompatibilities  much data
“mediation” and conversion
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
192
APIs, Codings, Protocols —
All Three Are Required [4/6]
• Motivation for not standardizing protocols:
– Only (standard) APIs are necessary, protocols are
vendors’ “value-added” feature, thus proprietary
– Only (standard) codings are necessary ... “just point
me to the data”, protocols are lower implementation
details
• What happens if protocols are not standardized?
– Each (proprietary) implementation develops its own
protocols to communicate across wide area networks
– Proprietary solutions produce “islands” of
interoperability
– Wide area, multi-vendor solutions become impossible
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
193
APIs, Codings, Protocols —
All Three Are Required [5/6]
- Std APIs may be implemented via
std or proprietary Protocols
- Std Protocols may be accessed
by std or proprietary APIs
- Both std APIs/Protocols improve
wide area interoperability
Semantics
Bindings: APIs
Requirements
Harmonized standardFunctionality
APIs, Codings,
and Protocols promote:
- Application portability
- Data portability Conceptual Model
- Multi-vendor, “open” solutions
Semantics
- Wide area, end-to-end
interoperability
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
Bindings: Protocols
- Std APIs may use std or
proprietary Codings
- Std Codings may be used
by std or proprietary APIs
- Both std APIs/Codings
improve portable apps/data
Bindings: Codings
- Std Protocols may use std or
proprietary Codings
- Std Codings may be exchanged
via std or proprietary Protocols
- Both std Protocols/Codings
improve system interoperability
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
194 
APIs, Codings, Protocols —
All Three Are Required [6/6]
• Common APIs:
– Application portability
– Separation of application and low-level implementation
• Common codings:
– Representation of information
– File/exchange formats, portable data
• Common protocols:
– Necessary for multi-vendor and wide area networking
– Internet relies on common protocols, not common APIs
• Common APIs, codings, protocols:
– All are necessary
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
195
1484.X: Codings vs. Encodings
• Codings: the structure and representation of
information
– Examples: XML, Tcl, tabbed, object-oriented, Java binding
• Encodings: the bit/byte representation and format
– Examples: ASCII, ISO 10646, IEEE floating point, UNIX x86
calling conventions
• Both coding and encoding example:
– “The name shall be coded in XML as
<NAME><FAMILY>…</FAMILY><GIVEN>…</GIVEN></NAME>
and
encoded in ASCII.”
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
196
1484.X Bindings: Mappings To
Other Standards Frameworks
• Bindings to APIs
• Bindings to codings
(information organization)
• Bindings to protocols
• Examples:
Requirements
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
– APIs: C/C++, Java, Perl
– Codings: XML, TCL
– Protocols: HTTP, DCTP
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
197
1484.X Encodings: Bit/Octet
Data Representation and Format
• Not to be confused with
“codings”
• Examples:
Requirements
– POSIX/Win32 subroutine
linkage
– UTF8
– IETF text format
Functionality
Conceptual Model
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
198
1484.X: Bindings -> Encodings
APIs -> Calling Conventions
Semantics
Language-Related
Other
Related Stds
Bindings: APIs
Requirements
Functionality
Conceptual Model
Language/Protocol
Related
OS-Related
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
Encodings:
Calling Conventions
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
199
1484.X: Bindings -> Encodings
Codings -> Data Formats
Semantics
Related Specs
Related Stds
Stds Activity
Bindings: Codings
Requirements
Functionality
Related Stds
Conceptual Model
Stds Activity
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
Encodings:
Data Formats
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
200
1484.X: Bindings -> Encodings
Protocols -> Communication Layers
Semantics
Related Stds/Specs
Stds/Specs
Stds Activity
Bindings: Protocols
Requirements
Functionality
Conceptual Model
Presentation Features
Octet Encodings
Semantics
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
Encodings: Various
Communication Layers
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
201
IEEE 1484.14: API and XML Bindings
IEEE 1484.X is: .2, .4, .6, .7, .8, .10., 11., 12., .17
IEEE 1484.X
Normative Wording
Requirements
IEEE 1484.X
Informative Wording
IEEE 1484.X,
IEEE 1484.14 XML
Functionality
IEEE 1484.X, 1484.14,
And Other Standards
IEEE 1484.X,
IEEE 1484.14 SDA
Normative Wording
Conceptual Model
IEEE 1484.14 SDA
Informative Wording
Semantics
IEEE 1484.15 DCTP,
IEEE 1484.16 HTTP
Various Standards
Bindings: APIs
Bindings: Codings
Bindings: Protocols
Encodings:
Calling Conventions
Encodings:
Data Formats
Encodings: Various
Communication Layers
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
202 
IEEE 1484.14:
APIs and XML Bindings
• Define APIs: C, C++, Java, JavaScript, Visual
Basic, Perl, Tcl
• Contributions from several organization
• Collaboration with many standards
organizations
• Related protocol work:
– IEEE 1484.15 DCTP (data/control transfer protocol)
– IEEE 1484.16 HTTP bindings
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
203
IEEE 1484.14:
Session Services, API Examples
• NewSession(): Opens a new session to repository
• DestroySession(): Closes repository
• OpenView(): Starts data access to a portion of the
repository
• CloseView(): Ends data access
• SetParam(), QueryParam(): Changes or retrieves
session parameters
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
204
IEEE 1484.14:
Handler Services, API Examples
• SetHandler(), QueryHandler(): Set up and inquire
about event handlers
• RequestSecurity(), RespondSecurity(): Allow
“server-side” authentication requests
• RequestNomad(), RespondNomad(): Can setup nomadic
(reconnectable) connections
• RequestEvent(), RespondEvent(): Used for handling
most exceptions and errors
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
205
IEEE 1484.14:
Data Perspective Services, API Examples
• SetNaming(), QueryNaming(): Set or inquire naming
convention
• SetCoding(), QueryCoding(): Sets data coding, i.e.,
organization of information
• SetView(), QueryView(): Set or inquire view
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
206
IEEE 1484.14:
Data Transfer/Walk Services, API Examples
• GetValue(), PutValue()
• GetDeepValue(), PutDeepValue()
• Copy(), DeepCopy()
• Move(), DeepMove()
• NewObject(), DeleteObject()
• WalkGetObject(), WalkPutObject()
• List(), DeepList()
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
207
IEEE 1484.15:
Data Interchange Protocols WG
•
•
•
•
Chair: Paul Siegel, Edutool.Com
Technical Editor: Frank Farance, Edutool.Com
URL: http://ltsc.ieee.org/wg15
Documents:
– “Data and Control Transfer Protocol”
http://edutool.com/dctp
– Status: expect submissions by 1999-12
– Summary: Protocols for high-volume, small-sized
transactions
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
208
IEEE 1484.15: Scope
• This standard will provide a common lightweight
protocol for exchanging data among clients, servers,
and peers.
• The standard addresses data exchange at a finer
granularity than HTTP and is intended to perform
better in a wide range of network infrastructures,
qualities of service, distributed systems, nomadic
systems, and security systems.
• The standard will define a protocol and semantics
that can easily be implemented in networking
applications and can easily be bound to APIs.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
209
IEEE 1484.15:
Data Interchange Protocols WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, assessment info, catalog
info, query
• Secondary design issues: evaluation, learner records, coach,
learning resources
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
210
IEEE 1484.15: Purpose
• A good number of protocols exist for exchanging
data, such as FTP, HTTP, CORBA. However, these
protocols don't perform well (e.g., HTTP is not good
for fine grain data), they don't have enough
semantics (e.g., FTP cannot get/put attributes,
properties, or metadata), or they are difficult to
interface to (e.g., CORBA cannot be conveniently
accessed in Perl or Tcl).
• A lightweight protocol that was easily implementable
and addressed the needs of learning technology
would have wide acceptance and integration within
many applications because protocols are one of the
key elements to portable, interoperable distributed
(distance) learning systems.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
211
IEEE 1484.15:
DCTP Example Messages
•
•
•
•
•
•
•
•
•
•
RESOLVE: connect to repository
OPEN: begin access to repository
GIVEAUTH, NEEDAUTH: authentication
NOMAD: nomadic (disconnected) access
CV: change view (directory)
GETVAL: get info from repository
PUTVAL: put info to repository
LIST: retrieve names in repository
CLOSE: end access to repository
UNRESOLVE: disconnect from repository
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
212
IEEE 1484.15:
Sample DCTP Transactions
• Attach to user “Côté”:
RESOLVE /home/C%e2t%dc
RESULT 1
OPEN 1 read-write
NEEDAUTH password
GIVEAUTH password hashed “asbkjed”
SET CODING XML
• Get personal info:
GETVAL name
RESULT <NAME><FAMILY>Côté</FAMILY>
<GIVEN>Joseph</GIVEN></NAME>
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
213
IEEE 1484.15:
Sample DCTP Transactions
• Read performance info for “session-01”:
LIST performance
math-02
physics-11
CV math-02
LIST
session-01
session-02
GETVAL session-01
RESULT <PERFORMANCE>
<DATE_TIME>19990102030405</DATE_TIME>
<METRIC>89</METRIC>
<CODING_SCHEME>numeric</CODING_SCHEME>
</PERFORMANCE>
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
214
IEEE 1484.15:
Sample DCTP Transactions
• Write performance info for new “session-03”:
LIST
session-01
session-02
NEW list session-03
PUTVAL session-03 <PERFORMANCE>
<DATE_TIME>19990809101112</DATE_TIME>
<METRIC>A+</METRIC>
<CODING_SCHEME>letter</CODING_SCHEME>
</PERFORMANCE>
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
215
IEEE 1484.16:
HTTP Bindings WG
•
•
•
•
Chair: Steve Griffin, IMS Project
Technical Editor: Not yet assigned
URL: http://ltsc.ieee.org/wg16
Documents:
– Various presentations, IMS work
– Status: expect submissions by 2000-03
– Summary: HTTP-tunneled interface for data
interchange
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
216
IEEE 1484.16: Scope
• This standard will provide common bindings to HTTP
for learning technology services.
• The standard will specify common URL suffixes (e.g.,
“cgi-bin” paths), HTTP commands, and/or HTTP
POST body contents that will correspond to common
learning technology services available through web
servers.
• The standard will include the semantic description,
syntax and encodings (in the case of post body
contents), and interface definition to these services,
and extension mechanisms to support future growth.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
217
IEEE 1484.16:
HTTP Bindings WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, assessment info, catalog
info, query
• Secondary design issues: evaluation, learner records, coach
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
218
IEEE 1484.16: Purpose
• Web browsers and servers are commonly available,
thus, the desire the leverage existing infrastructure.
• A common standard would allow the developers of
learning content, management systems, learner
profile systems, metadata systems, and supporting
services to access services via a common webbased interface.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
219
IEEE 1484.16: Why HTTP?
• Platform independent
• Programming model independent
• Works with firewalls and common firewall
configurations
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
220
IEEE 1484.16: Service Example
Student
Profile
Service
What is the
student’s name?
Content
Steve
You didn’t ask the
question in a way
that I understood?
For some reason, I
can’t answer your
question.
1999-12-08
• Service
Binding
Examples
–
–
–
–
–
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
RMI
DCOM
CORBA
FTP
HTTP
221 
IEEE 1484.16: Related Activities
• Standards and specification development
organizations:
– IEEE 1484.15 Data Interchange Protocol
– IMS API HTTP binding
– AICC HTTP Protocol
• Other similar efforts:
– As an ORB transport
•
•
•
•
WIDL (Java to HTTP binding)
DCOM HTTP tunneling
Other tunneling protocols
CORBA?
– Extension to HTTP
• WebDAV (from W3C)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
222
IEEE LTSC (P1484)
Mgmt. Systems and Applications Activities
•
•
•
•
IEEE 1484.11 Computer Managed Instruction **
IEEE 1484.18 Platform and Media Profiles
IEEE 1484.7 Tool/Agent Communication
IEEE 1484.8 Enterprise Interfaces
** Extended slide presentation for this WG
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
223
IEEE 1484.11:
Computer Managed Instruction (CMI) WG
•
•
•
•
Chair: Jack Hyde, FlightSafetyBoeing
Technical Editor: Kris Sundaram
URL: http://ltsc.ieee.org/wg11
Documents:
– AICC contributed AGR006 as base document
– Expect AICC to contribute AGR009
– “CMI Draft 1.8”
Status: Working Draft, 1998-09
– Summary: Learning management system interface
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
224
IEEE 1484.11:
Document Development
• Original contribution from AICC
• Improve technical areas:
– Multi-platform
– Longer technical horizon (>5 years)
– Better definition of “assertions” ==> better
conformance testing
• Improve process:
– Accredited standards process to formalize
specification
– IEEE LTSC will do maintenance/interpretation
phase
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
225
IEEE 1484.11:
Computer Managed Instruction (CMI) WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: performance info, assessment info, query,
catalog info (metadata), locator index (e.g., URLs), invocation of
learning content
• Secondary design issues: behavior, learner records, coach, learning
resources, learning content, delivery
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
226
IEEE 1484.11: CMI Separates Content
From Management Systems
•
•
•
•
Student
Performance
CMI System
Send
Send
Receive
CMI
Lesson
to
Lesson
CMI
CBT Lesson
1999-12-08
Instructor/Developer
to
Lesson
Records
Send
Lesson
Evaluation
Sets lesson parameters
Launches lessons
Records lessons’ results
Framework for organizing
content (assignable units)
• LAN and web-based
systems
• Collaboration with:
IEEE 1484.6 Course Sequencing
IEEE 1484.10 CBT Data
Interchange
IEEE 1484.12 Learning Objects
Metadata
IEEE 1484.14 APIs and XML
IEEE 1484.16 HTTP Bindings
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
227
IEEE 1484.18:
Platform Profiles and Media WG
•
•
•
•
Chair: Frank Farance, Edutool.Com
Technical Editor: Not yet assigned
URL: http://ltsc.ieee.org/wg18
Documents:
– Working group just formed
– Status: expect submissions by 2000-03
– Summary: Functional specification of browsers,
media, etc., via standards profiles
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
228
IEEE 1484.18: Scope
• This standard profile will identify existing standards
and specifications of learning technology platforms
and their content.
• Several standards profiles will be developed for
several operating scenarios, such as "browser
platform", "workstation platform", "web media types".
• The standard profile will not specify the technical
details, but limitations and enhancements to these
standards and specifications.
• It is expected that these profiles will be updated and
amended often enough to track current technology.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
229
IEEE 1484.18:
Platform Profiles WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: delivery, learning content, locator index
(e.g., URLs), multimedia, learner entity, behavior, learner entity
• Secondary design issues: learning preferences, evaluation, coach,
query, catalog info (metadata), learning resources
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
230
IEEE 1484.18 Purpose
• Many systems require compatibility for common suite of
features such as browsers, operating systems, and content.
• A standard profile would specify functionality (e.g., Java 1.1,
JPEF, GIF-89, C95, ...) rather than implementations (e.g.,
Netscape 4.0, Windows 95, Adobe PDF plug-in).
• A specification based on functionality allows consumers and
vendors a wider range of implementations that are
conforming.
• Since many standards and specifications may be implied by
compatibility, a standard profile would allow consumers and
vendors to point to a single document that references the
collection of features.
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
231
IEEE 1484.7:
Tool/Agent Communication WG
• Chair: Randy Saunders, Raytheon Learning
Institute
• Technical Editor: To be assigned
• URL: http://ltsc.ieee.org/wg7
• Documents:
– Tool/Agent Communication, 1997-10-16
http://ltsc.ieee.org/ltscdocs/wg7/tooltutorspec.html
– Status: Base Document, 1997-09
– Summary: Common interactions among tools,
agents, and portable interfaces
– Target: Not yet planned
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
232
IEEE 1484.7:
Problem Statement
• How can tools communicate in a vendor-independent
way?
• How can applications (agents) access tool so custom
software can be integrated with COTS (commercial
off-the-shelf) tools?
• Component integration is key: significantly lowers
development cost for learning content, tools, and
systems
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
233
IEEE 1484.7:
Tool/Agent Communication WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: coach, behavior, evaluation, assessment
info, performance info, learner records, query, catalog info
(metadata), locator index (e.g., URLs)
• Secondary design issues: query, catalog info (metadata), learning
resources, delivery
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
234
IEEE 1484.7:
Configuration Example
• Example: CMU Equation
Solving Tutor (EST) must
communicate with other
tools, e.g., spreadsheets
• Technical requirements:
communication among tools
and their agents; vendor
independence
• Techniques: scripting
languages, simulation
protocols (e.g., DoD DMSO
HLA)
Tool/Agent Messages
Agent 1
1999-12-08
Agent 2
Tool
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
235
IEEE 1484.8:
Enterprise Interfaces WG
•
•
•
•
Chair: Thor Anderson, IMS Project
Technical Editor: To Be Assigned
URL: http://ltsc.ieee.org/wg8
Documents:
– None
– Status: Forming, PAR not yet approved
– Summary: Interfaces for back office systems
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
236
IEEE 1484.8:
Enterprise Interfaces WG
Learner
Entity
Multimedia
Delivery
Behavior
Interaction Context
Evaluation
Learning
Preferences
Learning Locator
Content
Catalog Info
Learning
Resources
Query
Coach
(history)
Performance/
Preferences
(new)
Performance
(current)
Learner
Records
• Primary design issues: learning preferences, performance info,
learner records
• Secondary design issues: learner entity, coach
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
237
IEEE 1484.8:
Information Sources/Relations
• Information about people and organizations:
–
–
–
–
–
–
Personal demographic/address data
Personal security/email directory data
Groups
Organization demographic and address data
Education/training registration
Degrees, certificates, competencies
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
238
IEEE 1484.8:
Information Source/Relations
• Information about classes (or learning unit):
– Class and component descriptions; other
information
– Class scheduling
– Linking teachers to classes
• Relationship between learners and classes:
–
–
–
–
–
Class enrollment
Attendance tracking
Completion/results of course components
Class completion/grading
Class work groups
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
239
IEEE 1484.8: Sample Applications
• Human resource systems: tracks skills and
competencies and define eligibility for training
programs
• Student administration systems: supports course
catalog management, class scheduling, academic
program registration, class enrollment, attendance
tracking, grade book, grading, etc.
• E-mail, security, directory services: tracks IDs,
passwords, E-mail addresses, and other learner
information across an entire organization
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
240
For Further Information
• IEEE LTSC (P1484) web site:
http://ltsc.ieee.org
Check web site for papers, meetings, minutes, etc.
• Chair: Jim Schoening, US Army (CECOM)
+1 732 532 0118, Schoenin@mail1.monmouth.army.mil
• Vice Chair: Frank Farance, Edutool.Com
+1 212 486 4700, frank@farance.com
• Secretary: Debbie Brown, Mississippi State University
+1 601 325 9397, debbie@erc.msstate.edu
• Administrator: Kris Sundaram, sundram@hotmail.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
241
For Further Information
• LTSC General Mailing List
– Send one line to “listserv@listserv.readadp.com”:
subscribe P1484 FirstName LastName
– E-Mail Reflector: p1484@listserv.readadp.com
• 1484.1, Architecture and Reference Model
– Mike Collett, Education Online
mike@collett.demon.co.uk
– Send one line to “listserv@listserv.readadp.com”:
subscribe ARCH-RM FirstName LastName
– E-Mail Reflector: arch-rm@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
242
For Further Information
• 1484.2, Learner Model
– John Tyler, MITRE Corp.
jtyler@mitre.org
– Send one line to “listserv@listserv.readadp.com”:
subscribe LEARNER-MODEL FirstName LastName
– E-Mail Reflector: learner-model@listserv.readadp.com
• 1484.3, Glossary
– Katherine Sinitsa, IRTC ITS UNESCO/IIP
kath@umod.kiev.ua
– Send one line to “listserv@listserv.readadp.com”:
subscribe GLOSSARY FirstName LastName
– E-Mail Reflector: glossary@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
243
For Further Information
• 1484.4, Task Model
– Tom Probert, US Dept. of Labor
probert@ecii.org
– Send one line to “listserv@listserv.readadp.com”:
subscribe TASK-MODEL FirstName LastName
– E-Mail Reflector: task-model@listserv.readadp.com
• 1484.5, User Interfaces
– Ian Wright, Vega UK
ian.wright@ibm.net
– Send one line to “listserv@listserv.readadp.com”:
subscribe USER-INTERFACES FirstName LastName
– E-Mail Reflector: user-interfaces@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
244
For Further Information
• 1484.6, Course Sequencing
– Jim Schoening, US Army (CECOM)
Schoenin@mail1.monmouth.army.mil
– Send one line to “listserv@listserv.readadp.com”:
subscribe COURSE-SEQUENCING FirstName LastName
– E-Mail Reflector: course-sequencing@listserv.readadp.com
• 1484.7, Tool/Agent Communication
– Randy Saunders, Raytheon Learning Institute
RSaunders@HTI.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe TOOL-AGENT FirstName LastName
– E-Mail Reflector: tool-agent@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
245
For Further Information
• 1484.8, Enterprise Interfaces
– Thor Anderson, IMS Project
tanderson@imsproject.org
– Send one line to “listserv@listserv.readadp.com”:
subscribe ENTERPRISE FirstName LastName
– E-Mail Reflector: enterprise@listserv.readadp.com
• 1484.9, Localization
– Erik Duval, Katholieke Universiteit Leuven
erik.duval@cs.kuleuven.ac.be
– Send one line to “listserv@listserv.readadp.com”:
subscribe LOCALIZATION FirstName LastName
– E-Mail Reflector: localization@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
246
For Further Information
• 1484.10, CBT Data Interchange
– Bill McDonald, FlightSafetyBoeing
william.a.mcdonald@boeing.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe CBTINTER FirstName LastName
– E-Mail Reflector: cbtinter@listserv.readadp.com
• 1484.11, Computer Managed Instruction
– Jack Hyde, FlightSafetyBoeing
jackie.q.hyde@boeing.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe CMI FirstName LastName
– E-Mail Reflector: cmi@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
247
For Further Information
• 1484.12, Learning Objects Metadata
– Wayne Hodgins, Autodesk Inc.
wayne.hodgins@autodesk.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe LEARNING-OBJECTS FirstName LastName
– E-Mail Reflector: learning-objects@listserv.readadp.com
• 1484.13, Student Identifiers
– Mike Collett, Education Online
mike@collett.demon.co.uk
– Send one line to “listserv@listserv.readadp.com”:
subscribe STUDENT-IDENTIFIER FirstName LastName
– E-Mail Reflector:
student-identifier@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
248
For Further Information
• 1484.14, Semantics and Exchanges Bindings
– Tyde Richards, Macromedia
trichards@macromedia.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe SXB FirstName LastName
– E-Mail Reflector: sxb@listserv.readadp.com
• 1484.15, Data Interchange Protocols
– Paul Siegel, Edutool.Com
siegel@farance.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe PROTOCOLS FirstName LastName
– E-Mail Reflector: protocols@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
249
For Further Information
• 1484.16, HTTP Bindings
– Steve Griffin, IMS Project
sgriffin@collegis.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe HTTP-BINDINGS FirstName LastName
– E-Mail Reflector: http-bindings@listserv.readadp.com
• 1484.17, Content Packaging
– Mike Fore, US Army (ATSC)
forem@atsc.army.mil
– Send one line to “listserv@listserv.readadp.com”:
subscribe CONTENT-PACKAGING FirstName LastName
– E-Mail Reflector: content-packaging@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
250
For Further Information
• 1484.18, Platform and Media Profiles
– Frank Farance, Edutool.Com
frank@farance.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe PROFILES FirstName LastName
– E-Mail Reflector: profiles@listserv.readadp.com
• 1484.19, Quality Systems for Life-Long Learning
– Jim Schoening, US Army (CECOM)
Schoenin@mail1.monmouth.army.mil
– Send one line to “listserv@listserv.readadp.com”:
subscribe QUALITY-LLL FirstName LastName
– E-Mail Reflector: quality-lll@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
251
For Further Information
• 1484.20, Competency Definitions
– Claude Ostyn, Click2Learn.com
claude.ostyn@click2learn.com
– Send one line to “listserv@listserv.readadp.com”:
subscribe COMPETENCY-DEFINITIONS FirstName LastName
– E-Mail Reflector:
competency-definitions@listserv.readadp.com
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
252
Future LTSC (Quarterly) Meeting Schedule
1999-12-06 / 1999-12-10, Washington, DC, USA
2000-03-13 / 2000-03-17, London, UK
Co-Located with JTC1/SC36
2000-06-21 / 2000-06-26 (ex. Sunday), Montreal, QC, Canada
Overlap with/adjacent to Ed-Media and ITS conferences
Plenary on Monday — Workshop with Ed-Media
2000-09-20 / 2000-09-25 (ex. Sunday), Albuquerque, NM, USA
Co-Located with JTC1/SC36
AICC meets in same location during following week
overlap on Monday (1484.6, 1484.7, 1484.10, 1484.11)
2000-12-04 / 2000-12-08, Southern Europe (Italy or Greece)
2001-03-19 / 2001-03-23, West Coast, US
2001-09, Europe (Greece or Italy — opposite of 2000-12 mtg)
1999-12-08
IEEE LTSC Work Program/Process, F. Farance
©1999 Edutool.Com
253