Обсуждение

Бег на месте получается. Одни выпускают очередной клон ER, чтобы снова вручную чертить в Visio, как предыдущие поколения чертили на бумаге. Другие - перекладывают это же в текстовый формат, получая неизменное "ехал COBOL через COBOL". "Вот я чешу затылок, чем такое может отличаться от модели данных" - а ничем. :) Разница в сложности имплементации поддержки в информационных системах. Готовые "картинки" поддержать проще, чем виртуальные машины, их рисующие.

Ну, я и чешу затылок, потому как ничем вроде не отличается -- и это даже не только мне заметно. ))) Вот явное выделение виртуальной машины, поддерживающей какую-то foundational ontology (то есть виртуальной машины, рисующей картинки) это IMHO правильный ход. Но и там есть свои проблемы: если это не декларативная машина, а с проблесками исполняемой семантики, то изменения модели обычно неоткатываемые полностью. Но так и в других человеческих артефактах собираемые сложные штуковины не все можно потом разобрать обратно без их поломки. Сталь, если не так сплавляешь, уже назад к руде не вернёшь. То есть накатки-откатки для подобных операций могут быть, но по факту они будут ограниченными. Впрочем, всякие фотошопы тоже с этой проблемой сталкиваются, и ничего, решают. Я не хочу поддерживать готовые картинки и запросы к ним. Я хочу programmatic computer-aided design/architecture/data_model. И, похоже, что foundational ontology должна тупо писаться на языке. Будут ли это просто написанные на языке структуры данных (а потом что-то типа https://tools.ietf.org/html/rfc7049 и https://github.com/saurvs/CBOR.jl для загрузки-выгрузки) или таки именно скрипты, которые генерят эти структуры (тут нужно сказать, что в Julia типы вполне себе объекты для вычислений), это уже рабочие решения. То есть архитектурно там получается несколько разных уровней договорённостей: -- Пользовательский интерфейс: IDE для exploratory modeling. Выбор хост-языка (предполагаю, что это Julia). -- Метаметамодель, языковые вопросы: формализм языка (foundational ontology). На каком языке работаем? Парадигма и синтаксис: виртуальная машина, поддерживающая моделирование. -- Метамодель, и к ней онтологические вопросы: описание системы, т.е. онтология системы + полноценный онтологический язык/язык моделирования данных для интеграции данных жизненного цикла (частных, несистемных описаний). И вот тут upper ontology, онтологические паттерны и прочий разговор не про форматы, а про моделирование мира. Вот особенность SysMoLan главным образом должна быть тут, но без понимания, на каком холсте эту онтологическую картину рисуем (т.е. foundational ontology и способ алгоритмической с ней работы) до этого не договоримся. -- Модель (в которую плавно переходит метамодель): middle ontology (сами пишем системную модель), описания domain ontology (подключаемых к системной модели уточняющих её частных описаний в разных форматах разных CAD и систем моделирования). И да, все эти моделирования системы и софта (с сопутствующими аналитическими тулами и наоборот, синтетическими тулами -- генерация/порождение), моделирование данных и сопутствующая интеграция данных -- это всё про одно и то же. Для меня это также дискуссия о многоуровневости innate machinery (как она понимается, например, в https://arxiv.org/abs/1801.05667 -- мы ж вынуждены и на это ориентироваться). Моделирование обеспечивается некоторым стеком, и что там уже присутствует в момент выхода на рабочие задачи, имеет значение. Например, стек ISO 15926 состоял из одного уровня в 200 низкоуровневых понятий, и не было ни уровня под ним (представления даже в триплах появились сильно потом, но не было нормальной компьютерной их поддержки), ни над ним (шаблоны появились сильно потом, и кажись, до сих пор нет набора этих шаблонов, достаточно высокоуровневых, чтобы они уже выходили на использование subject expert, а не на использование онтологами для обслуживания чисто онтологических задач).

Формат данных в ISO 15926 был изначально (из давно используемого в автомобильной и авиа-промышленности ISO 10303). Заигрывание с низкоуровневым семантик вебом, всё же, более поздний фейл (типа "онтологи, давайте жить пилить гранты дружно"). А вот игнорирование уровня subject expert и разработка "виртуальной машины" (15926-2 и далее) не для определённых программ, а для абстрактных верований о природе реальности - изначальная проблема всей движухи. Для себя (после некоторого количества выброшенных архитектур и прототипов) я вывел в приоритеты работу с корпусом требований. Наборы пользовательских ситуаций, которые сразу должны быть удобно отражены в языке. Потому что любые проекты вида "сейчас мы выпустим что-то абстрактно умное, а конкретику к нему допишут" обречены. Должно быть что-то, что лучше прямо сейчас. А не только имеет перспективу когда-нибудь превзойти традиционный подход "из SQL, палок и такой-то изоленты".

Ну да. SysMoLan сразу (без ожидания, что паттерны эти кто-то напишет) должен моделировать систему не хуже, чем это делают на ArchiMate или SysML. Прямо "из коробки". И не "для определённых программ" поддерживать что-то там, а сам быть такой программой. А во вторую очередь уже цеплять разные другие программы, каким-то штатным образом. Например, 1D-модели на Modia (чтобы далеко не ходить за примерами).

Тут вот народ из Industrial Ontologies Foundry (IOF) тоже неспешно копает в направлении Common Logic в рамках https://sites.google.com/view/industrialontologies/home Даже есть события этого года https://sites.google.com/view/industrialontologies/events/past И куски онтологий, извлеченные из стандартов https://github.com/gruninger/colore

И часть народа отсюда National Center for Ontological Research а там системно-инженерные мероприятия вперемешку с онтологическими ))