О способах моделирования темпоральности
Для многих методов моделирования представление темпоральности (изменений моделируемой системы во времени) является серьезной проблемой. Можно придумать множество способов описания интуитивно понятного 3-мерного пространства, наполненного объектами, но когда возникает необходимость отразить взаимодействия этих объектов, изменение их состава и свойств описать временность их существования в целом - все становится не столь очевидно. Приходится вводить понятия Состояний и Событий, от которых недалеко и до темпоральных частей (расщепления информационного объекта, отражающего моделируемый объект, на подчиненные объекты, описывающие отдельные стадии его существования).
Все эти способы так или иначе работают, но
их использование тяжело дается и аналитику, и - особенно - программисту. Если для описания изменений свойств объекта приходится создавать дополнительные объекты - это неизбежно усложняет запросы, а если таких объектов будет несколько сотен или тысяч для каждого «основного» объекта - время выполнения запросов также сильно пострадает.
Существуют базы данных, поддерживающие «нативную» темпоральность - хранение рядов значений для каждого свойства каждого объекта. Представим таблицу Excel, где в каждой ячейке содержится не отдельное число или строка, а вложенная таблицы из двух колонок, одна из которых хранит значения, которые свойство объекта когда-либо имело (или ссылки на другие объекты, с которым он был связан), а другая - время начала актуальности данного значения свойства. Если такая база данных поддерживает передачу в запросе метки времени, приложение сможет легко получать описание состояние объектов на любой момент. Если же добавить к объекту в целом атрибуты, описывающие время начала и окончания существования - можно считать, что функциональные потребности в описании темпоральности закрыты полностью. Такая поддержка есть, например, в HBase - базе данных из экосистемы Hadoop.
Что же делать тем, кто познал преимущества онтологического моделирования и работает с данными, «родным» местом хранения которых являются графовые базы RDF triple store? Очевидно, что в них поддержки темпоральности нет, и вряд ли стоит ожидать ее появления. Пытливые умы закаленных философией и мат. логикой методологов рождают различные формализмы для представления темпоральности внутри самой модели. Это не радует практикующих аналитиков и программистов, а также ведет к деградации производительности и практической невозможности построить пригодную для эксплуатации автоматизированную систему - если только речь не идет об очень «ленивых» чисто интеграционных процессах. Во всяком случае, об автоматизации логического вывода, главной «вишенке на тортике» онтологий, точно можно забыть.
Решение проблемы состоит в создании такого хранилища, которое позволит работать с данными так, как будто они находятся в RDF triple store, в частности - применять правила логического вывода, но при этом будет иметь «нативную» поддержку темпоральности. В применении к графовым структурам данных это означает хранение структуры графа на любой момент времени. Используя SPARQL-запросы при работе с таким хранилищем нужно указывать метку времени, и оно в ответ будет возвращать те данные, которые соответствуют состоянию графа на указанное время. Можно представить себе, что хранилище - это кинопленка, состоящая из множества «снимков» графа на конкретные моменты времени.
Именно такой подход мы реализовали в платформе АрхиГраф. Наличие такого механизма позволяет аналитику не задумываться о явном представлении темпоральности в модели и на концептуальном уровне описывать только ее мгновенное состояние, а от программиста требует лишь указывать метку времени при запросах.
На наш взгляд, ценность такого подхода огромна. Сомневающиеся в этом могут почитать о формализмах типа ИСО 15926, попробовать поработать с представленными в соответствии с ним данными при помощи SPARQL-запросов и правил логического вывода, а потом осознать тот факт, что так усложнять себе жизнь вовсе не обязательно.
Рассмотрим классическую задачу, требующую введения темпоральности в модель: пусть существует техническое место, на котором в разное время установлены разные единицы оборудования. Аналитик моделирует классы Технических мест и Единиц оборудования, а также вводит свойство-связь (ObjectProperty), отражающее факт наличия Единицы оборудования на Техническом месте. Именно свойство, а не дополнительный связующий объект (конечно, реификация все равно может потребоваться, но в большинстве случаев она осуществляется только ради отражения темпоральности - и именно для этих случаев мы упрощаем модель). Программист реализует функционал, отражающий в автоматизированной системе операции, в результате которых Единицы оборудования (ЕО) устанавливаются на Технические места (ТМ) и снимаются с них. При каждой операции создания или удаления связи между ЕО и ТМ он передает метку времени, соответствующую моменту возникновения или исчезновения связи. При запросах на извлечение объектов он также может указать метку времени, чтобы получить состояние моделируемой системы на любой момент, отличный от текущего.
Таким образом, если автоматизированной системе необходимо узнать, какая ЕО была установлена на конкретном ТМ в тот или иной момент времени - она всего лишь передает этот момент в качестве параметра запроса. SPARQL-запрос одинакового синтаксиса с разными метками времени вернет различные результаты.
Как все это устроено «под капотом»? Не очень просто, и в этом решении содержится наше очередное ноу-хау. Могу лишь сказать, что RDF triple store практически не используется для хранения данных. А возможность выполнять SPARQL-запросы (а значит - и применять, например, правила контроля целостности и логического вывода SHACL) имеется.
Считаем, что с реализацией этого механизма сняты практические препятствия для создания корпоративных систем (например, управления активами) на основе онтологических моделей, поскольку одним из основных препятствий для этого было неприемлемое возрастание сложности модели и падение производительности при попытке отразить в одном графе состояние моделируемой системы на любые моменты времени.
Мы ведем реализацию практических промышленных проектов на основе этого подхода, и надеемся в ближайшие месяцы рассказать о конкретных результатах.
Все эти способы так или иначе работают, но
их использование тяжело дается и аналитику, и - особенно - программисту. Если для описания изменений свойств объекта приходится создавать дополнительные объекты - это неизбежно усложняет запросы, а если таких объектов будет несколько сотен или тысяч для каждого «основного» объекта - время выполнения запросов также сильно пострадает.
Существуют базы данных, поддерживающие «нативную» темпоральность - хранение рядов значений для каждого свойства каждого объекта. Представим таблицу Excel, где в каждой ячейке содержится не отдельное число или строка, а вложенная таблицы из двух колонок, одна из которых хранит значения, которые свойство объекта когда-либо имело (или ссылки на другие объекты, с которым он был связан), а другая - время начала актуальности данного значения свойства. Если такая база данных поддерживает передачу в запросе метки времени, приложение сможет легко получать описание состояние объектов на любой момент. Если же добавить к объекту в целом атрибуты, описывающие время начала и окончания существования - можно считать, что функциональные потребности в описании темпоральности закрыты полностью. Такая поддержка есть, например, в HBase - базе данных из экосистемы Hadoop.
Что же делать тем, кто познал преимущества онтологического моделирования и работает с данными, «родным» местом хранения которых являются графовые базы RDF triple store? Очевидно, что в них поддержки темпоральности нет, и вряд ли стоит ожидать ее появления. Пытливые умы закаленных философией и мат. логикой методологов рождают различные формализмы для представления темпоральности внутри самой модели. Это не радует практикующих аналитиков и программистов, а также ведет к деградации производительности и практической невозможности построить пригодную для эксплуатации автоматизированную систему - если только речь не идет об очень «ленивых» чисто интеграционных процессах. Во всяком случае, об автоматизации логического вывода, главной «вишенке на тортике» онтологий, точно можно забыть.
Решение проблемы состоит в создании такого хранилища, которое позволит работать с данными так, как будто они находятся в RDF triple store, в частности - применять правила логического вывода, но при этом будет иметь «нативную» поддержку темпоральности. В применении к графовым структурам данных это означает хранение структуры графа на любой момент времени. Используя SPARQL-запросы при работе с таким хранилищем нужно указывать метку времени, и оно в ответ будет возвращать те данные, которые соответствуют состоянию графа на указанное время. Можно представить себе, что хранилище - это кинопленка, состоящая из множества «снимков» графа на конкретные моменты времени.
Именно такой подход мы реализовали в платформе АрхиГраф. Наличие такого механизма позволяет аналитику не задумываться о явном представлении темпоральности в модели и на концептуальном уровне описывать только ее мгновенное состояние, а от программиста требует лишь указывать метку времени при запросах.
На наш взгляд, ценность такого подхода огромна. Сомневающиеся в этом могут почитать о формализмах типа ИСО 15926, попробовать поработать с представленными в соответствии с ним данными при помощи SPARQL-запросов и правил логического вывода, а потом осознать тот факт, что так усложнять себе жизнь вовсе не обязательно.
Рассмотрим классическую задачу, требующую введения темпоральности в модель: пусть существует техническое место, на котором в разное время установлены разные единицы оборудования. Аналитик моделирует классы Технических мест и Единиц оборудования, а также вводит свойство-связь (ObjectProperty), отражающее факт наличия Единицы оборудования на Техническом месте. Именно свойство, а не дополнительный связующий объект (конечно, реификация все равно может потребоваться, но в большинстве случаев она осуществляется только ради отражения темпоральности - и именно для этих случаев мы упрощаем модель). Программист реализует функционал, отражающий в автоматизированной системе операции, в результате которых Единицы оборудования (ЕО) устанавливаются на Технические места (ТМ) и снимаются с них. При каждой операции создания или удаления связи между ЕО и ТМ он передает метку времени, соответствующую моменту возникновения или исчезновения связи. При запросах на извлечение объектов он также может указать метку времени, чтобы получить состояние моделируемой системы на любой момент, отличный от текущего.
Таким образом, если автоматизированной системе необходимо узнать, какая ЕО была установлена на конкретном ТМ в тот или иной момент времени - она всего лишь передает этот момент в качестве параметра запроса. SPARQL-запрос одинакового синтаксиса с разными метками времени вернет различные результаты.
Как все это устроено «под капотом»? Не очень просто, и в этом решении содержится наше очередное ноу-хау. Могу лишь сказать, что RDF triple store практически не используется для хранения данных. А возможность выполнять SPARQL-запросы (а значит - и применять, например, правила контроля целостности и логического вывода SHACL) имеется.
Считаем, что с реализацией этого механизма сняты практические препятствия для создания корпоративных систем (например, управления активами) на основе онтологических моделей, поскольку одним из основных препятствий для этого было неприемлемое возрастание сложности модели и падение производительности при попытке отразить в одном графе состояние моделируемой системы на любые моменты времени.
Мы ведем реализацию практических промышленных проектов на основе этого подхода, и надеемся в ближайшие месяцы рассказать о конкретных результатах.