А вот фреймворк по interoperability — он вводит какую-то терминологию для "программирования-в-большом", самый важный для нас термин тут будет "федерирование" в отличие от "унификации" и "интеграции".

Хотя в жизни всё это инженеры называют "интеграция", но айтишники находят разные варианты.

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

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

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

Данные нужны именно для вычислений. И только для вычислений. Нет?

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

@WatchTh15 , в среде онтологов ходит шутка (а может и не шутка), что все виды отношений между сущностями сводятся к "часть-целое"

@unmuamua Скорее вычисления нужны для данных?

Но нас же практические применения интересуют, а не шутки онтологов)

В функциональном программировании, данные, это такой вид вычислений, только очень простой ;-)
Поэтому, данные и вычисления друг другу нужны ;-)

Про ангелов на кончике иглы неинтересно. Так же можно сказать, что и вычисления - это S-exprs, данные.

Но когда вычисления закончились, то они не нужны, а нужны результаты.

Неа. Вычисления, это ещё и редукции, строго и чётко определённые.

Результаты могут быть и вычислениями, в том числе.

И это вполне так практически полезно и используется.

Для конкретики: содержимое БД ненаблюдаемо  (обычно, кроме дампа) "как содержимое", а только через запросы. Я это имел в виду. Нам не важно, что там лежит, важно, что можно сформировать ответ на вопрос "про красные тракторы", каковой является просто описанием вычисления.

И в некотором смысле, даже "описанием описания вычисления", поскольку БД по запросу проводит вычисление (планирование и оптимизацию), которое порождает конечное вычисление (выполнение физического запроса).

а сама база это как известно снэпшот потока данных

ох уж эти компиляторщики ))

Вот-вот, я-то не компиляторщик, а они - полные "ох уж эти"! 😂

Или даже свёртка... 🤔

Смежный, наверное, вопрос в практической плоскости: можно ли описать Archimate модель через типы языка программирования. А если нельзя то как нужно расширить систему типов чтобы это стало возможным