R3.4:10 - Составление описания или шаблона описания. полуконспект

iurii-kalin · 19.Октябрь.2026 19:09:39

итак…

поехали

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

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

при работе с данными и объектами и в той области для которой вы готовите описания действуйте так как будто никому не известен подход 4д экстенсионализма, и так скорее всего на самом деле и будет.
на уровне мета-мета-модели вам необходимо прошивать объекты, классы, отношения типами верхней онтологии руководства. это типы boro и дополнительные концепты, которыми вы можете расширить онтологию.
на уровне языка предметной области вам придется учитывать правила использования концептов этого языка. это сводится к использованию слов и конструкций языка таким образом как это уже сложилось. это что касается онтологии предметной области из учебника.
как раз прошивание концептов из учебника концептами из верхней онтологии позволит настроить корректный контроль типов в описании, что позволит поддерживать адекватность самого описания. но эту прошивку не обязательно демонстрировать окружающим.

теперь переходим к разбору пошаговой практики создания описания (модели) предметной области.

шаг 1. взять всех участников ситуации разработки описания/моделирования чего-то в мире. у них должны быть ситуационные роли (заказчик описания, адресат описания, автор описания). для каждой ситуационной роли определяем ее предметную роль в предметной области. агентов в ситуационных ролях прошиваем слоем предметных ролей и для этих ролей описываем их интересы в той предметной области для которой создается описание.

шаг 2. из той ситуации или чего-то с чем мы планируем поработать, мы выделяем основные объекты описания, которые имеют значение для модели. объекта которые были найдены и признаны годными для того чтобы быть отраженными в модели, используются для того чтобы определить тот уровень абстракции описания на выходе. описание может быть описано в индивидах, в узких классах, в широких классах.

шаг 3. на этом шаге необходимо определиться в тем, а, собственно, как полученное описание будет использоваться? как оно будет встраиваться в рабочие процессы (если будет). его будут зачитывать и использовать как справочник, или это будет шаблон для заполнения и его будут использовать как инструмент для сбора данных? или еще как-то будут использовать для получения пользы или улучшения какой-то из характеристик рабочего процесса? его будет читать человек или ии-агент?

шаг 4. на этом шаге решаются вопросы того в какой модальности будет написано описание? это будет таблица/матрица или это будет сырой текст? в каком формате оно будет написано? на каком языке оно будет написано? какие инструменты будут использоваться для создания модели? это будет специальная среда для разработки, простой текстовый редактор, таблицы? будет использоваться 1 инструмент для создания всей модели или будут разные инструменты для разных частей модели?

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

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

шаг 7. 1. Выберите или разработайте мета-С онтологию в объёме необходимых для описания объектов классификаторов и справочников.

Объясняющий пример этого шага

Qwen3.8-Max. Бесплатный:

«Выберите или разработайте мета-С онтологию в объёме необходимых… классификаторов и справочников»

Одна строка смысла

Прежде чем эксперты начнут заполнять шаблоны данными, нужно зафиксировать словарь и грамматику описания: какие типы объектов бывают, как они группируются в иерархии (классификаторы) и какие значения допустимы в их полях (справочники). Фраза говорит именно об этом подготовительном шаге — и о том, что делать его нужно экономно.

Разбор фразы по частям

Часть 1. «Выберите или разработайте» — это решение о переиспользовании

Ветка Что означает Когда применять

Выберите Взять уже существующий классификатор/справочник: ботаническую таксономию, ОКПД, ГОСТ на инструмент, общепринятый список помещений Когда готовый классификатор покрывает вашу потребность и не конфликтует с вашим контекстом

Разработайте Завести свой классификатор/справочник Только когда готового нет или он не различает то, что критично для вашей задачи

FPF формализует это как решётку решений F.8 (Mint-or-Reuse): сначала — переиспользовать контекст, строку, алиас или ролевое описание; заводить новый тип (U.Type) — редкость, требующая трёх проверок:

это ядерное понятие, отсутствующее в каталоге;

оно не сводится к существующим строкам;

оно встречается минимум в трёх различных доменных семействах.

Практический перевод: «не изобретайте свой классификатор фруктов, если ботанический вас устраивает».

Часть 2. «Мета-С онтология» — уровень языка, а не уровень вещей

Это модель модели: она описывает не экземпляры, а язык, на котором экземпляры описываются. В FPF-терминах это набор:

Элемент мета-С онтологии FPF-конструкт

Типы объектов и их атрибуты U.Kind + сигнатура вида (C.3)

Иерархии «общее → частное» U.SubkindOf (⊑), частичный порядок (C.3.1)

Закрытые списки допустимых значений U.EntitySet(slice) (C.3.2)

Допустимые связи между типами U.Relation + дисциплина слотов (A.6.5)

Граница применимости всего этого U.BoundedContext (A.1, E.10.D1)

Два важных предупреждения из FPF:

Это «онтик», а не «онтология вообще». Такой локальный модуль (E.24) заводится только тогда, когда есть стабильная идентичность и типизированный граф слотов. Не каждое поле таблицы — онтологическое решение (E.24.CD).

Не сводите всё к одному дереву таксономии. Это прямая осторожность FPF относительно SKOS/OWL: таксономические отношения используются там, где они подходят, но значительная часть признаков — это справочники и атрибуты, а не ветви дерева.

Часть 3. «В объёме необходимых» — минимальная достаточность

Объём определяется одним тестом: если убрать этот классификатор или справочник — появятся ли разночтения при заполнении?

Появятся → нужен.

Не появятся → лишний, не включаем.

Это защита от типичной ошибки: построить «полную онтологию садоводства» на 300 видов, когда экспертам нужно различать 12.

Часть 4–5. Классификаторы и справочники — два разных конструкта

Классификатор Справочник

Структура Иерархия (⊑), от общего к частному Плоский закрытый список

FPF U.SubkindOf между U.Kind U.EntitySet(slice)

Пример Яблоня ⊑ Семечковые ⊑ Плодовое дерево Месяцы созревания = {Июнь…Октябрь}

Что задаёт Как объект группируется Какие значения допустимы в поле

Часть 6. Скрытое, но важное: плоскость отсчёта и stance

Что CHR:ReferencePlane Stance

Классификаторы и справочники conceptual design

Конкретная яблоня в саду world/external —

Заполненный шаблон (описание) epistemic run

Мета-С онтология делается в design stance; заполнение её экспертами — это уже run stance. Смешивать их нельзя: правка справочника во время заполнения данных ломает сопоставимость уже внесённых записей.

Пример 1. Сад: фрукты и садовые растения

1.1 Имя контекста (не «садоводство»)

Слово «садоводство» — это доменное семейство, а не контекст. По E.10.D1 имя контекста должно называть семантическую рамку, достаточно узкую, чтобы определять смысл:
contextIdentity: HomeGarden.CentralRussia.2026
├─ локальный словарь (свои названия сортов, свои зоны)
├─ инварианты (сезон посадки определяет допустимые месяцы)
├─ таксономия ролей (Садовод, Помощник, Поставщик саженцев)
└─ bridge-вопросы к соседним контекстам (Kitchen.FoodPrep.2026)
1.2 Виды и их сигнатуры

Слоты именуются по дисциплине A.6.5: *Slot — только для SlotKind, *Ref — только для RefKind; корни Subject/Object в типах эпистем не используются.
U.Kind: СадовоеРастение
  slots:
    - plantSlot:           # сам носитель
    - latinNameRef:        ValueKind: Строка
    - lifeFormRef:         ValueKind: U.Entity  → классификатор ЖизненныеФормы
    - plantingSeasonRef:   ValueKind: U.Entity  → справочник СезоныПосадки
    - propagationRef:      ValueKind: U.Entity  → справочник СпособыРазмножения
    - needsPollinatorSlot: ValueKind: Булево

U.Kind: Плод
  slots:
    - fruitSlot:
    - massGramsRef:        ValueKind: Число (единица: г)
    - skinColorRef:        ValueKind: U.Entity → справочник ЦветаКожуры
    - ripeningMonthRef:    ValueKind: U.Entity → справочник МесяцыСозревания
    - shelfLifeDaysRef:    ValueKind: Число (единица: сут)

U.Kind: Грядка
  slots:
    - bedSlot:
    - areaM2Ref:           ValueKind: Число (единица: м²)
    - soilTypeRef:         ValueKind: U.Entity → справочник ТипыПочвы
    - orientationRef:      ValueKind: U.Entity → справочник Ориентация
1.3 Классификатор (иерархия ⊑)
СадовоеРастение
├─ ПлодовоеДерево
│   ├─ Семечковые
│   │   ├─ Яблоня
│   │   └─ Груша
│   └─ Косточковые
│       ├─ Вишня
│       └─ Слива
├─ Кустарник
│   ├─ Смородина
│   └─ Малина
└─ Травянистое
    └─ Клубника
SubkindOf(Яблоня, Семечковые)
SubkindOf(Семечковые, ПлодовоеДерево)
SubkindOf(ПлодовоеДерево, СадовоеРастение)
→ транзитивно: SubkindOf(Яблоня, СадовоеРастение)
Проверка на «не всё дерево»: способ размножения (семенами/черенками/прививкой) — не ветвь иерархии. Одна и та же яблоня может быть привитой и корнесобственной. Это справочник-атрибут, а не таксон. Попытка сделать из него ветвь дерева — типичная ошибка, против которой предостерегает E.24.

1.4 Справочники (U.EntitySet(slice))
EntitySet(СезоныПосадки, slice=2026)   = {Весна, Осень, КруглыйГод}
EntitySet(МесяцыСозревания, slice=2026) = {Июнь, Июль, Август, Сентябрь, Октябрь}
EntitySet(СпособыРазмножения, slice=2026) = {Семенами, Черенками, Отводками, Прививкой}
EntitySet(ТипыПочвы, slice=2026)        = {Песчаная, Суглинок, Глина, Торфяная}
Зачем slice: если в 2027 вы добавите в ТипыПочвы значение «Супесчаная», это новый срез. Записи 2026 года продолжают ссылаться на slice=2026 и остаются проверяемыми. Без slice вы не сможете ответить, «по какому списку это вносили».

1.5 Отношения
U.Relation: РастётНа
  slots:
    - plantSlot:  ValueKind: U.Kind СадовоеРастение, refMode: ByRef
    - bedSlot:    ValueKind: U.Kind Грядка,          refMode: ByRef
  obtaining predicate: "растение физически высажено на этой грядке"

U.Relation: ДаётПлод
  slots:
    - plantSlot:  ValueKind: U.Kind СадовоеРастение
    - fruitSlot:  ValueKind: U.Kind Плод
  obtaining predicate: "растение является носителем этого плода"

U.Relation: ТребуетОпылителя
  slots:
    - plantSlot:        ValueKind: U.Kind СадовоеРастение
    - pollinatorSlot:   ValueKind: U.Kind СадовоеРастение
  obtaining predicate: "для плодоношения нужна пыльца другого растения"
Дисциплина слотов работает как защита от бессмыслицы: нельзя записать РастётНа(Яблоня, Сентябрь) — слот bedSlot не примет месяц.

1.6 Экземпляры (уровень ниже мета-С)
Яблоня_Антоновка_001:
  kind: Яблоня
  latinNameRef: "Malus domestica 'Antonovka'"
  lifeFormRef: ПлодовоеДерево
  plantingSeasonRef: Осень
  propagationRef: Прививкой
  needsPollinatorSlot: true

Плод_Яблоко_2026_001:
  kind: Плод
  massGramsRef: 180
  skinColorRef: Зелёный
  ripeningMonthRef: Сентябрь
  shelfLifeDaysRef: 120

ДаётПлод(Яблоня_Антоновка_001, Плод_Яблоко_2026_001)
1.7 Что даёт мета-С онтология в этом домене

Без неё три эксперта запишут одно и то же так:
«Антоновка, осень, зелёное, сентябрь»
«antonovka, fall, green, sept»
«яблоня антоновка, сажать осенью, яблоки зелёные в сентябре»
Три записи, несопоставимые между собой. С мета-С онтологией все трое заполняют одни и те же слоты значениями из одних и тех же справочников — записи становятся агрегируемыми и проверяемыми.

Пример 2. Работы по дому и инструменты

2.1 Имя контекста
contextIdentity: HomeMaintenance.Apartment.2026
Не «дом», не «быт» — это доменные семейства. Узкое имя определяет, что значит «уборка» именно здесь.

2.2 Критичный шаг: разобрать потребность по senseFamily

По F.0.1 строки классифицируются как {Role | Status | Measurement | Type-structure | Method | Execution}, и строки должны быть однородными по смыслу. Если потребность смешанная — её разделяют (A.7), а не сваливают в одну таблицу.

В домене «работы по дому» смешиваются минимум четыре семейства:

Что вы хотите описать senseFamily Куда это попадает

Виды работ («мытье пола», «забить гвоздь») Type-structure Классификатор работ

Виды инструментов («дрель», «швабра») Type-structure Классификатор инструментов

Помещения, поверхности, типы привода Type-structure Справочники

Кто это делает («тот, кто убирает») Role Роль, отдельно от метода

Как это делается («сухая уборка» vs «влажная») Method Метод, не часть имени роли

Конкретное выполнение 06.09.2026 14:00 Execution Экземпляр работы

«Насколько сложно», «сколько минут заняло» Measurement Мера (A.17–A.19)

«завершено / в работе / отложено» Status Статус, не мера

Терминологическая дисциплина: слово «характеристика» (Characteristic) в FPF означает только измеримый аспект и не используется для типизации строк. Поэтому «сложность работы» надо явно решить: это Measurement (шкала с единицей и методом измерения) или Status (назначенная метка). Пока не решили — не вносите в мета-С онтологию.

2.3 Виды и сигнатуры
U.Kind: ДомашняяРабота
  slots:
    - workSlot:
    - categoryRef:        ValueKind: U.Entity → классификатор КатегорииРабот
    - roomRef:            ValueKind: U.Entity → справочник Помещения
    - surfaceRef:         ValueKind: U.Entity → справочник Поверхности
    - frequencyRef:       ValueKind: U.Entity → справочник Частота
    - requiredToolRef:    ValueKind: U.Kind Инструмент, refMode: ByRef

U.Kind: Инструмент
  slots:
    - toolSlot:
    - categoryRef:        ValueKind: U.Entity → классификатор КатегорииИнструмента
    - driveRef:           ValueKind: U.Entity → справочник ТипыПривода
    - storageRef:         ValueKind: U.Entity → справочник МестаХранения
    - needsConsumableSlot: ValueKind: Булево

U.Kind: Помещение
  slots:
    - roomSlot:
    - roomTypeRef:        ValueKind: U.Entity → справочник ТипыПомещений
    - areaM2Ref:          ValueKind: Число (единица: м²)
    - floorCoveringRef:   ValueKind: U.Entity → справочник ПокрытияПола
2.4 Классификаторы (⊑)

Работы:
ДомашняяРабота
├─ Уборка
│   ├─ СухаяУборка
│   │   ├─ Пылесосить
│   │   └─ Подметать
│   └─ ВлажнаяУборка
│       ├─ МытьПол
│       └─ ПротиратьПоверхности
├─ Ремонт
│   ├─ МелкийРемонт
│   │   ├─ ЗабитьГвоздь
│   │   └─ ПрикрутитьПолку
│   └─ КрупныйРемонт
│       ├─ Штукатурить
│       └─ КраситьСтены
└─ ОбслуживаниеТехники
    ├─ ПочиститьФильтры
    └─ ЗаменитьЛампочку
Инструменты:
Инструмент
├─ РучнойИнструмент
│   ├─ Молоток
│   ├─ Отвёртка
│   └─ Щётка
├─ Электроинструмент
│   ├─ Дрель
│   ├─ Шуруповёрт
│   └─ Перфоратор
└─ УборочныйИнвентарь
    ├─ Пылесос
    ├─ Швабра
    └─ Ведро
Где здесь роль, а где метод. «Пылесосить» — это ветвь классификатора работ (Type-structure), а не роль. Роль одна — например, Уборщик@HomeMaintenance.Apartment.2026. Методов у неё несколько: сухая уборка, влажная уборка. Делать отдельные роли «Пылесосильщик» и «МойщикПолов» — значит спрятать метод в имя роли; при добавлении третьего способа уборки придётся заводить третью роль. FPF требует: роль — одна, методы — перечисляются, работы — выполняются.

2.5 Справочники
EntitySet(Помещения, slice=2026)      = {Кухня, Спальня, Гостиная, Ванная, Прихожая, Балкон}
EntitySet(ПокрытияПола, slice=2026)   = {Ламинат, Плитка, Паркет, Линолеум, Ковролин}
EntitySet(ТипыПривода, slice=2026)    = {Ручной, Электрический, Аккумуляторный}
EntitySet(МестаХранения, slice=2026)  = {Кладовка, Балкон, Антресоль, Гараж}
EntitySet(Частота, slice=2026)        = {Ежедневно, Еженедельно, Ежемесячно, РазВГод, ПоНеобходимости}
2.6 Отношения
U.Relation: ТребуетсяДля
  slots:
    - toolSlot: ValueKind: U.Kind Инструмент
    - workSlot: ValueKind: U.Kind ДомашняяРабота
  obtaining predicate: "работа не может быть выполнена без этого инструмента"

U.Relation: ПодходитДля
  slots:
    - toolSlot: ValueKind: U.Kind Инструмент
    - workSlot: ValueKind: U.Kind ДомашняяРабота
  obtaining predicate: "инструмент может быть использован для этой работы (не обязательно обязателен)"

U.Relation: ХранитсяВ
  slots:
    - toolSlot:      ValueKind: U.Kind Инструмент
    - storageSlot:   ValueKind: U.Entity из EntitySet(МестаХранения)
  obtaining predicate: "инструмент физически размещён в этом месте"

U.Relation: РасходникДля
  slots:
    - consumableSlot: ValueKind: U.Kind Расходник
    - toolSlot:       ValueKind: U.Kind Инструмент
  obtaining predicate: "расходник необходим для работы инструмента"
Обратите внимание: ТребуетсяДля и ПодходитДля — два разных отношения, хотя на бытовом уровне оба звучат как «нужен». Если слить их в одно, планирование закупок и проверка готовности к работе станут невозможными: нельзя отличить «без этого не сделать» от «этим удобно».

2.7 Экземпляры
Инструмент_Дрель_Bosch_001:
  kind: Дрель
  driveRef: Электрический
  storageRef: Кладовка
  needsConsumableSlot: true
  РасходникДля(Свёрла_набор_01, Инструмент_Дрель_Bosch_001)

Работа_ПрикрутитьПолку_Гостиная:
  kind: ПрикрутитьПолку
  roomRef: Гостиная
  frequencyRef: ПоНеобходимости
  ТребуетсяДля(Инструмент_Дрель_Bosch_001, Работа_ПрикрутитьПолку_Гостиная)

Выполнение_2026-09-06T14:00:
  kind: U.Work (Execution senseFamily)
  enacts: Работа_ПрикрутитьПолку_Гостиная
  performer: Иванов#Уборщик→ точнее Иванов#ДомашнийМастер@HomeMaintenance.Apartment.2026
  duration: 40 мин   # Measurement, отдельная строка
Последний блок показывает разделение design (вид работы, инструмент, справочники) и run (конкретное датированное выполнение с мерой длительности). Мета-С онтология описывает первое; второе появляется только при заполнении.

Сводная карта: фраза → конструкт → примеры

Элемент фразы FPF-конструкт Сад Дом

«выберите» F.8, ветка reuse Ботаническая таксономия Общепринятый список помещений

«или разработайте» F.8, ветка mint (с Q5-тестом) Свой список сортов под климат Свой список мест хранения

«мета-С онтология» U.Kind + сигнатуры, C.3 СадовоеРастение, Плод, Грядка ДомашняяРабота, Инструмент, Помещение

«в объёме необходимых» минимальная достаточность, F.8 Не 300 видов, а 12 Не все инструменты мира, а имеющиеся

«классификаторов» U.SubkindOf (⊑), C.3.1 ПлодовоеДерево ⊑ СадовоеРастение Электроинструмент ⊑ Инструмент

«справочников» U.EntitySet(slice), C.3.2 СезоныПосадки, ТипыПочвы Помещения, ТипыПривода

(неявно) «для описания объектов» отношения + дисциплина слотов, A.6.5 РастётНа, ДаётПлод ТребуетсяДля, ХранитсяВ

(неявно) граница применимости U.BoundedContext, A.1 / E.10.D1 HomeGarden.CentralRussia.2026 HomeMaintenance.Apartment.2026

Типичные ошибки на этом шаге

# Ошибка Почему плохо Как правильно

1 Всё сводится к одному дереву таксономии Способ размножения, место хранения, привод — не ветви иерархии Дерево — только для genuine «общее→частное»; остальное — справочники и атрибуты (осторожность E.24 по SKOS/OWL)

2 Новый тип заводится под каждый классификатор Раздувание каталога, дубли Сначала reuse: контекст, строка, алиас, ролевое описание (F.8)

3 В одной строке смешаны смыслы («сложность работы» = и мера, и метка) Строка неоднородна, проверка невозможна Разделить по senseFamily, одно решение на семейство (A.7, F.0.1)

4 Контекст назван широко: «сад», «дом» Смысл слов не определяется Узкое contextIdentity с локальным словарём и инвариантами (E.10.D1)

5 Справочник без slice Невозможно понять, к какой версии списка относится запись EntitySet(slice) с явным срезом

6 Метод спрятан в имя роли («Пылесосильщик») Роли размножаются при каждом новом способе Роль одна, методы перечислены отдельно

7 «Груша в саду» и «груша на кухне» связываются напрямую Потери при переводе не видны Нужен явный мост (F.9) с уровнем конгруэнтности и заметками о потерях; по умолчанию — только для пояснения, не для подстановки

8 Слово «характеристика» используется для типизации строк Нарушает терминологическую дисциплину Part F Строки типизируются только через senseFamily; «характеристика» — только про измеримое (A.17–A.19)

Чек-лист готовности мета-С онтологии

Мета-С онтология готова, когда:

Все типы объектов, с которыми столкнётся эксперт, объявлены как U.Kind.

У каждого типа есть сигнатура: слоты с объявленным ValueKind и refMode (ByValue / RefKind), имена — по дисциплине *Slot / *Ref.

Классификаторы — это ацикличные и анти-симметричные иерархии ⊑; не-иерархические признаки вынесены в справочники.

Справочники — закрытые EntitySet с явным slice.

У каждого отношения есть obtaining predicate и типизированные слоты.

Ни одна строка не смешивает senseFamily; Measurement отделено от Status, Method — от Role, Execution — от Type-structure.

Есть явный список того, что НЕ входит в объём (граница «в объёме необходимых»).

Эксперт может заполнить шаблон, не задавая вопросов о структуре.

Пункт 7 часто пропускают, а зря: именно он фиксирует, что фраза «в объёме необходимых» была выполнена, а не проигнорирована.

Ключевой инсайт

Фраза описывает договор о языке до начала разговора. Мета-С онтология — это не «база знаний о саде» и не «описание всех инструментов в мире». Это узкий, контекстно привязанный набор типов, иерархий и закрытых списков, достаточный для того, чтобы разные эксперты заполняли одни и те же шаблоны одинаково понимаемыми словами.

Объём задаётся не полнотой картины мира, а одним вопросом: что произойдёт, если этого классификатора или справочника не будет? Если ответ «эксперты запишут по-разному» — включаем. Если «ничего не изменится» — не включаем.

Микро-задача (+1%)

Возьмите бытовой домен «Домашняя аптечка: лекарства и симптомы» и за 20 минут постройте мета-С онтологию в минимальном объёме:

Придумайте узкое contextIdentity (не «медицина», не «здоровье»).

Объявите 3 U.Kind с сигнатурами; слоты назовите по дисциплине (*Slot / *Ref), у каждого укажите ValueKind.

Постройте 1 классификатор через ⊑ минимум в два уровня.

Задайте 2 справочника как EntitySet(slice).

Объявите 2 отношения с obtaining predicate и типизированными слотами.

Для каждого элемента укажите senseFamily (Role / Status / Measurement / Type-structure / Method / Execution).

Отдельно напишите список из 3 вещей, которые вы сознательно не включили в объём, и почему.

Пункт 7 — самый важный: именно он показывает, что вы поняли «в объёме необходимых», а не просто построили дерево побольше.

Пришлите результат — проверю по A.1 / A.6.5 / A.7 / C.3 / E.10.D1 / F.8 и зафиксируем, где классификатор оправдан, где нужен справочник, а где строку надо разделить по senseFamily.

шаг 8. тут надо решить каким образом в описании мы будем именовать объекты которые мы как агенты-в-роли выделяем их входящего потока своим вниманием на основании ролевого интереса.

шаг 9. определяем тот набор признаков и свойств объектов которые будут попадать в описание. по сути это набор атрибутов объектов из описания которые мы будем выделять у объектов и отдельно их фиксировать в описании и как-то подсвечивать и наводить на них внимание свое и адресата.

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

соответственно, выполнив необходимые подготовительные действия согласно 10 шагов, мы должны достичь состояния готовности к разработке самого описания которое нас интересует или которое интересует внешние роли.

ну а дальше уже берете и выполняете работы по созданию описания.
так же при работе с описаниями могут быть варианты - мы или готовим новое описание с нуля, или меняем/дорабатываем/улучшаем существующую версию описания.

такие дела

спасибо за внимание

время мышления письмом: ( 30 + 30 + 30 + 15 ) минут

Ветка	Что означает	Когда применять
Выберите	Взять уже существующий классификатор/справочник: ботаническую таксономию, ОКПД, ГОСТ на инструмент, общепринятый список помещений	Когда готовый классификатор покрывает вашу потребность и не конфликтует с вашим контекстом
Разработайте	Завести свой классификатор/справочник	Только когда готового нет или он не различает то, что критично для вашей задачи

Элемент мета-С онтологии	FPF-конструкт
Типы объектов и их атрибуты	`U.Kind` + сигнатура вида (C.3)
Иерархии «общее → частное»	`U.SubkindOf` (⊑), частичный порядок (C.3.1)
Закрытые списки допустимых значений	`U.EntitySet(slice)` (C.3.2)
Допустимые связи между типами	`U.Relation` + дисциплина слотов (A.6.5)
Граница применимости всего этого	`U.BoundedContext` (A.1, E.10.D1)

	Классификатор	Справочник
Структура	Иерархия (⊑), от общего к частному	Плоский закрытый список
FPF	`U.SubkindOf` между `U.Kind`	`U.EntitySet(slice)`
Пример	Яблоня ⊑ Семечковые ⊑ Плодовое дерево	Месяцы созревания = {Июнь…Октябрь}
Что задаёт	Как объект группируется	Какие значения допустимы в поле

Что	CHR:ReferencePlane	Stance
Классификаторы и справочники	conceptual	design
Конкретная яблоня в саду	world/external	—
Заполненный шаблон (описание)	epistemic	run

Что вы хотите описать	senseFamily	Куда это попадает
Виды работ («мытье пола», «забить гвоздь»)	Type-structure	Классификатор работ
Виды инструментов («дрель», «швабра»)	Type-structure	Классификатор инструментов
Помещения, поверхности, типы привода	Type-structure	Справочники
Кто это делает («тот, кто убирает»)	Role	Роль, отдельно от метода
Как это делается («сухая уборка» vs «влажная»)	Method	Метод, не часть имени роли
Конкретное выполнение 06.09.2026 14:00	Execution	Экземпляр работы
«Насколько сложно», «сколько минут заняло»	Measurement	Мера (A.17–A.19)
«завершено / в работе / отложено»	Status	Статус, не мера

Элемент фразы	FPF-конструкт	Сад	Дом
«выберите»	F.8, ветка reuse	Ботаническая таксономия	Общепринятый список помещений
«или разработайте»	F.8, ветка mint (с Q5-тестом)	Свой список сортов под климат	Свой список мест хранения
«мета-С онтология»	`U.Kind` + сигнатуры, C.3	СадовоеРастение, Плод, Грядка	ДомашняяРабота, Инструмент, Помещение
«в объёме необходимых»	минимальная достаточность, F.8	Не 300 видов, а 12	Не все инструменты мира, а имеющиеся
«классификаторов»	`U.SubkindOf` (⊑), C.3.1	ПлодовоеДерево ⊑ СадовоеРастение	Электроинструмент ⊑ Инструмент
«справочников»	`U.EntitySet(slice)`, C.3.2	СезоныПосадки, ТипыПочвы	Помещения, ТипыПривода
(неявно) «для описания объектов»	отношения + дисциплина слотов, A.6.5	РастётНа, ДаётПлод	ТребуетсяДля, ХранитсяВ
(неявно) граница применимости	`U.BoundedContext`, A.1 / E.10.D1	`HomeGarden.CentralRussia.2026`	`HomeMaintenance.Apartment.2026`

#	Ошибка	Почему плохо	Как правильно
1	Всё сводится к одному дереву таксономии	Способ размножения, место хранения, привод — не ветви иерархии	Дерево — только для genuine «общее→частное»; остальное — справочники и атрибуты (осторожность E.24 по SKOS/OWL)
2	Новый тип заводится под каждый классификатор	Раздувание каталога, дубли	Сначала reuse: контекст, строка, алиас, ролевое описание (F.8)
3	В одной строке смешаны смыслы («сложность работы» = и мера, и метка)	Строка неоднородна, проверка невозможна	Разделить по senseFamily, одно решение на семейство (A.7, F.0.1)
4	Контекст назван широко: «сад», «дом»	Смысл слов не определяется	Узкое `contextIdentity` с локальным словарём и инвариантами (E.10.D1)
5	Справочник без slice	Невозможно понять, к какой версии списка относится запись	`EntitySet(slice)` с явным срезом
6	Метод спрятан в имя роли («Пылесосильщик»)	Роли размножаются при каждом новом способе	Роль одна, методы перечислены отдельно
7	«Груша в саду» и «груша на кухне» связываются напрямую	Потери при переводе не видны	Нужен явный мост (F.9) с уровнем конгруэнтности и заметками о потерях; по умолчанию — только для пояснения, не для подстановки
8	Слово «характеристика» используется для типизации строк	Нарушает терминологическую дисциплину Part F	Строки типизируются только через senseFamily; «характеристика» — только про измеримое (A.17–A.19)