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

А вот главный мой вопрос. Имеется какой-то "язык онтологов", кроме FOL (который скорее язык логиков и изначально для другого)? BORO я почитаю, конечно, но на это уйдет время.

Если сделать 4D-СУБД - наступит гармония и счастье? 😂

@pavetok В том и вопрос. 4D-экстенты не совпадают! Физически это разные объекты, так как моделирование вревремнное.

Тогда есть еще проблема декомпиляции. Широко известный факт мы легко (если не заморачиваться с опитимизациями) можем откомпилировать с высокоуровнего языка на низкоуровневый ассемблер. А в противоположном направлении - на порядки сложнее, чтобы получить идиоматичный код, нужно немножечко распознавать образы в ассемблерном коде, чтобы воспроизвести исходные высокоуровневые конструкции. При трансляции через FOL проблемы будут те же - разобрать вниз легко, обратно собрать сложно. Наверное.

Допустим агент A1 выводит из эксплуатации нечто, являющееся для него насосом. Сразу после этого агент А2 везет на свалку нечто, являющееся для него грузом. Вроде физически это одно и то же, но для А1 и А2 это штуки "разных типов". Как такое в типах моделировать?

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

Но тут у нас есть формальный высокоуровневый язык! А про онтологов я слышу, что у них только логики.

На этот вопрос же не теория типов будет отвечать даже

Вопрос к тому, как такое выражать на языке программирования. В том числе в ситуации, когда ручки и ножевой блок используются в программе управления требованиями в конструкторском бюро, а две половинки ножниц и винтик даны в САПР в том же бюро, и нужно как-то состыковать их: чтобы требования относились к тому, что проектируется в САПР.