@clayrat Они лучше, но этого недостаточно. Это лучший материал для описания мира, но всё ещё нет способа его описания.

это вы наверное @unmuamua отвечали

Да, пардон

следует ли понимать так, что описания мира есть, но они недостаточно формальны для запихивания в компьютер? чем тогда занималась аналитическая философия последние сто лет (я не знаю, чем, кстати, но чем-то же занималась?)

По сути Domain Modeling Made Functional показывает, что это лучше, чем Domain Modeling Made Object-oriented, которое показывало что оно лучше чем Domain Modeling Made in package languages.

Вот как должна называться книжка, чтобы выдать версию Domain Modeling лучше, чем Functional? Этот вот вопрос.

Часто то, что находится за 1 минуту гугля — это или прошлый state-of-the-art, или в новой области — текущий state-of-the-art. Так что не переживайте )))

Аналитическая философия последних тридцати лет как раз отражена в книжках BORO и HQDM в полной мере. Possible worlds, 4D — это вот всё.

Кое-какие попытки это выразить есть.
И связаны с линейщиной и пучками ;-)

Я тогда ещё лет через десять спрошу

Минуточку. Когда Вы говорите, что типы (той или иной системы) - это материал, то это понятно, как нечто вроде выбора языка описания *данных*. Но когда Вы говорите про способ, то сюда входит всё то, что умеют делать онтологи? Просто слышать, что стыковка по смыслу делается на основании совпадения 4D объема, как-то зябко.

По сути - да. Стыковать в описании не прямо по экстентам, конечно, это слишком низкоуровнево, и эти экстенты сложно и не всегда нужно описывать, но понимая, что стыкуемые сущности - это один объект, если это один экстент, и разные объекты, если это разные экстенты.

А вот хардвер и софтвер на нем, как их отличить?

Читайте BORO :) Софтвер - выполняющаяся программа, а не текст - это физический объект/процесс, который включает в себя некое железо в течение своего выполнения.

процесс в смысле 4d-экстенсионализма, а не процесс в смысле объекта OS.

Вот онтологи умеют делать такие диаграммы (и говорят, что в подобных описаниях нормально будет иметь порядка 200 типов "из коробки" — upper ontology).
Требуется выбрать язык описания для такого — foundational ontology. Сегодня это RDF/OWL с логикой первого порядка, или даже CycL с логикой "полуторного порядка". А программирование всё одно на каких-то прикладных языках, типа Java или Julia. Вот и вопрос: а сразу нельзя на типах Julia? Там вроде как нормальная такая система типов. А сам язык вполне достаточен для всех нужных операций над этими типами. И типы там динамические, всё довольно гибко должно получаться.

Как это лучше сделать?! Все проблемы на стыках предметных областей, а не в рамках одной предметной области — у онтологов, программистов, логиков всё в порядке внутри их предметных областей. А проблемы только на стыке, когда нужно всё собрать в готовое решение, и чтобы работало.

@ailevenchuk А расскажите подробнее про внешние роли и их потребности? Не совсем понятно, как эти диаграммы "as is" применять, скажем, программисту.

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

ну вывод доказательств с типами худо-бедно состыковали через структуральную пруфтеорию

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

Мой вопрос как раз в этом. Эти диаграммы впрямую применяют модельеры данных для систем PLM (product life cycle management) или ERP. Они делают по ним концептуальную модель данных, которую потом приземляют на физическую модель данных конкретной СУБД. А программист, по идее, должен будет приземлить эту концептуальную модель на физическую модель данных своего языка программирования (то есть на систему типов). Но вот как это сделать мы сейчас и выясняем. Об этом, похоже, любили рассуждать объект-ориентированные программисты, и ещё опытом поделились люди из F# тусовки. Остальные работают ad hoc (при этом, конечно, и диаграмм не применяют — ход на поиск физических объектов ими не понимается как теоретический, а просто как эвристика: "покажи пару примеров, чтобы я понял").