CC BY
281
УДК: 004.4’244, 004.436.4.
МОДЕЛИ И МЕТОДЫ РАЗРАБОТКИ ВЕБ-ПРИЛОЖЕНИЙ НА ОСНОВЕ ОНТОЛОГИИ ПРЕДМЕТНОЙ ОБЛАСТИ
П.А. Шапкин
В статье описываются модели и методы, применимые для обработки информации, представленной в виде RDF-графов и оснащенной онтологией предметной области. Модели строятся таким образом, чтобы приблизить структуру системы к механизмам, используемым при обработке данных в формате XML, а также к принципам объектно-ориентированного программирования. Рассматривается архитектура информационной системы, использующей описываемые подходы
Ключевые слова: онтологии, веб-программирование, дескрипционная логика
1 Введение
Развитие интернет-технологий привело к появлению новых форматов, направленных на представление смысла, или семантики данных. Данные форматы составляют основу инициативы «семантического интернета».
Для представления данных с учетом их семантики используется язык RDF [1], позволяющий описывать данные в виде семантических сетей, строящихся из троек ^объект, атрибут, значение}. При этом одна и
та же сеть может быть по-разному записана на языке RDF, но одинаково воспринята при интерпретации этих записей. Эта особенность делает RDF более подходящим средством для описания данных в среде Веб, чем XML [2]: в XML также существуют различные способы описания семантически эквивалентных сущностей, однако не существует способов установления данной эквивалентности при интерпретации этих описаний.
При использовании RDF для представления данных схема данных может быть определена в виде онтологии на языке OWL [3]. Онтология представляет собой формальное описание предметной области в виде определений используемых понятий (концептов) и их свойств (ролей).
Концепция семантического интернета получила большое развитие, но все еще не нашла широкого применения. Во многом это связано с дефицитом инструментария, необходимого для разработки приложений, полностью ориентированных на семантическое представление данных. В данной работе описываются модели и методы, с помощью которых проводится разработка веб-ориентированной информационной системы, на всех этапах использующей формат RDF для представления данных. Настройка
Шапкин Павел Александрович - Национальный исследовательский ядерный университет «МИФИ» (Москва), аспирант, Е-шаП [email protected] 228
системы на предметную область осуществляется с помощью онтологий.
Статья организована следующим образом: в разделе 2 описывается принцип построения модели и метамодели предметной области на основе онтологии; в разделе 3 описываются модели и методы, используемые при обработке онтологии и RDF-данных; в разделе 4 описывается структура системы, основанной на принципах, описываемых в данной работе.
2 Онтологическое представление модели предметной области
2.1 Онтологии и их формальные основы
Каждая информационная система позволяет выполнять операции над некоторым множеством объектов (сущностей) А, используемых для представления информации. Онтология представляет собой формальную модель предметной области, в которой типы сущностей описываются в виде концептов (понятий). Концепты определяются при помощи дескрипций (описаний). Каждому концепту ставится в соответствие некоторый предикат на множестве А , а, следовательно, некоторое множество значений, удовлетворяющих этому предикату. Функция, реализующая такое соответствие, называется интерпретацией и обозначается как
(-)1. В общем случае множество А зависит от выбранной интерпретации, что обозначается как А1.
В основе языка описания онтологий OWL лежит формальная система, называемая деск-рипционной логикой (ДЛ) [4]. Дескрипционная логика определяет правила построения дескрипций концептов. Помимо концептов в рассмотрение вводятся роли и индивиды. Роли понимаются как типы связей между объектами предметной области, интерпретация ставит в соответствие каждой роли множество упорядоченных пар значений из А. Индивиды трактуются как объекты предметной области; интерпретацией индивида является отдельное значе-
ние из А. При этом делается соглашение о том, что различные индивиды имеют различные интерпретации.
Дескрипции в ДЛ строятся по следующей схеме:
1) базовыми строительными блоками являются универсальный и пустой концепты, атомарные концепты и роли, а также индивиды;
2) более сложные концепты и роли строятся из атомарных при помощи конструкторов концептов и ролей.
Универсальный и пустой концепт, обозначаемые Т и 1, описывают, соответственно, любую сущность, и пустую. Атомарные концепты — первичные, неделимые концепты, специфичные для каждой предметной области.
Существуют различные варианты деск-рипционных логик, отличающиеся предоставляемым набором конструкторов. OWL DL основан на разновидности под названием SHOIN(D) . Списки основных конструкторов концептов, определяемых для SHOIN(D), представлены в таблице. Помимо конструкторов, перечисленных в таблице, SHOIN ( D) включает в себя конструкторы, реализующие работу с простыми («конкретными») типами данных, такими как строки, числа и т. п. Для каждого конкретного типа может быть задан набор дополнительных предикатов, напр., предикаты сравнения чисел и т. п.
На концептах задаются отношения эквивалентности и вложенности. Два концепта C и D считаются эквивалентными, что записывается как C = D , т. и т. т., когда C1 = D1 для всех I. Концепт C называется вложенным в D, когда C1 ^ D1 для всех I. Вложенность
видовые концепты «наследуют» все свойства родовых, т. е. являются вложенными в них.
Наибольший интерес представляют те разновидности ДЛ, в которых отношение вложенности является вычислимым, т. е. существует процедура, проверяющая истинность либо ложность формулы С ^ D для любых допустимых дескрипций концептов С и П в любой интерпретации. Особенность БН01Ы(П) в том, что при высокой выразительности она сохраняет вычислимость вложенности [5]. Из вычислимости вложенности концептов следует разрешимость других связанных, таких как проверка противоречивости концепта (С ^1 ) и проверка несовместимости пары концептов (С пП =1).
Тогда как вложенность концептов схожа с наследованием классов в объектноориентированном программировании (ООП), вычислимость данного отношения заключает в себе основное отличие онтологий от ООП: иерархия наследования не обязательно должна быть задана разработчиками, она может быть вычислена в любой момент.
2.2 Составление онтологии предметной области
Представление модели предметной области в виде онтологии дает ряд преимуществ. Во-первых, онтологии предоставляют большие возможности для описания метаданных. Системы, широко использующие метаданные модели предметной области, являются легко настраиваемыми. Для внесения изменений в такие системы во многих случаях требуются лишь небольшие изменения модели предметной области.
концептов реализует родо-видовые отношения:
Список конструкторов концептов в ДЛ БН01Ы(П)
Название Обозначение Интерпретация
Атомарное понятие C D Фиксированное подмножество А
Универсальное понятие Т AI
Пустое понятие 1 0
Отрицание —A AI \ C1
Пересечение C n D CI n DI
Объединение C u D CI u DI
Ограничение существования 3R.C {i eAz 3b.(a,b) e R1 лb e C1j
Ограничение диапазона VR.C a eAI Vb.(a, b) e R1 ^ b e C1 j
Ограничения численности > nR и < nR a eA b| (a, b) e R1 }> nj и
a eA |{b| (a,b) e R1 }< nj
Во-вторых, онтологии поддерживают расширение и объединение. При составлении модели можно либо основываться на уже существующих онтологиях, либо разрабатывать онтологию для конкретной предметной области с нуля. Но и в последнем случае возможно позднейшее объединение разработанной онтологии со схожими онтологиями. Для этого требуется составить определения эквивалентных концептов среди пересекающихся онтологий и указать их эквивалентность в явном виде.
При разработке онтологии предметной области каждый тип сущностей описывается в виде концепта, атрибуты и связи сущностей представляются ролями. Для построения системы, основанной на онтологии предметной области, в данную модель необходимо внести определенный набор метаданных. Основная задача — выделение особых сущностей, которые будем называть ресурсами. Они отличаются тем, что при каждом обращении к системе пользователь работает с каким-либо определенным ресурсом, или набором однотипных ресурсов. Т. е. это те классы объектов, к которым система предоставляет непосредственный доступ для просмотра и редактирования. Ресурсы могут разделяться на непересекающиеся типы. Типы ресурсов могут различаться методами хранения: одни ресурсы могут храниться в базе данных (БД), другие в файловой системе, третьи могут быть доступны через внешние службы. Кроме того, система может предоставлять пользователям различные наборы действий для работы с ресурсами различных типов.
Метаданные указанного вида вносятся в модель предметной области путем наследования концептов различных сущностей от концептов соответствующих типов ресурсов. А в зависимости от того, от каких концептов наследуется концепт ресурса, система может обрабатывать его тем или иным образом. Для связывания операций, требуемых для обработки объектов с концептами, к которым они относятся, предлагается применять системы шаблонов.
3 Принцип обработки ЯБЕ-данных на основе шаблонов
Обработка данных подразумевает либо их преобразование для получения производных данных или представления исходных данных в другом формате, либо выполнение действий, управляемых обрабатываемыми данными. Обе эти задачи можно свести к вычислению некоторой функции, зависящей от природы обрабатываемых данных: при преобразовании результатом вычисления будут являться новые данные, во втором случае — выполнение некото-
рых действий. Для построения метода обработки данных в формате RDF будем отталкиваться от задачи преобразования, которая потом будет обобщена и на задачу выполнения действий. Разрабатываемая модель схожа с методом преобразования данных в формате XML, с использованием шаблонов XSL [6], поэтому будем называть ее моделью обработки RDF-данных на основе шаблонов.
Преобразование RDF-данных может быть построено по тому же принципу, что и язык XSL. Любое преобразование может быть определено в виде набора шаблонов, представляющих собой кортежи (c, e), где c — концепт, определяющего класс объектов, к которым применим данный шаблон, e — функция, проводящая преобразование, соответствующее данному шаблону. Для удобства будем пользоваться функцией concept , возвращающей концепт, связанный с заданным шаблоном.
В общем случае система шаблонов TS e TemplateSystem(InputType, OutputType), где InputType — тип входных данных, OutputType — тип результата обработки, представляет собой кортеж (ts, e), в которой ts — множество шаблонов, а e e InputType ^ OutputType — функция, проводящая преобразование входного объекта в выходной. Зададим проекцию templates, возвращающую список шаблонов заданной системы шаблонов.
Для целей создания информационной системы, обрабатывающей семантическую информацию, требуется наличие шаблонных систем двух типов: первый тип систем (концептуальные системы) принимает на вход концепты, второй (индивидуальные системы) — индивиды. При этом на вход как тех, так и других систем может подаваться набор дополнительных параметров.
Следует заметить, что описанный принцип обработки информации схож с подходом ООП: шаблоны связываются с концептами так же, как методы связываются с классами, они представляют собой операции, выполняемые одинаковым образом для некоторого множества объектов предметной области.
При применении системы шаблонов к входному объекту должен выполняться шаблон, концепт которого наиболее близок к входному объекту. В случае концептуальной системы шаблонов входной концепт должен быть вложен в концепт выбранного шаблона, в случае индивидуальной системы входной индивид
должен принадлежать концепту выбранного шаблона. При этом встает вопрос разрешения конфликтов, т. е. выбора наиболее подходящего шаблона в том случае, когда для обработки входного объекта подходит сразу несколько шаблонов.
3.1 Алгоритм выбора шаблона
Требуется описать функцию choose(i, ts), осуществляющую выбор шаблона, соответствующего индивиду i из системы шаблонов ts . Прежде всего, требуется наложить некоторые ограничения на допустимые системы шаблонов.
Определение. Система шаблонов T называется правильно сформированной, если выполняется следующее условие:
Vtl312 e templates(T).concept(t1) e
concept(t2) v concept(t1) з concept(t2) V
v concept (t1) n concept (t2) = (0.
Данное ограничение говорит о том, что в правильно сформированной системе не должно быть шаблонов, концепты которых пересекаются между собой: для любых двух шаблонов связанные с ними концепты должны быть либо вложенными один в другой, либо быть несовместимыми.
Дальнейшие рассуждения будем строить для индивидуальной системы шаблонов. Для применения их к случаю концептуальной системы шаблонов везде, где используется операция проверки принадлежности индивида концепту e, должна применяться операция проверки вложенности концептов e .
Определение. Глубиной шаблона Т в системе шаблонов T будем называть значение функции
depth(T, T) : Template х TemplateSystem ^ N0 , где N0 ={0,1 ,2, к} — множество неотрицательных целых чисел, вычисляемой следующим образом:
1) если
31 e templates(T).concept(T) е concept(t), то depth(T, T) = 0
2) если
3t e templates(T).concept(T) е concept(t), то depth(T, T) = depth(t, T) +1
Теорема. В правильно сформированной системе шаблонов если
т = choose(i, T) = maxMdepth(t T){t | i e concept(t) &
t e templates(T)}
, то
1) данный шаблон единственен;
2) данный шаблон является наиболее близким к индивиду i , т. е. не существует шаблона, концепт которого более специфичен, чем у Т, и при этом содержит i; т. е. Vt e templates(T).i e concept(t) ^
Т е concept(t) V t = Т
Доказательство: Докажем первое утверждение: шаблон, выбираемый с помощью описанной функции choose , единственен. Если бы это было не так, то существовало бы несколько шаблонов с равной глубиной, концептам которых принадлежит i . Рассмотрим любые два из них. По условию правильно сформированной системы шаблонов концепты этих шаблонов могут либо включаться один в другой, либо быть несовместимыми. Т. к. i входит в оба концепта, несовместимыми они быть не могут. Следовательно, один из них должен быть включен в другой. Но в таком случае они имеют разную глубину, что противоречит предположению о том, что их глубины равны друг другу. Утверждение доказано.
Докажем от противного второе утверждение. Пусть
3t e templates(T).i e concept(t) & t ф т & t ет Т. к. t е т , то depth(T, t) > depth(T, т) ; но по условию теоремы depth(T, т) максимальна — противоречие. ■
Доказанная теорема позволяет составить алгоритм выбора наиболее подходящего шаблона для обработки конкретного индивида или концепта. Основная задача состоит в том, чтобы просматривать шаблоны в порядке убывания глубины. Первый из просматриваемых шаблонов, концепт которого включает в себя объект обработки, и является наиболее подходящим. Это говорит об адекватности данного механизма поставленной задаче.
3.2 Проверка непротиворечивости систем шаблонов
Рассмотрим некоторую систему шаблонов S . При разработке информационной системы, работающей на системе S , важным свойством является наличие гарантии того, что при функционировании не возникнет ошибок. Некоторые виды ошибок могут быть выявлены до выполнения системы, на основе статического анализа структуры шаблонов. Под проверкой системы на непротиворечивость будем подразумевать следующие операции:
• проверка существования шаблонов для визуализации всех ресурсов;
• проверка существования шаблонов для обработки всех действий с БД для всех ресурсов;
Указанные проверки позволяют получить гарантию, что система не выдаст ошибок, если пользователем введен корректный запрос. Эти проверки используют структуру онтологии предметной области и выполняются путем све-рения с ней используемых систем шаблонов.
Кроме того, возможно осуществлять проверку индивидуальных шаблонов на предмет использования только тех ролей индивидов, которые связаны с концептом шаблона. В противном случае может произойти ошибка времени выполнения, т. к. обрабатываемый индивид может не иметь требуемой роли.
Подобная проверка может быть осуществлена с помощью тестового применения каждого шаблона к индивиду-заглушке для его концепта. При попытке обращения к роли R для заглушки m возвращается некоторое тестовое значение, если m e 3R.T, в противном случае генерируется ошибка. Если при применении шаблона к заглушке ошибок не произошло, его можно считать непротиворечивым.
4 Реализация информационной системы на основе шаблонного подхода
4.1 Структура системы
За основу для построения системы взят подход Модель-Вид-Контроллер (Model-View-Controller, MVC) [7], используемый во многих веб-каркасах, таких как Apache Struts, Spring MVC, Ruby on Rails и т. п. Система взаимодействует с окружающим миром через отдельный объект, называемый диспетчером запросов. Диаграмма алгоритма обработки запроса диспетчером приведена на рисунке, он включает в себя следующие действия:
• анализ запроса;
• выполнение операций с БД;
• визуализация результата;
• возвращение результата пользователю.
[неудача]
Разобрать запрос
^Разобрать запрос^-
[успех]
(а
Выполнить операции с БД
•Д^ ^Сообщить об ошибке^
Визуализировать результат
Алгоритм обработки запроса диспетчером запросов
Непосредственно самим диспетчером выполняется только анализ запроса, и возвращение результата пользователю, для выполнения остальных операций управление передается 232
другим объектам: исполнителю операций с БД и визуализатору.
При анализе запроса рассматриваются запрошенный пользователем URL и HTTP-метод и определяется ресурс и действие, которые над ним необходимо выполнить, а также формат, в котором пользователь ожидает получить ответ. Если разобрать запрос не удалось, то пользователю возвращается сообщение об ошибке.
В случае удачного разбора запроса результат передается исполнителю операций с БД, результатом работы которого является некоторый информационный объект, представленный индивидом в RDF-графе. Данный индивид передается одному из визуализаторов — тому, который соответствует запрошенному пользователем формату представления данных. Обработанный визуализатором результат возвращается пользователю в качестве ответа.
Исполнители операций с БД и визуализа-торы представляются в виде шаблонных систем, соответственно, концептуальных и индивидуальных. Исполнитель операций с БД является концептуальной системой шаблонов, т. к. после анализа запросов известен только тип ресурсов, к которому осуществляется запрос, т. е. на вход системы подается концепт данного типа ресурсов. Визуализатор же обрабатывает индивид, полученный в результате работы исполнителя операций с БД.
4.2 Пример: система доступа к взаимосвязанным объектам научной информации
В качестве примера рассмотрим реализацию портала, предоставляющего доступ к базе данных научных публикаций. Ограничим функционал системы только просмотром данных. Система включает в себя информацию о публикациях, авторах, научных мероприятиях, организациях. Между указанными сущностями существует множество связей. Кроме того, необходимо реализовать использование внешних источников данных. Внешней по отношению к реализуемой системе информацией являются классификационные схемы, с помощью которых производится тематическая разметка публикаций. Доступ к классификационным схемам может быть осуществлен через веб-службу, имеющую RDF-интерфейс.
Модель данной предметной области можно представить в виде онтологии, где сущностям соответствуют концепты, связям — роли. При этом возможно применение стандартных онтологий, таких как Dublin Core [Ошибка! Источник ссылки не найден.]. Концепты, описывающие модель классификационных схем, могут быть взяты из онтологии, сопровождающей службу классификационных схем.
В системе выделяются два вида ресурсов: внутренние ресурсы — публикации, авторы, мероприятия, организации, и внешние ресурсы
— классификационные схемы и их рубрики. Данные ресурсы различаются по способу доступа к данным.
Для каждого типа ресурсов система должна предоставлять следующие функции:
•просмотр информации о каком-либо объекте;
• просмотр списка объектов какого-либо типа;
• поиск объектов.
Данные действия имеют различные наборы параметров. Для просмотра информации об объекте необходимо идентифицировать его в системе. Для совместимости с реляционными БД, идентификацию объектов удобно проводить путем выявления наборов идентифицирующих свойств. Комбинация значений для данных свойств должна однозначно идентифицировать объект внутри заданного ресурса. Такой механизм наиболее близок к механизму первичных ключей, используемому в реляционных БД. Таким образом, для просмотра информации о конкретном объекте необходимо задать его ресурс и набор значений идентифицирующих свойств.
Для просмотра списка объектов необходимо указать ресурс, объекты которого будут просматриваться. Для просмотра объектов, связанных с каким-либо определенным объектом, необходимо идентифицировать данный объект: указать его ресурс и значения идентифицирующих свойств; а также указать тип связи.
Поиск объектов можно считать надстройкой над операцией просмотра списка. Для осуществления поиска необходимы те же параметры, что и для просмотра соответствующего списка объектов, плюс поисковое выражение.
Каждому из указанных действий должна соответствовать система шаблонов, загружающих необходимую информацию из источников данных. Конкретная система выбирается при обработке запроса диспетчером и затем используется для получения необходимых данных. Шаблоны визуализации зависят от требуемого
формата. Они принимают на вход индивид и модель, загруженную на первом этапе, и возвращают отформатированное представление данных. В системе поддерживается два формата представления данных: HTML — для просмотра данных пользователями-людьми, RDF
— для программного доступа к данным.
5 Заключение
В данной работе рассмотрены модели и методы, позволяющие работать с данными в формате RDF способами, аналогичными используемым в подходе ООП. Основу подхода составляют системы шаблонов, схожие с методами классов в ООП. Использование формальных моделей позволяет логически доказывать адекватность используемых алгоритмов и непротиворечивость разрабатываемых систем шаблонов.
Литература
1. Lassila, O. Resource description framework (RDF) model and syntax specification / O. Lassila, R. R. Swick. — 1999. — W3C Recommendation 22 February 1999.
2. Extensible markup language (XML) 1.0 / T. Bray, J. Paoli, C. M. Sperberg-McQueen et al. // W3C recommendation. — 2000. — Vol. 6.
3. OWL, язык веб-онтологий. Руководство. Рекомендация W3C 10 февраля 2004. http://sherdim.rsu.ru/pts/semantic web/REC-owl-guide-20040210 ru.html.
4. Baader, F. The Description Logic Handbook: Theory, Implementation, and Applications / F. Baader.
— Cambridge University Press, 2007. — 622 pp.
5. Borgida, A. On the relative expressiveness of description logics and predicate logics / A. Borgida // Artificial Intelligence. — 1996. — Vol. 82, no. 1-2. — P. 353-67.
6. Clark, J. XSL transformations (XSLT) version 1.0 / J. Clark et al. // W3CRecommendation. — 1999.
— Vol. 16, no. 11.
7. Приемы объектно-ориентированного проектирования. Паттерны проектирования / Э. Гамма, Р. Хелм, Р. Джонсон, Д. Влиссидес. — СПб: Питер, 2007. — 366 с.
8. Dublin core metadata for resource discovery / S. Weibel, J. Kunze, C. Lagoze, M. Wolf // Internet Engineering Task Force RFC. — 1998. — Vol. 2413
Национальный исследовательский ядерный университет «МИФИ» (г. Москва)
MODELS AND METHODS FOR THE DEVELOPMENT OF WEB-APPLICATIONS BASED ON DOMAIN ONTOLOGIES P.A. Shapkin
The article describes models and methods suitable for processing of information that is represented in the form of RDF graphs along with the domain ontology. Models are drawn up in a way similar with the processing of XML data and in compliance with the principles of the object-oriented programming. Architecture of the system based on the described approach is presented
Key words: ontologies, web programming, description logics
