Очередная версия FPF (по прежнему адресу – First Principles Framework — Core Conceptual Specification (holonic).md — Яндекс Диск) отличается переработанными паттернами A.19 и A.19.D1, которые часть из раскиданных по тексту 379 терминов gauge заменила на термины механизма нормализации: “приведения значения к стандартной шкале”. Сейчас в FPF оказались перепутанными механизмы нормализации, скоринга (который может выдавать несколько значений), индикаторизации (выбор нескольких характеристик в качестве важных для последующего выбора на их основе), но ещё есть механизмы “публикации и телеметрии” и много чего ещё. После разбирательства с “нормализацией” термин gauge остался в количестве 255 штук, что уже немного легче – но надо продолжать распутывать этот клубок дальше. А дальше я хочу доразбираться со шкалой универсальности дисциплин, в том числе понятием трансдисциплинарности. И в какой-то момент заговорить об архитектуре. Характеризация и нормализация (писал об этом в Характеризация и нормализация: очередная чистка FPF: ailev — ЖЖ), скоринг и всё прочее - тут первая остановка. Тут этих механизмов ой-ой-ой сколько получается, я всё утро с этим вожусь. Главное, что общие (сравнение как таковое, чего угодно) и частные (сравнение дисциплин) механизмы оказались сильно переплетены в ходе создания части G, и нужно теперь их аккуратно расплести, выплатить кусочек архитектурного долга. И это ещё на несколько дней.
Ужас в том, что для такого аккуратного раскладывания FPF по уровням универсальности (архитектурное решение!) уже неплохо бы иметь шкалу универсальности, язык разговора об архитектуре, но их не сделать, пока аккуратно не разведёшь вручную все эти механизмы, методы, входы и выходы методов – и уже на их базе не определишь эти механизмы. Bootstrapping, “раскрутка”. Ничего, прорвёмся, но не так быстро, как хотелось бы.
Положение на шкале универсальности существенно связано с уровнем онтологии (foundational, upper, middle, domain-specific, у меня огромное количество слайдов на эту тему “онтологической стратификации”). В текущих руководствах программы рабочего развития онтологию мы называем “моделью” и там сразу появляется модель, мета-модель, мета-мета-модель как раз для трансдисциплинарности и мета-мета-мета-модель для обсуждения самой онтологии как таковой. Сейчас, после опыта работы с FPF, я мог бы назвать мета-мета-мета-модель “первыми принципами”, самыми базовыми и универсальными. Аксиомы, постулаты, измерения, сравнения, инварианты и прочее “самое общее, элементарное, откуда вырастает всё остальное”. Вторые принципы - это мета-мета-модель, наши руководства МИМ главным образом прописывают этот уровень универсальности моделей/онтологий/“картин мира”. Третьи принципы - это мета-модели каких-нибудь учебников, отраслевых или даже корпоративных стандартов. Это очень условное деление, тут хорошо бы иметь шкалу вот этой “универсальности”, “числа мета- для модели”, “трансдисциплинарности”, “номера принципов” – уж как ни назови. А потом? Потом уже делать традиционные для онтологов вещи: вставлять семантику в имена, делать их “самоописывающимися”, привет semantic web и всей этой программе “самодокументируемых имён объектов”, “самоописываемых данных” – хорошая ведь была задумка, только не очень рабочая.
Но проблема имён остаётся не только по линии универсальности. Ибо при росте числа имён очень хочется внести тип/вид/класс/категорию объекта прямо в имя, даже если речь идёт не об онтологии, а о “разузловке” инженерного объекта. И от идентификации мы прямиком попадаем в мир десигнации, “означкования”. Если у вас 100500 объектов (это сильно заниженное число, у какого-нибудь авиалайнера это будет где-то 5млн. индивидуальных объектов), вам нужно уметь точно называть каждый из них. И получаются “многоуровневые” имена и правила такого именования, или как говорят в инженерии – “кодирования”, и ещё один термин – designation. У нас есть ISO 81346-2 для системных описаний, который как раз про десигнацию. И ещё куча подобных стандартов. Почему бы не:
– обобщить этот стандарт десигнации с систем до холонов (холархии вместо системной иерархии)?
– обобщить с десигнации холархий на десигнацию каких-то произвольных иерархий (например, иерархий мета-моделирования)?
И одним универсальным механизмом десигнации (видите, как вместо “дисциплина” появляется ещё один термин “механизм”? с этим тоже ведь надо будет разобраться) закрываются две проблемы: каким языком описывать архитектуру и каким языком описывать онтологию самого FPF? И тут я вспомнил про идеи проекта SysMoLan – systems modeling language (последний раз писал об этом где-то в 2021 году, Системное моделирование на SysMoLan в IME Codia (interactive modeling environment СOda + julIA): ailev — ЖЖ, до этого в 2019 Дискуссия о типах и SysMoLan продолжается : ailev — ЖЖ, до этого была цепочка текстов в 2018 году Цепочка "SysMoLan": ailev — ЖЖ). Там одна из мыслей и была: иметь domain-specific language на базе какого-то общего хост-языка (смутные мысли были, что там может быть в основе язык программирования, но потом я признал, что хост-язык должен быть менее строгий – нужен “псевдокод”), а вот объекты там именовать похожим способом на ISO 81346, ибо там внизу всегда физический мир, то есть системы. В FPF как раз решена часть проблем SysMoLan, и можно попробовать идеи этого проекта ещё раз.
Я по-быстрому написал вот такой промпт:
В подгруженном файле спецификация FPF, которую мы улучшаем. Пользователей её пока нет, поэтому возможен радикальный рефакторинг без учёта legacy.В ответ на этот промпт GPT-5 Pro радостно выдало набор стандартов, идеи из которого должны как-то решить проблему в FPF:В спецификации замечено много случаев плохой работы с именами (names, labels, lexemes), хотя довольно много внимания уделяется разным lexical guards, ontolexical guards, lexical firewalls и т.д. Большие проблемы в том, что имена сейчас (за редким исключением вроде ClaimScope и работы суффиксами и “головами”) не содержат в себе каких-то отсылок к U.Kinds/U.Types.
Предлагается ввести в FPF механизм десигнации понятий, который позволяет легко по самому десигнатору как name/label опеределять тип/вид сущности, а не только узнавать её идентификатор. Так, label map в FPF сейчас трактуется полностью произвольно: иногда это “карта”, иногда - “преобразование картирования”, иногда вообще нет смысла “карты”, а речь идёт о “преобразовании нормализации”. То же самое о словом gauge, которое то ли нормализация как механизм, то ли нормализация как преобразование, то ли результат преобразования.
Есть разные способы десигнации. Один из мягких способов, применяющихся в инженерии - это предписание capabilities выполнять девербативами (отглагольными существительными), чтобы чётко было видно стоящее за некоторыми терминами действие. Так, вместо неоднозначного map появляется пара map и mapping, где map это отсылка то ли к работе (повелительное наклонение глагола, выполнить действие картирования), то ли к карте, но зато mapping будет отсылкой к методу и это позволит сделать меньше ошибок.
Есть варианты так называемого “промышленного использования” ISO 15926-2, в котором примерно 200 типов стандарта просто приписываются к предлагаемым именам в обязательном порядке, и это помогает убрать довольно много ошибок. Можно считать, что виды/типы FPF kernel как раз аналогичная top ontology, и требовать при введении каких-то понятий давать им десигнаторы с явным указанием типа. Попытки такого подхода уже есть в FPF, где речь идёт о kinds как “головах” и “суффиксах” для каких-то десигнаторов/имён.
В текстах военных и государственных органов, где появляется много уникальных “свежепридуманных” понятий, имена делают многословными для уточнения, а затем сокращают до лексемы-аббревиатуры, которая оказывается редкой и поэтому не слишком перегруженной в отличие от заимствованных бытовых слов вроде “map” или даже “gauge”. В FPF тоже используется этот способ десигнации, например SCR/RSCR (но какой там U.Kind в их иерархии уже нельзя понять).
Есть и более продвинутые схемы/механизмы/правила/стандарты десигнации. Например, в инженерии предлагается для системных иерархий и связанных с системами документов использование “кодировки” ISO 81346-1. В FPF подобный механизм можно обобщить на холоны. Но ещё можно заметить, что онтологические решётки устроены подобным образом (иерархия kinds), и похожую схему десигнации можно применить и для имён понятий, когда их очень много. Так, в FPF явно предписано, что есть иерархия kinds, где Entity на верхнем уровне, далее идёт уровень, где наряду с Characteristics и прочими сущностями идёт Holon, ниже как виды холонов будут Episteme и System, а также другие виды холонов, ниже уже какие-то конкретные виды/kinds для эпистем и систем, наборов, фаз и прочих вариантов холонов. Так что ISO 81346-1 можно считать примером способа десигнации в произвольных иерархиях (в том числе холархиях, системных иерархиях и таксономиях).
Есть и многие другие примеры дисциплин десигнации в инженерии, и обязательно надо учитывать, что в некоторых из них слово designator используется явно, в некоторых его нет и речь идёт об “именах”, а в некоторых о “лексике”, очень часто о “терминологии”, иногда о “метках/label”. Например, довольно много десигнация обсуждается в программировании как “правила именования идентификаторов”. И есть тонкая разница между “идентификацией” и “десигнацией”.
Сгенерируй теперь на английском с учётом приведённых примеров дисциплин десигнации (и пополнив число дисциплин по нормам OEE NQD) по процедуре части G набор архитеорий десигнации в FPF, чтобы затем выполнить по решениям паттернов этого набора архитеорий рефакторинг имён в FPF. Речь идёт о всех именах в FPF, а не только тех примерах имён, которые упоминались именно как примеры. Сгенерированный набор архитеорий должен касаться десигнации всех имён/десигнаторов в FPF и тех прикладных архитеориях, которые будут генерироваться с использованием FPF. В сгенерированном наборе архитеорий не забывать прописывать consequences как trade-offs (positive and negative with mitigations).
– ISO/IEC 81346-1:2022 for reference designation in system hierarchies (we borrow its reference-designation mindset for holons).
– ISO 704:2022 for designation vs concept vs definition and principles of term formation.
– ISO/IEC 11179-5:2015 for metadata naming principles (uniqueness, structured names).
– W3C OntoLex-Lemon (2016) + Lexicog (2019) for lexicon/ontology separation and multi-register lexicalization (we map Tech/Plain to lemon entries).
– FAIR Principles (2016) and OBO Foundry P12 (Naming Conventions) to keep labels machine-actionable and human-intelligible.
– For OEE/NQD context: ISO 22400 analyses for OEE KPIs and Quality-Diversity (QD) literature (2016→2025) to ground gauge/portfolio naming.
И ещё откомментировало, что всё так просто не получится, ибо надо решать и проблему идентификации (выделения объектов) и десигнации, и учитывать многоаспектность именования (81346 не столько про холоны и иерархии, сколько про их различия в зависимости от аспектов, и там сразу много несовместимого с подходом к аспекту capability как главному для системы). Как говорится, “много вопросов, но мне нравится направление мыслей”. Дальше немедленно мне были предложены type-encoded designators, scope-aware designators, holon reference designation system (ой! слово система явно тут “художественно” применённое, но опять же "мне нравится направление мысли), context-local, bridge-ready naming и так далее. А дальше читать невозможно, ибо чёткой ontological lattice в FPF нет, поэтому примеры десигнаторов сразу ужасны: по идее там надо привязаться к уровням какой-то шкалы (уровни иерархии), а для этого см. все проблемы начала этого поста: нужны общие/универсальные/трансдисциплинарные/верхнеонтологические/“первопринципные”/мета-мета-мета-уровневые механизмы характеризации (как взять предмет разговора и получить его набор характеристик), как измерить, как нормализовать, как дальше вынести нормализованное значение в те самые “уровни” (scoring), как сравнить и уж потом как привязать имя к тому, что там получилось. И это надо делать для характеризации и сравнения квазаров в дальних галактиках, арбузов на рынке, традиций системной инженерии, качества обслуживания в химчистке, но и даже для имён в ходе десигнации: какие-то из этих имён подходят лучше, какие-то хуже, им надо присвоить поэтому характеристики, затем измерить, затем нормализовать замеры, затем сравнить, часть этих характеристик выбрать индикаторами, а часть – целевыми показателями, чтобы выбрать из них лучшие имена. А потом? А потом означковывать всё вокруг, начиная с понятий самого FPF и заканчивая архитектурными квантами в тех системах, которые мы создаём.
Самое интересное произошло после написания этого текста. Обычно после написания я даю по-быстрому проверить этот текст GPT-5 (не Pro, ибо “по-быстрому”) на содержательные ошибки и потом прошу нарисовать картинку, по картинкам я их потом легко различаю в ленте. Но сегодня вдруг вместо содержательных ошибок сетка восприняла этот текст как мой план действий (правильно! это же “Лабораторный журнал”, мышление письмом/моделированием), заглянула в соседние чаты и нашла там всё недостающее, и вдруг выдала абсолютно осмысленный план моих ближайших действий: какие паттерны писать первыми, какие править, что там менять и т.д. – и даже FPF в этом чате нет, он подкачался из соседних чатов. Контекст всё-таки решает. Выигрывает даже не самая умная сетка, а выигрывает сетка с правильным контекстом.
