Pull to refresh

Comments 6

Семантика и деятельность
Иными словами: RDF и Event Sourcing?) Кажется про это уже было в сипсонах www.w3.org/TR/rdf11-concepts/#change-over-time. Из популярного, на похожих идеях основан OpenGraph от Facebook.

Спасибо за цикл статей. Но все еще не понятно, чем мотивирована критика. Это абстрактные размышления при погружении в новую тему или был какой-то болезненный личный опыт практического применения описываемых технологий?
С критикой (мифами) получился явный перебор и скорее всего потому, что общий текст был разбит на четыре части — первые две явно перетащили на себя одеяло. Еще должна появится пятая часть про логическую кластеризацию (логические миры) и субъектность онтологий, привязанная именно к критике базовых идей семантического веба. Также для понимания «критики» надо соотнести ее с предыдущими моими текстами о WEB 3.0, а точнее с отказом от сайтоцентристской идеологии, поддерживаемой в старом «семантическим вебе».

Если же по большому счету, то на мой взгляд, есть необходимость пересмотра базовых оснований семантического подхода — описание деятельности требует перехода от субстанциональной на процессуальную/событийную логику.

В тему я начал погружаться с 2011 года. Был опыт незавершенного проекта семантической социальной сети — делал для себя, все работало, просто не хватило маркетинговых ресурсов (есть описание в текстах на хабре). Потом был блокчейн. Сейчас настало время соединения этих двух технологий)

Идеи хорошие, не новые (фактически, описывается стандартное делопроизводство/документооборот). Скажите, а Вы применяете такой подход при создании систем? Ведь главная проблема — как правильно выводить состояние на основе "действий".
Мы, например, в качестве "source of truth" использовали графовые базы где-то с 2012. Event-sourcing и materialized view (Apache Samza, как пример) — еще один и, видимо, более модный вариант.

За намеками в этом тексте стоит событийные семантика и логика и субъектно-событийный подход к моделированию сложных систем (все в разной степени проработки).
Событийное моделирование бизнес логики я применил в пилотном проекте платформы для аренды недвижимости в одном из эмиратов. Работало) Но там не было завязано на семантику.

как правильно выводить состояние на основе «действий».
Мое решение — писать данные (события) в ациклический направленный граф, а состояния получать по срезам графа.
Мое решение — писать данные (события) в ациклический направленный граф, а состояния получать по срезам графа.

Интересно, в каком виде Вы храните такой граф?


Например, у нас получилось все хранить в графовой базе и такой граф у нас содержит как "действия" (один "документ" порождает другой и документы меняют через действия "регистры", моделирующие "срезы" состояний), так и "семантико/онтологическую" связь сущностей, например "Страна состоит из регионов" или "Год содержит квартал". Больше того, так как каждый вид связи-действия и связи-"онтологии" могут характеризовать доступность для конкретного пользователя (кабинета), через такой ациклический граф мы можем, также, моделировать систему доступа. Есть правила для перехода по видам связей: семантические связи (отношения справочников) доступны всем; связь-действие доступна тому, кто ее произвел; связь "имеет доступ"; обратное направление связи "передал в" и т.п.) и если от конкретного кабинета к ресурсу имеется непрерывный путь "разрешающих" связей, то данный ресурс доступен данному кабинету.

Сейчас проект находится в статусе теоретической разработки и первых прототипов. Начинался он еще четыре года назад, но потом меня отвлекли на блокчейн проект. Сейчас вернулся соединять решение двух проблем — семантика и трастед — в одном флаконе. Поскольку в прототипе поиск еще не реализован, то массив событий хранится просто в таблице. И даже не могу сказать какая будет БД в продукте (графовая или документарная) — надо просто тестить, скорее всего потребуется мультимодельная. Сейчас довожу до ума теоретическую часть, ТЗ и ищу возможность реализации (я сам не программист, хотя первый прототип на коленке написал).

В целом подход отличается от вашего тем, что в нем формат данных однороден — любой факт записывается как событие: и действие, и атрибут, и отношение. Фиксация любого изменения — это событие. Любой объект или любой актор представляется как множество (поток) событий. То есть все узлы — это события, фиксируемые конкретным актором на других событиях (подразумевается не ограниченная арность: А = «температура — 38» > В = «А — растет» > С = «В — 2 часа»). Все события записываются в едином формате. Ребра — отношения логической обусловленности событий (можно понимать, как условные или причинно-следственные связи). Условная связь событий позволяет реализовать исполняемые модели, то есть в графе реализована не только структура данных, но и алгоритмы/модели бизнес-процессов (по сути, конечные автоматы). И еще прикол в особой логике — событийной/процессуальной, в которой не используется понятие «класс» (до полного формализа логика еще не доведена, но пока это не тормозит).
Sign up to leave a comment.

Articles