August 23rd, 2019

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
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 в выражении структуры мира (в том числе онтологами). Но других развитых систем типов для описания мира не предлагают. Меня вот этот вопрос мучает.

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