Category: it

2019

Об цифровую трансформацию: то же оргразвитие, и даже не в профиль

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

Цифровая трансформация -- "цифровая" означает, что будет много компьютеров. Как будто их не было и в автоматизации! Автоматизация -- вроде как что-то делал человек, а потом это же стал делать компьютер. Но нет, если что-то стал делать компьютер, то он это будет делать по-другому, и человек тоже займётся чем-то другим: организация от использования компьютеров не столько "автоматизируется", сколько "трансформируется". Ага, с использованием компьютеров. По сути дела, речь идёт об организационном развитии

Можно было бы поддаться веянию времени и начинать говорить о цифровой трансформации, это ж синоним (цифровой -- компьютеризированный по самые брови, трансформация -- это как раз оргразвитие), но этот термин как придёт, так и уйдёт. Скоро, скоро уже заговорят о какой-нибудь "искусственноинтеллектуальной трансформации" или как это будет называться (когда выяснится, что подойдёт не просто работа с данными, а только работа с данными при участии машинного интеллекта), заменят компьютеры на квантовые -- это будет "квантовый оргскачок" и так далее. Вон, несколько дней назад Гартнер выдал новое слово "hyperautomation", гиперавтоматизация. Что, выучиваем и его? Больше buzzwords богу buzzwords?

Мы помним, что почта вдруг стала электронной, а потом просто почтой (а потом переписка ушла вообще мессенджеры и какие-нибудь Slack или MS Teams). Бухгалтерия тоже становилась механизированной (с Феликсами и табуляторами на перфокартах), а потом компьютеризированной, а потом осталась бухгалтерией.

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

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

Повторюсь:
-- компьютеры используются для того, чтобы была память для модели организации (архитектура, операционный учёт)
-- компьютеры используются для управления коллективным вниманием к этой памяти (issue tracking, управление работами)
-- компьютеры используются для принятия решений (машинный интеллект, и не нужно думать об AGI. Любое вычисление подойдёт, лишь бы не в голове человека).

Подробней об этом я писал в:
-- системная осознанность, https://ailev.livejournal.com/1487672.html
-- киборгизация людей и организаций: поднимаем осознанность, то есть рулим вниманием, https://ailev.livejournal.com/1488271.html

И мы всё это используем в нашем проекте развития -- использование информационных технологий в реализации стратегии Школы:
-- EdTech для blended learning -- те же PLM/ALM + CAD/CAM/IDE, только в образовательный профиль, https://ailev.livejournal.com/1473691.html
-- чего мне не хватает в MS Teams -- https://ailev.livejournal.com/1490524.html
-- стратегирование Школы системного менеджмента -- https://ailev.livejournal.com/1493744.html
-- видео семинара по созданию AIsystant и blended learning services, https://ailev.livejournal.com/1494270.html
-- чеклисты в blended learning services: не прощёлкать важное, но и не забюрократизироваться, https://ailev.livejournal.com/1497117.html
-- множество заметок в lytdybr (например, https://ailev.livejournal.com/1496250.html -- там я говорил про RPA как ведущий тренд)

Дальше нужно понимать, чем же именно проекты развития с компьютерами отличаются от "просто проектов развития". По большому счёту, ничем. Но в этих проектах развития заимствуется огромное число находок из управления жизненным циклом и управления работами из software engineering. В частности, в управлении жизненным циклом из существенных новаций можно заметить DevOps (плавно переходящее в NoOps, https://ailev.livejournal.com/1367897.html) и свеженький его извод SRE (site reliability engineering, включая обширную дискуссию его похожести и отличий от DevOps -- главным образом то, что в NoOps куда-то делись Dev, а в SRE они в полной мере присутствуют).

Так что отдельных курсов в Школе системного менеджмента по цифровой трансформации не будет, но тема вполне раскрывается -- это курс "Системный менеджмент и стратегирование", ибо день "совершенствование и развитие" (да и все остальные дни, впрочем, тоже) там как раз про вот это вот всё. Организаций без цифры уже не бывает вообще, организации без развития/трансформаций (конечно, с цифрой!) -- мертвы, и скорее раньше, чем позже.

В НИУ ВШЭ мы читаем также курсы в магистратуре "Цифровая трансформация образования" -- https://www.hse.ru/ma/dt/. Там, конечно, всё завязано на госбюджет, поэтому "цифровая трансформация". Мы же сказали бы просто: это школа менеджеров развития образования. Если есть практика организационного развития, то есть и деятельностная роль -- управляющие развитием, менеджеры развития.

В Школы мы сделали отдельный чат поддержки выпускников, которые ведут проекты развития в своих или в клиентских организациях. И в ближайшее время проведём несколько семинаров, где будем обсуждать их проекты развития (пока запланирована уже парочка, но их будет много, много больше). Отдельно говорить о том, что это проекты "цифровой трансформации", "информатизации", "автоматизации" и т.д. -- не нужно. Это само собой. По-другому не бывает.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216830525489499
2019

Лекция "Машинный интеллект 2019"

Читал сегодня в Высшей школе менеджмента НИУ ВШЭ кругозорную лекцию "Машинный интеллект 2019" для DBA (doctors of business administration). DBA это вроде как следующая ступень после MBA, и точно так же это совсем не научная или инженерная степень. Студентами там сидели вполне состоявшиеся руководители и предприниматели. Лекция шла целый день, четыре пары.

Вот программа, это просто заголовки слайдов (значения всех умных слов там разъяснялись "на пальцах" и примерах, а математики и программирования не было вообще):

1. Интеллект: машинный и биологический
Будущее уже здесь, только оно неравномерно распределено. Откуда взялся человеческий интеллект? Искусственный интеллект: "то, что компьютеры пока не умеют делать". В чём суть сегодняшнего прорыва в машинном интеллекте? Всё быстро. Глубокое обучение: глубокие абстракции. Почему только сейчас? Тезис Sutton, 13 марта 2019. Сингулярность. Примеры сегодняшнего (а не будущего). NLP — обработка естественного языка. Goal: capuchin-like. Скорость исследований: растёт по закону Мура. Как устроены исследования. Ловкость, embodied intelligence. Заземление/grounding и embodied intelligence. Творчество и соревновательность (adversarial architectures). Open endedness. Там нет "интеллекта", в чём тогда крутость? Как относиться к AGI. Принципиальная схема киберличности. Киберличность и работа с вниманием. Роботы заберут работу? Чьи это виртуальные ассистенты? Adversarial attacks, deepfakes и так далее. Нейтральность технологий.

2. Интеллект-стек
Системные уровни интеллект-стека. Эмерджентность. Стек платформ машинного интеллекта. Платформы машинного обучения. Главный алгоритм. Альтернативный стек глубокого обучения. Малая связность: ключ к развитию и совершенствованию. Метафоры жизненного цикла "компетенции" (в том числе машинной). Языковые модели. Загон данных (data wrangling), сантехника данных (data plumbing). Проблема innate priors. Моделирование, программирование, проектирование, онтологизирование, формализация — это всё одно. Машинное обучение и уровень когнитивной архитектуры. Перспективы.

3. Применения
Мечты человечества (как оценивать прогресс?). Деятельностный кругозор ("как устроена жизнь"): применения AI везде, где есть применение людей. Инвестиции в AI. Forbs: обзор 50 AI startups (17 cентября 2019). Сегодняшний фронтир: автомобили. Инвестиции сегодня, результаты завтра. Что дают дешёвые качественные камеры? Ножиданные виды сервиса и слежку. Машинный перевод. Офисный ИскИн, который построил Джек. Научные открытия. Интернет вещей (IoT), BigData и AI, тесно связанные с предсказательной аналитикой. Робототехнические заводы (тёмные фабрики). Корпусная инженерия. Код и AI модели как ещё один тип медиа: магазины и облака. Взять идеи из машинного интеллекта в педагогику. Основные проблемы. Цикл жизни инженерных технологий: пример AI. Дилемма инноватора.

В ШСМ я эту кругозорную лекцию повторю 3 ноября 2019, http://system-school.ru/machine

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

Чего мне не хватает в MS Teams

Провёл вчера целый день в офисе MS (pun intended, речь идёт о помещении) в изучении MS Teams, читал тамошние пейджеры и много думал. Основной плюс -- Teams можно рассматривать как эдакую систему повышения осознанности в командах. Презентация продукта напирала на то, что Teams имеет много разных средств управления вниманием команды, это ровно в направлении мыслей по киборгизации команд: https://ailev.livejournal.com/1488271.html

Но основная проблема в сегодняшних Teams для меня -- не реализован жизненный цикл issue, а без этого проектная работа не будет полноценной. Обобщённый жизненный цикл issue (я даю его на курсах) таков: сначала появляется issue, который потом становится task, который потом превращается в notice. Ну что твоя бабочка, которая яички-гусеницы-куколки-бабочки, у каждой формы со своей жизнью, но это всё одна и та же особь. И вот эти отдельные жизни issue пока в Teams нельзя связать: обсуждение будет вестись в разных местах. Обсуждения в каналах-беседах, чатах, протоколах к собраниям, комментах к задачам тамошнего трекера оказываются несвязанными: эта мощная говорильно-комментаторская машинка по управлению коллективным вниманием крайне неоднородна, и даже ссылки на начало или продолжение разговора не везде просто ставятся из этих разных мест.

Как живут вместе разработчики и клерки (разработчики сидят в Visual Studio и Azure DevOps, клерки в Office и Teams) -- непонятно, ибо в Teams всё выстроено вокруг офисных документов в папочках, а в DevOps вокруг системы управления версиями кода. Всё, что на вкладках в Teams (даже на вкладках Planner как тамошней реализации канбан-доски) -- остаётся на вкладках и не втягивается в беседы, хотя есть способы привлекать внимание ко вкладкам (коннектор может сообщить, что во внешней системе что-то произошло и выдать в беседу ссылку на место, куда смотреть).

Но это же всё в Teams можно подавать как достоинство: каждая вещь может быть сделана несколькими разными способами, и это неплохо. Ну, и система открыта для интеграции: Forms, и PowerApps, и Flow -- простые автоматизации работы с формами, создания приложений, создания каких-то процедур/воркфлоу: можно легко наращивать функционал для каких-то рутинных задач, если они массовы и рутинны. Слова "приложение", "сервис", "продукт" отчаянно путаются, ибо интерфейс вроде как всё замешивает в одно целое на любых экранах. При всех ограничениях на эту целостность: поместить запись в окошко вовсе не означает, что тут же можно содержимое окошка обсудить. Нет, обсудить можно, функционально для этого отличная, но обсуждение будет где-нибудь ещё. Или прямо тут -- но вырванное из контекста других бесед.

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

Альтернативные решения (сразу в голову приходит стек Jira+Confluence+Slack) по тем же критериям более заморочены: они ориентированы на разработчиков больше, и меньше на менеджеров, предпринимателей и уж тем более на внешних людей. Остаётся признать, что нет в айтишном мире счастья, оно всегда впереди, как горизонт.

Ещё одно -- это ни разу не социальная сеть, а тот самый "кровавый энтерпрайз" из айтишного фольклора, за файерволом. У нас же Школа, поэтому границы проектных команд и "просто сообщества" размыты (абитуриенты и alumni, а не только учебные группы. В учебных группах issue tracker и проекты, в сообществах -- чисто поболтать и такие проекты, как events: семинары и конференции).

Ещё барьер для входа. MS Teams это форум+мессенджер+контент+групповые звонки и поэтому входной барьер там примерно вчетверо от входного барьера в одиночных приложениях. Нужно полчаса на то, чтобы разобраться в интерфейсе. Если человек к нам приходит на короткий шестичасовой курс, то будет ли он доволен, когда ему придётся в этом разбираться? Но на втором же коротком курсе это окупится сторицей. Или если курс шестидневный. Это опять же к вопросу, что у нас Школа представляет собой какой-то симбиоз кровавого энтерпрайза и социальной сети.

Записал себе в план набросать архитектуру курса blended learning (cейчас Школа использует фейсбук, телеграм, imind, яндекс.диск, почту и ВКонтакте для организации работы -- плюс зоопарк самых разных authoring tools, от Офиса и yEd до видеокамеры, Archi и совсем уж экзотических рисовалок у наших курсантов). Сказать, что связность всех бесед выше, чем она была бы в Teams -- нельзя. Но значительная часть бесед идёт в соцсетях или группах telegram и публична. Но часть наоборот, непублична -- обсуждения в учебных группах, обсуждения по линии менторства. Там обсуждаются рабочие проекты, они не любят яркого света. Вот как правильно поделить внешние и внутренние беседы -- это отдельный вопрос.

Что касается учебных проектов -- идеи из статьи про учебный CAD+PLM остаются в силе (https://ailev.livejournal.com/1473691.html), и будем их потихоньку реализовывать. Но думать и о социальном шлейфе, жизненный цикл курсантов начинается задолго до начала курсов и прекращается сильно после их окончания. С абитуриент-курсант/студент-alumni (при этом ещё для каждого отдельного курса и для школы со множеством курсов в целом -- есть разница) та же онтологическая проблема, что и с issue-task-notice: софт это должен поддерживать, но из коробки ни один софт это поддерживать не будет.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216340724924791
2019

Дискуссия о типах и SysMoLan продолжается

Обсуждение SysMoLan в чате представления жизни типами (https://t.me/typeslife) не утихает.

Философская логика
В частности, там пришёл Brenoritvrezorkre (The name Brenoritvrezorkre is written in Gloatre, a language invented by Vordb Dréagvor Uèzréèvb, https://katab.asia/2018/10/16/zurghtapre-of-cannibals/, Бреноритврезоркре — плохая примета, дурное предзнаменование) и рассказал всем, как нужно заниматься экдурантизмом и пердурантизом в частности и философской логикой в целом (для начала читать 18 томов учебника, вот ссылка на том 18, остальные сами найдёте -- https://b-ok.cc/book/3662367/9d5f0c. Не знаю, насколько знание этих восемнадцати томов может помочь в нашей задаче выразить в типах языка программирования понятия системного подхода в том небольшом объёме, который есть в учебнике (и для начала IEC81346 как подмножество этих понятий. Хотя это я лукавлю, стандарт-то большой и заковыристый, понятий там предостаточно). Знание этих восемнадцати томов учебника может помочь IMHO примерно так же, как знание всех томов Кнута может помогает программистам в их работе. И для меня неважно абсолютно, что такое possible worlds в логическом формализме и какая там история их создания. Для меня важно ровно то, что я могу при помощи possible worlds принимать решения в своём проекте: говорить о том, какая именно модель будет реализовываться и какие последствия будут от тех или иных моих решений, и как связаны мои планы и актуальное состояние. Абсолютно прикладное использование, реализация прагматического поворота в философии. Нет использования — не нужно обсуждать этот формализм, есть использование — нужно обсуждать.

Тем не менее, какое-то знание философской логики всё-таки помогает чуток разобраться. Скажем, меня прежде всего волнует описание физического мира в первую очередь, и в концептах системного подхода, а не описание описаний в любых концептах (например, при помощи очень часто встречающихся в IT URI и даже URL). Поэтому у меня ключевой вопрос про моделирование IEC81436, где в том числе обсуждается вопрос привязки документов к системам, а у justy_tylor ключевой вопрос про работу с документами без их привязки к системам.

Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

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

Дальше там был короткий спор про философию как таковую (моё отношение к философии как к художественной литературе, особенно в стране победившей истории философии вместо философии, см. "О философах как властителях душ" https://ailev.livejournal.com/1128233.html и там дальше про этих властителей дум роскошные комменты). Но это всё было сочтено оффтопом к теме чата.

Естественный язык против формул
Ещё темой было использование естественного языка -- почему мы не можем от него отказаться и говорить только формулами. [байка он] Лет так пять назад я попал на конференцию по аналитической философии, делал это руководитель логико-философского кружка ВШЭ Виктор Горбунов. Он сильно удивлялся, откуда инженеры знают про possible world и Дэвида Льюиса. Но занятно было другое: шли обычные для конференции разговоры-разговоры разных докладчиков, не произносилось ни одной формулы, всё как обычно. Но вдруг кто-то из зала сказал: "я, кажется, понял!". Он вышел к доске и исписал в гробовой тишине всю доску формулами. Ему поправили из зала одну ошибку (даже не ошибку — он мелом плохо нарисовал точку над одним из квадратиков), и дальше до конца дня ни в речах, ни на доске никаких формул не было. [байка офф]

У каждого человека свои представления в голове об уровне формализма, на котором он хочет работать. И работать нужно на полном спектре мышления, а не всё время "в формулах". Фишка в том, чтобы двигаться по спектру формальности мышления, а не просто работать в рамках одного формализма всё время (у меня про это много больше в книжке "Визуальное мышление", https://ridero.ru/books/vizualnoe_myshlenie/ или её можно взять бесплатно в info чата, можно посмотреть ещё вышедшие до этой книжки короткие тексты по развитию мышления -- https://ailev.livejournal.com/1425003.html и про творчество в системном мышлении https://ailev.livejournal.com/1425331.html).

На помянутой в байке конференции доклады были все об идеях Крипке, Льюиса и их коллег, но без формул. С формулами была только вот та самая вставка. Как я понимаю, людей на логическом отделении философского факультета учат отождествлять текст и формулы в обе стороны — формализовывать и деформализовывать. Поэтому они не стесняются говорить о формальном и текстом тоже, это абсолютно нормально. С архитектурными моделями точно так же: Дэвид Файерсмит предупреждает всех, что из архитектурной документации ни в коем случае не должен уходить текст и оставаться только модели на формальных языках моделирования -- ибо даже сам смысл выбора тех, а не иных способов моделирования (viewpoints) должен обосновываться текстом и представляться в составе документации, равно как и самое верхнеуровневое описание в виде "архитектурного эссе".

Почему для работы с формальными системами (особенно, если их несколько одновременно в рассмотрении) нужно иметь и естественный язык — об этом любит рассуждать John Sowa (родоначальник computational ontology, он и до сих пор бодрый дядька, недавно его чуть в сообществе Ontolog FORUM не забанили — он там сильно наехал на создателей очередного всеобщего онтологического ISO по поводу их заблуждений, там работала уже административная машинка и голосовательные популистские механизмы, а John "вынул гранату, кинул в окно — дедушка старый, ему всё равно". Я там член попечительского совета, с интересом наблюдал за этой историей борьбы здравого смысла с бюрократической политкорректностью. Онтологии дело нервное!). Так что формализмы и естественный язык нормально сосуществуют, и это не бага, это фишка/фича.

Народные онтологии
Обсуждали в том числе и использование народной (из общепринятых словарей) онтологии -- ибо были сделаны попытки использования теории типов с интерпретацией на базе "просто из вебстера". то у меня превращается. Вопрос на практике возник из непонимания, как делать системы тегов: на основе какой-то таксономии (которые вроде бы хоть как-то логически выверялись), или на основе народных представлений ad hoc (folksonomy). Любили при этом поговорить о фасетной классификации и всяких подобных материях. Потом оказалось, что:
а) предмет интереса во времени плывёт, и из старых текстов берут вовсе не ту информацию, по которой они были протегированы
б) полнотекстовый поиск заменяет все эти теги

Онтологии — это просто добавление к таксономиям разных типов отношений. Дальше мы уже обсуждали тут, что Грубер определил computational ontology как формализацию для концептуализации предметной области, но его поправили, заявив, что это должна быть shared концептуализация — то есть речь идёт о разделяемой (каким-то сообществом, folk) картине мира, а не любой картине мира.

Дальше понимаем, что народные онтики (куски онтологий без вписывания их в общую upper ontology и без требований внутренней непротиворечивости) и разные феноменологические онтики по факту совпадают друг с другом. Неважно, теория у тебя народная или бывшая научная теория флогистона, если ты попал в мир, описываемый современными термодинамическими моделями. При этом появляется вопрос о том, какой (онтологический ли или нет) статус носят модели термодинамики в тот момент, когда они уже есть, но только сформулированы и поэтому ещё никак не shared. Поэтому слово shared опять начало исчезать: когда выяснилось, что в какой-нибудь инженерии или оргуправлении даже программист способен включить в себе роль онтолога и путём приложения мозга существенно упорядочить исторические напластования концептов, даже не выходя на рассуждения об upper ontology. Модели мира при этом получались компактней, реализации софта компактней и надёжней, людям становилось легче работать.

А потом и вообще пошли разговоры, что нужно безо всяких этих upper ontology разговоров просто стараться чуток улучшить местные представления о мире. Но брать значения из словаря общих слов (народная интерпретация, под ней всегда есть какая-то феноменология), если речь не идёт о чём-то узкоотраслевом — эта рекомендация исторически остаётся.

У нас совершенно конкретная предметная область. И проход улучшения феноменологии для концептов из учебника был, это несколько лет обсуждалось в сообщстве Русского отделения INCOSE, обкатывалось на разных учебных курсах, понимание уточнялось и по возможности согласовывалось с современными онтологическими представлениями (в том числе представлениями из книжки BORO). Формализом там, конечно, и не пахнет, ну так я ж особо и не настаиваю — просто потихоньку обсуждаются разные уровни этого формализма (там ведь эти формализмы до самого низа, и всегда будут проблемы, не хотелось бы их прихватывать, начиная от уровня проблем оснований математики).

Foundational ontology и солвер для неё как менеджмент внимания/управление данными
В какой-момент я в очередной раз прояснил свой интерес в дискуссии: предположим, я пытаюсь сделать язык для системных описаний/моделирования, при этом заявляю, что где-то под ним должен лежать более общий язык онтологического моделирования. То есть foundational ontology, над ней upper ontology без понятия "система" (зато там понятие агента, возможных миров и т.д. -- онтологическое моделирование как таковое), а уже дальше middle ontology как системная онтология, системные концепты как только одна из рабочих онтологий в рамках upper ontology. Это вроде как должно быть удобно, когда приходится миксовать системные и не системные (каковых большинство, конечно) рассуждения.

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

Я придерживаюсь сейчас этой позиции, примерно это же предложил Matthew West с его HQDM в альтернативу онтологии ISO15926, а также некоторые другие неожиданные товарищи (типа СМД-методологов, регулярно обсуждающих этот вопрос -- ибо для них в силу их гуманитарной ориентированности концепты upper ontology как-то неразрывно связаны с рассуждениями о боге, но хочется иметь светскую upper ontology, для чего и интересует системный подход как основа светской онтологии -- это эхо, конечно, чисто метафизической дискуссии, привет из прошлого. Тем не менее, это пример того, что желающих иметь системную upper ontology "из коробки" достаточно много и кроме меня и Matthew West).

Так что я за то, чтобы делать сразу системный моделер, а не сначала общеонтологический, а затем на нём системную специализацию. То есть не моделер типа Protege-дляOWL-только-не-OWL-а-лучше, или моделер для MOF-UML, а уж потом их специализировать до моделера SysMoLan, а сразу моделер SysMoLan.

И да, я понимаю, что работать в этом моделере придётся с самыми разными описаниями. Но нельзя терять тот аспект, что эти описания привязываются друг ко другу, и в конечном итоге к системам. Поэтому имена, к которым все эти описания привязываются в конечном итоге, важны. Стандарт IEC81346 даёт best practices в том, как делать имена для систем, и даже даёт best practices, как делать имена для документации этих систем (хотя этот вопрос там и не главный и значительно хуже проработан. Может, в последние годы там что-то изменилось с именами описаний, тоже вышли какие-нибудь практические рекомендации). Конечно, любое описание деталей Боинга (например, по три описания на каждую деталь — их сразу будет 18млн.) будет иметь URI и даже URL. Но я просто не хочу забывать, что это всё описания каких-то деталей Боинга. И идентификация по URI мне мало даёт понимания, где во вселенной мне искать эту деталь, часть чего она и для чего используется. Ибо URI это только про описания, про сферические информационные системы-в-вакууме. Я же изначально задаюсь вопросом, информация о чём в этих информационных системах. У меня не логистическая задача, а содержательная: мне ж нужно методы работы не с описаниями брать, а методы работы с domain.

Да, я согласен, что управление конфигурацией это смежная дисциплина: появление и трансформация объектов в ответственности инженеров, а уже учёт появившегося и логистика это сразу объект менеджеров. Но считать, что всё сводится только к информационной стороне вопроса я не готов. Из коробки должно быть отношение representation к физическому миру.

Дальше было заявление justy_tylor "Тут у нас разница в интересах. Если придерживаться "онтологической" терминологии, то мой интерес это foundational ontology. Я считаю, что только построив foundational, и подтвердив её удобство в мэппинге между используемыми на практике представлениями данных и modeling approaches, можно построить приемлемую upper ontology над ними. Потому что обратный подход (upper без приличной foundational) мы уже наблюдали, в том числе, в ISO 15926, и получались какие-то untested beliefs. Поэтому вопросами upper я не занимаюсь - рано".

Для меня это уже было понятно, для меня это звучит как:
1. Foundational ontology для моделирования описаний, но не для моделирования мира в целом
2. Foundational ontology для upper ontology из классической онтологики, без акцентов на системном подходе.

Это выборы justy_tylor в уже высказанной развилке: системное мышление в рамках upper ontology или системное мышление в рамках middle ontology. При этом я с тяжёлым вздохом говорю, что ни upper, ни systems middle ontology действительно ни при чём при выборе foundational.

Но дальше есть некоторое соображение. Я в своё время начинал работать в исследовательском вычислительном центре, где разрабатывалось много-много компиляторов, языков программирования и т.д.. И было поэтому много-много людей, которые занимались формальной семантикой языков. И почему-то успех был в ЖЦ, когда создавалось полностью неформальное ad hoc решение на диких эвристиках, и эти дикие эвристики вдруг оказывались хорошими, под них люди кряхтели и подыскивали формализм, потом подхакивали эту эвристику, чтобы не поломать её об формализм и дальше получали формальное успешное решение. А вот где сначала был формализм, потом попытки его "прикласть" через создание "прикладного языка с формализом внутри" — вот тут всё плохо было обычно. Учёные восхищались, система входила во все учебники как "удивительно простая и элегантная, решение всех проблем" — но популярности эта "элегантность и компактность формализма" явно не добавляла. Монады хаскела можно отнести к очередным примерам (пока хаскел с 1990 года уже 30 лет "продолжает набирать популярность", успел стать суперпопулярным и потом умереть тот же эклектичный перл, родившийся примерно в то же время, в 1987 году, а Питон от 1989 года успел стать суперпопулярным и не умереть). Оказывается, формализмы и обильная математика под языками программирования не являются гарантами их популярности -- и даже наоборот, как-то коррелируют с непопулярностью!

Поэтому я интересовался: можно ли как-то эвристически забабахать моделер SysMoLan как "не основанного на крутой математике языка", а потом (в случае успеха) задним числом ему что-то там формализовать, если это хоть чему-нибудь поможет. Но попал в тусовку "формализаторов передним числом", вместо обсуждения выражения SysMoLan в типах языка программирования (например, Julia, но можно было бы и какого другого -- ибо в Julia можно было бы потом сделать "по образу и подобию") идёт обсуждение выражения языка в типах теории типов!

ISO 15926 рухнул IMHO ровно из-за выбора мощного рудиментарного формализма триплами. Триплами можно что-то выразить на очень низком уровне, это foundational ассемблер и должен быть очень глубоко под капотом. До удобных шаблонов с n-арностью в выражении мира мир ISO15926 так и не дорос, ло. Если бы сразу были шаблоны, то всё ещё могло бы состояться. А потом эти шаблоны бы посадили на какой-нибудь формализм, а хоть и те же триплы. Но потом, когда бы всё уже было понятно как устроено и был бы опыт моделирования. А иначе — 18 триплов, описывающих величину с указанием единицы измерения, я помню (). И никакого практического способа указать "x=5кг" вот этими вот пятью символами, ибо "шаблоны и как их выразить, чтобы не порушить формализм" было выдумано явно несвоевременно.

Прорывы типа реляционного формального исчисления и SQL — ну, это ошибка выжившего. Всегда есть исключения, которые на слуху именно потому, что они выжили. За счёт чего они выжили? Я высказывал какие-то свои соображения по поводу де-факто разделения языков управления данными и языка вычислений над данными. Это зыбкая граница в computer science и даже software engineering, но уж какая есть.

Так что я интересуюсь в чате у знатоков языков программирования: как принято типами языков программирования выражать онтологии? А мне отвечают: сначала нужно иметь foundational ontology, чтобы выражать онтологические upper ontology типы, для этого нужно придумать формализм, для него сделать солвер, и уж потом это всё выражать в Julia. Я время от времени задаю вопрос про "можно ли прямо типами языка и структурами данных Julia?" и получаю ответ, что нет — ибо должен быть не GPL+eDSL с моими типами и структурами данных, а GPL+язык запросов+солвер-с-формализом. Но поскольку время от времени появляются разные варианты ответов, то я продолжаю внимательно слушать.

Дискуссия дальше идёт о том, нужна ли вообще upper ontology или сразу микротеории без upper (но само понятие микротеории тогда как выражать? из какой оно онтологии?), а foundational ontology это и есть "новый upper" (у байесовцев в ML это называется innate priors — те концепты, что мы не можем выучить из мира и таки должны задать "в аппаратуре/алгоритме обучения"). Я готов и это обсуждение поддержать. Но моя мысль, что вот это "реализованное в аппаратуре" должно бы включать мир (физичный), модели (описание) и тех, кто описывает (агентов с их предпочтениями в интересах и намерениями по изменению мира, для чего им и нужны модели). А поскольку мир и агентов и описания, то можно смело туда сразу записывать и системный подход, как уточняющий тем, как управлять вниманием в мире. Управление вниманием, системное мышление из менеджерских/логистических краёв, оно не про трансформации.

Собственно, про это "управление вниманием", "менеджерское/логистическое" программирование для того, чтобы предоставить данные для трансформации возникло как моя реакция на реплику justy_tylor по поводу задач, которые он считает важным для языка работы с foundational ontology: "осуществление логического вывода (прямо в этом представлении), двухсторонний мэппинг с другими представлениями (оптимизированными под конкретные предметки), визуализация (таблицы, деревья, диаграммы), интеграция фрагментов описаний, разрешение конфликтов интеграции (как автоматически на машинном уровне, так и в diff-merge утилитах с участием человека), и так далее".

Для меня в этой реплике были перечислены чисто логистические/управленческие данными/базоданческие задачи/управление вниманием над памятью — работа не по содержанию, а "взять нужный кусок и отдать кому-нибудь содержательному для вычислений/трансформаций" плюс "взять у содержательных людей/программ кусок и добавить к имеющемуся". У меня все менеджеры примерно так и думают про системы обеспечения: им всё равно, что там потом за содержание, откуда берутся и в чём состоят содержательные задачи. Вот и появляются инфраструктурные навороты, которыми потом никто не пользуется.

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

То есть получается, что есть один язык для собственно работы (какая-нибудь Julia), а все эти выводы-мэппинги и т.д. это управление памятью и вниманием над памятью (какой-нибудь SQL).

И все эти заходы на морфизмы — у меня прямо таки все кейсы перед глазами, когда менеджеры рассуждают про строительство предприятий, стараясь абстрагироваться, спички эти предприятия выпускают, вебсайты, или ракеты на Марс. Опыт показывает, что в итоге предприятие работает очень хорошо, пока у инвестора деньги не кончаются. Если строишь завод самолётов, то завод будет работать хорошо, только самолёты могут не летать )))

Надо будет подумать. Современный AI, конечно, все задачи сводит к управлению вниманием и памятью сегодня, но в знаниях не всё можно "вспомнить" или "найти где лежит". Чтобы в базе данных что-то появилось, туда нужно что-то класть. Языки запросов, как известно, базу данных не меняют, почему их и называют языками запросов. Это потом почему-то хочется туда и запись информации вставить. Всегда хочется.

Надо будет ещё подумать, почему эта формализация мне менеджеров против инженеров напоминает. При этом абсолютно понятно, что для логистики "что угодно достаём откуда угодно и транспортируем в заданном формате куда угодно, гарантируя непотерю содержания" и работы "делаем преобразования" требуются разные архитектуры, разные языки, разные способы работы. PLM и мэппинг — это про логистику, это ж lifecycle management, менеджмент. В принципе, инженер без логистики ничего делать не может (задачу он получает, входные данные и материалы получает, выход тоже у него уходит куда-то в другое место). Но разделение "логистика/внимание vs трансформация" при всей его неуловимости в области информационных технологий и математике по крайней мере хоть как-то объясняет мне происходящее. Разделение труда: одни на фортране считают режимы, а другие на логическом языке SQL (pun intended) выдирают из общих описаний материал, на котором первые считают эти самые режимы. Все довольны, всем счастье. Языки не представления знаний, а управления данными и инженерные языки для предметных вычислений. Хм. Как-то подозрительно всё сходится.

Так что нужно сделать два языка, как-то связанных друг с другом, или один мультипарадигмальный язык, в котором есть и язык логического вывода для управления вниманием/данными, и язык общего программирования для трансформаций данных. Общий язык для менеджеров данных и инженеров предметной области. Потому как разрыв мной ощущается где-то в этом месте: базы данных с языками запросов и по сопричастности логические языки и классические языки представления знаний с FOL/HOL в основе против каких-то специфичных преобразований на GPL и тогда логика в GPL появляется только для доказательств правильности (иначе все умрут, если логикой не долько добывать данные и доставлять их на обработку, но и обрабатывать/трансформировать/что-то с ними вычислять). И между этими языками вроде как неминуемые всякие ORM (object-relational mapping) и прочие GPL-logic mappings, которые я бы и хотел исключить -- почему и затеял всю эту дискуссию.

Ну вот поиск метафоры это хорошо, но всё одно меня не греет. Если мэппинг, то скажут что "берите функциональный язык, и мэпьте". На уровне приложений из метафор есть search (в том числе поиск решения в пространстве решений), а есть learn как вычисление подходящего ответа по выученному ранее (человеком, который потом это выученное в своём мозгу закодировал как модель в GPL или нейронной сеткой в компьютере, которая сама учится на примерах).

Грубо говоря есть какие-то CAD-с-редакторами и солверами разных domain, где так или иначе что-то типа Архимейта или 3D-моделера, а есть PLM с "базой данных и логистикой", куда все эти CAD втыкаются. Это общая структура разработки чего угодно, даже программного кода (есть IDE и есть Git). Я немного писал об этом в https://ailev.livejournal.com/1277009.html, и даже EduTech для образования может быть описана таким образом, https://ailev.livejournal.com/1473691.html.

И у меня гипотеза, что CAD будет всегда с GPL внутри (когда-то в AutoCAD был даже лисп, но потом всё нормализовалось). И IDE будут с GPL внутри, ибо "всякая достаточно большая программа содержит в себе кривой и плохой common lisp", уж так получается. А в PLM всегда важен мэппинг, чтобы взять данные из одного вида CAD и послать их часть в другой CAD на просмотр и редактирование (руками или программно — это неважно).

Фишка в том, что CAD и PLM не живут друг без друга, поэтому начинаем с моделера-CAD, а заканчиваем всё одно PLM-базой данных с кучей экспорт-импортов, или наоборот — начинаем вроде как с мэппинга-в-PLM, а заканчиваем сначала неизбежной визуализацией, а потом и обязательно редактированием WYSIWYG и для этого всё одно солвером, то есть приходим к группе CAD для разных domain, отражённых в начальной PLM-базе.

Если начинать с мэппинга, то сразу вопрос: а где брать системные модели, к которым мэппить всё остальное? Нужен таки моделер перед тем как к нему мэппить. Моя идея взять IDE типа Вижуал Студия и считать её моделером, если модель будет в текстовом eDSL системного моделирования. А потом да, к ней мэппинг, когда эта модель уже есть и есть средства её отображения. Прошлый вариант ТЗ уж как я его понимаю я формулировал в https://ailev.livejournal.com/1488488.html — и более точно пока сформулировать не могу. После этого текста из нового пока у меня только эта мысль про различие eDSL для управления данными (и представление знаний вроде как идёт сюда, тут все интеграции и прочие "семантические технологии") и для работы с данными (все матлабы и CAD вроде как тут, а логические языки не тут) с какими-то "мэпперами" из типов/foundational ontology языка рабочего языка программирования в типы/foundational ontology менеджерской базы данных, я продолжаю эту мысль думать дальше, она интересна. С этой мыслью domain онтологической работы и по сопричастности системной работы представляется мне немного другим. Трансдисциплины (онтологика и представление знаний, системное мышление) для управления вниманием, а оптимизация, порождение и прочее такое делается на других дисциплинах их eDSL.

Итого: Чтобы выразить в каких-то типах GPL (языка программирования) типы системного мышления, нужно сделать какой-то язык запросов/управления данными для представления знаний в языках программирования (языкGPL-с-языком-запросов, и с этим ещё нужно будет поразбираться — мне это место у justy_tylor мутно). В этом языке запросов/управления данными будут делаться запросы на выборки из представления знаний о мире в каком-то графе, а для этого будет реализован солвер, предположительно для FOL или теоркатегорный или ещё какой формальный (тут тоже мутно, мнения различаются). И вот для этого солвера нам нужно предложить формализацию данных для вычислений этого солвера, связав её как-то с понятиями системного подхода.

Для меня это звучит более понятно как поиск foundational ontology для upper ontology из учебника. И для foundational ontology предполагается, что можно сделать движок/солвер/реализацию языка запросов и хранилище данных для этих запросов (но это не предполагает вычислений в инженерном смысле, а просто "управление данными"), а upper ontology из учебника при этом как-то закодировать в виде данных для этого движка. Такой подход подразумевает, что математически все запросы смогут быть исполненными (хотя гарантий времени исполнения и возможности оптимизации запросов не даёт никто, и это сильно меня напрягает: похожие проекты по формализации с похожей архитектурой все заканчивались печально, типа тех же разработок с BDI и агентским подходом и родственниками — математически там было всё ОК, но вот пользоваться софтом там было невозможно).

Ещё в чате тут помянули агентский подход с BDI и его многочисленными родственниками и неудачку с использованием логик в агентском подходе для содержательной работы (символический искусственный интеллект от забора до обеда и неминуемая неудачка в связи с этим). Но не буду цитировать, ищите в чате сами на "BDI".

Теория прототипов, трансформеры и успех языков программирования
justy_tylor заметил, что "помимо упоминавшихся BORO, ISO 15926, Gellish, HQDM, а также книжки @ailevenchuk и мелькающей в последнее время таксономии IEC 81346, для понимания рассматриваемых тем неплохо бы прочитать:
1. Три тома материалов HOPL. https://en.wikipedia.org/wiki/History_of_Programming_Languages
2. Пару книг Лакоффа по когнитивной лингвистике: George Lakoff and Mark Johnson "Metaphors We Live By", George Lakoff "Women, Fire, and Dangerous Things: What Categories Reveal About the Mind".

Лакофф затем, что популярно описывает явления вроде "базового уровня восприятия", понимание которых является ключевым для создания эффективных EDSL".

Я нашёл это замечание очень интересным. Типы и FOL из theory theory поддерживают медленное мышление по Канеману, а прототипы (Лакофф! Первичное восприятие!) — быстрое. Если говорить об успехе в рамках теории percieved cognitive load, то эту нагрузку, получается, нужно считать не в типах/классах из theory theory, а в прототипах (https://plato.stanford.edu/entries/concepts/ -- про теории понятий, в том числе theory theory и prototypes, хотя там есть и другие). То есть в спектре мышления по мере движения по этому спектру в пространстве смыслов формализация не просто relax в рамках theory theory по мере движения влево, но и меняется её способ, и всякие "интуиции" по поводу тех же типов/классов (и отнесения к типам/классам) формулируются как прототипы для типов/классов. Это, конечно, гипотеза, но покрутить её было бы весьма любопытно. Если (как предложила @pionmedvedeva в какой-то момент) у нас таки спектр формальности, т.е. в середине там гибриды медленного и быстрого мышления, то по факту у нас где-то в середине будут и гибриды theory theory и теории прототипов.

Сам заход на то, что нужно для создания удобного eDSL поразбираться с мышлением, мне кажется важным. Понятно, что и IEC81346, и понятия из учебника системного мышления — они все из theory theory. И предлагаемые для них варианты концептуализации (предлагаемые foundational ontology) тоже из theory theory. Что про эти навороты будут думать люди, которые не прошли десятилетнего математико-логического тренинга (а, например, прошли пятилетний подобный тренинг) — это в дискуссии только разок мелькало, когда про когнитивную нагрузку говорили и в том числе теорию piercieved cognitive load как барьер к массовому распространению.

Очень, очень интересно. Это для меня вторая интересная мысль из дискуссии, после мысли про язык представления знаний как язык логистический для управления вниманием на какой-то памяти, но не трансформации. [при этом, конечно, сразу захочется его иметь и для трансформации, и попытки делать чисто логические вычисления для меня становятся чем-то типа недифференцируемого варианта трансформер-архитектуры для нейронный сетей: выкидывается всё, кроме работы внимания — https://medium.com/inside-machine-learning/what-is-a-transformer-d07dd1fbec04, и я понимаю, что это аналогия полная шапкозакидательства, но мы ж тут Лакоффа и метафоры обсуждаем, или что?! )))]

Логическое моделирование в системной инженерии
Вообще, должен сказать, что логическое моделирование в системной инженерии по факту есть (хотя его и нет — занимаются им единицы инженеров, это местный курьёз, который подаётся как мейнстрим примерно так же, как когда-то подавался пролог). Это OCL к UML, для которого есть профиль SysML. Он насквозь объект-ориентирован, но задним числом через UML и MOF к нему был приделан логический формализм, и есть текстовый язык OCL, который может выразить всё, что выражается тамошними диаграммками, плюс ещё много чего логического. Мне не нравится SysML, ибо системности и онтологичности в нём ноль. И GPL там совсем не предусмотрен. Но есть несколько моделеров (дико дорогих, но и опенсорс что-то есть). Есть и похожие решения с другими архитектурными языками, не опирающиеся на какие-то стандарты. Но они также не слишком системны. Так что ссылок не даю. Это если вы считаете, что я про них не знаю. У меня десять лет назад вышла статья в INCOSE INSIGHT — я там ругаюсь на SysML, https://levenchuk.com/2009/12/08/sysml-is-the-point-of-departure-for-mbse-not-the-destination/
2019

Роли начальников, роли помощников, роли любителей, роли карьеристов

Начальник в проектных ролях -- это джокер, играет любую подвернувшуюся ему роль. Имеет право. Квалификация игры по роли тут уже не имеет значения -- "я начальник, ты дурак", если спецы по данной роли в команде есть. При этом у начальника хотя бы есть полномочие делегировать исполнение роли, если есть кому. А вот у самых разных помощников/ассистентов по должности делегировать исполнение роли обычно некому, хотя "должностные обязанности" примерно так же расплывчаты, как у начальников -- "заниматься всем, чем нужно". И об уровне образования помощников пекутся много меньше, чем об уровне образования начальников. При этом на помощников накидывают не только много работы (это нормально!), но много работы по самым разным практикам -- а это означает, что квалификация помощников в выполнении этих разных практик будет плохой, они не смогут специализироваться и достигнуть мастерства по каждой из них.

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

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

Пример из моего любимого детского садика Монтессори (https://ailev.livejournal.com/1485977.html): помощник педагога там имел целый букет страннейших ролей, в том числе роль охранника. Помощник педагога в роли охранника отгонял по вечерам детей от дверей, ибо дети садились под двери и ожидали там родителей. Роль охранника поменяли на роль аниматора: помощник педагога играл с детьми, и ни у кого из детей не появлялось желания выйти из игры и сесть под дверь. Этот пример показывает, что разбирательство с ролями ведёт часто к архитектурным решениям: важнейшие/архитектурные решения для организации это про то как роли распределяются по их исполнителям. Так вот иногда интересней поменять не исполнителя, а саму роль и играемую этой ролью практику. Заметить такую ситуацию и даёт работа с таблицей ролей.

Таблица ролей даёт и много материала для лидерской работы (как живых людей уболтать выполнять их роли): часто люди начинают играть те роли, которые никак не соответствуют занимаемой ими должности -- это любительские роли. Почему это происходит? Иногда причина в кривизне архитектуры: делать дело/выполнять ролевую практику нужно для успеха проекта, но конструкция/штатное расписание не предусматривает для этого дела ровным счётом ничего. И это обычная ситуация, тут ничего не поделаешь. Но иногда причина в личных ролевых предпочтениях, людям нравятся какие-то роли, хотя работа от них этого не требует (а иногда выполнение таких ролей и прямо вредит работе). Я когда-то играл в духовом оркестре военной кафедры, и любил сыграть там на концерте на саксофоне какую-нибудь джазуху: хриплый тембр саксофона при этом легко перекрывал весь остальной оркестр и мою импровизацию легко было слышать из зала. Ни в каких нотах этого не было, для выступления это было не нужно, это были мои персональные хотелки. Иногда для успеха концерта это было хорошо, иногда плохо. В любом случае -- это была проблема лидерства: я в самый критический момент (на концерте) от проектной роли игрока маршей по нотам лихо отходил, и играл любительскую роль джазмена, уж как мог. Лидер оркестра регулярно с этим разбирался, это была его проблема. Если в игротехнической компании человек в должности менеджера проекта играет роль игрока-любителя, то вместо управления проектом/операционного управления он будет тратить много рабочего времени на обсуждение вопросов геймдизайна.

Ещё одна категория людей, которые выявляются при работе с таблицей ролей -- это карьеристы. Это необязательно плохо, но это тоже нужно учитывать. Карьеристы прихватывают роли других должностей, они просто по факту начинают выполнять другую работу (часто продолжая выполнять работу по своим ролям). Лидеру опять-таки нужно этим озаботиться, например, перевести человека на другую работу (не всегда ступенькой вверх, для карьериста может быть важна работа на похожей должности, но с другим предметным содержанием), если выполнение этих других ролей у него хорошо получается, т.е. профессиональная квалификация достаточна. А если не получается, и это "хотелки", то можно или подучить сначала, а потом перевести на другую работу, или провести воспитательную беседу о необходимости хорошо выполнять свою работу, а не прихватывать чужую. Или решать более сложную задачу: работу на текущей должности карьериста выполнять будет некому, но всей организации уже будет понятно, что карьеристу на текущей должности делать нечего, и нужно его двигать туда, куда он хочет -- но кто тогда займёт его место?! Это типичные проблемы лидеров: проблемы соответствия должностей с приписанными к ним ролями и исполнителей ролей со всеми их хотелками по поводу исполнения этих ролей.

Интересно, что с таблицей ролей вполне можно работать и на уровне таких исполнителей, как оргзвенья более чем из одного человека (например, подразделения или какие-нибудь рабочие группы или комиссии. В последнем абзаце текста про соотношение ролей деятельностных, проектных, функциональных, организационных тоже это упоминается -- https://ailev.livejournal.com/1487927.html).

Табличка с ролями поднимает осознанность в организационной работе (https://ailev.livejournal.com/1488271.html), служит чеклистом: она заставляет думать про какого-нибудь программиста как программиста-должность, программиста-роль, программиста-исполнителя и не позволяет ничего из этого пропустить. Дальше можно задаваться вопросом про квалификацию исполнителя роли, про достаточность полномочий должности для игры по роли, уместность этой роли у данной должности и т.д. В случае программиста ответы на эти вопросы будут тривиальны, но не всегда (интересы любительства или карьерные интересы могут вас сильно удивить в некоторых случаях). А вот в случае должностей начальников и помощников мой опыт свидетельствует, что удивление результатами рассмотрения по табличке наступает почти всегда: должности настолько заслоняют их роли в обыденной жизни, что работа с их ролями обычно открывает что-то новенькое и даёт много пищи для размышлений и улучшений.
2019

SysMoLan как eDSL для Julia

В дискуссии о типах языков программирования/моделирования/представления знаний (там, кстати, уже 320 дискутантов -- https://t.me/typeslife) сегодня был очередной поворот: попытка вместо говорения об онтологии и представлении знаний (что сразу вызывает математических и философских духов) говорить о предметно-специфичности, продолжая программистскую традицию и попадая в программистский язык. Так что ответы на наши вопросы про языки моделирования разных предметных областей будем искать по ключевым словам "domain-specific".

Когда-то и Fortran называли domain-specific, ибо он только для formula translations, а не универсальный, как машинный язык. И то же самое было со всеми языками высокого уровня, они были domain-specific. Тем не менее, domain-specific пока чётче ведёт к цели, чеми использование всяких других слов. Нам нужно делать еmbedded domain-specific languages (eDSL) с domain-specific types (как онтикой предметной области) и domain-specific solvers (для того, чтобы интерпретировать модели в онтике/типах предметной области, задавать вопросы/делать запросы/вычислять).

В группе "Аттик" мехмата МГУ рассказывали, что нашли причину, почему Паскаль никак не мог победить Фортран в своё время. Они считали, что Паскаль был безблагодатен по сравнению с пакетными языками (Modula, Ada), ибо не было "пакетов" как раз для реализации общей для нескольких программистов системы типов — нельзя было делать "пакеты" как eDSL для domain-specific работы (те самые domain-specific types и domain-specific solvers, в терминах группы Аттик domains -- это были миры и solvers -- исполнители для этих миров). В Фортране же это реализовалось на раз-два через common-блоки! Потом какие-то аналоги common blocks начали делать в паскаль-компиляторах (но это уже потом! в учебниках паскаля это не было свойством языка, а только свойством реализации в конкретном компиляторе). Потом появились на краткий исторический миг пакетные языки, а потом domain specificity начали понятными словами объяснять как делать в ООП и в реляционных моделях данных — тут все эти "пакетные языки" и деревянные с сетевыми базы данных начала восьмидесятых и смыло в унитаз истории, где они и находятся до сих пор.

Вся дискуссия в чате крутилась вокруг того, что удобных для программирования eDSL языков программирования/моделирования/запросов к базам данных/представления знаний нет. Так что я продолжаю придерживаться мнения, которое выработалось у меня на прошлом такте дискусии (https://ailev.livejournal.com/1487293.html): работать тогда будем с Julia как хост-языком. И на Julia будем реализовывать структуры данных и солверы SysMoLan как eDSL.

Вчера на докладе на митапе по Julia (https://juliameetup.timepad.ru/event/1047482/, слайды https://yadi.sk/i/yBeUJJj1iuiJXQ, видео https://vimeo.com/360541672#t=4940s) я высказал ещё пару идей. Солверы для eDSL отличаются тем, что эффективно обрабатывают частные случаи -- предоставляют оптимизированные для этих частных случаев решения. И в Julia как раз отрабатывается такой подход на примерах методов оптимизации (JuMP) и методов решения систем дифференциальных уравнений (DifferentialEquations). Солверы этих систем -- это просто коллекция самых разных солверов, эффективных для самых разных ситуаций. Итого eDSL выглядит как набор типов, в терминах которых удобно описывать предметную область, плюс набор эффективных солверов -- типы должны универсально отражать задачи предметной области, а солвер должен устойчиво работать и жужжать в части скорости. Поэтому типы должны быть более-менее богаты в части их конструирования для отражения объектов и отношений в domain (сравнимы в этом плане с богатыми типами статических языков программирования), но динамическими, чтобы по ходу дела в runtime подбирать оптимизацию для solver. Ну, и проблема двух языков: на одном и том же языке и компактно и красиво (с рафинадом) высокоуровнево выражать domain, но не теряя низкоуровневости в скорости. И настолько не теряя низкоуровневости, чтобы эта оптимизация докатывалась аж до уровня железа -- до GPU. Вот Julia как раз имеет примеры таких решений. Вот этим путём и хочется пойти для SysMoLan: иметь возможность самых разных солверов для предлагаемых SysMoLan как eDSL структур данных.

Идти туда, как мне кажется, нужно в несколько шагов:

1. Сделать простой (архитектурный и требований) текстовый моделер для простых архитектур и использовать его, например, для обучения инженерии требований и инженерии системной архитектуры. У меня проходит в год сотня студентов и курсантов по разным линиям, вот это будет учебный софт. SysMoLan в объёме реализации IEC81346-1 для моделирования системного разбиения (чтобы можно было показать функциональное и конструктивное системное разбиение в их взаимосвязи на пару уровней) тут вполне подойдёт. Это MVP. Ничего вычислять даже не будем (может быть, будем проверять целостность, но и тут не факт), только отображать удобно. Солвер -- голова инженера. Для чего такое нужно? Для помощи со стороны компьютера в присмотре за вниманием в ходе архитектурной работы и работы над требованиями, речь идёт о киборгизация архитектора (вот тут про киборгизацию присмотра за вниманием: https://ailev.livejournal.com/1488271.html). Как над шахматными партиями удобней думать, если есть просто шахматная доска, на которую можно смотреть, так и архитектурный моделер помогает думать уже тем, что он помогает стабилизировать внимание архитектора.

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

В чате была дискуссия о том, что лучшим приближением к языкам представления знаний является common logic, и какой-нибудь FOL солвер. При этом SQL предлагался как успешный вариант языка для FOL -- без пояснения того, как это всё предполагается в работе у инженера. Ибо логические языки почему-то нигде не взлетели в их чистом логическом виде.

Тут ещё и социальные аспекты, конечно. Пара релевантных ссылок в Communications of ACM (http://cacm.acm.org/blogs/blog-cacm/173328-programming-languages-are-the-most-powerful-and-least-usable-and-learnable-user-interfaces/fulltext) -- там обсуждается вопрос, почему люди не хотят учить языки программирования (языки моделирования, языки мета-моделирования). Там вводят понятия cognitive load (http://en.wikipedia.org/wiki/Cognitive_load, связанные с использованием рабочей памяти умственные усилия), для разных людей они будут разные при изучении предмета. И далее говорится, что люди оценивают не реальную когнитивную нагрузку, а субъективно воспринимаемую (percieved) будущую нагрузку -- когда вы даже воспринимать её по факту не можете, ибо ещё не знакомы с предметом. Да, и полезность вы тоже представить не можете, ибо не знакомы с предметом. А решение "учить-не учить" принимается до изучения предмета. То есть бесполезно уговаривать что-то учить, потому как оно "полезно". Решение принимается не только и не столько по "пользе", сколько по "цене изучения" -- например, считает ли потенциальный ученик, что у него есть способности к предмету. Это всё expectancy value motivational theory -- https://www.researchgate.net/publication/265965932_Expectancy-Value-Cost_Model_of_Motivation. If students are not convinced they can learn it and they are not convinced of the value, then they don't learn it. Решение автор текста предлагает в повышении usability для изучаемых предметов (языков программирования/моделирования), но и learnability -- это разные свойства. Requirements нужно формулировать для обеих характеристик. Легко такую банальность предложить, трудно выполнить.

Вопрос мой в том, что современные информационные системы решают многие из тех задач, которые раньше считалось, что смогут решать только экспертные системы. И эти системы написаны на обычных языках программирования, а не на логических языках. Нет ли какого-то способа представления знаний, отличного от тупого использования логического языка? Логическая парадигма только одна из многих, и в языках программирования она явно не главная. Иначе мы бы видели вокруг сплошных потомков Пролога. Но нет, потомки Пролога везде маргинализуются, и никакая опенсорсовость им не помогает. CycL тоже делал OpenCyc, потом закрыл этот проект: не взлетело. Логическое не взлетает, на SQL делают только запросы в базу данных, а не программируют -- вот я и интересуюсь, что ещё на свете существует для представления знаний. Какая-нибудь Java для представлений знаний неудобна, но модели самых разных domain обрабатываются в мире главным образом на ней, а не на CycL или Agda. Получается, вся краса мира у нас уходит в язык программирования, который нужен для того, чтобы вызвать SQL над базой данных, в которых и отображён domain. При этом как domain отражается в реляционных базах данных — понятно, этому учат в университетах, и по большому счёту DDD (domain-driven design) тоже редко когда про язык программирования, чаще про базы данных.Ответа в чате я так и не получил, хотя обсуждение и было бурным. Так что за подробностями отправим в чат, а тут продолжим.

3. Иметь дифференцируемый язык представления знаний как eDSL, чтобы использовать этот язык не только для ручного ввода архитектурных моделей и моделей требований в рамках облегчения работы subject expert по knowledge aquisition, но и в рамках порождения/generation, а ещё в рамках оптимизации (про "дифференцируемое всё" я писал в https://ailev.livejournal.com/1464563.html). У Julia тут неплохая репутация: Viral Shah [один из разработчиков компилятора Julia] addressed the World Artificial Intelligence Conference, held in Shanghai Aug 29-31 with a discussion on "Julia: Generalizing Deep Learning with Differentiable Programming" (почему я и хотел бы держаться к Julia поближе, а не к C#, С++, R или каким-то другим языкам, не приспособленным для численных методов). Порождаемые архитектуры, оптимизируемые архитектуры, фронтир — вот это всё тут, все эксперименты с искусственным интеллектом и компьютерным творчеством.

4. А ещё нужно будет реализовать mapper (генератор конверторов/адаптеров/плагинов/мостов и т.д. -- систему типа .15926 https://github.com/TechInvestLab/dot15926/, только не обязательно на ISO15926, зато с удобным порождением парсеров и генераторов данных, eDSL для этого), ибо любой архитектурный редактор быстро будет нуждаться в частных моделях из разных САПР, и дело быстро дойдёт до полноценной PLM. Когда будет реализовываться мэппер, там результат будет вполне дискретный и формальный и FOL внутри, а вот методы получения моделей данных могут быть с использованием нейросетей, вероятностных языков и разных других численных алгоритмов. В итоге получится гибрид, а не только нейросети или только строгая логика. Вот, кстати, пример такого "загрузчика данных" (мэппера) для табличек: о "импорту табличек в программу", Flatfile can automatically match 95% of imported columns, using a combination of machine learning and fuzzy matching. Users can upload data via CSV, XLS, or simply paste from the clipboard — https://venturebeat.com/2019/09/10/flatfile-pursues-intelligent-data-importing-with-2-million-round/. JuliaDB при этом тоже работает с файлами табличек, в колонках которых могут быть любые типы Julia, а не только числа или строки, но всё-таки мэппер должен работать не только с табличными форматами. Первое, о чём спросят инженеры, так это о мэппинге 3D-моделей современных САПР.

Задача представления системных знаний на SysMoLan сложная, поэтому решаем её эволюционным путём, а не "сразу всё во взаимоувязке". Системный подход не должен становиться болезнью, когда вгоняет проект в analysis paralysis и заставляет "учесть всё-всё" в один подход и один проход.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216230511529525
2019

Объединяем программирование, моделирование, представление знаний

24 августа в 13:11 был создан чат "Типы в языках программирования, моделирования, представления знаний" -- https://t.me/typeslife, и за прошедших четыре дня в него набежало уже 176 любителей поговорить о типах. Ох, и много было наговорено! Текста я туда написал тоже оченьмногабукофф, даже не буду сюда эти тексты копировать. Но сформулирую некоторые выводы.

1. В основе всего должен лежать какой-то "обычный GPL". Под этим "обычным GPL" имеется ввиду современный язык, на котором можно делать eDSL. Например, C# и Julia. Языки, на которых легко программировать, хорошая инфраструктура, приемлемая надёжность кода, надёжность обеспечивается понятностью. Языки, у которых дизайн-цель безопасность (доказательства правильности программ) -- они не подходят, а если для "обычного GPL" потребуется при передаче в production обеспечить безопасность, то ничего не нужно переписывать: просто будут воткнуты дополнительные аннотации и типизация таки будет проверена (средствами языка, или внешним чекером, это неважно), а то и в рантайме поставим дополнительные тесты.

2. Языки представления знаний -- это какая-то формальная машинка для работы с микротеориями. Обычно там какой-то логический движок, FOL плюс какие-то HOL расширения. SQL, SPARQL (забыть: триплы это тупик. Начинать нужно сразу с n-арных предикатов), Datalog и прочая -- вот это оно всё. Но смотреть нужно на CycL как на успешный движок. Другое дело, что языки представления знаний крайне не приспособлены для моделирования. Поэтому хорошо бы реализовать язык представления знаний как eDSL над GPL. И помнить, что язык для знаний -- это полноценный движок/солвер FOL прежде всего. Онтологика это онтология+логика.

И тут ещё важен коммуникационный аспект: идёт обмен моделями разных микротеорий, поэтому не будет хватать "просто базы данных", нужны расширения для документарных форматов (думаем о чём-то типа бинарного варианта JSON-DL). Собственно, по этому пункту максимальное количество непоняток, разночтений, споров -- по сути дела именно тут мой начальный запрос: как встречаются foundational ontology и upper ontology, нужно ли вообще иметь upper ontology, если всё микротеории, и т.д..

Этот язык justy_tylor реализует как компилятор на C# (ему важна совместимость с корпоративной инфраструктурой и сахарность синтаксиса), а для меня важны были бы стыки с deep learning, probabilistic programming и NLU + всякое инженерное моделирование. Это сегодня главным образом Python и проблема двух языков, но конкурентом там потихоньку становится Julia. Поэтому можно думать о том, чтобы сделать eDSL как набор различных разогнанных на GPU FOL/HOL солверов по примеру DifferentialEquations, JuMP и Modia.

3. В языках важна их сахарность (этот тезис подробно развивал justy_tylor). По формальным моделям есть множество "эквивалентностей", но вот людям или удобней, или неудобней какие-то конкретные синтаксисы, а уж что там потом делает компилятор, преобразуя из удобного для хорошей нотации формализма в удобный формализм для быстрых вычислений -- это дело компилятора. Если нужно преобразовавать в триплы, то пусть солвер FOL это преобразует и оптимизирует где-то там внутри себя, а на поверхности должны быть паттерны, n-арные предикаты (я помню весь ужас перехода от триплов к представлению паттернами -- заборы и коровники на много частей стандарта). Язык с плохим синтаксисом и хорошей семантикой проигрывает языку с хорошим синтаксисом и плохой семантикой. Поэтому возможность "нотационных расширений" важна. Среди таких расширений можно назвать Prolog DCG как пример компактности "из ниоткуда" для парсинга (DCG -- https://www.metalevel.at/prolog/dcg или DCTG — http://cmsmcq.com/2004/lgintro.html, и можно поглядеть ещё работы по проекту FONC O-Meta с теми же целями "минимальный язык для парсинга", но там не FOL а хитро понимаемая объект-ориентированность -- http://tinlizzie.org/ometa/), какой-то синтаксис для possible worlds (и тоже в VPRI были работы на эту тему -- http://www.vpri.org/pdf/m2013002_experiments.pdf). Так что языко-ориентированность в том числе и нотационная -- она важна.

4. Ну, и eDSL для моделирования/simulations, всяческих микротеорий -- синтаксис, типы, солвер для модели. Это понятно, это не обсуждается. Пример тут Modia для инженерного моделирования. С этим всё понятно, тут нет особых вопросов.

Итого: нужно смотреть на то, что происходит с языками представления знаний: всякими knowledge graphs до того момента, когда их вливают в нейросетки -- какие там языки представления графа, что там с выводом, как ускоряют вывод. Отдельно алгоритмы, отдельно разгон на GPU -- хотя это связанные вопросы обычно). Последние интервью Дугласа Лената говорят о том, что там продолжается линия на "мы разгоним FOL с HOL над knowledge graphs с микротеориями и прочими хитростями до приемлемых времён, и таки победим всех, ибо common sense и причины таки у нас".

Но иметь какой-то eDSL проект по представлению знаний (солверы FOL-HOL, посаженные на GPU) в Julia, напоминающий JuMP и DifferentialEquations -- это было бы интересно.

Самый большой риск: логические языки все эзотеричны, они ещё более эзотеричны, чем функциональные языки (про Curry-Howard помним, да), и языки представления знаний в классической чисто логической традиции выражения FOL поэтому рискуют быть такими же эзотеричными, как Пролог или CycL сотоварищи. Другое дело, что SQL это и FOL и тьюринг-полный язык, так что необязательно речь идёт о чём-то страшном-страшном. Так что там могут быть "форматы представления FOL" и собственно FOL-солверы. Но это детали.

Всё одно дело мутное. Эти самые вопросы с foundation ontolgy и upper ontology и выражением микротеорий (что нарушает всю "консистентность вывода" в рамках программы -- и нужны средства работы с микротеориями, которых нет в существующих системах типов языков программирования, плюс коммуникационные вопросы по обмену/федерированию знаний в этих микротеориях), похоже, нужно искать таки в языках знаний, а не языках программирования или языках программирования баз данных. И прикручивать болтами к экосистеме deep learning, NLU и прочим пришельцам из вычислительной математики. Так что пока меня не убедили, что в Julia это всё делать бессмысленно. Наоборот.

UPDATE: обсуждение в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216135078543760
2019

Чат по типам в языках программирования, моделирования, представления знаний

Поскольку в чате "Zависимые типы в массы!" обсуждение моделирования жизни этими типами считается оффтопом (странно, но так), то был стартован другой чат -- в котором могут обсуждаться кроме зависимых типов самые разные типы и бестипья -- "Типы в языках программирования, моделирования, представления знаний", https://t.me/typeslife. И там сразу какая-то дискуссия, с самого начала (за первый час в чат пришло более двадцати человек).

Но и эти типы в языках (а хоть и программирования, моделирования, представления знаний (онтологизирования). А я бы ещё предложил и типы в коннективистских структурах, типа нейронных сетей. "Линейщина", как там ласково называют любые переходы к недискретной математике -- от quantitative type theory https://bentnib.org/quantitative-type-theory.html до собственно дифференцируемых типов в дифференцируемых программах по линии рассуждений "дифференцируемое всё. от чёрно-белой модели мира к рябенькой" -- https://ailev.livejournal.com/1464563.html.

Больше типов богу типов!

Но мой вопрос, поднятый в "Типы языков программирования как foundational ontololgy" https://ailev.livejournal.com/1485657.html и далее развёрнутый в "Foundational ontologies -- типы в языках программирования против БД" https://ailev.livejournal.com/1486211.html про state of the art систему типов как foundation ontology пока остаётся неотвеченным: разные системы типов разбираются сами по себе, чаще всего без обсуждения того, как они хороши в качестве foundation ontology (то есть хороши вместо объектов из ООП, табличек из реляционной алгебры, триплов из логики первого порядка и т.д.).

Я вообще уподобил эти системы типов CISC и RISC архитектурам процессоров. Простые системы типов точно так же побеждают "по очкам", как RISC процессоры в процессорной архитектуре.

Ну, и дальше -- как делать DDD с этими complex type systems или reduced type systems, это ж современная форма онтологической работы. Моделировать в языке программирования и API, или сразу делать концепутальную модель данных для базы данных и как её потом транслировать в физическую модель данных для конкретной базы данных и/или языка программирования. И как там быть с программированием/моделированием/онтологизированием-в-большом (см., например, материалы по ссылкам в https://ailev.livejournal.com/1391038.html).

Сейчас всё больше и больше людей занимаются по факту онтологией, но не знают об этом. Ну, типа "говорят прозой", но не знают слова "проза". Фишка в том, что ещё непонятно, где знание прирастает быстрее — у самих computational ontologists или в этих смежных областях.

Вот люди из NLP с deep learning пришли, и почти вся допотопная вычислительная лингвистика пошла лесом ))) С классическими compotational ontologists вполне может быть подобная история.

Так что я бы про онтологию как практику привязки моделей к жизни говорил, а вот про онтологов — уже с большой осторожностью. Люди, занимающиеся DDD занимаются онтологией, хотя и кулибинствуют вовсю. И люди, делающие классификаторы с нейронками, тоже занимаются онтологией, и тоже кулибинствуют. А ещё есть классические формальные философы (которые с формулами, но без языков программирования — типа "математики в её связи с миром"), так они тоже занимаются онтологией — типа David Lewis с его possible worlds. Онтология при этом, конечно, должна сильно поменяться, когда ей занимаются все, кому не лень. Она и меняется.

Кому интересно -- разговаривают об этом вот тут (https://t.me/typeslife).

Для меня это важно в связи с SysMoLan (например, https://ailev.livejournal.com/1449992.html -- про онтологический статус объектов SysMoLan, про систему его типов) и в связи с планирующимся курсом вычислительного мышления, где нужно будет говорить про state-of-the-art в типах -- https://ailev.livejournal.com/1477090.html

UPDATE: меня очень волнует набор типов из моего учебника системного мышления, гармонизированный с IEC81346. К этому модель HQDM будет поближе, но всё одно нужно разрабатывать эту upper ontology отдельно — инженерная и менеджерская жизнь-то с этим системным мышлением чуток поменялась. И это нужно в upper ontology учесть.

Ну, и какую систему типов, сиречь foundational ontology мне для этой концептуальной/методлогической работы выбрать?

Вот это мой вопрос!
2019

Foundational ontologies -- типы в языках программирования против БД (2/2)

Окончание. Начало текста в https://ailev.livejournal.com/1486211.html

[но триплы или FOL -- это язык для представления результатов, но не ведения самой онтологической работы. Формального языка для обсуждения физического смысла, приговариваемого к уравнениям, нет. С онтологией те же проблемы]
Абсолютно так. Ровно те же проблемы. При этом "смысл около, описанный комментариями" — это так не должно быть. Для меня это всё как-то связано со схемами причинности, где за последние лет пятнадцать произошла революция (там всё было формализовано, говорят теперь о причинном выводе — то есть там смогли навести логику, см. https://ailev.livejournal.com/1435703.html).

То есть у нас есть прагматика (для чего это всё), причинный вывод (те самые "связи в комментариях"), рассуждения по абдукции и выучивание модели мира для объяснений (вот свежее соревнование — https://leaderboard.allenai.org/anli/submissions/about), большие базы знаний common sense для всего этого и foundational ontologies для быстрой обработки.

При этом, похоже, методы работы крайне разнятся, когда нужно интегрировать данные нескольких разных проектов (базы данных, где foundational ontology делается сейчас таблицами, и идёт разгон скорости за счёт работ типа СQL) и просто сочинение произвольных foundational ontology в виде самых разных систем типов языков программирования с весьма эпизодическим понимание, нафиг оно вообще нужно при работе программиста, моделирующего мир на всём это разнообразии (ибо те, кто разрабатывают все эти типы, обычно решают олимпиадные задачки in the small, и им фортранных типов бы хватило с головой для моделирования мира. Ну, и паскалевских структур, но и их могли бы заменить common blocks в фортране — там же по факту за счёт этих common blocks был реализован пакетный язык, а не "просто императивный", весь этот поход на модула и ада был не нужен по сравнению с тем же паскалем с аналогом common blocks, вот и не взлетело). ООП как раз выросло из того, что предлагалось не "держать комментарии в уме", а прямо моделировать понятия мира объектами — и для in the small это хорошо шло. Про триплы же не пошло ввиду отвратительной производительности субд с этой foundational ontology со стороны "математики" и плохо продуманных средств работы с онтологическими паттернами со стороны выражения моделей мира (ибо триплы это оказалось как ассемблер, а как поднимать уровень языка сразу не договорились, и прошло очень много времени, пока хоть какая-то договорка прошла. Но после этого всё сдохло, ибо эти "онтологические паттерны" для выражения мира плохо клались на триплы, всё в аппаратуре было медленно и печально как по памяти, так и по времени — часть этих проблем описана в https://justy-tylor.livejournal.com/171175.html).

То есть для меня это всё история про связь foundational ontology и upper ontology — их вечная нестыковка. При этом в upper ontology научились тоже как-то модуляризировать их, "микротеории" делают. А в foundational ontology если мультипроект, то базы данных, а если "просто программа", то вообще системой типов не заморачиваются и работают на чём есть (ну, или "безумные инженеры" пытаются выдумать, зачем вообще нужны их навороченные типы, хотя хватило бы типов паскаля для большинства целей, а все навороты — это для одной-двух "фишек" в программе). Работы типа использования типов в F# для онтологического моделирования https://pragprog.com/book/swdddf/domain-modeling-made-functional — это большая редкость, ибо в задачах с использованием DDD сразу предполагается работа с СУБД, а не работа внутри программы. Но объектные СУБД при этом накрылись медным тазом (идея о том, что система типов в БД и в программах должна быть одна и та же — конечно, ООП, если везде было только ООП). И с тех пор эту идею никто не поднимал на щит опять. Типы в базах данных развиваются отдельно, в языках программирования отдельно. Связь между ними держится "в уме", теми самыми "комментариями в голове программиста", как комментарии физика держатся в голове для уравнений математики в его задачах.

Вот пример такого рассуждения, связывающего "вершки и корешки", тот же Валерий Крылов два дня назад: "В принципе, за прошедшие с нашей .15926-движухи годы я ни разу не видел успешного применения подхода 4D (выделение темпоральных частей и их реификация, как в ISO 15926) или подхода 3D+1 (реификация отдельных фактов, как в Gellish) на практике. Кому нужны лишние джойны и медленные запросы к базе данных? Никому. Поэтому используется 3D с прошивкой времени прямо в факты под конкретные задачи, благо с появлением фич из temporal databases в SQL:2011 это стало ещё немного удобнее. И в рамках отдельных микротеорий это самый правильный подход" (это в дискуссии к начальном посту данного треда про онтологическое моделирование "на типах в языках", а не "на базах данных" — https://ailev.livejournal.com/1485657.html).

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

[хотите сделать онтологический клей? так в чём проблема всё-таки?]
Обычно мне требуется некоторое время для объяснения сути дела — наличие проблемы ещё и с трудом признаётся. То есть в разговорах эта проблема обсуждается (куда ж без неё, программировать-то надо), а в книгах и статьях — нет. Разные тусовки, занимающиеся онтологиями, базами данных, типами в языках, соответствующей математикой — они эту проблему не видят, посколько она "на стыках".

"онтологический клей" — я думаю, это такое высказывание о задаче интеграции данных жизненного цикла, когда есть что склеивать этим клеем. А я говорю ещё и о том, что хотел бы понимать, как написать декларации типов для решения задачи в какой-то предметной области. Учебники по тому, как это делать для реляционных баз данных есть. Как это делать для графовых баз данных — появляются потихоньку. Как делать для программ безо всяких баз данных (с persistance, например) — мне показали на один, для F#. Но это не общий рассказ про то, как делать такую работу в языках программирования. При этом если взять ООП — то там опять всё радостно появляется, ну так за тридцать лет могло и появиться. Но почему-то ООП базы не выжили, и в языках программирования тоже ООП сегодня только ленивый не пинает — то есть не так уж и хорош этот подход к моделированию мира оказался.

И текущий момент таков, что все работают с проблемой "на коленке", кулибинствуют. Проблема на стыке интересных задач разных сообществ. Я весь этот тред пытаюсь поточнее изложить формулировку. Ибо в этой формулировке каждое из сообществ видит хорошо свою половинку проблемы, а вторая половинка для неё невидима — вот и не получается разговора.

Проблема как раз в том, что никаких примеров и нет. Вот вам дают обсчитать какую-то хитрую метрику кредитного риска. На входе данные от оператора (которому эту метрику нужно считать), а ещё данные из базы данных. Экраны для оператора из банка должны придумать вы, а база данных уже кем-то придумана — вы получаете не мир, а его модель в каком-то формализме (реляционная база данных, например — но это ж не говорит о том, как именно отмоделирован там мир!). При этом вы выясняяте подробности про хитрую метрику кредитного риска у subject experts, делая пометки у себя в блокнотике. А потом вы пишете декларации типов в вашей программе, исходя из возможностей вашего языка программирования (конечно, это язык с зависимыми типами! Из тех, что часто обсуждаются в этом чатике) — и как-то отражаете в нём то, что идёт с экранных форм, рассказал вам эксперт по рискам и вы достаёте из базы данных. И вот как вы это делаете, и о чём в этот момент думаете, полностью относим к вашей смекалке и сообразительности. Хотя онтологи тут бы сильно возражали, люди из баз данных укоризненно качали головами, а программисты вообще не замечали бы проблемы — "все ж с данными так делают!".

У онтологов и людей из баз данных есть соображения о том, как описывать мир (у онтологов на уровне концептуального проектирования, у разработчиков баз данных на уровне приземления концептуальных моделей данных на реляционные главным образом, или на графовые структуры). А у программистов ничего про мир не говорится, про приземление концептуальных моделей на типы не говорится. И эти дилетанты в моделировании данных, но профи в алгоритмике и математике моделируют мир уж как могут, "исходя из опыта". А вот про алгоритмику у них наука! И про типы без относительно того, что ими выражать (ими ведь мир описывают, без этого они не нужны) — тоже наука. А вот как описывать мир этими типами — нет науки. Вот мне надо описать работу атомной станции со всех сторон (чертежи, режимы работы реактора, штатное расписание персонала и т.д.). Я её реляционной моделью данных должен описывать, одним из вариантов ООП или каким-то вариантом использования зависимых типов? Молчание мне ответом. При этом люди из БД победят — они сразу скажут, что данных много и с ними будут работать сразу много программ. И все ваши зависимые типы и ООП и даже некоторая часть онтологов (но не все, там мостик-то протоптан некоторый) отвалятся по факту.

Ну вот SAP — это про базы данных, и там "из коробки" есть модель данных на примерно 30тыс. табличек. Это некоторая модель предприятия. При этом, скажем, если у тебя нужно описать каталог оборудования и (что неправда) каждый вид оборудования описывается одной табличкой, то 15тыс. видов оборудования (это очень маленький каталог!) описываются сразу 15тыс. табличек, и запросы к такой базе начинают быть грустными. При этом, конечно, как-то изгаляются: на реляционной модели пишут какую-то другую "наложенную объектную модель" (чаще всего объектную, ибо других вариантов не знают) и как-то уже заполняют всю базу в соответствии с этой моделью. Потом скорости не хватает, и пишут прямо поверх этой модели в исходные таблички, наступает бардак. Но вот обработка ведётся где-то в "бизнес-логике", внутри программ. А программы пишутся на "обычных языках программирования", и дальше идут запросы в базу данных, переконвертация из типов базы данных в типы языка программирования, а затем вычисления для предметной области обработки этих данных (что-то там в коропоративной аналитике, например) в самом языке программирования и затем выгрузка результатов назад в базу данных. Всё это сопровождается головной болью по поводу синхронизации работы разных программ над этой базой данных (кто-то ещё читает, а кто-то уже пишет туда же), распараллеливания работы (считать-то много, параллельность выполнения запроса к базе, дальше параллельность обработки выгруженного), часть вычислений уходит в GPU-ускорители баз данных, часть в GPU-ускорители для операций с массивами языка программирования, и весь этот весёлый бардак с перегоном из формата в формат для вроде бы копеечных обработок весело журчит и булькает часами, и энтерпрайз прямо на глазах становится кровавым. Перегонка СУБД в оперативную память помогает, но не сильно — там всё плохо архитектурно, так что это просто "механическое ускорение", оно не из первых принципов. Так что SAP очень, очень хороший пример того, как всё печально)))

Ну вот я спрашиваю, как мне кодировать мир не в реляционных табличках, а прямо в типах языка программирования? Есть методичка? А мне отвечают: кодируй мир в реляционных табличках, но мы тебе расскажем, как более безошибочно строить реляционный запрос к этим табличкам, где ты закодировал мир (и всё достоинство нового языка в том, что он хорошая прокладка к SQL — который убог). Только программировать ты будешь на функциональном языке, типы внутри языка у тебя будут побогаче, но как кодировать в этой богатой системе типов мир, мы тебе не скажем — ибо ты просто будешь работать с этой богатейшей системой типов с убогим миром реляционных табличек. Ну, с убогим миром реляционных табличек и паскаль справится. Вопрос-то в том, что сначала богатый мир упихиваем в таблички, а потом таблички распаковываем в чудесатые типы — уже после того, как миру при упихиванию его описания в реляционку уже обрезали всё, что можно.

Так что там нет ответа на мой вопрос. Там foundational ontology — реляционная модель данных, или ER-модель (entity-relationship). А я говорю, что можно ли использовать систему типов языка программирования как foundational ontology — есть ли где такие работы? В ответ пока слышу, что "в основе всего множества и отношения, то есть графы. Графы упаковываем в таблички, получаем реляционку. Потом делаем запросы или на SQL, или для пущей оптимизации на CQL". Ну, это может быть одним из ответов. Но тогда я перестаю понимать, почему программисты не используют реляционные структуры прямо внутри программ, а используют навороченные системы типов, включая зависимые! Зачем им богатые системы типов, если в основе только отношения и функции, и они отличненько выражаются графом, а граф выражается табличками, а с табличками уже работает даже Excel и уж тем более SQL или его математизированный родственник CQL? ))) Я уж совсем утрирую, но в каждой шутке есть только доля шутки )))


Меня не интересуют SQL базы данных с реляционной моделью данных как foundation ontology. Я спрашиваю, зачем мне вообще эти базы данных, если у меня есть много более богатые системы типов для описания мира мимо реляционного представления — и я могу выражать сложные описания мира в типах языков программирования много более кучеряво, чем в реляционных табличках. А если мне скажут, что это неуниверсально, так я отвечу, что для доступа к значениям типов в языке программирования у меня есть сам этот язык — и уж он всяко будет не хуже языка запросов, он ведь как раз для обработки данных, упакованных в этих его кучерявых типах придуман!

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

Делают также попытки работать только в типах языка программирования, выгружая и закружая прямо дампы памяти для persistance. Существует уже куча бинарных форматов для этого (ибо XML и JSON тут опять же не помогают, а только мешают — выедают время, память и мозги на организацию кодирования-перекодирования при чтении-записи бинарных данных типов языка в текстовое представление). Но и там есть свои засады. В том числе то, что написанное одной программой становится трудно писать другой программой. Казалось бы, почему? Ведь в базах данных всё то же самое — но читают же! А тут типы языков программирования — но чтение оказывается по факту невозможным! Тут тоже отдельная история, но пока эта история маргинальна. Но она уже есть, ибо накладной расход на СУБД при нынешнем отсутствии ограничений на оперативную память и тренде на обработку в оперативной памяти уже игнорировать становится нельзя.

Ну, а понятные проблемы, о которых вы тут пишете, примерно в этих же формулировках обсуждались и десять лет назад, и в чуть более мутных — двадцать лет назад. Так что ждём-с прорыва. ))) Вот мой прежний плотный набег на тему был где-то в 2012 году, я и поинтересовался, что с тех пор произошло. Похоже, что особо ничего и не произошло. Ну вот Julia появилась с не-ООП моделью, а multiple dispatch и своей хитрой системой типов. Но там тоже онтологическая работа с этими типами не описана, хотя есть любопытные ходы на работу с моделями и DSL как таковыми на базе макроса @model — есть даже что-то типа инструкции, как писать DSL на Julia: https://julialang.org/blog/2017/08/dsl

Но в целом — продолжаем ждать каких-то результатов, идут исследования, это я из дискуссии уже понял.

[а почему вы не сформулируете проблему формально?]
А вы разве сомневались, что я не буду наводить тут формализм? Ибо формализм это обычно сжатие информации — и непонятно, что в ходе обсуждения окажется важным. Вот дообсудим, и будет формализм. А пока его нет — естественный язык.

Ну и "фантазируете" так это я гипотезы строю, а много пишу — так это я для разных проектных ролей описания привожу. Ибо часть моих слов для вас непонятна просто потому, что вы непонимаете, откуда я их беру. Скажем, Шекспира не читали, а кто-то идёт рядом и орёт в трубку: "Молилась ли ты, дьявол, Дездемона, на ночь? Я вот скоро уже приеду, и уж я тебе задам!". Вы вместо того, чтобы срочно вызвать полицию (если Шекспира читали) будете думать: "какой идиот, совершенно неформальное описание даёт — и вообще, зачем молиться перед тем, как к тебе приедут?".

Эх, были бы нормальные формализмы, я бы тут эти тексты не писал, а просто ими пользовался!

[так нету ещё "категорий и гомотопий из коробки", чтобы помочь с выражением онтологий!]
Мне ж необязательно именно "категории и гомотопии". Вдруг ещё что-то интересное появилось из новенького? Ну, и десяток лет назад ровно такие ответы были, мы ж тычемся в эту тему довольно давно. Когда мы начинали работать с ISO 15926, то вместо триплов одним из вариантов формализма рассматривалась теория категорий — вот, например, я писал об ISO15926L как языке программирования с логическими/категорными вычислениями, и там же ISO15926 по идее А.Власова рассматривать ISO15926 как язык описания типов в языках программирования, если к онтологии добавить языковую компоненту (ровно та же тема, что мы обсуждаем сейчас, и что вы говорите, "идут исследования как такое делать"). Прошло 9 лет с этого поста — и всё в том же печальном виде, "исследования идут" ))) Вот: https://ailev.livejournal.com/831024.html

[Так типы -- это не как строить мат.модели для мира, а как эти модели описывать!]
"В каких терминах математические модели описывать" — это как раз foundational ontology. Холст, на котором всё рисуется. Меня как раз этот ответ-то устраивает! А потом отдельно — про сами математические модели, как в них моделировать — это онтология, как upper ontology (понятно какую) нарисовать средствами foundational ontology.

Фишка в том, что John Sowa предлагает онтологии, у которых нет foundational ontology c понятными над ней вычислениями называть не онтологиями, а терминологиями — ибо там можно брать слова-термины для неформальных рассуждений. А в онтологиях можно брать термы для формальных рассуждений.

Но как я понял, устаканненных каких-то формализмов нет, и самый супер-пупер вариант — это предложить онтологам для их математических моделей задействовать разогнанную реляционку с теоркатегорным языком запросов в CQL, или намекать, как заюзать конкретный аппарат типов F# для подобной работы в DDD, но вот каких-то общих рекомендаций для подобной работы нет — "исследования идут". Ну да, десятки лет уже идут, ждём-с.

А пока катит новая волна из deep learning со всем вероятностным и дифференцируемым и многомерным: концепты (те же типы) как вектора в многомерном пространстве, вероятность отнесения к типу, выучиваемость типа вместо его программирования и т.д.. И все эти онтологии и "графы знаний" теперь массово грузят уже не в типы программ на языках программирования, а в нейронную сетку. То есть пока линия исследований в теории категорий рожает, появляется совсем новая линия этой же работы на других совсем механизмах и других идеях. Посмотрим, какая линия родит быстрее (моё мнение — должен появиться какой-то гибрид, но пока исследования идут независимо).

[так богатые системы типов нужны только для программирования функций и процессов! строгость нужна для доказательства правильности этих программ!]
Но зачем тогда супервыразительные системы типов, если моделировать нужно только функции и процессы?! В моделировании мира, кстати, тоже есть моделирование функций и процессов — но их упихивают в те же таблички!

И вот тут есть некоторая проблема с поворотом мозгов. В инженерии есть два способа работы с функциональными описаниями: через функции (ролевое поведение) и через ролевые объекты (которые себя ведут, т.е. функции у них). Функции выражаем отглагольными существительными, а ролевые объекты — просто существительными. А потом замечаем, что в языке существительных миллионы (включая спецтерминологию многих предметных областей). А вот глаголов всяких десяток тысяч основных, максимум тысяч тридцать. Более того, про глаголы люди думать толком не умеют, ибо с трудом их представляют (про поведение думать обычно очень контринтуитивно). А про вещи — думают на раз-два. При этом то самое 4D это попытка функции превратить в объекты (поведение определяется как взаимодействие участвующих вещей, отношение участия это специализация отношения часть-целое в 4D, в том числе речь идёт о темпоральных частях, то есть части во времени aka состоянии). То есть разнообразие мира, требуемое для коммуникации людей по всему множеству проблем, всё-таки упирается не в разнообразие функций, а в их одинаковость, но разнообразие связанных с ними вещей. Поэтому на нижнем-то уровне всё может жужжать в терминах отношений и функций, а вот на верхнем по необходимости должно представляться вещами — и вот тут и может быть зарыта собака. Если дать удобные средства конструирования из этих отношений и функций ролевых объектов — будет понятно, как представлять мир. А пока там "отношения и функции до самого низа", вещи представляем табличками, между табличками прописываем отношения, приговариваем к ним возможные функции (подразумеваемые). А потом уровнем ниже жужжим на языке программирования этих функций и отношений. А сахар выразительности для ролевых объектов остаётся уделом ООП, реляционок и прочих удобных для них систем моделирования. Но что-то мне подсказывает, что так рассуждать про современные системы типов неправильно. Хотя всё сказанное ну очень выглядит правдоподобно. Смотрит онтолог на мир, видит вещи и немного отношений (об этом ему говорит в теории концептов так называемая theory theory, я давал ссылку). Смотрит на описание типов в языке программирования — там ничего этого нет, и нет инструкции, как проще такое кодировать. Он идёт к спецам по моделированию данных в СУБД и они описывают ему реляционную модель. Он хватается за голову и идёт к триплам. Сильно легчает с головой, но проблема с памятью и временем исполнения — и приходится возвращаться к реляционкам. В общем, куда ни кинь, всюду клин )))

И чтобы не допускать неправильные композиции функций и процессов -- для этого не супервыразительность нужна, а вроде как обратное свойство -- набор ограничений ))) Для меня "нет выразительности — нет проблемы ограничивать лишнюю выразительность" ("нет головы — нет проблемы"). Или это выразительные языки ограничений для описания ограничений-утверждений типа https://en.wikipedia.org/wiki/Object_Constraint_Language ?

Другая линия вопросов — какой ценой это достигается. Не смог сходу найти цитату одного из успешных разработчиков языка, что "никто никогда не платит за формальную правильность, но всегда платят за удобство и скорость", это когда разработчика языка спросили о том, когда он выдаст формальную семантику. То есть ответ был "никогда, чтобы проект был живым". Максимальная безопасность это обычно максимальная цена, наращивать её можно бесконечно, и чем она больше, тем сложней пользоваться продуктом. Но можно выдать опасную в пользовании систему и в случае дыр отлаживаться — сумма сил, потраченных на отладку может оказаться меньше суммы сил на выворот мозга при разработке. Это, замечу, вечно живая дискуссия. Она в онтологии тоже популярна — та же разница между терминологиями и онтологиями проходит по этой линии. И в эту дискуссию тоже стремительно врываются рассуждения про вероятности, что смывает текущие аргументы обеих сторон дискуссии и заставляет дискутировать по-новой.

Про строже это понятно в части правильности, непонятно про выразительность. Чем более выразительная типизация, тем более разные объекты можно описывать этими типами. Самая выразительная в мире система типов лучше всего опишет разнообразие предметов окружающего мира. Значит, её хорошо использовать для описания окружающего мира во всей его полноте? И тут прошедшая дискуссия говорит, что нехорошо — описывай мир реляционной алгеброй, а наши богатые типы мы будем использовать для доказательства правильности программ исполнения реляционной алгебры. Зачем для программ исполнения реляционной алгебры супервыразительность в типах? Я понимаю про строгость в типах для этих целей, но выразительность-то для этого воробья зачем? А за описанием мира во всей его полноте не гонимся, что ещё хитрого можно в мире описать новыми хитрыми подвывертами в системе типов не думаем. Вот это мне странно.

Почему вся выразительность используется не для выражения нюансов описаний окружающего мира, а только для ограничений неправильного поведения?! Для ограничения неправильного поведения достаточно очень ограниченной выразительности. Но если у нас выразительность повышенная, то почему мы тогда отказываемся говорить об описании мира, а только говорим об ограничениях неправильного поведения? Это как иметь алфавит с 500 буквами и говорить, что им нужно не мир описывать, а чистить ошибки в описании мира алфавитом из 5 букв. То есть имеем богатейшую систему типов, и используем её для описания программ обработки реляционных баз данных с реляционными описаниями мира, но не для ведения баз данных с богатыми по типам описаниями мира. Почему?

Я понимаю, что для выражения богатства мира нужна богатая система типов. Это я пытаюсь ярко продемонстрировать противоречие, которое мне тут рассказывают: что богатство типов нужно только для поддержки скоростных вычислений внутри БД с небогатой системой типов. Моя позиция как раз в том, чтобы брать языки с хорошей типизацией, и прямо на них писать модели предметной области — как наборы объектов и отношений, так и работающие с этими объектами и отношениями функции. Те самые DSL, взаимодействие между объектами которых обеспечивается хост-языком. Так сказать, не объект-ориентированность, а DSL-ориентированность. И богатая система типов нужна для выражения объектов и отношений в DSL. И для DSL могут быть какие-то онтологические guidlines в части описания объектов окружающего мира (DDD для меня это как раз маленькая часть таких guidlines). Но это моя гипотеза.

В жизни же DSL вдруг оказываются микросервисами с такими API, что с типизацией там фейспалм, а онтологизация там ad hoc.

И вся онтология уходит в концептуальные модели данных для базы данных, но не в концептуальные модели данных для языков программирования.

И трёхслойка (про концептуальную схему данных, логическую схему данных и физическую схему данных) известна для баз данных, но не для языков программирования. А ведь физическая схема данных — это оно и есть: как вся эта этажерка на основе upper ontology описывается в терминах поддержанных машиной вычислений на foundational ontology. И я возвращаюсь к изначально заданной теме: вот почему не рассказывается массово, как объекты мира выражать в терминах современных систем типов? Про ООП такого было и есть много, но БД на идеях ООП провалились, и сами ООП сегодня не считаются таким уж state-of-the-art в выражении структуры мира (в том числе онтологами). Но других развитых систем типов для описания мира не предлагают. Меня вот этот вопрос мучает.

Типа как кто-то выращивает персики, виноград, арбузы всё новых и более сладостных сортов, а кушать все продолжают сырую пшеницу и жалуются, что живот болит. И никаких инструкций, как кушать те самые персики. Они разрабатываются вроде как из любви к искусству, для скрашивания уродливости мира, помещаются в музеи. Почему мир не моделируют в этих типах, а моделируют только обработки внутри БД?! Почему?!
2019

Foundational ontologies -- типы в языках программирования против БД (1/2)

Когда мы работали с ISO 15926, то вместо триплов одним из вариантов формализма рассматривалась теория категорий — вот, например, я писал об ISO15926L как языке программирования с логическими/категорными вычислениями, и там же идея avlasov рассматривать ISO15926 как язык описания типов в языках программирования, если к его онтологии добавить языковую компоненту -- это 2010 год, https://ailev.livejournal.com/831024.html. Прошло 9 лет с этого поста — и я высказываю обратную идею: не ISO 15926 как система типов в языке программирования, а типы языков программирования как foundational ontology для upper ontology (ISO 15926 или какая там ещё) вот тут, пару дней назад: https://ailev.livejournal.com/1485657.html. В том числе, почему бы и не какая-то система типов, происходящая из теоркатегорного подхода. И я пошёл в чат любителей dependent types (https://t.me/joinchat/Ai4h2D9SWO8GfISyv-CHsQ), где более 400 его участников рассказали мне, что "из коробки" решения никакого пока нет, а "исследования идут" (старт дискуссии был тут: https://t.me/c/1062361327/22873).

В ходе разговора, конечно, много чего всплыло:
-- как это всё связано с теорией концептов, в том числе theory theory
-- онтологическая работа как комментарии к формальным структурам на FOL -- это как физический смысл, приписываемый мат.уравнениям. Это похоже на схемы причинности и причинный вывод (subject experts рисуют схему причинности, а дальше проверки идут вычислениями).
-- дифференцируемые и вероятностные системы типов, выучиваемые типы против традици
-- бестиповые языки и почему они не выживают
-- как работа с типами связана с programming-in-the-large и programming-in-the-small
-- почему не выжили трипл-сторы
-- почему не выжили объектные базы данных
-- абсолютная безопасность как абсолютная непригодность для работы
-- почему богатые системы типов не используются для моделирования окружающего мира как foundational ontology, а вот убогие реляционные базы данных и даже ещё более убогие трипл-сторы активно используются. А богатые системы типов используются для программирования вычислений над убогими системами типов.
-- для F# таки нашлась книжка, описывающая как делать DDD с его системой типов -- https://pragprog.com/book/swdddf/domain-modeling-made-functional (частичный ответ на мой вопрос "как использовать богатую систему типов для моделирования богатого на сущности мира" -- но для частного функционального языка)
-- про табличные базы данных помянуто в Seven Sketches on Compositionality. An Invitation to Applied Category Theory -- http://math.mit.edu/~dspivak/teaching/sp18/7Sketches.pdf. Более подробно про compositionality (как понять целое высказывание, состоящее из связанных частей) и applied category theory см. в https://arxiv.org/pdf/1809.05923.pdf и https://plato.stanford.edu/entries/compositionality/
-- knowledge representation in bicategories of relations -- https://arxiv.org/abs/1706.00526
-- теория категорий для ускорения реляционных данных, CQL (categorical query language, https://www.categoricaldata.net/ -- open source, литература в https://www.categoricaldata.net/papers), с коммерческим решением по интеграции данных на его основе -- https://conexus.ai/
-- стек технологий, где задачи моделирования мира и вычислений над моделью строго развязаны: движки над foundational ontology это могут быть одни движки (все эти SQL, SPARQL и CQL), а вот вычисления над моделью делаются из языков программирования с их богатыми типами ad hoc
-- Использование теории категорий для моделирования модальностей в юридических контрактах: https://legalese.com/. Очень похоже на проект с такими же целями, как SysMoLan, только там для юридизмов — идеи с модальными логиками будут развиваться. Там, правда, у онтологов тоже есть предпочтения, модальности сегодня проще моделируются как раз классификаторами, то бишь теми же типами.
-- ... много всего по мелочи, я не писал сюда подробных ответов, больше собственные реплики. А полезные ссылки привёл прямо тут в предыдущих строчках.

Делать литературную обработку всего треда мне лень, но для архивных целей вытащу свои реплики сюда. Всё началось с перепоста:

-- Высказывается идея, что типы в языках программирования — это foundational ontology. А для upper ontology (в том числе 4D upper ontology) нужно просто сделать DSL в каком-то расширяемом языке (например, взять для этого Julia). Даётся критика требований визуальности, высказываются сомнения в reuse онтологических моделей людьми и осмысленность их подготовки для использования кремниевыми мозгами. И указывается, что вероятностные типы и коннективизм тоже нужно включать в рассмотрение. В тексте предлагаются работы для todo list и приводится много разных ссылок. Незнакомому с онтологической инженерией человеку текст не будет понятен. -- https://ailev.livejournal.com/1485657.html

[но это ж всё философия! нет формул!]
Вот стенфордская энциклопедия философии, как раз статья про Type Theory. Вся из формул состоит: https://plato.stanford.edu/entries/type-theory/. то, что мне нужно — тоже ни разу не философия. И пруверы у онтологов — самый распространённый инструментарий. Только онтологи задаются вопросом, какие объекты в мире они моделируют, а математикам это пофиг. Так что это математика+ ))) Онтологика. )))

Вот пример того, что заботит онтологов: https://www.cyc.com/wp-content/uploads/2015/04/AAAI-SharmaA.1646.pdf

Cognitive systems must reason with large bodies of general knowledge to perform complex tasks in the real world. However, due to the intractability of reasoning in large, expressive knowledge bases (KBs), many AI systems have limited reasoning capabilities. Successful cognitive systems have used a variety of machine learning and axiom selection methods to improve inference. In this paper, we describe a search heuristic that uses a Monte-Carlo simulation technique to choose inference steps. We test the efficacy of this approach on a very large and expressive commonsense KB, Cyc. Experimental results on hundreds of queries show that this method is highly effective in reducing inference time and improving question- answering (Q/A) performance.

Формулы в статье есть, в количестве ))) И ссылки на литературу типа Bridge, J. P., Holden, S. and Paulson, L. 2014. Machine Learning for first-order Theorem Proving. Journal of Automated Reasoning, 53(2):141–172

Люди, занимающиеся только "традиционными нетрадиционными" языками программирования и математикой просто не залезали в AI. А там сейчас бодро, и у машинных обучателей, и у онтологов.

[а что такое вероятностные типы?]
Ну, теория веороятностей стала логикой. Вот вам короткая ранняя статья на эту тему -- E.T.Jaynes, Probability theory as logic, 1989, 16 страниц -- https://b-ok.cc/book/454548/12202a. А вот более современная классическая книжка: E.T.Jaynes, Probability Theory: The Logic of Science, 2003, 757 страниц --
https://b-ok.cc/book/942315/05fbc7. Другое направление — это probabilistic programming, https://arxiv.org/abs/1809.10756. Языков на эту тему уже чёртова туча (в частности, реализованных как DSL, в последнее время чаще всего на Julia): https://en.wikipedia.org/wiki/Probabilistic_programming [а вот работа по доказательству правильности вероятностных программ -- Formal verification of higher-order probabilistic programs: reasoning about approximation, convergence, Bayesian inference, and optimization, https://dl.acm.org/citation.cfm?doid=3302515.3290351, январь 2019. И ещё наброски
http://users-cs.au.dk/spitters/ProbProg.pdf Faissole, Spitters, "Synthetic topology in Homotopy Type Theory for probabilistic programming"
https://github.com/FFaissole/Valuations/].

Если брать онтологическое понимание типа как участника отношения классификации, то все задачи распознавания в deep learning — это вероятностное отнесение к типу. Поэтому получают распространение сейчас и вероятностные онтологии, но там пока не слишком весело (ибо люди из deep learning пока обходятся без онтологов, они работают с простейшими онтиками для отдельных задач. Онтологи нужны, когда нужно собрать какую-то общую модельку из десятка разных моделек, или объяснить что-то, или работать с особо большими структурированными моделями, а в deep learning работа с multitask ещё не слишком развита).

[это оффтопик, это статистический анализ программ, а у нас тут логика]
Не надо путать вероятностную логику со "статистическим анализом программ", да и речь не идёт о доказательстве правильности программ. Другое дело, что логика -- это одновременно и про:
— правила хороших рассуждений вообще
— конкретный вариант хороших рассуждений
— тесно переплетена с онтологией (ибо рассуждать всегда нужно над чем-то)

И везде есть математика, доказательства, языки программирования, семантики и т.д.

Поэтому легко запутаться с этими топиками-оффтопиками.
Мне просто показали место, где "с людьми можно поговорить о типах в языках программирования", я и обрадовался. Выяснилось, что отнюдь не о всех типах, и не о всех языках программирования/моделирования. А жаль. Все сидят по своим норкам, каждый занимается маленьким кусочком проблемы типов, результаты одних невидимы другим.

[может, это всё в чат по теории категорий? -- https://t.me/ru_catheory]
У нас было множество попыток использовать теорию категорий в качестве аппарата для языка системного моделирования — все закончились ничем. Не приспособлены кролики для лазания ))) Там кстати и в названии "учим и обсуждаем", но не "обсуждаем и применяем" — прикладность всё никак и никак не получается.
То, что в любой формальной системе можно выразить что угодно, это понятно. Вопрос был в том, что это "легкое и простое выражение" что потом позволяет делать? А ничего особенного, как выяснилось. Просто выражать. Ну, просто выражать можно и так, как сейчас выражают — инженеры же искали не теоретическую красоту, а облегчение свой работы. Облегчения не было предъявлено, пути к облегчению работы не были показаны.

[так а что инженеры ищут в новых теориях?]
Речь шла о создании языка системного моделирования. И обсуждался формализм (или отсутствие такового). Было много разных заседаний. Вот тексты, там в ранних много про теорию категорий — но так и не срослось. Цепочка SysMoLan -- https://ailev.livejournal.com/1443879.html. Но есть и ещё одна задача, по факту та же самая -- о предмете курса вычислительного мышления, https://ailev.livejournal.com/1477090.html

[а что мешает инженерам взять Coq, Idris и прочие языки исчисления конструкций?]
Тогда программисты бы это взяли ещё раньше инженеров. Но не берут ))) Язык оказывается социальной проблемой: берут языки за возможность что-то на них делать, а не за математичность, красоту, современность и прочие качества.

Заход на обучение computer science на базе функционального маленького языка не получился: все остальные курсы не получалось надстраивать над знаменитым SICP, обучение дальше шло по факту с нуля. Прикладная польза была ноль, хотя курс сам легендарный. Для Coq ведь будет то же самое.

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

[вы ходите увидеть язык на все случаи жизни? так универсальные языки универсально неудобны. Инженерам нужны DSL, собранные конкретно для них. И собирайте эти DSL хоть на машине Тьюринга]
Под каждым DSL своя онтология. И мы возвращаемся к проблеме типов. DSL — это domain-specific language. Domain — это предметная область, набор предметов. Что попадает в эти предметы, и как эти предметы описывать — онтологический вопрос. Дальше вопрос не в математической мощности, а в вычислимости, удобстве написания и т.д.

Про машины Тьюринга развлекитесь: https://arxiv.org/abs/1611.02854. Вы ещё дифференцируемые типы не обсуждаете? Пора бы уже. Оптимумы для типов будете искать )))

[так инженеру по требованиям, инженеру-архитектору, инженеру по испытаниям нужны разные языки, они по-разному описывают систему. Так?]
Нет, я не согласен с таким различением — и ровно потому, что вопрос ставится онтологически. Целевой системой и у инженера по требованиям, и у инженера-архитектора, и у конструктора, и у инженера по испытаниям является работающая установка-в-железе (или программа в тот момент, когда она на рабочих серверах и на неё передано управление), в тот момент, когда они наносят непоправимую пользу своей работой. Описание (документирование) происходит и потребностей, и требований, и архитектуры, и планов испытаний, и результатов испытаний. Ключевое требование — чтобы они отражали реальность (онтологичность, моделирование мира, а не просто запись всяких фантазий), а не были просто упражнением в формализации.

Вот это моделирование мира инженерами выполняется:
— в программировании in-the-small (обычно один человек решающий как бы задачку олимпиадного программирования) типами языков программирования, у кого это Julia, у кого-то Haskell, у кого-то Coq (хи-хи), но чаще всего это Java и ООП в полном расцвете сил.
— в программировании in-the-large (много софтов, работающих над какими-то общими данными на разных серверах) некоторой системой типов, наваянной либо над трипл-стором с запросами на FOL, либо над реляционной базой данных, где жужжит реляционная алгебра
— а ещё есть много-много обработки данных, где явной работы с типами нет, а есть Excel-таблицы и всякие запрограммированные на них формулы, работа с типами ведётся тем самым "в уме", а типы представимы в ER-модельке, выраженной набором табличек (но это ни разу не реляционная база данных, и там никакой алгебры, всё руками и не нормализовано).

Вот мой вопрос начальный как раз к тому, что довольно много литературы во отражению мира в реляционных базах данных (равно как работ по критике табличных представлений для подобной работы), чуток меньше литературы про отражение мира во всяких нереляционных моделях данных, например трипл-сторах (семантик веб, как оно называлось — и FOL там была наше всё). Но и там случилась засада, хорошо описанная в https://justy-tylor.livejournal.com/171175.html. Сейчас растёт литература по моделированию мира во всяких NoSQL моделях данных.

А вот литературы по отражению мира в системах типов, развивающихся в "просто языках программирования" нет. Так что там делают всё более и более хитрые модели данных, но неведомо, как их использовать для моделирования задач. Известно же, что в DDD для предметов предметной области (domain-driven design, слово domain то же, что в DSL, и слово "предметы" в "предметной области" я неслучайно употребил вместо привычного "объекта") должны существать какие-то объекты в программе. И эти объекты обычно выражают системой типов. И вот это место сразу становится мутным — какие типы брать, и что ими выражать в мире полностью отдаётся на "опыт и смекалку". Базы данных проектируют хоть как-то, этому специально учат, а вот модели данных в программах почему-то не проектируют — весь акцент идёт на алгоритмику, а не моделирование данных.

Это и был мой начальный вопрос: вот изобрели новую систему типов, всунули её в какой-то язык программирования — но объяснили, что даёт эта система типов для улучшения моделирования данных, для улучшения описания мира? Или это просто выпендрёж из серии "у меня ещё про типы столько разных интересных идей, и ещё столько разной недоиспользованной математики осталось"? (я надеюсь, что достаточно выразительно сформулировал наезд )))

Мой вьюнош как-то пришёл с одного из первых своих уроков физики, и сказал, что физика трудней математики: в математике можно писать что угодно, если не нарушаешь простые правила, а вот в физике нужно всегда проверять экспериментами, соответствует ли это "что угодно" миру за окошком. И математику нужно знать в полном объёме плюс добавить сюда знание мира за окошком, чтобы не фантазировать в своих формульных выкладках. Вот я примерно то же самое спрашиваю про системы типов в языках программирования: пофиг, что там крутая математика — но как в этих типах мир выражать, чтобы ошибок потом поменьше было? Например, в ООП что для одного проекта объект, то для другого атрибут, и наборот (как печально сформулировал консорциум по моделированию данных EPISTLE в конце 20 века). Поэтому для инженерных данных ООП не подходит, ибо страшная головная боль объединять данные разных проектов — в том числе проектов инженерии требований, инженерии системной архитектуры, конструирования (когда на САПР работают и строят трёхмерные модели деталей, проверяя их прочность), испытаний. Если система большая, типа Боинга или атомной станции, то с ООП просто головная боль. Поэтому объектные-из-ООП базы данных не взлетели вообще никогда.

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

[так вы занимаетесь эдакого рода физикой?]
Даже точнее: онтологию традиционно относили к метафизике, а не физике ("над физикой") )))

Хотя я больше занимаюсь эпистемологией — вопросом о том, как я эту онтологию познаю/выучиваю из мира )))

[ну вот поглядите на CQL -- categorical query language, https://www.categoricaldata.net/]
О, это интересно. Про моделирование данных меж тем ничего не сказано, кроме того что вроде как можно отследить преобразования в разных пайплайнах — что откуда пришло и куда ушло.

У меня вообще впечатление, что все "математические" работы идут из постановки задачи programming/modelling-in-the-small. То есть один человек сидит и пишет программку на 200 строк, кучерявые данные не нужны, зависимостей от программ других людей минимум, всё внимание алгоритму и правильности в пределах этих 200 строк. Умножьте даже на порядок или два, это всё равно in the small — один человек=одна картина мира.

Мои вопросы главным образом про поддержку работы in the lagre, когда множество проектных групп делают разные куски системы, исходя из своих разных картин мира, а потом эти куски системы ухитряются совместно работать — ибо они договорились, как совмещать эти разные картины мира/онтики в рамках какой-то одной онтологии.

https://en.wikipedia.org/wiki/Programming_in_the_large_and_programming_in_the_small

[для сохранения композициональности (когда можно в лоб составлять систему из мелких кусочков) и городится весь теоркатегорный огород!]
Вот не факт, ибо есть мир, есть я, есть они и есть описание мира моё и их — и композициональность как она тут понимается это больше про описание мира без мира, меня и их. Математическая композициональность. Это тоже нужно, да, но дальше хорошо бы показать, как этим пользоваться, тот самый domain modeling в мультипроектной команде, когда они складывают свои описания мира.

В мире моделирования тоже есть запросы на композициональность, и вместо Simulink придумали акаузальное моделирование. Когда для каждого аспекта моделирования делают свой набор уравнений (теплотехники свой, экономисты свой, электрики свой и т.д.), и оформляют эти наборы уравнений как библиотеки. А потом (в отличие от Simulink, где каждое усложнение модели приходится аккуратно вписывать в каждое место кода) машина из этих наборов из разных библиотек составляет систему уравнений и решает её.

Ещё есть expression problem — http://en.wikipedia.org/wiki/Expression_problem (и Julia решает её через multiple dispatch, там типы добавляются без необходимости что-то перекомпилировать в старом коде).

То есть заход на эксперименты в in the small хорош, но его недостаточно. Мышление коллективно, программирование/моделирование/онтологизирование тоже коллективно и суть одно.

[ну, мы ещё не разобрались, как записывать всё зависимыми типами, у нас только исследования]
Мой вопрос был главным образом не про "как", а про "зачем" ))) То, что до in the large не добрались, так это часть моего вопроса: по принципиальным сображениям, то есть невозможно до этого будет добраться, ибо работать не будет (как не заработали трипл-сторы и объектные базы данных), или наоборот, после окончания экспериментов вдруг все проблемы будут решены и это станет возможным.

[так инженерам что, нужен для перевода с двух их DSL какой-то третий язык?]
Я вот как раз сразу про этот третий язык — какой он должен быть? ))) Ибо после этого сразу появляется идея, что можно было бы сразу выучить его, если уж на него всё можно перевести с других языков. Он ведь самый универсальный. Собственно, нужда в общей картине мира возникает только в момент встречи двух разных языков и понимании, что начиная с третьего языка уже выгодно иметь какой-нибудь "рабочий английский" в проекте. Когда встречаются китаец, малазиец и испанец, то в этой компании все говорят по-английски, хотя англичан среди них нет ))) Вот вопрос сразу к "английскому для моделирования данных": каким он должен быть? Удовлетворительного ответа на этот вопрос нет.

Ну, и про то, что инженер по требованиям работает на одном языке, а инженер-архитектор на другом, так не совсем так. Различия в языках диктуются различиями в предметной области, а не различиями в требованиях или архитектуре (ибо что для одного "потребности", то для другого "требования" для третьего "архитектурные решения" — эта терминология относительна в части системных уровней). То есть это всё описания каких-то систем, просто на разных границах. А описания да, все на разных языках — ибо при пересечении системной границы появляется эмерджентность, и приходится описывать другие свойства.

[ну, у нас люди идут по пути создания своей математики со своими основаниями математики. И в гомотопических типах это даже более правда, чем в зависимых типах]
Моделировать не "как в математике". Физики моделируют "как в физике", напрямую используя математику. И в математике есть даже мнения, что математика интенсивно развивалась в 20 веке, именно обслуживая запросы физиков.

У меня запрос похож на запрос физиков к математике. Только я не физик, а разработчики типов в языках программирования не математики. )))

[а что там с экстенсиональным/интенсиональным?]
На эту тему идёт вечная дискуссия. В 4D экстенсиональной онтологии принято считать, что вся система тамошних типов идёт от того факта, что это типизация объектов из реального физического мира (то есть это объекты, занимающие место в пространстве-времени). Если объекты занимают одно и то же место в пространстве-времени, то это один и тот же объект. Например, "Анатолий Левенчук" и "интенсивно цокающий по клавишам субъект" прямо сейчас занимают одно и то же место в пространстве (а "прямо сейчас" указывает ещё и на время). Значит прямо сейчас это один и тот же объект. Внешнее определение через пространство-время — экстенсинональное, а extent это (со времён Декарта) протяжённость в пространстве-времени, то что задаёт наличие объекта в этом мире. Всё остальное — это работа со множествами этих существующих в мире объектов. Множество, понятно, уже не существует в мире, это другой объект.

Ну, и это всё постоянно обсуждается, ибо не все онтологи согласны считать 4D представления о мире чем-то важным. А другие говорят, что тогда им немедленно попрёт фишка фантазировать о мире, плюс появляются неприятные вопросы про то, каков мир в момент времени между 3D его срезами )))

[так у нас математика в типах, в чистой отвязке от физики!]
Ну вот не так. У меня ж полно друзей с мехмата, и он недаром называется "механико-математический" — связь с физикой там предполагается! Вообще, эта привязка к миру или отвязка от мира есть и в самой математике, даже если отползти подальше от физики как таковой. Поглядите текст М.Атья "Математика в двадцатом веке", http://www.mccme.ru/free-books/matpros/i8005024.pdf.zip — он там про алгебраическую ветвь математики, "фон-нейман-компьютерную" и геометрическую ветвь, с приветом физикам, пространству и deep learning.

Можно ещё пообсуждать: когда я пишу про математику и про приготовление зелёного чая — это я по-русски пишу, или таки использую два языка "чтобы удобно было"? Или это DSL на базе русского хост-языка? )))

[если нужен таки третий язык, то это будет линейщина-моноидальщина, выраженная n-категорным языком. Если совсем попросту, то мультимодальная линейщина]
Ну вот ткните меня в книжку типа https://pragprog.com/book/swdddf/domain-modeling-made-functional для этого, или места, где такое обсуждают сейчас для этой мультимодальной линейщины. [7 скетчей, наверное, самое близкое]

[Но задачи будет решать не проще, если всё просто переписать в более общий язык]
Верное замечание. В deep learning в последнее время там воздерживаются от публикации работ с обобщениями или переформулированием в другие формализмы, если это не двигает как-то SoTA. Теоркатегорщикам можно заказывать кружку "your model is a special case of my model", это недорого: https://www.cafepress.com/mf/34058049/special-case_mugs

[так а CQL чем не подходит? язык запросов к базе данных на теоркатегорных основаниях!]
Там в статьях ссылка на categorical.info перенаправляется на https://conexus.ai/ — мотенизация CQL идёт полным ходом.

сonexus offers support for open-source CQL, support for data integration projects using CQL, and sells a proprietary extension of CQL that scales the open-source version along three dimensions:
- Visualization and programmer productivity
- Data size beyond a single in-memory node
- Artificial intelligence capabilities beyond simple equational reasoning

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

Вот критика этих табличных и реляционных представлений (BORO Book, http://borosolutions.net/sites/default/files/Business%20Objects%20-%20Re-Engineering%20for%20Re-Use%20%282nd%20Ed%20-%20watermarked%20draft%20-%2020050531%29.pdf#page=1&zoom=auto,-22,848), и это же пример IMHO лучшей онтологической книжки по моделированию данных (про концептуальное моделирование, а не про физическую реализацию, языки запросов, скорость работы и т.д. про foundational ontology там нет, там только про мир и его модели и как это должно отображаться разными типами в upper ontology).

Печаль момента в том, что предложенная концептуальная модель кладётся далее в триплы — а это тупик.
* * *
Окончание текста в https://ailev.livejournal.com/1486407.html

Обсуждение в чате блога -- https://t.me/ailev_blog_discussion/402, в фейсбуке -- https://www.facebook.com/ailevenchuk/posts/10216100232112621, в новом чате телеграмма про типы языков программирования (уже все типы, а не только depended), буквально с самого начала чата -- https://t.me/typeslife