Философия и цифровые технологии. Сборник статей
Согласно событийной семантике, деятельность как система, в которую входят задействованные в ней предметы, акторы и производимые ими действия, может быть описана как поток событий. Под событием понимаются произведенное актором различение изменения (завершение техпроцесса, обнаружение дефекта в изделии и т. п.) или исходная фиксация значения свойства объекта. В качестве событий фиксируются появление и исчезновение индивидов сущностей, различение значения их свойств, выполнение элементарных операций с объектами. По сути, предлагается унифицированный подход к данным, когда в виде событий записываются как изменения элементов деятельности, так и все статично фиксируемые их свойства.
В формате события его семантическое содержание записывается кортежем. Семантическое содержание такого триплета трактуется как фиксация значения Value, имеющего тип ValueType (свойство или акт), на сущности, определенной событием BasicEvent. Поскольку все данные в EventFlow записываются в виде событий, то следует говорить, что любое событие (и приписывание значения свойства, и совершение акта) фиксируется на некотором предшествующем событии. Например, все свойства индивида (сотрудника компании) записываются как события фиксации их значений в предметной области.
Принципиальное отличие событийной семантики от объектной (в том числе имеющей темпоральные расширения) – введение между событиями обусловливающих связей, задающих отношения логического или причинного следования. События A и B считаются обусловливающими для события C, если констатируется обязательность их существования для выполнения C. Обусловливающие связи записываются в специальном поле формата события Condition, содержащем идентификаторы событий, послуживших условиями для совершения текущего события (C, Condition: A and B). Таким образом, онтология деятельности представляется в событийной семантике не только графом, устанавливающим связи между индивидами сущностей и значениями их свойств, но и темпоральным ориентированным ациклическим графом, фиксирующим временные последовательности обусловливающих друг друга событий.
Другим отличием событийной семантики от объектной является ее субъектность – обязательность указания актора, зафиксировавшего событие. В общем случае событием считается не изменение как таковое, а исключительно факт различения этого изменения участником деятельности – актором, в качестве которого может выступать человек, программный агент, датчик. Это требование важно не только с точки зрения смысла, вкладываемого в событие актором, но и с технологической точки зрения, поскольку значение события Value фиксируется конкретным актором (человеком или датчиком), а следовательно, зависит от состояния актора. Включение актора в формат события позволяет учитывать несогласованные, а порой и противоречивые утверждения, отражающие различные точки зрения, что существенно во многих предметных областях. Кроме того, наличие в формате события ссылки на актора позволяет одним запросом к событийному графу получать полное описание актора как участника конкретной деятельности.
Событийный граф содержит два типа событий: модельные события (описывающие семантическую и темпоральную связанность сущностей и актов) и предметные события, фиксирующие конкретные значения свойств индивидов и акты их изменения. Модельное событие можно представлять как шаблон, декларирующий наличие свойства у сущности или возможное действие актора с этой сущностью, а предметное событие – как результат «заполнения» этого шаблона конкретным значением в ходе какой-либо деятельности. К примеру, по модельному событию может быть создано поле экранной формы, в результате заполнения которого в граф будет добавлено новое предметное событие со значением, введенным актором. Модельные события, задающие фиксированное множество свойств некоторой сущности или действия, группируются в модели. В событийной семантике устанавливается правило, согласно которому предметное событие может быть создано только по конкретной модели. То есть каждое новое событие проверяется не только на выполнимость (наличие обусловливающих событий), но и на соответствие конкретной модели, в которой, помимо семантического содержания события и условия его выполнимости, задаются и особые ограничивающие свойства, устанавливающие, например, количество допустимых для индивида предметных событий, область возможных значений, права доступа и др.
Поле Condition модельного события содержит логическое выражение, составленное из ссылок на значения других модельных событий. Во время исполнения модели в логическое выражение подставляются значения предметных событий, и если выражение принимает значения true, то в граф добавляется новое предметное событие, соответствующее модельному. При этом в поле Condition предметного события заносятся идентификаторы событий, обусловивших его генерацию, то есть данные о ребрах событийного графа.
От DataFlow к EventFlow
Архитектуру EventFlow, по сути, следует рассматривать как событийный вариант шаблона DataFlow: соответствующие программы обычно представляются в виде направленного графа, в узлах которого расположены операторы, а ребра указывают на зависимости узлов по данным. Оператор очередного узла начинает выполняться сразу по получении всех необходимых данных от предшествующих узлов. Данные по ходу вычислений передаются от узла к узлу в виде токенов (рис. 1). Первые варианты DataFlow-компьютеров появились более полувека назад, но не получили широкого распространения из-за ряда нерешенных проблем, проявившихся как на уровне архитектуры, так и при создании языков программирования.
EventFlow наследует от DataFlow принцип асинхронной генерации новых данных по мере готовности результатов предшествующих операций, но в качестве данных выступают не числовые или строковые значения, а семантически определенные события: новое предметное событие генерируется по модельному событию при появлении всех обусловливающих событий (рис. 2). Иначе говоря, EventFlow-система ориентирована не на преобразование входных данных в выходные с передачей промежуточных результатов от оператора к оператору, а на реализацию бизнес-логики, которая прописана в семантических моделях. При этом генерируемые предметные события фиксируют в графе шаги выполнения алгоритма, а не промежуточные данные расчетов. Модели EventFlow – это программы на семантическом языке, исполняемые универсальным контроллером с использованием данных графа, а результатом исполнения моделей являются новые предметные события.
Важным отличием EventFlow является то, что модельные события, определяя семантику предметного события и условия его генерации, не содержат данных о последующих шагах бизнес-логики. То есть если узел графа DataFlow «знает», куда переслать токен с результатом вычислений, то модельные события в EventFlow задают только логическую обусловленность собственного выполнения, не предписывая условий для генерации последующих событий. Решение без токенов, с одной стороны, упрощает архитектуру, а с другой – соответствует бизнес-схеме, когда каждый актор выполняет свою операцию при получении всех необходимых для этого ресурсов и не осведомлен о том, кто воспользуется результатом его работы – ответственность за выполнение следующих шагов будет лежать уже на других акторах.
Такой способ реализации бизнес-логики позволяет обеспечить модификацию имеющихся моделей и введение новых без остановки выполнения бизнес-процессов. Добавленное модельное событие будет генерировать новые предметные события исходя из их обусловленности существующими событиями и не может повлиять на уже работающий алгоритм действия. Эта особенность EventFlow-архитектуры с учетом исходной семантической определенности данных не только упрощает согласование работы различных групп разработчиков моделей, но и позволяет реализовать совместную деятельность независимых контрагентов.
Особо следует обратить внимание на соотношение подхода EventFlow и технологии no-code. Модельные события движка EventFlow создаются с помощью экранных форм, и пользователям достаточно знать лишь основы событийной семантики (базовые примитивы и принципы построения исполняемых моделей действий) – им не требуется осваивать синтаксис языка описания событий и формат событий. По сути, EventFlow – это технология no-code, в которой исполняемым кодом являются событийные модели, то есть последовательности семантически определенных записей в темпоральном графе, а не скомпилированный программный код, который получается на выходе no-code-платформ. Конечно, EventFlow-движок написан на традиционном языке программирования и запускается на стандартном компьютере, но вся бизнес-логика реализуется на уровне семантически определенных событий.
EventFlow на практике
В качестве основного применения субъектно-событийного подхода [1, 4] предполагалось создание онтологий предметных областей, в которых принципиально важным является сохранение исторических данных (например, событий историй болезней). Исполняемые событийные модели на основе подхода DataFlow расширили потенциальную область применения этого подхода, а EventFlow добавил инструменты алгоритмической обработки потоков данных из любых источников с сохранением результата в виде семантического темпорального графа, информация из которого используется в работе исполняемых моделей. Существенными преимуществами EventFlow по сравнению с решениями Workflow являются скорость создания и модификации исполняемых моделей на том же языке, что используется для семантического описания данных, а также параллельность исполнения модельных событий согласно DataFlow. Архитектура EventFlow найдет применение в сфере автоматизации технологических и бизнес-процессов с возможностью гибкой и перманентной настройки схем данных, включая модели действий.
Объединение событийно-ориентируемой архитектуры, семантического моделирования и подхода DataFlow позволило создать спецификацию записи данных, которая одновременно задает и формат семантического описания событий, и структуру хранения событий в виде темпорального графа, а также является языком описания исполняемых моделей действий. EventFlow предлагает инструменты для описания бизнес-логики на семантическом языке, сокращая разрыв между данными и алгоритмами, ускоряя разработку приложений, не требуя от пользователей знания языков программирования. Архитектура EventFlow позволит минимизировать проблемы интеграции, сделав центральным элементом корпоративной ИТ-архитектуры события, а не фиксированные бизнес-приложения.
Литература
1. Александр Болдачев. Субъектно-событийный подход к моделированию сложных систем, 2015. URL: https://habr.com/ru/post/256509 (дата обращения: 22.09.2021).
2. Martin Fowler. Event Sourcing, 2005. URL: https://martinfowler.com/eaaDev/EventSourcing.html (дата обращения: 22.09.2021).
3. Сергей Горшков. Единая точка доступа к данным предприятия // Открытые системы. СУБД. – 2018. – №4. – С. 33—35. URL: https://www.osp.ru/os/2018/04/13054596 (дата обращения: 21.09.2021).
4. Александр Болдачев. Темпоральность и философия абсолютного релятивизма. – М.: Ленанд, 2011. URL: http://philosophystorm.org/books/aleksandr-boldachev-temporalnost-i-filosofiya-absolyutnogo-relyativizma (дата обращения: 21.09.2021).
Семантическое
моделирование
Классы, множества,
группы, системы
Хабр, 25 января 2016
https://habr.com/ru/post/275865/
Описание предметной области (создание ее онтологии) начинается с выделения объектов и их классификации, которая традиционно заключается в составлении дерева классов-подклассов и приписывании к ним индивидов. При этом термин «класс», по сути, используется в значении «множество»: отнесение объекта к классу мыслится как включение его в качестве элемента в соответствующее множество. Цель этого текста показать, что такой унифицированный подход к описанию структуры предметной области является сильным упрощением и не позволяет зафиксировать разнообразие семантических отношений объектов.
Давайте рассмотрим три варианта классификации индивида Жучка:
• Животное – собака – лайка – Жучка.
• Служебная – ездовая – Жучка.
• Псарня – упряжка собак – Жучка.
Первую последовательность соподчиненных сущностей однозначно принято описывать через задание классов и подклассов: Жучка является индивидом класса «лайка», класс «лайка» – подклассом собак, а тот подклассом класса «животное». При этом класс «животные» трактуется как множество всех животных, а класс «лайки», как подмножество множества «собаки». Однако такое описание, пускай и достаточно наглядное, содержательно является тавтологичным, самореферентным: индивида Жучку мы называем лайкой, если она входит в множество лаек, а само множество лаек определяем как совокупность всех индивидов лаек – то есть включение в множество содержательно дублирует поименование. К тому же, описание класса-множества полностью исчерпывается описанием индивида, подпадающего под задающее класс понятие. Также следует отметить, что оперирование подобными классами-множествами не зависит от количества элементов в них: лайка Жучка будет лайкой даже тогда, когда она останется единственной, последней лайкой на Земле. Более того, оперировать такими классами-множествами мы можем даже при отсутствии индивидов в них: можно построить онтологию уже вымерших динозавров, помыслить класс, в который только в будущем войдет проектируемое уникальное устройство, или построить модель предметной области мифических животных, героев сказок, хотя при этом мощность всех классов-множеств будет равна нулю.
Итак, если говорить о содержательной стороне анализируемой классификации (животное – собака – лайка – Жучка), то она (содержательная сторона) никак не может быть выражена через отношение множеств и подмножеств. В данном случае мы имеем дело с концептуализацией – выделением понятий и установлением родо-видовых отношений между ними. При этом фактическое число элементов концептуального класса, то есть объем понятия, не фигурирует при его определении и упоминается (да и то не содержательно) только когда одно понятие («лайка») подпадает под другое («собака»), то есть когда выступает как вид рода. Да, мы можем констатировать, что объем понятия «собака» больше, чем объем понятия «лайка», но реальное числовое соотношение этих множеств не имеет никакого онтологического смысла. Превышение объемом класса объема подкласса при родо-видовых отношениях отражает лишь то, что по определению рода в него должно входить несколько видов – в противном случае эта классификация становится бессмысленной. То есть в родо-видовой концептуальной классификации нас интересует именно содержание понятий – чем вид «собака» отличается от вида «кот» (который также подпадает под родовое для них понятие «животное»), а не то, как соотносятся объемы множеств рода и вида и тем более объемы видовых понятий («собака» и «кошка»). И чтобы отличать концептуальные классы от действительно счетных множеств, правильнее было бы говорить о подпадании индивида под понятие, а не о включении его в класс/множество. Ясно, что в формальной записи утверждения «подпадает под понятие Х» и «является элементом класса Х» могут выглядеть одинаково, но непонимание существенной разницы между двумя этими описаниями может привести к серьезным ошибкам в построении онтологии.
Во втором варианте (служебная – ездовая – Жучка) нас также не интересует сопоставление понятию «ездовая» какого-либо множества: смысловое содержание утверждения «Жучка – ездовая» не зависит от того, является ли она единственной ездовой или таковых много. Казалось бы, мы и здесь имеем дело с родо-видовыми отношениями: понятие «ездовая» можно рассматривать как видовое относительно родового понятия «служебная». Но связь индивида «Жучка» с понятием «ездовая» существенно отличается от связи с понятием «лайка»: второе, концептуальное, понятие имманентно и неизменно присуще индивиду, а первое отражает локальную во времени специализацию. Жучка не родилась ездовой и с возрастом может перестать быть ею и перейти в разряд сторожевых, а под старость вообще потерять всякую «профессию». То есть, говоря о специализации, мы всегда можем выделить события приобретения и утраты связи с тем или иным понятием. К примеру, Жучка могла быть абсолютным чемпионом породы, а потом утерять это звание, что принципиально невозможно с концептуальными понятиями: Жучка от рождения и до смерти, то есть на всем временном отрезке своего существования как индивида, является собакой и лайкой. Так и человек остается концептом «человек» всю жизнь, но ситуационно (от события до события) может подпадать под специализирующие понятия «школьник», «студент», «врач», «муж» и пр. И как уже отмечалось, связь с этими понятиями ничуть не означает включение в некоторое множество (хотя это и может так выглядеть) – приписывание специализирующего понятия всегда есть результат конкретного отношения индивида с другими индивидами: поступление в школу, ВУЗ, получение диплома, регистрация брака и пр. Поэтому специализирующие понятия можно назвать еще реляционными
Конец ознакомительного фрагмента.
Текст предоставлен ООО «ЛитРес».
Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.
Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.
Вы ознакомились с фрагментом книги.
Для бесплатного чтения открыта только часть текста.
Приобретайте полный текст книги у нашего партнера:
Полная версия книги