Семантический треугольник 45 лет назад: " всего три! всего три вещи! но я уже пятый день не могу их внятно связать друг с другом!"
Удивительно, но я занимаюсь в эти дни тем же, что 45 лет назад, в 1980 году: семантическим треугольником. Тогда мне крупно свезло: моё распределение в университете потеряли (удивительно!) и неожиданно дали мне в связи с этим освобождение (чего была почти нулевая вероятность), затем меня месяц мурыжили и таки не взяли работать в вычислительный центр РИНХа, а потом приглашавший меня туда Женя Самойлович, который до этого работал в ВЦ РГУ сказал, что дико извиняется (потом уже стало понятно, что меня не взяли из-за пятой графы) и организовал блат на должность инженера в исследовательском ВЦ РГУ, в отдел прикладных задач (ОПЗ), или как его называли – отдел прикладных забот. Когда я пришёл туда, я зашёл в дико накуренный кабинет начальника отдела, Гарегина Карапетовича Тер-Григорянца, набитый дико курящими мужчинами и женщинами (это был 1980 год, тогда половина программистов, если не больше, была женщинами, старая ещё традиция), представился – и получил первый вопрос: “какие у вас отношения с математикой?”. Я нагло заявил, что “какие надо, такие и будут”, народ в этом сизом дыму упал под стол смеяться, а начальник объявил, что я принят. Я тогда ещё не знал, что ОПЗ занимается проблематикой искусственного интеллекта как это понималось в 80е, то есть экспертной системой на базе чего-то вроде фреймов Минского.
Одно из первых рабочих заданий было – помочь с описанием строительства здания. Вот справочник по строительным нормам, в нём стоимость каждой операции, надо просто описать что там за операции, а потом ЭВМ (тогда не было никаких “компьютеров”) возьмёт моё описание, данные из справочника по стоимости этих операций и подсчитает сметную стоимость. Всё ли мне понятно? Да, всё. ОК, тогда иди и делай. Я быстро осознал, что в справочнике приводятся атомарные операции с их ценами, но не написано сколько каких операций делать и вообще плохо понятно, что такое операции, ибо они были вроде бы одинаковые, но параметризовались материалами и объёмами, а ещё как-то группировались. ОК, мне надо было сделать DSL (тогда таких слов не было, ну да ладно) для описания строительства дома, но начальник мне вежливо объяснил (это был первый мой научный руководитель, и он же – последний), что его учил ещё его научный руководитель, что задачу надо решать в общем виде, а не в конкретном, ибо при маленьком шевелении ситуации частное решение развалится, а общее – нет. ОК, я взял книгу кулинарных рецептов и начал изобретать язык, который позволит записать кулинарные рецепты (они же абсолютно шаблонные! почти формальный язык!) так, чтобы это можно было засунуть в машину. И быстро выяснил, что почему-то это никак не получается.
Тут начальник подсунул мне идею: вот есть какой-то объект в мире (дом, картошка), есть строчки на языке программирования, которые его описывают – и есть некоторое представление о том, что именно надо в этом объекте описывать, ибо описывать-то можно разное. Поэтому думать надо о трёх вещах: объекте, знаках его обозначающих, и о понятии об объекте. И я пошёл думать об этих трёх вещах. Дальше я хорошо помню, как дней через пять усиленного думания я был злой как чёрт: всего три! всего три вещи! но я уже пятый день не могу их внятно связать друг с другом! Так в 1980 году я познакомился с семантическим треугольником (символ-мысль/концепт-объект/референт), треугольником Фреге (символ-смысл-значение/референт) в их тесной связке, и дальше как там всё это ни называлось.
45 лет спустя: ищем корень зла, и находим его в понятии “места в отношении”
Проходит 45 лет – и я последние дней пять борюсь опять с этим семантическим треугольником, поскольку мне надо его внятно изложить как один из первых принципов в форме, понятной для нежити. Причём некоторое время назад я это уже начерно сделал, это паттерн “C.2.1 – U.Episteme — Semantic Triangle via Components”, где даже уже сказано, что там не совсем треугольник, а даже возможный параллелограмм, и в этот параллелограмм не входит даже носитель, и даже не входит описываемый эпистемой предмет.
В новом заходе я работал над графом трансдукций (ага, “как записать операции, которыми мы строим дом или готовим борщ”, всё как 45 лет назад), дальше понимаем, что их как-то надо многоаспектно описать – и для этого нет ничего лучше ISO 42010, обнаруживаем, что у нас есть уже три разных описания того, как делать описания:
- как пакетировать-структурировать самые разные описания (паттерн MVPK). Идея в том, что “описание описаний” тоже имеет views: PlainView, TechCard, InteropCard, AssuranceLane for every edge/node where publication occurs.
- а ещё инженерные views, хорошо знакомое системное описание по ISO 42010: функциональное, конструктивное и т.д. Этого нигде нет, поэтому записано прямо как часть паттерна E.TGA – (Eulerian) Transduction Graph Architecture".
- ещё у нас есть strict distinction между объектом и его описанием, а также спецификацией I/D/S (intention, description, specification). Интенсиональный объект (всё что угодно, что попало во внимание), его описание и более-менее (начиная с уровня формальности описания F=4) формальное описание уже с именем “спецификация”. Дико криво, но всё руки не доходили: там ведь два разных отношения, держать их вместе – абсолютно плохо в части модульности.
ОК, останавливаем работу над реализацией задания на TGA (его объём уже 324Кзнака). И пишем задание на реализацию первопринципных multi-view описаний. С трудом, но появляется задание на набор паттернов этого multi-view, где само “описание” давалось как проекция: effect-free morphism (в отличие от механизма, у которого как раз внешние эффекты – кто сталкивался с теоретическим пониманием отличий процедурного и функционального программирования, тот всё быстро поймёт). Есть 1. эпистема, дальше определяем 2. морфизм над эпистемой как математический язык (гарантия того, что на верхних уровнях “всё сойдётся”), дальше на базе морфизма строим 3. содержательные рассуждения про view-viewpoint-description, обобщённый аналог 42010. И упираемся в то, что нежить дико путается с понятием aboutness, вот прямо всё разваливается. ОК, начинаем изучать, что там не так – и хотя бы “как это назвать”. Появляется набор имён: AboutnessTarget, DiscourseReferent, EpistemeReferent, FocalEntity и ещё много чего разного вроде EpistemicAboutnessEntity. Появляется побочный результат от этой работы: улучшение паттерна F.18 по генерации приличных имён, и там даже не все ещё идеи реализованы. А нежить несёт и несёт: в жизни это Entity-of-Interest (из ISO 42010:2022, там тоже сделали попытку оторваться от систем и перейти на “что угодно”, но попытку я ругал, и правильно ругал – там исчез grounding на системы в надежде, что кто-то его сделает, но вот я бы о grounding явно сразу говорил), ещё в FPF часто встречался object=of=talk, и таких имён “объекта в руках” (ещё одно имя) – десяток основных.
Я чешу затылок и предлагаю встроить в название отношение/операцию, сделать pragmatic turn: DescribedEntity. Всё вообще рассыпается: нежить оказывается в том же положении, что и любая мокрая нейросетка, которая пытается разобраться с семантическим геометрическим представлением о понятии: треугольник, параллелограмм и всякое такое столетней давности. Да это же я в 1980 году! Ну, или наши инженеры-менеджеры, которые только-только занялись моделированием на первых стажировках МИМ, там они как раз знакомятся с этим самым семантическим параллелограммом и впадают в то же состояние, что и я: такие умные и блестящие, но что-то никак не удержать в мышлении четыре его вершины!
Принимаю решение переписать и C.2.1 – переопределить понятие эпистемы, она же knowledge unit, meme, description и ещё кучи других похожих (спасибо F.18, “горшочек варит”, с именованием стало попроще - за час делается то, на что раньше у меня уходило несколько дней размышлений). И заодно обнаруживаю, что надо переписывать “A.7 – Strict Distinction (Clarity Lattice)” с его I/D/S, ибо там явно засел кусок эпистемы: этот самый AboutnessEntity и Description, хотя и не multi-view, не хватает только “понятия”. И ещё под ногами всё время путается TopicHolon, который довольно быстро переименовываем в том же стиле “морфизации всего” в GroundingHolon – и неожиданно нежить быстро соглашается.
И вот тут пошло топтание на месте, абсолютно уже мне непонятное: нежить никак не могла сообразить, что табуретка и её чертёж в I/D/S и в эпистеме – то же самое. Ибо в одном месте это Entity, а в другом – DescribedEntity, дураку же понятно, что это разное, “буквы не сходятся”!
И я вспоминаю, что мне говорила Пион: её впечатлило, что наши инженеры-менеджеры не в состоянии разобраться в том, что находится в месте n-арного отношения. Её это очень удивляло, но факт – и поэтому она приняла решение просто дополнительно тренировать инженеров-менеджеров, вставить ещё одну ступеньку в и без того пухнущее объяснение того, как устроено моделирование мира (одно из потенциальных имён эпистемы было – “модель”, я не говорил?). Пока этого понимания нет, мы не можем определить эпистему – она ведь просто “многоместное отношение многих разных вещей” (а там сложнее, например, тип эпистемы – “многоместное отношение с сигнатурой”, инстанс эпистемы – это конкретный кортеж, достроенный до “карточки с полями”, и дальше уже инстанс карточки – публикационная сущность, где все поля уже заполнены и публикуются как набор view под какими-то viewpoints)! Да, там “черепахи до самого низу”, говорить и что-то обсуждать на этом языке невозможно, но если вам потребуется слить два разных описания какого-то сложного инженерного объекта (скажем, атомной электростанции, у меня было много проектов на эту тему), то вам нужна именно такая точность, именно такая подробность.
Эпистема – что же это такое? Ах, лучше это слово вообще запретить.
Обратите внимание, у меня было спутано в предыдущем абзаце разное:
– эпистема - это knowledge unit, meme, description
– эпистема - это многоместное отношение многих разных вещей
– тип эпистемы – это многоместное отношение с сигнатурой
– инстанс эпистемы – конкретный кортеж, достроенный до карточки с полями
– инстанс карточки эпистемы – и вы ещё не запутались в этом всём, ибо поля уже заполнены и публикуются как набор views? Это одна и та же эпистема с одним и тем же типом и разные на неё views, это разные объекты в их связанном как-то knowledge graps, который описывает эпистему с её типом, или это одна и та же эпистема, у которой скачет её онтологический тип в каждом упоминании в моём тексте? Проще, если писать слово эпистема вместе с её типом: EpistemeKind (это "многоместное отношение), EpistemeTuple (заполненный кортеж, до публикации, абстрактный), EpistemeCard (“карточка”, тот же заполненный tuple но уже с репрезентациями), EpistemePublication (что там публикуется), и это даже не весь список того, что надо для более-менее точного и практичного описания. И ещё я сказал, что эпистемой часто называется какое-то view, но это рекурсия, ибо view у эпистемы, и это же эпистема!
Итак: у нас есть эпистема с её типом “многоместное отношение” (а за каждым отношением есть глагол/морфизм!), в котором есть слоты (слоты – это чтобы не путать их с “ролями”, ибо роли у нас в RoleEnactment и там только холоны с их ролевыми масками). Мы говорим, что "слово эпистема будем использовать только в заголовке паттерна, а в остальных местах – EpistemeKind как тип, и это n-арное отношение, EpistemeTuple как кортеж значений без репрезентации, “инстанс отношения”, EpistemeCard как инстанс кортежа с репрезентациями до публикации, EpistemePub как опубликованная карточка с перепакованным под viewpoints и интересы/concernd содержимым, EpistemeView как срез из EpistemePub). И тут довольно тонкий момент: тут полно отсылок к отношениям, сигнатурам, спискам параметров. И в них – слоты, и это настоящая засада.
Из засады выскакивают слоты/параметры/места в отношениях и сигнатурах
У слота есть аж три типа/вида:
- SlotKind, имя вида/типа слота (у нас это DescribedEntitySlot). В случае параметров, например, AgeParam. “ОписываемаяТабуретка” исчезает, это “СлотОписываемойТабуретки в морфизме/отношении”, а не “описываемость как принадлежащая табуретке”). За пределами морфизма и его слота никакой “описываемой табуретки” нет, есть только “табуретка”, а в морфизме есть “слот описываемой табуретки”. DescribedEntity не существует как сущность, это только имя для слота!
- ValueKind, имя вида/типа того, что находится в слоте по его мнению: это, конечно, Entity (ссылка на Entity, независимо от described). В случае переменных, например, Integer.
- RefKind, вид ссылки, которой заполняем, DescribedEntityRef. В случае переменной/слота “возраст” это AgeRef, которая может указывать на место, в котором лежит какое-нибудь целое (скажем, лежит 67). И тут опять же тонкости, знакомые программистам: все программисты путают “передачу аргумента по ссылке” и “передачу аргумента по значению”: и нехорошо путать ссылку-адрес и само значение, находящееся по этому адресу. Тут тот же самый адъ с коровниками, но различать “по ссылке” и “по значению” приходится уже не только программистам. Это первые принципы, ломка мозга на то, чтобы мыслить точно про то, про что мыслить полезно, а не потакание мозгу на то, чтобы мыслить абы как про абы что.
В жизни, конечно, так точно никто не будет говорить: это длинно, поэтому будут сокращать и использовать метонимию (вместо объекта-1 говорить про какой-то другой объект-2, находящийся с объектом-1 в каких-то отношениях, иногда по весьма длинной цепочке простых отношений). Дальше нейросетка должна делать “дисамбигуацию” (то есть восстановить, что же там имелось ввиду), но на 9 успешных разов “растуманивания смысла” будет приходиться 1 неуспешный – и эта ошибка будет выливаться иногда в секунды, иногда в часы, иногда в месяцы мороки по исправлению.
Теперь добавим ещё отличие имени от названного объекта, когда “если на клетке со львом написано “осёл” – не верь глазам своим”, имени типа объекта от имени значения.
С этим всем нейронные сетки страшно путаются, что живые, что не очень живые. Так, у нежити регулярно появляется DescribedEntityRef, DescribedEntity воспринимается не как имя слота, а как сама описываемая “Entity” (ага, как “описываемая Entity”, кавычки поставлены по-другому), как раз проблема с “невозможно понять, что там как называется в слоте кортежа” – а также в ситуации с системой во множестве ролей, функцией со множеством параметров, сигнатурой и т.д. Онтология – это не математика, не исправление ошибок в коде. Это связка между математикой (язык, которым всё называется) и реальной жизнью (нарезка мира на какие-то объекты, похожие в своём поведении на математические объекты), но при этом ещё и надо учитывать лексику – чтобы имена как-то соответствовали тому, что хочется выразить. Вот это всё “первые принципы”: как мы говорим о мире так, чтобы не путаться на каждом шагу. Вот это и надо тренировать в мышлении. И вот я уже 45 лет тренирую, но всё равно иногда путаюсь: уж больно убедительный тон у нежити, и я ей прощаю ошибки там, где должен был бы жестко на эти ошибки указать. Да, “семантический треугольник = эпистема с обсуждаемыми слотами “about, content, token” и замолчанными остальными, и этих остальных там – до чёртиков”.
Обратили внимание на то, что две последние строчки совпадают по формулировке, но имена там разные? Вот она, главная засада! Есть “ОписаниеДлиныТабуретки” (намеренно опустил Slot), в нём есть “СсылкаНаОписываемуюДлинуТабуретки”, она указывает на “ОписываемуюДлинуТабуретки” – мы же её описываем! Это не просто “ДлинаТабуретки”, а “ОписываемаяДлинаТабуретки”, которая в слоте! Ах, это не слот-контейнер, а ссылка? Да всё равно, binding/привязка есть! Правда же в том, что “описываемой длины табуретки” у табуретки нет, она есть у операции “описывание табуретки”! “ОписываемаяДлинаТабуретки” сама по себе в других ситуациях – просто “ДлинаТабуретки”. И ещё за ДлинойТабуретки тянется сама табуретка, как GroundingHolon – чтобы тыкать пальцем в табуретку, обсуждая, где её длина, а где ширина и как называть их для квадратной табуретки.
Это типичное “два юриста, три мнения”. Проблема, действительно, в непонимании, как в общем виде говорить о месте в отношении. И ровно то же самое с ролями: там есть система (Вася) система-в-роли (Вася-Инженер), абстрактный объект “роль” (Инженер), возможность системы выполнять роль (capability Инженер, понятие capability в FPF определяется немного не так, как сейчас в руководствах, но это нюансы). И дальше путаница Васи, Васи-Инженера и Инженера-роли и ИнженерногоМастерства у Васи. В случае отношения и его слота/места – всё то же самое, в общем случае мы вместо capability можем ввести eligibility. И засада в том, чтобы не путать, когда там надо ставить Ref/Slot, а когда там имя объекта – как “объекта из слота” и “объекта самого по себе”, два варианта. Старая онтологическая дискуссия, один из выходов тут – не поминать “морфированныйX” (например, ОписаниеТабуретки – “описание” это как раз отсылка к морфзиму) без суффикса Slot или Ref, чтобы не путать с “объектом отдельным от морфизма”. Но в жизни, конечно, ничего этого не будет: вы никогда не будете помечать “описанную нами табуретку” каким нибудь Slot. Если ты начал онтологизировать – оставь надежду, что вокруг тебя будет всё онтологичненько. Не будет. Но это не означает, что всем этим не нужно заниматься. Чисто не там, где не сорят. Чисто там, где убирают. Энтропия сама себя всегда повысит, а вот снизить её – это наша задача, природа же при этом будет упруго сопротивляться.
Какой тут наш ход? Мозг сам по себе это всё различить не в состоянии, поэтому мы даём ему поддержку в виде правильной нотации: имена SlotKind, ValueKind, RefKind.
Ближайшие планы с FPF
Так что сейчас я занимаюсь тем, что буду:
– определять общую дисциплину описания объектов в слотах отношений (там до сих пор лексическое сопротивление: упорно появляется невнятное facet/аспект как episteme facet slot вместо просто episteme slot. Это значит, что есть ещё недоговорённости. Ибо когда всё устаканивается концептуально, проблемы кончаются у нежити сразу всех производителей, а когда не устаканивается – проблемы у нежити тоже всех её производителей). Это важная штука, ибо всякие “проходы по мантрам” в наших руководствах – это ровно то же самое: наведённое “слотами” внимание на объекты и неожиданная смена имени, когда ты берёшь “инженера”, а видишь-то Васю, и наоборот. Это те же самые “яблоки из задачи” против “яблок, которые едят”. И тут ещё pragmatic turn, что все эти view-viewpoints про операции, а “объективных” и “нейтральных” взглядов не существует.
– определять понятие эпистемы из примерно десяти компонент, каждая из которые ещё и имеет много деталей (и вот почему все путались, ибо это не “три угла треугольника” столетней давности): 1. DescribedEntitySlot – “о чём говорим” (и на том конце будет потом Entity/сущность), 2.GroundingHolonSlot — “на каком холоне заземляем” (и на том конце Ref будет GroundingHolon или просто Holon, 3. ClaimGraph – замена мутного “понятия/concept” из старого треугольника, 4. RepresentationScheme – как устроена репрезентация (язык/нотация/формат или латентное пространство в распределённых представлениях), и там же допустимые операции репрезентации. Тут много SoTA: работы Dutilh Novaes о формальных языках как когнитивных артефактах и инструментах де-семантизации/вычислимости, Krämer о notational/operational iconicity; при этом мы не фиксируем конкретный тип репрезентации (символьный, диаграмматический, латентный), а только место схемы в эпистеме как frame/“многоместном отношении”, описываемом в свою очередь “карточкой эпистемы”), при этом попытка обсуждать именно “операнды”, а сами операции будут в дальше, в RepresentationOperations, понятие Representation как раз сейчас активно детализируется в науке и инженерии. 5. RepresentationToken – конкретный экземпляр представления (формула, модель, AST, часть KV-кэша, диаграмма и т.п. в рамках выбранной репрезентации/RepresentationScheme, 6. PresentationCarrierRef — носитель информации, то есть файл, веб-страница, IDE-панель, бумажный лист, сообщение в шине, embedding в памяти LLM и т.д. (то, что обсуждают Novaes/Krämer/Malafouris в части “как материал/носитель/medium влияет на операции”, тут ещё разбираться надо будет с carrier/medium, сейчас оба синонима), 7. RepresentationOperations — описание морфизмов/операций по репрезентации, вроде умножения в столбик по репрезентации натуральных чисел в арабской арифметике (с атрибутом InferenceRegime – сюда ложатся и Novaes с двумя ролями формальности, и Krämer, и distributed cognition Zhang/Norman, и современные LLM-агенты), 8.U.Viewpoint – перспектива агента (и тут RoleEnactors, concerns/interests, допустимость/предпочтительность репрезентаций и операций в этих репрезентациях, вроде как “хочу МСФО, а не РСБУ для вашего финансового учёта”), это как раз из ISO 42010, дотянутый на любые описания, pragmatic turn – всё только потому, что кому-то очень надо, 9.View — представление/presentation под viewpoint, конкретный “срез” ClaimGraph про DescribedEntity под данным Viewpoint и в данной RepresentationScheme (грубо говоря, “вот ваша выборка по запросу из базы данных”, тут Viewpoint как язык запросов), и именно это View чаще всего и называют Description, а поскольку их много, то ещё и проблемы как о них говорить, и их ещё и называют эпистемами, 10. ReferenceScheme – и вот тут довольно много всего, что позволит надёжно привязать граф утверждений и токены репрезентации к GroundingHolon, чтобы ухватить DescribedEntity и проверить – описание как-то соответствует описываемому объекту, или нет. В частности, тут Correspondences (как соответствуют друг другу разные Views под разными Viewpoints, Bridges из FPF и т.д.).
– возвращаться и доделывать эйлерианский граф потока трансдукций,
– а потом уже с его помощью продолжу раскатывать цепочку “от принципов к работе”.
