Новости мультипарадигмального моделирования данных
Концептуальное/онтологическое моделирование можно встретить:
-- в онтологическом моделировании на языках моделирования знаний
-- в системной инженерии и инженерии предприятий на архитектурных языках
-- в моделировании данных на языках моделирования данных
В онтологических языках победил OWL и осталась мечта о Common Logic (ISO/IEC 24707:2018 -- https://www.iso.org/standard/66249.html). В архитектурных языках победил SysML и частично AADL, но бытует и Capella и в каждом PLM вендор считает за честь представить что-то своё на эту тему, а в архитектуре предприятия тоже много всякого, но лидирует ArchiMate. В языках моделирования данных в какой-то момент победили ER-диаграммы (допотопный Express за язык не считаем), и ещё пяток лет назад был настрой двигать в сторону RDF/OWL (semantic web, все дела). Но тут безо всякого web появились в количестве NoSQL, и табличные представления сначала отползли (No SQL), а затем вернулись (Not Only SQL) -- оказалось, что моделирование данных в дикой жизни стало мультипарадигмальным. При этом OWL никак не решал задач моделирования данных, ибо провести пальчиком от концептуальной модели хоть куда-нибудь в данные и уж тем более в физику не представлялось возможным. И тогда вспомнили о наследниках линии NIAM/ORM -- факт-ориентированного моделирования. Кому хочется теории связи онтологического моделирования и моделирования данных -- вот я писал ещё в 2011 году "ну, и какая у нас онтологическая традиция?", https://ailev.livejournal.com/952930.html. Про факт-ориентированное моделирование -- ещё в 2009 году, https://ailev.livejournal.com/699549.html.
Мультипарадигмальное моделирование данных с упором на факт-ориентированное представление (и очень часто с упором на графовые представления) -- это относительно свежий тренд, и тут пока не слишком много инструментария, но он есть, и он продолжает линию ОRM и моделирования данных, а не OWL и представления онтологий или представления архитектур. Всё в онтологизировании, моделировании систем, моделировании данных очень похоже, но отличия таки есть.
COMN (произносится common, Concept and Object Modeling Notation) -- это мультипарадигмальный язык моделирования данных, который явно решает онтологические задачи, но он так и не взлетел: для него до сих пор не нашлось изготовителей моделера. Но это один из идеологических лидеров направления. Вот его гнездо: http://www.dataversity.net/concept-object-modeling-notation-comn/. Вот свеженькое интервью создателя по итогам семинара на Data Architecture Summit Conference 2018 -- https://www.infoq.com/news/2018/10/hills-data-modeling-nosql-comn. Вот книжка автора, подробно всё описывающая (чем-то напоминает книжку BORO -- отчётливо виден онтологический заход на моделирование данных и забегание даже в архитектурное моделирование. Обсуждается подробно таинственное отношение "репрезентации"): Ted Hills, NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software -- http://b-ok.cc/book/2972540/e75b65. COMN имеет цель примерно ту же, что ArchiMate -- чтобы можно было вести пальчиком по разным уровням моделирования, отслеживая на диаграмме (визуальный язык, увы) путь презентации-репрезентации от реального объекта к концепту, от концепта к данным, от данных к физическому представлению в компьютере.
Пару лет назад COMN хотел поддержать разработчик мультипарадигмального моделера данных Hackolade -- https://hackolade.com/. Но так и не поддержал, ограничился дизайном схемы для самых разных баз данных (document, graph, column-oriented, key-value, multi-model и даже JSON), причём не только forvard engineering, но и reverse engineering в этом моделере тоже есть, за что его и любят. Но нам этот моделер не так интересен, кроме его особого внимания к reverse engineering. Я помню, как пару недель назад в одном разговоре большой айтишный начальник мечтательно говорил, что хорошо бы найти такой инструмент, который всосал бы в себя весь имеющийся зоопарк описаний данных и красиво показал в таком виде, что можно было бы разобраться. Вот этот Hackolade целится как раз в эту потребность.
И таких мультипарадигмальных NoSQL моделеров данных существует некоторое количество. Вот тут страничка с залом славы (hall of fame) моделеров для графовых баз данных: http://graphdatamodeling.com/Graph%20Data%20Modeling/HallOfFame/DMHallOfFame.html. Туда попали, конечно, не все моделеры -- а только визуальные моделеры для графовых баз данных. Эта страничка полезна, чтобы понимать богатство экосистемы NoSQL моделирования данных, где отнюдь не всё сегодня сводится к ER-моделированию. Превалируют, конечно, разные реализации моделеров для GraphML -- поэтому чаще всего там можно встретить "графы знаний" как форму моделирования самых разных данных.
Но нас там интересует поиск моделеров с какими-то более-менее универсальными языками представления данных, а не просто моделеры создания схем данных для конкретных графовых СУБД. Например, моделер Factil, предназначенный для решения задач интеграции данных -- https://www.factil.io/. В этом моделере используется FIML -- Fact-based Information Modeling Language, факт-ориентированный язык, прямой наследник ORM. И там даже делается упор на текстовое представление, при этом история очень похожа на историю XML (которым стал SGML после обрезания, если кто помнит). ORM (Object-Role Modeling, создан в 90х) имел текстовую и графическую нотацию, а в 2008 году был создан уже CQL, который текстовый ORM с возможностью запросов. FIML -- это обрезанный (подмножество) CQL, хотя и с расширениями в сторону задач интеграции данных. Вот кратенькое описание: https://www.factil.io/introduction-to-fiml.
Понятно, что RuleXpress (множество идей из CQL было использовано в SVBR -- я и об этом писал в 2009 году, https://ailev.livejournal.com/692588.html и там получился свой онтологический язык для выражения business rules и моделер для его поддержки) тоже в этом списке: http://www.rulearts.com/. Не могу не напомнить манифест организационных норм -- https://ailev.livejournal.com/693597.html. Это ж как раз оно, онтологическое моделирование предприятий и то, как нужно в организации эти онтологии использовать. И довести эти онтологии до данных в корпоративных базах данных, как же без этого.
Это я всё продолжаю не столько бежать к цели (SysMoLan), сколько медленно ползти к ней, или даже просто лежать к ней. Ибо по линии развития онтологических языков мы уже ходили, по линии архитектурных языков ходили, а вот по линии языков моделирования данных -- пока нет. Нам же нужно описывать систему, пробегая по всей цепочке от реального мира через концепты к представлению этой системы в каких-то данных. С этим нужно ещё как-то подробней разобраться, с этой идеей "одного языка, на котором можно отследить связи разных уровней моделирования" -- как в случае Архимейта с его уровнями организации/концептов-софта/данных-железа/носителей.
Ну, и чтобы два раза не вставать: мне не нравится доминирование визуальных языков моделирования данных над текстовыми языками. Вся эта история будет немасштабируема, описывать даже небольшие системы будет плохо. А ещё меня смущает не слишком большая развитость этих языков (до SQL, который в конце концов допилили до полнотьюрингового "просто языка программирования", в этих факт-ориентированных языках моделирования данных пока далеко). Но мне нравится, что цель моделирования данных в этих языках хорошо видна, в отличие от OWL. Хотя в этих языках и плохо с модульностью, всё одно придётся её как-то там наводить.
И тут будет уместно вспомнить историю про скриптование в определении сложных 3D моделей на геометрическом движке, где начиналось с графических интерфейсов, а потом таки пришло к текстовым интерфейсам на сниппетах программного кода: началось с "революционного" графического интерфейса в Antimony (https://justy-tylor.livejournal.com/254781.html), но потом там было продолжение и появился абсолютно уже текстовый https://www.mattkeeter.com/projects/ao/ для programmatic computer-aided design, там посыл был "You can think of Ao as a homoiconic kernel: even fundamental, primitive shapes are represented as code in the user-level language. It's turtles all the way down" - всё там на Scheme. А после него и вообще текстовый с подходящим случаю интерфейсом http://libfive.com/. 3D модель появляется в результате описания её скриптами, которые её строят. Вот я чешу затылок, чем такое может отличаться от модели данных. И можно ли воспользоваться homoiconic kernel на Julia, где всё про гомоиконность было слизано в этом месте из того же источника -- из Lisp. Вот в таком стиле делать модели данных, желательно мультипарадигмальные. Шаблоны, скрипты, сниппеты описания данных -- неважно. SysMoLan Studio может выглядеть как-то похоже, там ведь тоже цель programmatic computer-aided design/architecture.
-- в онтологическом моделировании на языках моделирования знаний
-- в системной инженерии и инженерии предприятий на архитектурных языках
-- в моделировании данных на языках моделирования данных
В онтологических языках победил OWL и осталась мечта о Common Logic (ISO/IEC 24707:2018 -- https://www.iso.org/standard/66249.html). В архитектурных языках победил SysML и частично AADL, но бытует и Capella и в каждом PLM вендор считает за честь представить что-то своё на эту тему, а в архитектуре предприятия тоже много всякого, но лидирует ArchiMate. В языках моделирования данных в какой-то момент победили ER-диаграммы (допотопный Express за язык не считаем), и ещё пяток лет назад был настрой двигать в сторону RDF/OWL (semantic web, все дела). Но тут безо всякого web появились в количестве NoSQL, и табличные представления сначала отползли (No SQL), а затем вернулись (Not Only SQL) -- оказалось, что моделирование данных в дикой жизни стало мультипарадигмальным. При этом OWL никак не решал задач моделирования данных, ибо провести пальчиком от концептуальной модели хоть куда-нибудь в данные и уж тем более в физику не представлялось возможным. И тогда вспомнили о наследниках линии NIAM/ORM -- факт-ориентированного моделирования. Кому хочется теории связи онтологического моделирования и моделирования данных -- вот я писал ещё в 2011 году "ну, и какая у нас онтологическая традиция?", https://ailev.livejournal.com/952930.html. Про факт-ориентированное моделирование -- ещё в 2009 году, https://ailev.livejournal.com/699549.html.
Мультипарадигмальное моделирование данных с упором на факт-ориентированное представление (и очень часто с упором на графовые представления) -- это относительно свежий тренд, и тут пока не слишком много инструментария, но он есть, и он продолжает линию ОRM и моделирования данных, а не OWL и представления онтологий или представления архитектур. Всё в онтологизировании, моделировании систем, моделировании данных очень похоже, но отличия таки есть.
COMN (произносится common, Concept and Object Modeling Notation) -- это мультипарадигмальный язык моделирования данных, который явно решает онтологические задачи, но он так и не взлетел: для него до сих пор не нашлось изготовителей моделера. Но это один из идеологических лидеров направления. Вот его гнездо: http://www.dataversity.net/concept-object-modeling-notation-comn/. Вот свеженькое интервью создателя по итогам семинара на Data Architecture Summit Conference 2018 -- https://www.infoq.com/news/2018/10/hills-data-modeling-nosql-comn. Вот книжка автора, подробно всё описывающая (чем-то напоминает книжку BORO -- отчётливо виден онтологический заход на моделирование данных и забегание даже в архитектурное моделирование. Обсуждается подробно таинственное отношение "репрезентации"): Ted Hills, NoSQL and SQL Data Modeling: Bringing Together Data, Semantics, and Software -- http://b-ok.cc/book/2972540/e75b65. COMN имеет цель примерно ту же, что ArchiMate -- чтобы можно было вести пальчиком по разным уровням моделирования, отслеживая на диаграмме (визуальный язык, увы) путь презентации-репрезентации от реального объекта к концепту, от концепта к данным, от данных к физическому представлению в компьютере.
Пару лет назад COMN хотел поддержать разработчик мультипарадигмального моделера данных Hackolade -- https://hackolade.com/. Но так и не поддержал, ограничился дизайном схемы для самых разных баз данных (document, graph, column-oriented, key-value, multi-model и даже JSON), причём не только forvard engineering, но и reverse engineering в этом моделере тоже есть, за что его и любят. Но нам этот моделер не так интересен, кроме его особого внимания к reverse engineering. Я помню, как пару недель назад в одном разговоре большой айтишный начальник мечтательно говорил, что хорошо бы найти такой инструмент, который всосал бы в себя весь имеющийся зоопарк описаний данных и красиво показал в таком виде, что можно было бы разобраться. Вот этот Hackolade целится как раз в эту потребность.
И таких мультипарадигмальных NoSQL моделеров данных существует некоторое количество. Вот тут страничка с залом славы (hall of fame) моделеров для графовых баз данных: http://graphdatamodeling.com/Graph%20Data%20Modeling/HallOfFame/DMHallOfFame.html. Туда попали, конечно, не все моделеры -- а только визуальные моделеры для графовых баз данных. Эта страничка полезна, чтобы понимать богатство экосистемы NoSQL моделирования данных, где отнюдь не всё сегодня сводится к ER-моделированию. Превалируют, конечно, разные реализации моделеров для GraphML -- поэтому чаще всего там можно встретить "графы знаний" как форму моделирования самых разных данных.
Но нас там интересует поиск моделеров с какими-то более-менее универсальными языками представления данных, а не просто моделеры создания схем данных для конкретных графовых СУБД. Например, моделер Factil, предназначенный для решения задач интеграции данных -- https://www.factil.io/. В этом моделере используется FIML -- Fact-based Information Modeling Language, факт-ориентированный язык, прямой наследник ORM. И там даже делается упор на текстовое представление, при этом история очень похожа на историю XML (которым стал SGML после обрезания, если кто помнит). ORM (Object-Role Modeling, создан в 90х) имел текстовую и графическую нотацию, а в 2008 году был создан уже CQL, который текстовый ORM с возможностью запросов. FIML -- это обрезанный (подмножество) CQL, хотя и с расширениями в сторону задач интеграции данных. Вот кратенькое описание: https://www.factil.io/introduction-to-fiml.
Понятно, что RuleXpress (множество идей из CQL было использовано в SVBR -- я и об этом писал в 2009 году, https://ailev.livejournal.com/692588.html и там получился свой онтологический язык для выражения business rules и моделер для его поддержки) тоже в этом списке: http://www.rulearts.com/. Не могу не напомнить манифест организационных норм -- https://ailev.livejournal.com/693597.html. Это ж как раз оно, онтологическое моделирование предприятий и то, как нужно в организации эти онтологии использовать. И довести эти онтологии до данных в корпоративных базах данных, как же без этого.
Это я всё продолжаю не столько бежать к цели (SysMoLan), сколько медленно ползти к ней, или даже просто лежать к ней. Ибо по линии развития онтологических языков мы уже ходили, по линии архитектурных языков ходили, а вот по линии языков моделирования данных -- пока нет. Нам же нужно описывать систему, пробегая по всей цепочке от реального мира через концепты к представлению этой системы в каких-то данных. С этим нужно ещё как-то подробней разобраться, с этой идеей "одного языка, на котором можно отследить связи разных уровней моделирования" -- как в случае Архимейта с его уровнями организации/концептов-софта/данных-железа/носителей.
Ну, и чтобы два раза не вставать: мне не нравится доминирование визуальных языков моделирования данных над текстовыми языками. Вся эта история будет немасштабируема, описывать даже небольшие системы будет плохо. А ещё меня смущает не слишком большая развитость этих языков (до SQL, который в конце концов допилили до полнотьюрингового "просто языка программирования", в этих факт-ориентированных языках моделирования данных пока далеко). Но мне нравится, что цель моделирования данных в этих языках хорошо видна, в отличие от OWL. Хотя в этих языках и плохо с модульностью, всё одно придётся её как-то там наводить.
И тут будет уместно вспомнить историю про скриптование в определении сложных 3D моделей на геометрическом движке, где начиналось с графических интерфейсов, а потом таки пришло к текстовым интерфейсам на сниппетах программного кода: началось с "революционного" графического интерфейса в Antimony (https://justy-tylor.livejournal.com/254781.html), но потом там было продолжение и появился абсолютно уже текстовый https://www.mattkeeter.com/projects/ao/ для programmatic computer-aided design, там посыл был "You can think of Ao as a homoiconic kernel: even fundamental, primitive shapes are represented as code in the user-level language. It's turtles all the way down" - всё там на Scheme. А после него и вообще текстовый с подходящим случаю интерфейсом http://libfive.com/. 3D модель появляется в результате описания её скриптами, которые её строят. Вот я чешу затылок, чем такое может отличаться от модели данных. И можно ли воспользоваться homoiconic kernel на Julia, где всё про гомоиконность было слизано в этом месте из того же источника -- из Lisp. Вот в таком стиле делать модели данных, желательно мультипарадигмальные. Шаблоны, скрипты, сниппеты описания данных -- неважно. SysMoLan Studio может выглядеть как-то похоже, там ведь тоже цель programmatic computer-aided design/architecture.