Идея применения семантических моделей в корпоративных информационных системах существует давно, но устойчивая практика такого их использования еще не сформировалась. Семантические модели можно применять для интеграции данных, аналитики, управления знаниями; однако, общепринятого мнения о том, где они наиболее полезны, по каким методикам должны строиться такие модели, пока не сформировано.
Задача статьи — на практическом примере сравнить аналитический потенциал моделей, построенных по правилам интеграционного стандарта ISO 15926, который предписывает использование OWL и SPARQL для выражения моделей и работы с ними, и «обычной» семантических моделей, построенных без использования этого стандарта. Решение этого вопроса позволит выбрать диапазон задач, для решения которого целесообразно применять такие высокоуровневые парадигмы семантического моделирования, как ISO 15926.
Постановка проблемы
Необходимо кратко осветить историю вопроса, и суть взаимоотношений между ISO 15926 и «обычной» семантикой. ISO 15926 – стандарт обмена информацией, предназначенный для использования в промышленности (прежде всего, нефтегазовой). Исторически, акцент при разработке стандарта делался на обмен данными между различными организациями, т.е. между различными информационными инфраструктурами. Основные его особенности – специфический подход к классификации объектов и их отношений, учет временнóй составляющей объектов (4D моделирование), возможность моделирования жизненного цикла систем (а не просто текущего состояния той или иной системы). Стандарт содержит онтологическое ядро, и подразумевает использование общих библиотек справочных данных для создания прикладных информационных моделей. Все это обеспечивает как его преимущества (возможность создания высококачественных и релевантных моделей жизненного цикла систем, отличный потенциал использования для передачи информации между различными организациями при помощи общего «онтологического словаря»), так и недостатки (возрастающую сложность получающихся моделей, высокий «порог входа» по уровню знаний, необходимых для овладения стандартом и его использования).
Разработка стандарта была начата еще в 1990-е годы. С появлением в середине 2000-х технологий Semantic Web, они были утверждены в качестве технологической основы для выражения данных в соответствии с ISO 15926. Таким образом, основные концепции стандарта были заложены до возникновения Semantic Web, но только появление этих технологий предоставило необходимый технологический базис для создания способа выражения данных в соответствии со стандартом, обладающего потенциалом действительно широкого распространения. Некоторая идеологическая близость, но не идентичность этих технологий заложила основу того «противоречия», которое мы хотим разрешить. Поскольку принципы, по которым выполняется моделирование в соответствии с ISO 15926, не вполне соответствуют принципам представления объектов и отношений между ними, например, в языке OWL, объединение этих двух технологий получилось несколько синтетическим. Данные, построенные в соответствии с ISO 15926, могут быть разложены на элементарные элементы — триплеты RDF, но анализ отношений между информационными объектами представленной в таком виде модели средствами SPARQL будет затруднен.
Итак, суть противоречия, на которое мы собираемся пролить свет, состоит в следующем: утверждается, что семантические модели, построенные в соответствии с ISO 15926, обладают качественными отличиями от семантических моделей, построенных без подобного высокоуровневого руководства, только средствами «обычных» технологий Semantic Web. Таким образом, эти модели имеют принципиально разную природу (по крайней мере, идеологическую). Утверждается, что может иметь место конкуренция между этими двумя видами семантических моделей, причем аргумент в пользу «обычных» моделей может быть только один – относительная простота; по всем остальным показателям модели ISO 15926 являются более правильными и полезными.
Ниже мы детально рассмотрим эти утверждения, опираясь на практический пример, призванный четко обозначить взаимосвязь, сходства и различия ISO 15926 и «обычных» семантических моделей. Пока же обратимся к идеологии создания и применения семантических моделей данных («обычной» семантикой мы будем называть модели, построенные не в соответствии с ISO 15926).
Семантические модели и их применения
Основной движущей идеей при создании семантических технологий явилась необходимость обеспечения «понимания» алгоритмами вычислительных машин смысла (семантики) данных. Таким образом, исходной задачей этих технологий была аналитика: обеспечение возможностей извлечения знаний из связанных наборов информации.
По мере развития этих технологий, экспериментов по их применению в различных сферах, выяснилось, что они исключительно удобны для объединения (связывания) данных из различных по структуре источников. Отсюда возникло второе направление развития инструментов, основанных на идеях семантических сетей – интеграция информационных систем.
Никакого противоречия между аналитическим и интеграционным применением семантики нет; напротив, они находятся в неразрывном единстве. Ведь целью интеграции, как правило, является извлечение каких-то новых знаний из объединенного набора – таких знаний, которые не могли быть получены из каждого источника в отдельности. Задача упрощения переноса информации из одной информационной системы в другую тоже может быть решена при помощи семантических технологий, но является, скорее, дополнительным бонусом от их развития.
В ряде сфер применения удалось добиться существенных прорывов с использованием семантических технологий анализа информации. Особенно убедительными являются эти успехи в сфере медицины и биотехнологий. Например, на семантических технологиях строятся базы, объединяющие сведения о медицинских препаратах и их действии, клинические истории, генетическую информацию. Анализ таких баз помогает исследователям создавать новые лекарства. Это отличный пример ситуации, когда реляционные базы данных не в состоянии адекватно отразить многообразие связей между информационными объектами, и предоставить инструменты для анализа этих связей – а семантические технологии могут. Также семантические базы данных используются в здравоохранении (для анализа распространения заболеваний), и во множестве других применений.
Средства анализа информации при помощи семантических технологий входят и в повседневную жизнь. Например, разработчики Facebook Graph Search придумали отличный пример, который позволяет на обыденном уровне продемонстрировать принципиальную новизну семантического поиска (анализа): очевидно, что ни одна из существующих поисковых машин, строящихся по принципу поиска в тексте, не сможет ответить на вопрос «Какие рестораны нравились моим друзьям?», или «В каких городах живут мои родственники?». Поиск по графу, используя формализованный набор информационных объектов (люди, рестораны, города) и отношений между ними (нравится, живет в), способен дать нужный ответ быстро и совершенно точно. При этом условия запроса можно варьировать в тех пределах, которые допускает онтология (набор тех самых типов информационных объектов и связей между ними): аналогичные вопросы можно задать не о ресторанах, а о фильмах, не о родственниках, а об одноклассниках. Понятно, что все содержимое социальной сети Facebook представляет собой огромный единый информационный граф, с миллиардами узлов и связей. Возможность анализа и использования этих связей и составляет всю его ценность, что прекрасно понимают владельцы ресурса.
Опираясь на сказанное выше, мы можем определить критерии, которые должны предъявляться к информационным моделям, строящимся по принципам семантических технологий. Часть этих критериев вытекает из общих требований к моделям, часть – из специфики технологий, связанных с условиями их практической полезности. Перечислим их.
1. Результат выполнения какого-либо действия в реальной системе и в модели должен совпадать (отношения подобия между моделью и системой в исходном и конечном состоянии описываются одними и теми же правилами). Это требование обеспечивает прогностический потенциал модели: если оно выполнено, мы можем моделировать развитие системы, и воплощать результаты моделирования.
2. Модель должна отражать свойства объектов и связи между ними таким образом, который делает возможным извлечение знаний из модели при помощи существующих технологий (таких, как SPARQL). Это сугубо практическое требование, обеспечивающее пригодность модели для анализа. Фактически, оно декларирует возможность выполнения расчетов на модели.
3. Модель должна обеспечивать возможности расширения и масштабирования (укрупнения и детализации), без пересмотра ее онтологического ядра. Это требование налагает ограничения на отбор способов классификации объектов, разграничение объектов и их свойств; это требование можно серьезно детализировать.
Пример: создание и анализ «обычной» семантической модели
Рассмотрим теперь два «конфликтующих» способа построения моделей, и оценим их практическую полезность, исходя из перечисленных критериев. Пример мы возьмем из области промышленности, «родной» для обсуждаемого стандарта.
Опишем в виде семантической модели информацию о событии – установке насоса в трубопровод. Наша модель должна содержать следующие сведения:
- Место установки насоса (обозначенное на схеме завода определенным идентификатором; далее в тексте будем называть его «функциональным местом», в соответствии с терминологией ISO 15926);
- Сам насос, как физический объект определенного типа с определенным серийным номером, присвоенным ему в определенный момент времени;
- Сведения о том, что данный насос подходит данному месту (может быть в него установлен);
- Дата и время установки.
Сначала смоделируем эту информационную структуру без опоры на ISO 15926 (разумеется, создать ее можно множеством различных способов, мы произвольно выберем один).
Желтым показаны объекты, соответствующие событиям, зеленым – материальные объекты, без рамки – литералы. В пунктирную рамку обведено определение класса, которое, в принципе, относится к справочным данным, а не к конкретной модели. Стрелками показаны связи объектов друг с другом, и объектов с литералами (свойствами) – ребра графа.
В результате импорта этой онтологии в SPARQL, получится набор из 16 триплетов (ребер графа). Они соответствуют показанным на схеме линиям, плюс по одному триплету для типа каждого объекта. Конечно, схема упрощена – например, «модель» должна быть не литералом, а ссылкой на соответствующий объект.
По этой ссылке можно скачать RDF-представление данной модели, а также набор триплетов, в которые она превращается после импорта в точку доступа SPARQL.
Рассмотрим возможности анализа этой модели. Например, пусть мы хотим узнать, в какое именно место был установлен насос с известным нам серийным номером. Для этого нам потребуется следующая последовательность простых запросов:
SELECT * WHERE { ?pump <http://example.org/DC#Model> "Centrifugal Pump Model AB-123C"^^<http://www.w3.org/2001/XMLSchema#string> }
Этот запрос возвращает идентификатор объекта, содержащего информацию о насосе. Теперь найдем объект «установка насоса»:
SELECT * WHERE { ?installation <http://example.org/DC#InstalledItem> <http://example.org/DC#DE-1234F> }
Осталось узнать место установки:
SELECT * WHERE { <http://example.org/OurInstallation> <http://example.org/DC#InstalledPlace> ?place }
Мы просмотрели три ребра графа; конечно, эти запросы можно объединить в один.
Пример: создание и анализ модели по стандарту ISO 15926
В соответствии со стандартом ISO 15926, наше событие – установка насоса – должно быть описано шаблоном InstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlace. В упрощенном виде структуру ролей этого шаблона, позволяющую выразить информацию, примерно эквивалентную той, что показана в примере выше, можно представить таким образом:
На этой диаграмме экземпляры шаблонов окрашены желтым цветом, экземпляры (instrances) объектов – зеленым.
Такая структура, заполненная минимально необходимыми данными (без аннотаций), при импорте в SPARQL точку доступа превращается в 36 триплетов (скачать OWL и получающийся из него набор триплетов можно по этой ссылке). Отметим, что структура этих данных в триплетах получается вполне разумной, и не так уж сильно отличается от структуры модели без использования стандарта, как могла бы. Увеличение количества триплетов по сравнению с «обычной» семантической моделью в два с лишним раза связано с добавлением новых экземпляров объектов, а также ссылок на определения базовых типов, содержащихся во многих из них. Однако импорт справочных данных, особенно – определений шаблонов, даст гораздо худшие результаты с точки зрения оптимальности структуры графа. Так, определение только одного шаблона InstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlace составляет 148 триплетов, многие из которых включают blank nodes (узлы графа, не имеющие собственных идентификаторов). В том числе, многие триплеты связывают между собой два blank node. Работа с такими структурами средствами SPARQL очень сильно затруднена. На практике это выльется в серьезное возрастание сложности программного обеспечения, реализующего возможности создания или просмотра шаблонов. Для сравнения, «обычная» семантическая модель тех же самых данных укладывается всего в 38 триплетов, то есть она на порядок компактнее, чем модель ISO 15926 (не забудем, что упомянутые выше 148 триплетов описывают только один шаблон, а их в нашем примере четыре, плюс определения необходимых стандартных типов). Еще одно важное отличие состоит в том, что модель ISO содержит связи со внешними элементами, находящимися за пределами той точки доступа, в которой размещена текущая онтология – в частности, в RDL (Reference Data Library, каталог справочных данных; ниже мы еще вернемся к этим каталогам).
Рассмотрим возможности анализа модели, построенной по правилам ISO 15926. Выполним те же задачи, которые описаны выше для «обычной» семантической модели. Пусть мы хотим узнать, в какое именно место был установлен насос с известным нам серийным номером. В модели ISO нам потребуется следующая последовательность простых запросов:
SELECT * WHERE { ?temporalpart <http://standards.iso.org/iso/15926/tpl#valIdentifier> "S/N DE-1234F"^^<http://www.w3.org/2001/XMLSchema#string> }
Получаем в результате идентификатор экземпляра шаблона ClassifiedIdentificationOfTemporalPart. Теперь спрашиваем, с каким физическим объектом «насос» связан этот шаблон:
SELECT * WHERE { <http://example.com/tpl#CITP456> <http://standards.iso.org/iso/15926/tpl#hasTemporalWhole> ?pump }
Получаем идентификатор насоса (объект типа MaterializedPhysicalObject). Теперь можем получить список экземпляров шаблона, описывающего установку насоса:
SELECT * WHERE { ?installation <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> <http://example.com/tpl#MPO456> }
Получили идентификатор экземпляра шаблона InstallationOfTemporalPartMaterializedPhysicalObjectInFunctionPlace. Узнаем теперь, на какое функциональное место производилась установка:
SELECT * WHERE { <http://example.com/tpl#T123> <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> ?place }
Итак, нам потребовалось пройти четыре ребра графа. Очень важно, что для того, чтобы составить эти запросы, программист должен быть детально знаком с принципами ISO 15926, и обладать аннотированной библиотекой шаблонов (которой, на самом деле, нет в открытом доступе).
Сравнение аналитического потенциала моделей
Другой интересный аспект анализа этого графа связан со временем (учет темпорального аспекта является одной из сильных сторон ISO 15926). Если мы захотим узнать, какой насос был установлен на определенном функциональном месте в определенное время, нам придется сделать это при помощи не очень удобных средств работы с датами SPARQL. Сконструируем необходимый запрос.
Получаем эпизоды установки насоса, зная идентификатор функционального места:
SELECT * WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>. }
Теперь получим идентификатор насоса – ради разнообразия примеров, сделаем это в том же самом запросе:
SELECT * WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>.
?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> ?pump. }
С насоса, скорее всего, будет ссылка на его тип в RDL – с ее помощью мы сможем узнать, какой именно это насос; но эту часть модели мы оставили за пределами нашего примера. Осталось добавить в запрос условие на даты установки:
SELECT ?pump WHERE { ?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfFunctionPlace> <http://example.com/tpl#FP123>.
?inst <http://standards.iso.org/iso/15926/tpl#hasTemporalWholeOfInstallable> ?pump.
?inst <http://standards.iso.org/iso/15926/tpl#valStartTime> ?time.
FILTER (?time < "2013-05-09T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>)
}
ORDER BY DESC (?time)
LIMIT 1
Сочетание использования условия FILTER по дате установки, сортировки ORDER BY и ограничения количества выводимых результатов LIMIT дает нам только один нужный результат – позволяет отобрать эпизод установки насоса, предшествующий заданной дате.
На «обычной» семантической модели этот запрос будет иметь точно такую же структуру, и точно такое же количество элементов:
SELECT ?pump WHERE { ?inst <http://example.org/DC#InstalledPlace> <http://example.org/DC#R4598459832>.
?inst <http://example.org/DC#InstalledItem> ?pump.
?inst <http://example.org/DC#Created> ?time.
FILTER (?time < "2013-05-09T12:00:00Z"^^<http://www.w3.org/2001/XMLSchema#dateTime>)
}
ORDER BY DESC (?time)
LIMIT 1
Еще один интересный аспект использования моделей, построенных в соответствии с ISO 15926, связан с использованием RDL – библиотек справочных данных. В них хранятся определения типов устройств, их функций и т.д. Эти библиотеки доступны во внешних SPARQL точках доступа, обычно принадлежащих каким-либо отраслевым ассоциациям. В нашем графе есть одна ссылка на RDL – это определение типа функционального объекта, говорящее нам о том, что им должно быть устройство с функцией насоса. Если мы запросим информацию о типе имеющегося у нас объекта FunctionalPhysicalObject,
SELECT * WHERE {<http://example.com/tpl#FP123> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?rdl }
то получим ссылку на RDL: <rdl.example.org/sampleReferenceData#R4598459832> (а заодно узнаем, что наш функциональный объект относится к классу WholeLifeIndividual, и нескольким другим корневым классам ISO 15926 – не очень полезная для нас информация). Если теперь мы захотим узнать, что означает данное определение, мы должны будем выполнить запрос к другой точке доступа, где хранится данный RDL:
SELECT * WHERE {
<http://example.com/tpl#FP123> <http://www.w3.org/1999/02/22-rdf-syntax-ns#type> ?a.
SERVICE <http://rdl.example.org/sparql> { ?a ?b ?c. }.
}
Такой запрос вернет нам всю информацию, которая есть в RDL по данному типу устройств. В качестве RDL могут использоваться как библиотеки справочных данных (каталоги), поддерживаемые отраслевыми ассоциациями и регулирующими органами, так и частные каталоги, например, поставщиков определенного оборудования.
В «обычных» семантических моделях мы также можем использовать федеративные запросы. Мы можем создать общий каталог, например, оборудования, и разместить его в открытой точке доступа. Весь вопрос только в том, чьим «авторитетом» будет подкреплено такое хранилище информации. Придание авторитета справочникам является функцией различных ассоциаций. При этом, если не кривить душой, соответствие или не соответствие справочника тому или иному стандарту не добавляет к его «авторитету» практически ничего. Если же в качестве RDL используется каталог какой-то определенной компании, например, поставщика оборудования, то вопрос наличия «авторитета» полностью лишается смысла.
Сходства и различия «обычной» семантики и ISO 15926
Выводы из рассмотренных примеров использования семантических моделей вполне очевидны:
1. С технологической точки зрения, «обычные» семантические модели вполне симметричны моделям ISO 15926, если говорить о проектных данных (выражающих информацию о конкретных системах и процессах). Модели ISO имеют бóльшую сложность, и этот разрыв, в сравнении с «обычными» моделями, растет в зависимости от объема модели по линейному закону. Это объясняется наличием отдельных сущностей для выражения темпоральных частей объектов, а также необходимостью классифицировать объекты в соответствии с классификатором типов верхнего уровня.
2. С точки зрения вычислительного потенциала этих моделей – вычисления на них также несколько сложнее, чем в «обычной» семантике, но различие не является радикальным. Более существенно то, что для построения запросов необходимо не только знакомство с моделью, но и владение концепциями ISO 15926, а также наличие навигатора по шаблонам (который, насколько нам известно, отсутствует в открытом доступе; набор шаблонов и порядок их утверждения, насколько нам известно, тоже далеки от желаемых).
3. Система справочных данных и высокоуровневых сущностей ISO 15926 сильно усложнена по сравнению с «обычной» семантикой (если брать за показатель количество триплетов, требуемых для выражения модели – в 10 раз и более). В особенности это касается библиотек высокоуровневых сущностей, таких, как шаблоны. Работа с определениями (не экземплярами!) этих сущностей средствами семантических технологий значительно затруднена. Тем не менее, любое приложение, предоставляющее пользователю возможности работы с шаблонами, и «прячущее» от него их низкоуровневое представление, должно обладать широкими возможностями такой работы (поиск и просмотр, создание и редактирование определений шаблонов, их заполнение). Частичным решением проблемы может быть работа с шаблонами, выраженными не в виде триплетов в RDF-хранилище, а в виде файлов OWL.
4. Концепции ISO 15926, считающиеся его «ноу-хау», и обеспечивающие особую ценность этого стандарта – использование федеративного доступа и библиотек RDL, учет темпоральных частей – доступны и в «обычной» семантике. Все зависит от того, каким образом построена модель данных, и как реализовано разделение данных на проектные и справочные. Кстати, заметим, что нет никаких практических препятствий для использования библиотек RDL, построенных в соответствии с ISO 15926, в приложениях, использующих не соответствующие ему модели данных.
5. Действительную ценность стандарта составляет, прежде всего, его статус стандарта; общепринятые способы классификации и сами классификаторы (а также способы их администрирования) обеспечивают потенциал использования стандарта для интеграции между различными предприятиями, но несколько усложняют выполнение вычислительных задач на моделях. Это естественная ситуация: за любую универсальность приходится платить быстродействием.
Таким образом, стандарт ISO 15926 представляет собой один из способов построения семантических моделей, обладающий определенными достоинствами и недостатками по сравнению с другими способами, содержащими меньше высокоуровневого формализма. С точки зрения практической реализации и потенциала использования, между стандартом и другими способами нет принципиальной разницы, которая позволила бы противопоставить их как различные технологии. Декларирование наличия такой разницы могло бы считаться маркетинговым приемом пропаганды стандарта, если бы оно не играло вместе с тем отпугивающей роли для специалистов, уже знакомых с «обычными» семантическими технологиями (как это происходит сейчас на практике). К тому же, объяснить разницу между ISO 15926 и «обычной» семантикой на технологическом уровне людям, не являющимся ИТ-специалистами, но принимающим решения о создании той или иной программной инфраструктуры, крайне сложно.
Создание качественных моделей систем возможно как с использованием данного стандарта, так и без него; решение о его использовании должно приниматься исходя из контекста применения разрабатываемой информационной системы, прежде всего – с точки зрения возможного включения модели в интеграционные процессы, и с точки зрения требований к проведению вычислений на модели. Следование стандарту можно высказать в качестве общей рекомендации, однако при определенных обстоятельствах необходимость быстрых вычислений на модели может потребовать реализации более рациональной онтологии. Решать проблему оптимизации вычислений только аппаратными средствами, как правило, нерационально.
Основными препятствиями к распространению стандарта следует считать:
- высокий «порог входа» – объем знаний, необходимый для успешного использования этой технологии;
- отсутствие полноценной методической базы, документации, развитых сообществ поддержки, сборников примеров использования;
- отсутствие доступного широкому кругу пользователей программного обеспечения, предоставляющего возможности работы с моделями данных, построенными в соответствии со стандартом;
- отсутствие убедительных и открытых примеров успешного использования стандарта (выходящих за рамки простой декларации о том, что его применяют такие-то компании для таких-то целей).
Именно с этими проблемами и нужно бороться, распространяя стандарт как передовую практику. Его искусственное противопоставление «обычным» семантическим технологиям может играть в этом процессе только негативную роль.
Автор: SergeIndex
