Ролевые/функциональные сущности в описаниях

Онтология описаний -- это очень мутное дело, потому как для договорённостей в физическом мире мы можем использовать 4D экстенсионализм, говорить о вполне понятных отношениях часть-целое и системном мышлении, а в мире абстрактных объектов в этом отношении сразу всё плохо. Поэтому в учебнике системного мышления я сразу сделал оговорку, что наша версия относится к инженерным системам, которые будем считать находящимися в физическом мире. И это было ключевым моментом. После этого всё сразу стало понятно про ролевые/функциональные сущности и их функции, а также про конструктивные/физические объекты и их сервисы, а также отношении реализации как отсылке к этому самому 4D экстенсионализму (функциональный объект/роль, которую играет конструктивный объект. Ленты в теле делаются мышцами, костями и фасциями, да ещё и в каждый момент разными, река делается протекающей в ней водой, да ещё и разной в каждый момент). Интеллект как мыслительное мастерство дан как роль-вычислитель с функцией-мышлением, реализованный неизвестной конструкцией-из-мозга. Всё отлично, всё работает. С описаниями всё плохо, но мы время от времени флегматично замечаем, что классическое системное мышление игнорирует онтологические разборки и использует системное мышление для описаний абсолютно интуитивно и неформально, проводя отношение часть-целое среди описаний уж как придётся, а что касается функциональных ролевых и физических объектов, так такая проблема есть, но мы её временно игнорируем. Насколько насущная эта проблема "системного мышления для мира абстракций"? Вообще-то в "Образовании для образованных 2021" сам интеллект-стек дан как платформенные уровни объяснений разных практик, работающих с вполне себе абстрактными функциональными объектами. И умолчано, что там является объектами конструктивными (ибо они там явно не физические). Ходов с системностью описаний может быть несколько, и решать нужно как проблему композиции описаний (X is_part_of Y), так и проблему реализации (role X is_realized by Z). Я нарочно не пишу тип Z, ибо открыт вопрос и в том, может ли роль/функциональный объект быть реализован другим функциональным объектом (то есть "никаких физических объектов нет, а там ролевые объекты до самого низу"). То, что тут с типизацией Z мутно даже в физическом мире, легко обнаружить по гамбургер-диаграмме, https://www.researchgate.net/publication/273126714_General_AEC_reference_model_GARM_an_aid_for_the_integration_of_application_specific_product_definition_models. Оставим пока проблему собственно "системности" и подумаем про ролевые/функциональные объекты, и те, которые их играют. При этом учтём, что "роль в отношении" и "ролевой/функциональный объект/сущность" -- это про разное. И учтём, что про 4D роли был отличный обзор у Мэтью Веста, https://drive.google.com/file/d/1O8bsQJ9GVcI_WtHNdKqNC5ZLQIsJNxzn/view?usp=sharing. Какие очевидные ходы? -- считать, что ролевые сущности это типы/классы, а значения типов -- это "из чего они сделаны", то есть конструктивные сущности это "объекты во множестве" (и дальше обычный разговор про "вечные множества", если это типы и что делать, если в жизни изменяется число и состав сущностей во множестве). -- разобраться с природой affordances (см. материалы по тому, как что-то становится средством для агента), см. заходы в https://ailev.livejournal.com/1593746.html и общая работа с "обесцеливанием, но обучением/познанием", там тоже ведь есть про affordances в https://ailev.livejournal.com/1592493.html. Двойственность названия ролевые/функциональные сущности: указание на "функциональность" -- это и есть аспект affordance в плане телеологии, использования для устранения беспокойства/минимизации функции потерь или свободной энергии, уж как больше нравится, а ролевость тут affordance в плане обязательной реализации каким-то объектом из жизни, "конструктивом". -- считать, что ролевой объект -- это переменная, которая всегда что-то означает ("начальное значение ролевого объекта", в какой-то мере это роднит подход с теорией прототипов как "первым значением типа", и предыдущим пунктом про классификацию). Именем роли-переменной является хэш того, какие значения она принимала, то есть там ещё и какое-то управление конфигурацией встроено в модель, "работа со временем и возможными мирами", включая возвраты в этих мирах и попытки работать тем самым с контрфактуальностью. Описано это у Валерия Крылова в https://justy-tylor.livejournal.com/257665.html. IMHO это ужасно, ибо это не имя функционального объекта с накоплением знаний об affordances, а абсолютно технические (криптохэши) имена, и мы тут же влезаем в древнюю дискуссию о различиях идентификаторов и десигнаторов. Когда-то мы с vvagr устроили разговор про это в сообществе ISO 15926 и там их различили, это оказалось важным -- и десигнация, и идентификация. Вот и тут, нужно опять возвращаться и говорить про эти различения. И вспоминать и другие разговоры с Валерием про те самые роли (один из них он и сам вспомнил, про те же роли мы говорили в комментах тут: https://ailev.livejournal.com/1470152.html?thread=16180424#t16180424). -- ... хорошо бы иметь тут и другие ходы, но пока особо нету. Ещё одна поправка может быть про ролевые/функциональные сущности/entity против объектов/objects. Объект это всё, что во внимании. И тут вопрос про внимание на сущности и отношения между ними. Объектами могут быть и сущности, и отношения. Деление на объекты и отношения вроде нехорошо, ибо отношения и сами объекты. Поэтому не поправить ли ролевые/функциональные и конструктивные объекты на сущности? Или это мало кого волнует, включая самих онтологов? Важней что, что ролевые объекты/роли существуют, или что они нам важны и отслеживаются вниманием? Онтологическую работу можно только начать, закончить её нельзя. Бонус: необходимость онтологического разбирательства с объяснениями решения проблем разных subject matter experts в Julia, ибо они не справляются с объяснениями для пришедших экспертов в других языках программирования. Тред начинается с проблемы "приход питониста или сишника в Julia", которую я описываю как ""Садимся в лифт. Так, а где здесь руль?"", читать много реплик с https://t.me/JuliaLanguage/24350, и там про одинаковость проблемы в танцах и в Julia, и я замечу, что и проблемы, решаемой в текущем посте: роли нам нужны как раз для разделения пространства проблем и пространства решений (потребных функциональных сущностей и реализующих их конструктивных сущностей -- разделение внимания на "цели" и "средства", хотя для "бесцелевого" подхода нужны другие слова, все эти affordances). Два понятия, "для чего" и "на что направлено внимание". Это работа с типами, выдача объектов внимания какого-то заранее известного типа для обнаружения этих объектов (функциональных и конструктивных в жизни). Это общее для самых разных предметов, включая танцы. Если у вас в голове объект внимания типа traits, то вы будете искать экземпляры traits в Julia языке, Julia коде или в любых других местах, связанных с программированием. А поскольку у entity типа traits есть связи с class и method, то будете по сопричастности искать классы и методы (и найдёте даже какие-то слова похожие, и будете нещадно путаться). Наверное, нужны какие-то другие объекты внимания, когда говоришь про программирование на Julia, чтобы отслеживать другое. В танцах то же самое: движение это очень сложная штуковина, и за чем там следить — вопрос теоретический. Так, нормальное обучение танцам на телесном уровне идёт через координацию мышечных лент, а вовсе не через "движения". Движения тут следствие, если ты правильно наладил эти ленты. Новичку в танцах, или танцору из провинциальной студии сам объект "лента" неведом, ибо вниманию к этому объекту, операциям с ним в собственном теле нужно учить (а в танце обычно требуется скоординировать три ленты, что не так-то просто — и именно эта координация отличает танец новичка от танца опытного танцора). Снаружи лент не видно, это объекты внимания, доступные внутреннему восприятию и внутреннему построению из собственных костей, мышц, фасций. Это функциональные объекты. Вот с Julia все те же рассуждения. Объекты и внимание к ним задаются многоуровнево, и с этим нужно работать явно. Вот некоторый фрагмент текста, это объясняющий. Он и для Julia будет работать (хотя его нужно будет, конечно, адаптировать): https://ailev.livejournal.com/1594529.html Тут нужно чётко понимать, что в предметной области никаких traits нет, и в программировании как таковом нет. Но есть проблемы, которые нужно выразить в языках с разными абстракциями. Вот сначала нужно про проблемы говорить эти как объекты внимания и их типы, не слишком зависящие от языка программирования. Можно пообсуждать, как это. Но вот разговор про умножение матрицы можно сразу вести "как будто будем умножать на фортране", или "как будто будем умножать на питоне", или "у нас Julia, всё в порядке". Это может оказаться разный разговор. Поэтому сначала обсуждаем умножение матриц в терминах этой предметной области, а потом обсуждаем, как это сказать по-русски, по-джулийски, по нейросетевому. Что касается самой предметной области программирования, так нельзя считать, что это область ООП и обсуждать её в терминах ООП и как эти entities из ООП выражаются в языке. Часто ответ будет "никак не выражаются, мы это делаем по-другому". Проблема в том, что "это" не делаем по-другому, а вообще не делаем. Ибо "это" не явлено, нет решаемой проблемы, данной вне множества понятий парадигмы языка! Слово "это" указывает в пустоту! Без онтологической проработки будет в Julia как с танцами: кто интуитивно понял "через опыт работы" про то, чем Julia отличается от классического ООП и классической функциональщины, тот и молодец. А кто не понял, тот не молодец: он пришёл, что-то спросил, ему не смогли ответить, он плюнул и отвалился. А надо уметь объяснять, отвечать на вопросы. Но вся эта "онтологическая проработка" заключается в том числе в решении вопроса про "объектность и прикладность" (одно для собранности/внимания и восприятия, другое affordances и прагматичность) не только в физическом мире, но и в мире описаний. Ничего, потихоньку и тут прорвёмся.