11.4.1 Shared Vocabularies in Learning Engineering

The vocabulary of learning engineering is contested because the field draws on multiple disciplines that each developed their own terminology independently. Achieving terminological alignment across cognitive science, instructional design, software engineering, and data science is an ongoing professional project — not a solved problem.

Core Contested Terms

"Learning engineering" itself has been defined differently by different communities. Herbert A. Simon's 1967 usage emphasized applying scientific knowledge to teaching as an engineering discipline. [LE-LS-GL-001] Contemporary ICICLE usage frames LE as an iterative, evidence-based problem-solving process — a "verb," not a job title or technology category. [LE-LS-CO-001] The Journal of Learning Engineering's "Learning Engineering Primer" documents these definitional tensions and proposes operational definitions for community use. [LE-LS-JO-006]

"Adaptive learning" is used by ITS researchers (adaptive to knowledge state), commercial vendors (adaptive to learning style), and platform engineers (adaptive to completion data) with almost no overlap. IEEE P2247's taxonomy of adaptive instructional system components provides the most rigorous attempt at standardization. [LE-LS-SG-003]

"Assessment" spans formative feedback embedded in practice items, summative end-of-unit tests, competency-based credentials, and psychometric instruments — each with different technical requirements and validity standards.

Standardization Efforts

IEEE LTSC standards provide vocabulary anchors for key technical domains: xAPI (IEEE 9274) defines the vocabulary for learning experience statements — verb IDs, activity types, and context extensions — enabling consistent cross-platform data interpretation. [LE-LS-SG-002] IEEE 1484.20.2 defines the vocabulary for competency representation — enabling practitioners to specify what learners should be able to do in machine-readable, interoperable terms. [LE-LS-SG-004]

Practical Implication

When starting a new LE project, experienced practitioners establish a shared vocabulary glossary in the first design sprint — defining key terms for the specific team context and noting where definitions diverge from disciplinary norms. The Learning Engineering Toolkit recommends this as standard practice for cross-functional LE teams. [LE-LS-GL-007]

From the Learning Engineering Toolkit

The Toolkit presents shared vocabulary as both a human and a technical need. Chapter 10 (Tools for Teaming) treats it as a team skill: because a learning engineering team gathers specialists from several fields, people collaborate better when each has at least a working familiarity with the ideas and terms the other specialties use — a developer picking up the language of learning scientists, say, or an instructional designer appreciating what analytics can surface. [LET-10] The chapter argues that this common terminology lets everyone on the team collaborate more productively. [LET-10]

Chapter 14 (Software and Technology Standards as Tools) carries the same principle over to machines. It describes standards as formally published documents that record agreed conventions for data and software — how things are structured, defined, transmitted, tagged, and used — and argues that choosing them over bespoke or proprietary approaches raises interoperability so solutions can grow. [LET-14] One central device is the controlled vocabulary: a fixed, sanctioned set of terms that constrains and clarifies which tags are permitted. [LET-14] The chapter also identifies a dedicated layer in the interoperability stack for data dictionaries — standards that fix the meaning and permitted values of individual data elements. [LET-14]

The chapter illustrates how common vocabularies let separate systems understand one another. Connecting a course to an openly published linked dataset — the US Department of Labor's O*NET, for instance — lets a team draw on ready-made catalogs of tasks, skills, and knowledge instead of building their own, and labeling modules with agreed competency identifiers makes curricula easier to compare or combine. [LET-14] Yet no lone standard delivers interoperability; it requires several coordinated layers, frequently maintained by different bodies such as the IEEE Learning Technology Standards Committee and the World Wide Web Consortium. [LET-14] Design patterns, the chapter notes, serve a parallel role by giving teams a common language and mutual understanding. [LET-14] Between them, the two chapters describe shared vocabulary working on two planes at once — among the people staffing a team and among the systems those people construct. [LET-10], [LET-14]