Семантика — смысл знаков и данных

НЕ ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Архитектору Аналитику Инженеру

Семантика (от греч. semantikos — "знаковый", "смысловой") — часть лингвистики и логики, которая изучает смысл знаков, слов и высказываний. В IT то же слово используют шире: речь идёт о том, что означают данные, команды языка, поля в JSON или методы HTTP.

Слово "семантика" в чате разработчиков может означать три разные вещи. Ниже — как их различать и куда идти дальше: представление знаний, онтология, концептуальные схемы, семантический веб. Общий контекст — статья "Семантика" в Википедии. Раздел Мыслительная база связывает эти темы с графами, логикой и теорией информации.

---

Синтаксис и семантика — два слоя понимания

Синтаксис отвечает на вопрос как устроена форма — правила записи, по которым текст или файл считается корректным.

Семантика отвечает на вопрос что это значит — какой смысл несёт запись в конкретном контексте.

	Синтаксис	Семантика
Вопрос	Правильно ли написано?	Правильно ли понято?
Пример	В JSON есть {, }, кавычки у ключей	Поле "status": "active" — заказ открыт или пользователь активен?
Кто проверяет	Парсер, линтер, валидатор схемы	Люди, бизнес-правила, модель данных
Типичная ошибка	Пропущена запятая	Сумма в рублях прочитана как копейки

Файл может быть синтаксически верным и при этом бессмысленным для бизнеса. Типы в API совпали, а слово "клиент" в одном сервисе означает физическое лицо, в другом — юридическое. Компилятор поймает пропущенную скобку; согласовать смысл полей между командами помогают метаданные, концептуальные схемы и онтологии.

Аналогия из повседневной жизни

Представьте адрес на конверте.

• Синтаксис — почтовый индекс из шести цифр, улица написана кириллицей, есть номер дома. Форма соблюдена.
• Семантика — это действительно существующий адрес? Квартира 42 есть в этом подъезде? Получатель — человек или организация?

Почтовая служба сначала проверяет, что конверт оформлен по правилам. Доставка зависит от того, куда и кому адресовано письмо. В программах порядок похожий: сначала парсинг, затем интерпретация.

// Синтаксис — скобки и запятые на месте
если (x > 0) то вернуть x иначе вернуть 0

// Семантика — что такое x?
// метры, рубли, идентификатор пользователя?
// Без договорённости код формально корректен, но результат непредсказуем

Цепочка обработки в формальных языках

В формальных языках и компиляторах цепочка обычно такая:

Этап	Что делает	Пример ошибки
Лексер	Делит поток символов на токены (слова языка)	@ вместо буквы в идентификаторе
Парсер	Проверяет, что токены складываются в допустимые конструкции	если (x > 0 без закрывающей скобки
Семантический анализ	Проверяет смысл в рамках языка	сложение строки и числа без приведения типов
Генерация	Строит исполняемое представление	оптимизации, раскладка по регистрам

Подробнее о семантике языков программирования — в глоссарии и в статье Что такое код.

---

Синтаксис и семантика на примерах JSON

JSON (JavaScript Object Notation — текстовый формат обмена данными) часто используют в REST API. Разберём один и тот же документ с двух сторон.

Синтаксически корректный JSON

{
  "order_id": 1042,
  "status": "active",
  "amount": 15000,
  "customer": {
    "id": "usr-7",
    "email": "alice@example.com"
  }
}

Парсер JSON.parse (или аналог в другом языке) примет документ: фигурные скобки сбалансированы, ключи в кавычках, числа и строки записаны по правилам.

Синтаксические ошибки

{
  order_id: 1042,
  "status": 'active',
}

Типичные нарушения:

• ключ order_id без кавычек (в строгом JSON кавычки обязательны);
• одинарные кавычки у строки (в JSON — только двойные);
• лишняя запятая после последнего поля (в строгом JSON недопустима).

Такой текст не разберётся парсером. Ошибка видна сразу.

Семантические вопросы к тому же корректному JSON

Даже при валидном синтаксисе остаются вопросы без контракта:

Поле	Синтаксический тип	Семантический вопрос
amount	число	рубли, копейки, доллары? до или после НДС?
status	строка	заказ активен или пользователь активен?
customer.id	строка	внутренний ID, UUID, email?
active	строковое значение	полный список допустимых статусов?

JSON Schema (схема для описания структуры JSON) фиксирует часть семантики на уровне типов и ограничений:

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["order_id", "status", "amount"],
  "properties": {
    "order_id": { "type": "integer", "minimum": 1 },
    "status": {
      "type": "string",
      "enum": ["draft", "paid", "shipped", "cancelled"]
    },
    "amount": {
      "type": "integer",
      "description": "Сумма в копейках, целое число, без дробной части"
    }
  }
}

Поле description и enum — мост от синтаксиса к смыслу. Полное согласование домена — в глоссарии, онтологии и тексте OpenAPI.

Практический приём для команд

При ревью JSON-контракта задавайте два списка вопросов:

Синтаксис и схема

• проходит ли документ через валидатор?
• все обязательные поля перечислены в required?
• типы совпадают с потребителями?

Семантика

• единицы измерения явно указаны?
• перечисления статусов совпадают с БД?
• имена полей согласованы с единым языком домена?

---

Синтаксис и семантика в SQL

SQL (Structured Query Language — язык структурированных запросов) тоже разделяет форму и смысл.

Синтаксически верный запрос

SELECT customer_id, SUM(amount) AS total
FROM orders
WHERE status = 'active'
GROUP BY customer_id
HAVING SUM(amount) > 10000;

СУБД (система управления базами данных) примет запрос, если имена таблиц и столбцов существуют в каталоге.

Семантика имён и значений

Элемент	Синтаксис	Семантика
status = 'active'	сравнение строки со строкой	что считается "активным" заказом в этом продукте?
amount	числовой столбец	валюта, копейки, налог включён?
customer_id	внешний ключ	тот же идентификатор, что в CRM?

Два отчёта с одинаковым SQL по форме могут давать разные цифры, если справочник статусов или правила агрегации разошлись между командами. Концептуальная схема и реляционная алгебра помогают формализовать смысл до уровня таблиц.

Пример семантической ловушки

-- Отчёт A
SELECT COUNT(*) FROM users WHERE status = 1;

-- Отчёт B
SELECT COUNT(*) FROM users WHERE status = 'active';

Оба запроса синтаксически корректны. Если в справочнике 1 означает "заблокирован", а строка 'active' — другое состояние, цифры в отчётах несопоставимы, хотя слово "активные пользователи" в заголовке одно и то же.

Решение на уровне семантики:

• единый справочник статусов в метаданных;
• явные имена вроде account_state вместо размытого status;
• документированные инварианты в представлении знаний.

---

Синтаксис и семантика в коде

Языки программирования задают синтаксис грамматикой и статическую семантику системой типов.

Пример на псевдокоде

функция скидка(сумма: Деньги, клиент: Клиент) -> Деньги
    если клиент.уровень = "gold" то
        вернуть сумма * 0.9
    иначе
        вернуть сумма

Синтаксис — ключевые слова, скобки, типы в аннотациях.

Семантика — что такое Деньги (рубли с копейками или decimal?), что означает gold, можно ли применять скидку к уже уценённой позиции.

Ошибки двух уровней

Уровень	Пример	Кто ловит
Синтаксис	если x > 0 без то	компилятор, интерпретатор
Статическая семантика	x + "текст" для чисел	проверка типов
Динамическая семантика	деление на ноль в рантайме	тесты, мониторинг
Доменная семантика	скидка 110%	бизнес-правила, код-ревью

Связь с ООП: класс Order в коде — синтаксическая конструкция языка; соглашение, что Order.total всегда в копейках — доменная семантика, которую команда несёт в DDD.

---

Синтаксис и семантика в HTTP

HTTP (HyperText Transfer Protocol — протокол передачи гипертекста) разделяет форму сообщения и смысл операции.

Форма запроса

DELETE /api/users/usr-7 HTTP/1.1
Host: shop.example.com
Authorization: Bearer eyJhbGciOi...

Синтаксически корректны: метод, путь, версия протокола, заголовки.

Семантика метода и ресурса

Метод	Синтаксическая роль	Семантическая роль
GET	запрос с телом допустим, но редок	безопасное чтение, без изменения состояния
POST	тело часто присутствует	создание или команда с побочным эффектом
PUT	полная замена ресурса по URI	идемпотентная замена
DELETE	удаление по URI	ресурс исчезает или помечается удалённым

Один и тот же путь /api/users/usr-7 с методами GET и DELETE выглядит похоже, но означает разное. Подробнее — методы и статус-коды.

Статус-коды — синтаксис ответа и смысл для клиента

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"error": "status transition not allowed"}

• Синтаксис — код 422, заголовки, тело JSON валидно.
• Семантика — клиент понял запрос, сервер отклонил смысл данных (бизнес-правило), а не грамматику JSON. См. статус-коды.

Семантика доставки (третий уровень)

Отдельно от смысла поля order обсуждают гарантии повторной доставки сообщения:

• at-least-once — сообщение придёт минимум один раз, возможны дубликаты;
• exactly-once — ровно один раз (дорого, часто приближение);
• идемпотентность — повторный вызов даёт тот же эффект.

Hub-статья — Идемпотентность и семантика доставки. В код-ревью полезно уточнять: речь о смысле поля в домене или о гарантиях интеграции?

---

Три уровня слова "семантика" в IT

В разговоре полезно уточнять, о каком уровне идёт речь. Три уровня пересекаются, но отвечают на разные вопросы.

Уровень	Главный вопрос	Типичные артефакты	Соседние статьи
Предметная область	Что означают сущности?	глоссарий, ER, онтология	327, 328, 329
Язык и протокол	Что делает конструкция?	спецификация языка, RFC	38, HTTP
Операция и доставка	Что будет при повторе?	контракт очереди, idempotency key	133

Уровень 1 — семантика предметной области

Здесь речь о смысле сущностей и связей в модели бизнеса.

Вопросы этого уровня

• Кого называем "пользователем" — человека, аккаунт или организацию?
• Какие значения допустимы у статуса "активный"?
• Какие отношения между сущностями считаются реальными?

Инструменты

• Метаданные — описание конкретного ресурса;
• Концептуальные схемы — карта сущностей до таблиц;
• Онтологии — формальные классы и аксиомы;
• Представление знаний — правила и графы понятий.

Типичная ошибка

Два микросервиса используют поле amount, но один хранит копейки, другой — рубли. JSON в обоих случаях валиден; смысл поля разный.

Мини-кейс — поле client

Сервис "Корзина":  client = session_id посетителя
Сервис "Биллинг":  client = юрлицо с ИНН
Сервис "Отчёты":   JOIN по полю client без уточнения

Синтаксически все сервисы обмениваются JSON. Семантически client — три разных понятия. Лечение — развести имена (visitor_session, legal_entity) и зафиксировать в онтологии.

Уровень 2 — семантика языка, разметки и протокола

Здесь фиксируют правила интерпретации конструкций независимо от конкретного магазина или банка.

Примеры

• Что делает оператор if или ключевое слово async в конкретном языке.
• Чем отличаются HTTP-методы GET и DELETE при одинаковом виде запроса.
• Какой HTML-тег обозначает навигацию, а какой — основной контент (семантика и доступность в CSS).

Синтаксис HTML — теги и атрибуты. Семантика — роли элементов для браузера, поисковика и скринридера.

Таблица — конструкции и их смысл

Технология	Синтаксис	Семантика
JavaScript	=== и ==	строгое и нестрогое сравнение
CSS	display: flex	модель раскладки flexbox
HTML	<nav>, <main>	ориентиры для доступности
HTTP	Cache-Control	правила кэширования
SQL	LEFT JOIN	сохранение строк левой таблицы

Спецификации (ECMAScript, WHATWG HTML, RFC для HTTP) — договор о смысле на этом уровне.

Уровень 3 — семантика операции и доставки

Здесь описывают гарантии поведения при повторе вызова или сбое сети.

Ключевые понятия

• At-least-once — сообщение доставят хотя бы один раз, возможны дубликаты.
• At-most-once — дубликатов нет, возможна потеря.
• Идемпотентность — повторный вызов даёт тот же эффект, что и первый.

Пример

POST /payments  без ключа идемпотентности
  → два клика пользователя → два списания

POST /payments  с заголовком Idempotency-Key: uuid-...
  → повтор с тем же ключом → один платёж

Поведение операции при сбоях описывают отдельно от значения слова "заказ" в базе данных. Оба слоя нужны в событийных архитектурах.

---

Шеннон, информация и смысл

Теория информации (Клод Шеннон, 1948) измеряет данные количественно — энтропия, сжатие, пропускная способность канала — без привязки к смыслу.

Что измеряет Шеннон

Понятие	Смысл в теории Шеннона	Пример
Бит	единица неопределённости	монета: 1 бит
Энтропия	среднее число бит на символ	сжатие текста
Канал	пропускная способность	мегабит в секунду

Один и тот же набор битов может быть фотографией, логом или шифротекстом; теория информации не различает эти случаи по содержанию.

Что добавляет семантика

Семантика отвечает на другие вопросы:

• Назначение — для чего эти данные существуют?
• Как сопоставить их с объектами в мире или в другой системе?
• Какие правила интерпретации обязательны?

Аналогия

Передача по радио цифр 15000 — вопрос Шеннона: сколько бит нужно, надёжен ли канал.

Вопрос семантики: это цена в копейках, высота в миллиметрах или номер заказа?

Обе дисциплины нужны в данных: Шеннон — для сетей и хранения; семантика — для интеграций и аналитики.

Способы зафиксировать смысл (от простого к сложному)

Уровень	Что фиксирует	Пример
Комментарий в коде	локальная договорённость	amount_kopecks
Метаданные	описание конкретного файла или ресурса	автор, дата, теги
Словарь или справочник	допустимые значения поля в одной БД	status IN (...)
Концептуальная схема	сущности и связи домена	ER-диаграмма
Онтология	классы, свойства, отношения, аксиомы	OWL-модель
Граф знаний	факты в сети с URI	RDF

Метаданные похожи на этикетку на коробке. Онтология — на общий каталог складов: одни и те же названия полок во всех зданиях. Переход от этикетки к каталогу — тема представления знаний.

---

Семантический анализ

Семантический анализ — извлечение или проверка смысла из текста, кода или данных.

Семантический анализ в компиляторе

После успешного парсинга компилятор строит абстрактное синтаксическое дерево (AST) и проверяет:

• совместимость типов;
• объявлены ли используемые имена;
• допустимы ли вызовы методов для данного класса.

// Псевдокод на русском
пусть x: целое = "привет"   // ошибка семантики типов

пусть y: целое = 5
пусть z = y + true          // ошибка: сложение числа и логического

Такие ошибки синтаксически допустимы (скобки на месте), но семантически запрещены. См. формальные языки и выполнение кода.

Семантический анализ в NLP

NLP (Natural Language Processing — обработка естественного языка) извлекает смысл из текста людей:

• именованные сущности (имена, организации, даты);
• отношения ("Алиса работает в Acme");
• тональность отзыва;
• тематическая классификация.

Современные модели — трансформеры и NLP. Они угадывают смысл по статистике; для юридически значимых полей нужны явные схемы из представления знаний и онтологий.

Сравнение подходов

Подход	Сильная сторона	Слабая сторона
Правила и онтологии	объяснимость, аудит	ручная поддержка
Статистический NLP	гибкость на свободном тексте	ошибки на редких доменах
Гибрид	RAG + граф знаний	сложность внедрения

Семантический анализ в интеграциях

При стыковке систем выполняют mapping (сопоставление полей):

CRM.customer_ref     →  ERP.party_id
CRM.email            →  ERP.contact_email
CRM.status_code      →  ERP.lifecycle_state  (таблица соответствия)

Инструменты:

• ETL-пайплайны и интеграции;
• валидаторы JSON Schema на входе API;
• ответ 422 Unprocessable Content, когда JSON синтаксически верен, но значения нарушают бизнес-правила.

Модель или парсер могут распознать формат даты 2026-06-15, но не знают ваших правил скидок без явной схемы и глоссария. Автоматика работает вместе с договорённостями людей.

Конвейер проверки входящего API-запроса

---

Кейс-стади — несовпадение единиц измерения

Ситуация

Интернет-магазин вырос: появились сервис каталога, сервис заказов, сервис аналитики. Все обмениваются JSON. Поле line_total везде тип number.

Хронология

Команда	Договорённость "устно"	Факт в коде
Каталог	цены в рублях	price: 199.99
Заказы	суммы в копейках	line_total: 19999
Аналитика	"как пришло"	SUM(line_total)

Симптом

Отчёт показывает выручку в 100 раз выше реальности. JSON везде валиден. Ошибка семантическая.

Разбор по уровням

Уровень	Что пошло не так
Синтаксис	нарушений нет
Схема типов	везде number
Домен	разные единицы у одного имени
Операции	агрегация без нормализации

Решение

1. Переименовать поля: price_rub_decimal, line_total_kopecks.
2. Добавить в OpenAPI description и примеры.
3. Ввести тип-обёртку в коде (MoneyKopecks, MoneyRub).
4. Зафиксировать в концептуальной схеме и глоссарии.
5. Тест-контракт между сервисами на граничных значениях.

Урок: одинаковое имя + одинаковый тип ещё не гарантируют одинаковый смысл.

---

Кейс-стади — поле status

Ситуация

В таблице orders есть столбец status. Его используют фронтенд, бэкенд, отчёты и внешний склад.

Расхождения

Система	Значение active	Значение closed
Фронтенд	заказ в работе	доставлен
Склад	комплектуется	отгружен
Бухгалтерия	не используется	оплачен и закрыт
CRM	лид в воронке	сделка проиграна

Почему синтаксис не спасает

SELECT * FROM orders WHERE status = 'active';

Запрос корректен. Смысл active четыре разных.

Решение — семантическая нормализация

Шаг 1. Разделить понятия:

• order_fulfillment_state — логистика;
• payment_state — оплата;
• crm_deal_stage — продажи.

Шаг 2. Справочники с явными кодами и метаданными.

Шаг 3. Диаграмма переходов состояний (state machine) с подписанными событиями.

Шаг 4. Правила в представлении знаний:

ЕСЛИ fulfillment_state = "shipped"
   И payment_state = "captured"
ТО можно выставить бухгалтерский документ

Шаг 5. Версионирование API при добавлении нового статуса — см. раздел о версионировании.

---

Контракты API и семантика

API (Application Programming Interface — интерфейс прикладного программирования) — договор между системами. OpenAPI описывает пути, параметры и схемы.

Слои контракта

Слой	Что фиксирует	Инструмент
Транспорт	HTTP, TLS, кодировка	RFC, инфраструктура
Синтаксис	формат JSON, XML	парсер
Структура	поля, типы, обязательность	JSON Schema, OpenAPI
Семантика	единицы, инварианты, жизненный цикл	описания, глоссарий, примеры
Поведение	идемпотентность, порядок событий	документация, тесты

Пример фрагмента OpenAPI с семантикой

components:
  schemas:
    MoneyKopecks:
      type: integer
      description: >
        Сумма в копейках. Целое неотрицательное число.
        19999 означает 199 руб 99 коп. НДС включён.
      minimum: 0
      example: 19999
    OrderStatus:
      type: string
      enum: [draft, paid, packed, shipped, cancelled]
      description: >
        Состояние исполнения заказа. Не путать с payment_status.

Consumer-driven contracts

Команда-потребитель пишет тест: "мы ожидаем, что amount — копейки". CI проверяет поставщика. Так семантика становится проверяемой, а не только текстом в Wiki.

Связанные темы: интеграционное взаимодействие, тестирование.

---

Единый язык, DDD и глоссарий

DDD (Domain-Driven Design — предметно-ориентированное проектирование) вводит единый язык (ubiquitous language): одни и те же термины в разговоре с бизнесом, в коде и в документации. См. методологию и жизненный цикл.

Как выглядит единый язык

Термин в бизнесе	Класс в коде	Таблица в БД	Поле в API
Заказ	Order	orders	order
Покупатель	Customer	customers	customer
Строка заказа	OrderLine	order_lines	lines[]

Запрещены "синонимы без причины": client, user, buyer для одной сущности без явного различия в онтологии.

Ограниченный контекст

В DDD bounded context (ограниченный контекст) — граница, внутри которой термин однозначен. Слово "клиент" в контексте Продаж и Поддержки может означать разное, но внутри каждого контекста — одно.

Между контекстами — явный mapping, как в семантическом вебе.

Глоссарий команды

Короткие определения для фронта, бэка и аналитики:

Термин	Определение	Не путать с
Активный заказ	оплачен и не отменён	активный пользователь
Сумма заказа	копейки, НДС включён	цена в каталоге

Хранить в базе знаний. Связь с представлением знаний — правила и онтологии машиночитаемого глоссария.

---

Версионирование и эволюция смысла

Смена смысла при том же имени поля ломает интеграции сильнее, чем смена формата скобок.

Типы изменений

Изменение	Пример	Риск
Синтаксическое	XML → JSON	средний, видно сразу
Структурное	разбить name на first/last	высокий без версии
Семантическое	amount рубли → копейки	критический, тихий

Стратегии

Версия в пути

GET /api/v2/orders/1042

Версия в заголовке

Accept: application/vnd.shop.orders.v2+json

Параллельные поля на переходный период

{
  "amount": 199.99,
  "amount_kopecks": 19999,
  "amount_deprecated": true
}

События с версией схемы

{
  "event": "order.paid",
  "schema_version": 3,
  "payload": { ... }
}

Чеклист при изменении поля

• обновлён глоссарий?
• миграция данных с пересчётом единиц?
• уведомлены потребители API?
• контрактные тесты в CI?
• концептуальная схема синхронизирована?

---

Семантика в разметке и интерфейсах

HTML и доступность

Тег <button> и <div onclick="..."> могут выглядеть одинаково. Семантика для скринридера разная: кнопка объявлена как интерактивный элемент с ролью.

Landmark-элементы (<main>, <nav>, <header>) задают смысловую структуру страницы. Подробнее — HTML и CSS — семантика.

Микроразметка Schema.org

Атрибуты itemtype, JSON-LD — способ сказать поисковику: "это товар", "это цена". Связь с семантическим вебом.

---

Связь с соседними статьями маршрута

Статья	Вклад в общую картину
326 (эта)	различение формы и смысла, три уровня "семантики"
327	как записать знания для машин
328	формальные понятия домена
329	схемы от идеи до таблиц
330	обмен смыслом в сети, RDF, графы

Дополнительно: графы, логика, теория информации, структуры данных.

---

Практика для команды

На этапе проектирования

• начинать с концептуальной схемы, а не с таблиц;
• фиксировать единицы измерения в именах полей;
• разделять перегруженные status, type, name.

На этапе разработки

• JSON Schema / OpenAPI в репозитории рядом с кодом;
• контрактные тесты между сервисами;
• линтеры на запрещённые синонимы в API.

На этапе эксплуатации

• каталог данных (data catalog) с описаниями столбцов;
• алерты на аномалии (скачок сумм на порядок);
• ретроспективы инцидентов с пометкой "семантика / синтаксис".

Вопросы для код-ревью

• Понятно ли из имени поля, в каких единицах значение?
• Совпадает ли смысл с глоссарием?
• Есть ли описание в контракте API?
• Что произойдёт при повторной доставке сообщения?

---

Прагматика — смысл в контексте

Рядом с синтаксисом и семантикой в лингвистике выделяют прагматику — как смысл зависит от ситуации, говорящего и цели.

Примеры в IT

Высказывание	Без контекста	С контекстом
DELETE /users/5	удалить запись	в проде — инцидент; в тесте — очистка фикстуры
status = 0	число ноль	в прошивке — "выключено"; в API v1 — "черновик"
"клиент недоволен" в тикете	эмоция	приоритет SLA, эскалация

Прагматика объясняет, почему одна и та же семантика требует разных действий: резервное копирование перед миграцией, feature flag, канареечный релиз.

Связь с метаданными

Поля created_by, environment, valid_from в метаданных несут прагматический слой: кто утвердил смысл и когда он действует. В онтологиях временные версии понятий называют версионированием онтологии.

---

Семантика в событиях и очередях

В событийно-ориентированной архитектуре сообщение — это JSON плюс тип события.

{
  "type": "order.paid",
  "occurred_at": "2026-06-15T14:22:00Z",
  "payload": {
    "order_id": 1042,
    "amount_kopecks": 19999
  }
}

Синтаксис — валидный JSON.

Семантика типа — order.paid означает успешное списание, а не "заказ создан" или "чек отправлен".

Семантика доставки — подписчик может получить событие дважды; обработчик должен быть идемпотентным или использовать deduplication по event_id.

Таблица соглашений для команды:

Поле	Назначение
type	имя события из реестра
schema_version	версия смысла payload
event_id	уникальный идентификатор для дедупликации
occurred_at	момент факта в домене (не время отправки)

---

Семантика в аналитике и отчётах

BI-дашборд (Business Intelligence — система бизнес-аналитики) агрегирует таблицы. Ошибка семантики здесь особенно болезненна: цифры выглядят точными.

Типичные ловушки

• Разные определения "активного пользователя" — заход за 30 дней или за 7?
• Валовая и чистая выручка — одно имя столбца revenue.
• Окно атрибуции — клик и покупка в разных сессиях.

Практика

• metric store (хранилище определений метрик) с версией формулы;
• ссылка из отчёта на определение в базе знаний;
• тесты на эталонных наборах данных.

Связь с анализом данных: SQL корректен, определение метрики — семантика.

---

Семантика и безопасность

Информационная безопасность опирается на смысл ролей и действий.

Решение	Семантический вопрос
RBAC (Role-Based Access Control — разграничение по ролям)	что может роль editor?
Маскирование поля	email — PII (Personally Identifiable Information — персональные данные)?
Аудит-лог	какое действие означает user.delete?

Одинаковый HTTP 200 OK на удаление и на soft-delete (логическое удаление) — разная семантика для восстановления данных и комплаенса.

---

Мини-глоссарий

Термин	Краткое определение
Семантика	смысл знаков, данных, конструкций
Синтаксис	правила формы записи
Прагматика	смысл в контексте использования (кто, когда, зачем)
Онтология	формальная модель понятий домена
Метаданные	данные о данных
Инвариант	условие, которое всегда должно быть истинно
Mapping	сопоставление полей между схемами
Идемпотентность	повтор операции без лишнего эффекта
Bounded context	граница однозначности терминов в DDD
Триплет	утверждение "субъект — предикат — объект" в RDF
NLP	обработка естественного языка
RAG	дополнение ответов LLM извлечённым контекстом

---

Вопросы для самопроверки

1. Приведите пример JSON, который синтаксически верен, но семантически неоднозначен без контракта.
2. Назовите три уровня слова "семантика" в IT и по одному примеру на каждый.
3. Чем измерение Шеннона отличается от вопросов семантики?
4. Почему поле status часто становится источником ошибок?
5. Какие слои есть у контракта API кроме синтаксиса JSON?
6. Что такое единый язык в DDD и как он связан с глоссарием?
7. Какие стратегии версионирования вы знаете при смене смысла поля?
8. Чем семантический анализ компилятора отличается от NLP?
9. Как связаны эта статья, 327, 328, 329 и 330?
10. Опишите шаги исправления кейса с единицами измерения.

Задание со звёздочкой. Нарисуйте ER-фрагмент для заказа с отдельными справочниками для логистики и оплаты. Сверьте с концептуальными схемами.

---

Связанные статьи

• Представление знаний — как записывать знания для машин.
• Онтология в информатике — формальная модель понятий домена.
• Концептуальные схемы и информационные модели — ER, UML, уровни схемы.
• Семантический веб и графы знаний — RDF, Linked Data.
• Графы — маршруты, остовы и раскраски — математика графов.
• Теория информации — энтропия и каналы.
• Формальные языки и автоматы — лексер, парсер, семантика.
• Мыслительная база — о разделе.
• Метаданные.
• Основы интеграционного взаимодействия.
• Применение ИИ — RAG и графы знаний.

---