Anatoly Levenchuk (ailev) wrote,
Anatoly Levenchuk
ailev

Category:

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

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

    Error

    Anonymous comments are disabled in this journal

    default userpic

    Your reply will be screened

  • 17 comments