Практический сценарий использования сервера "Бизнес Семантика" для обмена данными в формате ISO 15926

Вопрос о совместимости «Бизнес Семантики» с ISO 15926 нужно рассматривать с учетом того, что «Бизнес Семантика» - всего лишь средство передачи данных. Наш программный продукт не осуществляет, говоря вообще, их «осмысления» (то есть преобразований, связанных со смыслом передаваемой информации), за исключением мэппинга на элементы структуры базы данных, а также той логики, которая может быть заложена в процедурах-обработчиках на клиентской стороне.

Поэтому вопрос корректнее поставить так: может ли «Бизнес Семантика» обрабатывать данные, соответствующие правилам ISO 15926? Да, может. В конечном счете, информация в ISO 15926 выражается в виде RDF-триплетов, что необходимо для ее сохранения на SPARQL-сервере, выполняющем роль фасада. Оттуда информация извлекается сторонними приложениями при помощи SPARQL-запросов.

Для реализации практического кейса возьмем пример из работы Hans Teijgeler «ISO 15926: an Introduction». Он описывает передачу сведений о значении температуры, выдаваемом датчиком, являющимся частью определенного устройства. Представим, что "Бизнес Семантика" получает данные из реляционной базы данных, куда их сбрасывает некое проприетарное приложение, регулярно опрашивающее датчики. База данных содержит таблицу "Значения температуры" (в реальном случае, конечно, таблиц было бы больше - как минимум, нужна еще таблица со списком датчиков; для упрощения нашего примера здесь мы будем работать только с одной таблицей - "Значения температуры"). Задачей "Бизнес Семантики" является преобразование этих данных в семантическую форму, и их публикация на "фасаде".

Сведения о значении температуры датчика в какой-либо момент времени описываются экземпляром шаблона PropertyWithValueOfTemporalPart. Данные о конкретном показании датчика будут записаны в OWL следующим образом:

<owl:Thing rdf:ID="T340982">
  <rdf:type rdf:resource="&p7tpl;PropertyWithValueOfTemporalPart"/>
  <meta:annUniqueName rdf:datatype="&xsd;string">
A temporal part of MPO349818 has a temperature of 67 Celsius since
2013-03-17T12:00:00Z
  </meta:annUniqueName>
  <meta:annRule rdf:datatype="&xsd;string">#com1_4598292121</meta:annRule>
  <meta:annAccessCode rdf:datatype="&xsd;string">#com1_273872</meta:annAccessCode>
  <p7tpl:hasTemporalWhole rdf:resource=“#MPO349818"/>
  <p7tpl:hasPropertyPossessor rdf:resource="#MPO349818_2013-03-17T12-00-00Z"/>
  <p7tpl:hasPropertyType rdf:resource="&rdl;R41192093771"/> <!-- Temperature -->
  <p7tpl:valPropertyValue rdf:datatype="&xsd;float">67</p7tpl:valPropertyValue>
  <p7tpl:hasPropertyScale rdf:resource="&rdl;R74877992703"/> <!-- degree Celsius -->
  <p7tpl:valStartTime rdf:datatype="&xsd;dateTime">
2013-03-12T12:00:00Z
  </p7tpl:valStartTime>
</owl:Thing>

Обратим внимание на важные составляющие этого фрагмента данных:

• T340982 - уникальный идентификатор данного измерения
• MPO349818 - уникальный идентификатор (URI) датчика
• R41192093771 - идентификатор показателя "температура"
• R74877992703 - идентификатор единицы измерения "градусы Цельсия"
• 67 - значение температуры (в градусах)
• 2013-03-12 12:00:00 - момент времени, в который датчик выдал такую температуру.

В RDF-триплеты эта информация преобразуется так (таблица из упомянутой выше работы Hans Teijgeler):

Сервер «Бизнес-Семантика» может получить, обработать и передать эти триплеты. Для этого в загруженной на сервер онтологии должны присутствовать определения используемых в них типов и свойств, таких как http://www.w3.org/2006/12/owl2-xml#Thing или http://www.infowebml.ws/owl/tpl#hasPropertyType. Также должны быть определены права доступа обменивающихся систем к данным типам объектов и свойств (это является несомненным достоинством «Бизнес Семантики», т.к. сам стандарт ничего не говорит о правах доступа и безопасности). Это требует определенной настройки сервера – так, в него должны быть загружены библиотека стандартных типов и библиотека шаблонов ISO 15926 (или, по крайней мере, их части, используемые в реальной ситуации обмена), для чего необходимо получить их в виде OWL файлов. Если требуется работа с полным набором типов и шаблонов ISO 15926, то выполнение такой операции, и дальнейшая работа с сервером, при загрузке всей библиотеки полностью, может стать крайне неудобной. В таком случае, альтернативным вариантом может быть включение на сервере режима, при котором он не проверяет наличие типов и/или свойств в «словаре», а также не проверяет права доступа. В нашем кейсе, однако, достаточно небольшого фрагмента онтологии, который мы вынесем в отдельный OWL-файл, и загрузим через панель управления "Бизнес Семантики".

Задачей клиентского модуля (коннектора) является формирование и преобразование триплетов. То есть, фактически, требование соответствия стандарту в большей степени относится к клиенту. Существующий на сегодняшний день веб-коннектор работает по тому же принципу, что и сервер, то есть обрабатывает триплеты, используя загруженную в него онтологию. Мы можем загрузить в коннектор «Бизнес Семантики» (или получить от сервера) фрагмент онтологии, выраженный в терминах, определенных в стандарте, и написать модули-обработчики для элементов этой онтологии, либо сопоставить их определенным элементам БД-источнка. Тогда и коннектор будет работать с данными, соответствующими стандарту. Как уже было сказано выше, работа с полным набором типов и шаблонов ISO 15926 вряд ли будет возможной. Но, с другой стороны, «Бизнес Семантика» решает задачу синхронизации данных между различными информационными системами; сложно представить себе практический случай, когда будет требоваться синхронизация  информации, представляемой при помощи неограниченного числа элементов библиотек типов и шаблонов ISO 15926.

Итак, после загрузки онтологии на сервер и в клиентский модуль, мы должны выполнить настройку мэппинга и обработчиков на клиенте. Как мы уже говорили, в нашем кейсе мы имеем дело с таблицей реляционной БД, которая является источником данных о температуре датчиков. Пусть эта таблица называется temp_data, и содержит столбцы:

• id - локальный идентификатор записи (1, 2, 3 и т.д.);
• uid - уникальный идентификатор измерения (в нашем примере - T340982);
• dt - дата и время измерения;
• value - значение температуры, полученное в ходе измерения.

В реальном случае, таблица содержала бы еще поле для идентификатора датчика, ссылающееся на таблицу "датчики", но в данном примере мы опустим его для краткости.

Ниже приведена таблица с настройками, которые нам нужно сделать в административной панели клиента "Бизнес Семантика":

Обратите внимание, что для сущности, помимо привязки к таблице БД, указана функция-обработчик handleTemp. Она сформирует те элементы шаблона, которые невозможно получить из полей БД: hasPropertyScale, hasPropertyPosessor и др.

Также нужно обратить внимание на то, что элементы онтологии, фактически содержащие ссылки на информационные объекты (датчик, вид измеряемой величины, шкала) имеют здесь тип "строка" - это издержки "локализации" нашего примера. Если бы мы ввели отдельную таблицу "датчики", элемент hasTemporalWhole ссылался бы на нее, и т.д.

После того, как эти настройки сделаны, и обработчик написан (его объем  - 12 строк кода), можно запускать интеграцию. Как только в таблицу БД будет добавлено новое значение - результат очередного измерения температуры - клиент "Бизнес Семантика" выдаст серверу информационное сообщение, имеющее следующий вид (для обмена между клиентом и сервером в нашем продукте используется синтаксис Turtle):

@prefix rdf: <http://www.w3.org/1999/02/22-rdf-syntax-ns#> .
@prefix owl: <http://www.w3.org/2006/12/owl2-xml#> .
@prefix p7tpl: <http://www.infowebml.ws/owl/tpl#> .
@prefix : <http://business-semantic.ru#> .

:T340982
 rdf:type  owl:Thing ;
 p7tpl:hasPropertyPosessor :MPO349818_2013-03-17T12-00-00Z ;
 p7tpl:hasPropertyScale "&rdl;R74877992703" ;
 p7tpl:hasPropertyType "&rdl;R41192093771" ;
 p7tpl:hasPropertyValue "67" ;
 p7tpl:hasTemporalWhole :MPO349818 ;
 p7tpl:valStartTime "2013-03-17T12:00:00Z" ;
 rdf:type "&p7tpl;PropertyWithValueOfTemporalPart" ;
.
 

Сервер "Бизнес Семантика", в свою очередь, помещает эту информацию в SPARQL-сервер, который будет играть роль фасада. При проведении эксперимента по этому кейсу мы использовали сервер Apache Jena/Fuseki. Мы создали два "измерения", результаты которых были переданы в SPARQL.

Представим теперь внешнее приложение, которое хочет опросить фасад, чтобы получить сведения о температуре датчика. Пусть приложению известен URI датчика. Тогда оно сделает следующий запрос:

PREFIX : <http://business-semantic.ru#>
PREFIX p7tpl:<http://www.infowebml.ws/owl/tpl#>

SELECT *
WHERE {
 ?measure p7tpl:hasTemporalWhole :MPO349818
}
 

Мы выполнили этот запрос вручную через консоль Fuseki, и получили следующий ответ:

(префикс http://business-semantic.ru был нами выбран произвольным образом, конечно, можно использовать любой другой)

Полученный результат - уникальные идентификаторы всех измерений, сделанных этим датчиком. Пусть теперь внешнее приложение хочет узнать конкретное время первого измерения, и значение температуры:

PREFIX : <http://business-semantic.ru#>
PREFIX p7tpl:<http://www.infowebml.ws/owl/tpl#>

SELECT *
WHERE {
 :T340982 p7tpl:valStartTime ?time.
 :T340982 p7tpl:hasPropertyValue ?value.
}
 

Запрос относительно второго измерения будет отличаться только идентификатором измерения. Он даст такой результат:

Таким образом, мы можем констатировать, что "Бизнес Семантика" выполнила функцию получения данных из реляционной БД, и их трансформацию в семантическую форму в соответствии с требованиями стандарта ISO 15926.

Опираясь на данный кейс, мы можем классифицировать наш продукт по степени соответствия стандарту ISO 15926 по шкале, содержащейся в документе JORD ISO15926 Compliance Specification. Наше приложение выполняет только некоторые из функций, перечисленных в нем; так, нашей задачей не является создание инструмента моделирования онтологий. Перечислим те критерии, по которым мы можем классифицировать свой продукт, и достигнутые по ним уровни соответствия стандарту (подразумевая, что "Бизнес Семантика" работает в связке со SPARQL-сервером):