Я существенно обновил F.18, воткнув туда четыре лексических оси. Теперь имена выбирать много, много легче! Если хотите понятийный минимум, то давайте свой текст, а потом для термина просите name card по F.18 - и дальше радуйтесь. Как выбрать название должности? Три строчки объяснения ситуации, пару итераций – и у вас, например, название должности (первое же полезное использование у меня оказалось именно таким). Tech (техническое имя) и Plain (имя для “простых людей”) оказались просто именами с Парето-фронта на шкалах:
– SemanticFidelity (P — Ontological precision). Question: Does the label verify against the “Minimal Definitional Statement (MDS)” and Concept-Set row without adding or losing core invariants? Scale: Exact ≻ Precise ≻ Vague ≻ Misleading.
– CognitiveErgonomics (S — Sociolinguistic admissibility). Question: Can the target RoleEnactors (engineers, managers) read, pronounce, and recall the label without specialist training? Scale: Natural ≻ Acceptable ≻ Jargon ≻ Alienating.
– OperationalAffordance (O — Morphological/action alignment). Question: Does the morphology of the label hint at its role in methods/morphisms (object vs process vs result) and support the required derivational family (noun/verb/participial forms)? Scale: Opaque, Role‑hinting, Action‑aligned. Action‑aligned labels make it obvious whether we are naming an actor, an activity, or an artifact (e.g., Author vs Authoring vs AuthoredArtifact). When the Kind is a Role, prefer agentive/holder morphology (…Role, …er, …or or local equivalents); when the Kind is Method/MethodDescription, prefer verbal or gerundive forms; when the Kind is Holon, prefer result nouns, when Work, prefer verb. Misaligned morphology (e.g., a Role named with a pure process noun) should be treated as a penalty on OperationalAffordance and, if retained for legacy or regulatory reasons, called out explicitly in Card notes.
– AliasRisk (A — Lexical overload). Question: How likely is a careful reader to import a wrong sense from neighbouring FPF artefacts or external canons when they see this string? Scale: Safe ≻ Context‑dependent ≻ High‑Risk ≻ Overloaded.
Дисциплина именований в слотах сигнатур (читай: как думать об интерфейсах) на месте – паттерн A.6.5 в FPF, и сигнатура (для которой этот паттерн и делался) как-то с ним согласована, правила использования суффиксов для ссылок в E.10 поставлены. Осталось весьма сомнительное место, ибо не очень понятно, как называется та штуковина, которая встаёт на место в слот. Расхожее слово тут “роль в отношении”, но как всегда – то ли это “маска”, то ли “сам объект”, язык остаётся мутным. Замены – это occupant в slot, не очень понятная штука. Ведь можно вставать в слот “ссылкой”, а можно “значением”. Рекомендация – избегать вообще называть этот объект, а пользоваться тройкой SlotKind, ValueKind, RefKind и использовать дальше предметно-специфичный язык. Я не ожидаю, что эта дисциплина будет выполняться, ибо один из комментов нежити был очень правильный: эта дисциплина явного именования видов в слоте задаёт очень много метаданных, ибо ранее безымянные сущности вроде “места в отношении” теперь требуют задания явного имени, а неявная типизация становится явной. Дополнительное моделирование “из ничего”. Поэтому без автоматизации вряд ли взлетит: дополнительная нагрузка на авторов, авторы-люди ничего этого делать не будут. Автоматизации же пока нет и не предвидится – ибо опыт показывает, что даже нежить игнорирует всю эту возню с формализацией интерфейса. Интерфейсы – это боль, это всегда трудно, это архитектурная работа, вершина инженерного мышления. Но теперь, если будут какие-то проблемы-затыки, то есть куда смотреть, там даже какие-то примеры (их даже не проверял). Ещё под эту дисциплину подхакан паттерн сигнатуры, A.6.0. Теперь можно задавать вопросы о том, что там с именами в слотах/аргументах/параметрах, ибо там и по значению передачи бывают, и по ссылкам, всё это надо было как-то указывать в лексике, чтобы был понятен тип находящегося в слоте: указатель/ссылка/адрес или сам объект. Как это использовать? Например, можно не просить людей писать это (делать из текста Rust/C++), а заставить AI валидировать написанное и ругаться, если тройка не восстанавливается из контекста однозначно. Если AI не может вывести RefKind (ссылка это или значение) из текста, значит в тексте что-то не то.
Ещё я в тексте с трудом, но удавил лексему AboutnessTarget, там везде осталось DescribedEntity – можно спорить, стало ли понятней, но инженерам точно стало понятней, а всякие философы-онтологи подождут. И тут важно, что это как-то поддерживается лексически: там DescribedEntitySlot и DescribedEntity как ValueKind, а RefKind тут будет Entity. И в морфизмах там было тоже лексика от “about”, и замена была предложена на “topic” – в ручном режиме вернул на “одну лексику для одного смысла”, поэтому всё было поправлено describedEntityChange, и ещё там теперь не “ось” для этого “change” и не “поворот оси”, а “характеристика”. И не “вращение очёмности”, а “перенацеливание описываемой сущности”. В плане выбора лексики нежить очень тупая, совсем как люди! И тем самым я вернулся ровно в то место, где я прервался в прошлый раз: у меня есть новый текст паттерна “C.2.1 --U.Episteme – Epistemes and their slot graph”. И там minimal kernel nodes/positions/slots that every episteme can refer to (An episteme kind is a signature over these slots), и тут огромное количество вопросов, будет много жёсткой правки и по типам, и по именам:
– DescribedEntitySlot → “what this episteme is about”;
– GroundingHolonSlot → “where/how this is grounded”;
– U.ClaimGraph → “what is being said (intensional content)”;
– U.ReferenceScheme → “how we read claims as statements about entities”;
– U.Viewpoint → “under which viewpoint we read/validate this episteme”;
– U.View (U.EpistemeView) → “a view‑episteme produced under a viewpoint”.
– и тут ещё много слотов, если не ограничиваться “минимальным набором”, например, множество слотов для нотаций-репрезентаций. И, конечно, надо ещё будет поработать над этими именами. Скажем, referenceScheme может вполне стать InterpretationScheme, а в дополнительных слотах там появляется RepresentationScheme, она же NotationScheme, и тут F.18 нам будет сильно в помощь. Но эту возню с именами можно пока отложить.
И тут обычно идёт вопрос: а как же быть с семантическим треугольником? Приходится поминать и его тоже, и тут тоже будут правки:
– (Symbol) = RepresentationToken + ReferenceScheme + Carrier (носитель информации, заметим, в эпистему не входит, а в треугольнике вроде как есть)
– (Concept) = ClaimGraph + ReferenceScheme (+ Viewpoint)
– (Object) = DescribedEntity + GroundingHolon
Поговорили о семинаре 7 декабря, решили – он будет обзором того нового, что появилось в FPF после первого семинара: именование через выбор кандидатов имени по Парето на четырёх шкалах (F.18), сигнатуры-интерфейсы-параметры и их понимание, “нетреугольное” понятие эпистемы как слотового графа, эйлерианские потоки, пример эйлерианского потока “от принципов к работе”, способы работы с огромными текстами в современных AI-чатах (что не успел в прошлый раз). Но времени будет на всё это меньше: три часа. А потом? А потом – FPF всем доступен, можно будет это всё пробовать самому.
Идея программы исследовательского развития в том, что там уже нет стажировки, где тебе делают инструктаж и разборы/review того, как ты работаешь по руководствам. Но это такая же программа развития, как и программа личного и рабочего развития, только вместо стажировок – семинары, где рассказывается о новинках. У семинаров есть особенность: их материал обычно ещё не изложен где-то в разжёванной учебной форме, он не предполагает инструктажа, это всё для знакомства с новинками и задания вопросов докладчикам, которые “уже в теме” от тех, кто “ещё не очень в теме, но уже понимает, зачем оно” (иначе бы не оказался на семинаре). Вот я где-то раз в пару месяцев намерен делать такие семинары, знакомить людей с фронтиром. Как где фронтир? Ну, в каждом новом паттерне FPF теперь нормативный раздельчик SoTA-Echoing, и там отсылки к исследованиям, на базе которых построен паттерн. Так что программа исследовательского развития – это руководство по методам мышления интеллект-стека (немного устаревшее, аж на пару лет), мои семинары по новинкам в мышлении, а ещё open source FPF, который можно и изучать, и применять.
Сегодня меня спросили, что из наших трёх программ (личного, рабочего, исследовательского развития) я бы понёс в школьный-студенческий возраст. Возраст – это чтобы не было ассоциаций с учебными заведениями и экзаменами. Но вот чему бы учил? Личное развитие, как организовать себя и планировать судьбу, карьеру, уметь читать-писать и вести дневник? Ну, вполне можно, но это не очень много и не очень долго. Рабочее развитие? Ну, эти люди ещё не работают, и проектов какой-то существенной помощи другим людям у них нет, чтобы иметь инструктаж на эту тему. Работа – это ведь не про “как помочь себе”, а “как помочь другим”. Но вот исследовательское развитие в его простейшей форме: как думать о мире, как задавать вопросы, как разбираться с полностью новым, как там связаны математика и физика – это то, что пропущено в любой учебной программе официального образования и полностью пропущено в любой учебной программе частного образования. Так что мне сейчас понятно: учить деток надо первым принципам, ибо всё растёт из первых принципов, вот им и надо учить. Если владеешь мышлением по первым принципам, то всем остальным вполне можно овладеть.
Мне кажется, что детей можно учить первым принципам, особо не спрашивая их, хотят ли они им учиться. Конечно, дети не хотят ничему учиться, если их специально не заинтересовывать. У лучших учителей дети заинтересовываются. Но, сюрприз: к этим лучшим учителям их приводят родители – и некоторое время не дают сбежать, чтобы было время заинтересоваться. А сами дети к правильным учителям не попадают, они просто не догадываются об их существовании. Со взрослыми так не получается. Если сказать “вот буду учить первым принципам”, то придёт ноль человек. Поэтому текущая моя гипотеза: надо пройти программу рабочего развития, а потом двигать в исследовательское развитие и потихоньку знакомиться с первыми принципами, как с хобби. А затем применять – в чистых исследованиях (это хобби! наука всегда была хобби, это очень недавнее изобретение человечества отобрать насильно деньги у населения под угрозой тюрьмы в форме налогов и чуть-чуть из этих денег дать “на науку”) или в инженерных R&D, где это часть какой-то предпринимательской стратегии.
