Построение хранилищ онтологических баз знаний Текст научной статьи по специальности «Компьютерные и информационные науки»

УДК 004.98, 004.652.4

ПОСТРОЕНИЕ ХРАНИЛИЩ ОНТОЛОГИЧЕСКИХ БАЗ ЗНАНИЙ

М.Н. Вехорев; М.Г. Пантелеев, к.т.н.

(Санкт-Петербургский государственный электротехнический университет (ЛЭТИ), mvehorev@gmail. com, mpanteleyev@gmail. com)

Описывается проблема хранения онтологически представленной информации в реляционных БД. Хранилище онтологий рассматривается как особый класс информационных систем. Классифицированы существующие подходы к хранению онтологий в БД. Определены ключевые факторы, влияющие на эффективность хранилищ онтологий, а также возможные направления дальнейших исследований в области организации хранилищ онтологической информации.

Ключевые слова: онтологии, организация хранилищ онтологий, реляционная СУБД, технология хранения RDF-триплетов, хранилище онтологий, язык запросов семантического Веб, движок запросов RDF.

Концепция и технологии семантического Веб - это динамично развивающиеся направления информационных технологий [1], которые обеспечивают возможность совместного многократного использования знаний различными приложениями, организациями и сообществами, позволяя компьютерам обрабатывать информацию на семантическом уровне.

Ключевым элементом информационных систем (ИС), основанных на технологиях семантического Веб, являются онтологические базы знаний. При создании крупных информационных систем по мере роста объемов используемых онтологий их хранение в плоских файлах оказывается непродуктивным. В связи с этим актуальна проблема организации эффективных хранилищ онтологических баз знаний (RDF-хранилищ).

Представление онтологий в семантическом Веб

Под онтологией, согласно общепринятому определению, понимается явная спецификация концептуализации.

Для автоматической обработки разделяемых знаний консорциумом W3C разработаны единые стандарты их представления: RDF (Resource Description Framework) и основанный на нем язык веб-онтологий OWL (Ontology Web Language). Под ресурсом понимается любая сущность, которой сопоставлен универсальный идентификатор URI (Universal Resource Identificator). Основной конструкцией языка RDF является утверждение, задаваемое тройкой <субъект> <предикат> <объект> (RDF-триплет), например: <стол> <цвет> <черный>. Использование URI для задания субъектов и свойств позволяет связывать отдельные утверждения (RDF-триплеты) в сколь угодно сложные семантические сети, имеющие единую интерпретацию в открытой сетевой среде.

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

Однако данный подход имеет недостатки: существенный рост затрат оперативной памяти при работе с большими онтологиями (более 106 триплетов) вследствие полной загрузки OWL-файла, а также значительное увеличение времени загрузки OWL-файлов по мере роста количества используемых онтологий. Это не позволяет использовать данный подход при создании крупных ИС и обусловливает необходимость построения RDF-хранилищ на основе реляционных СУБД.

Особенности RDF-хранилищ

Под RDF-хранилищем понимается информационная подсистема, предназначенная для хранения RDF-триплетов и выполнения запросов к ним.

Основными функциями RDF-хранилища являются:

• организация хранения онтологий в реляционной БД с использованием реляционных представлений;

• предоставление программного интерфейса для извлечения информации из хранимых онтоло-гий посредством языка структурированных запросов SPARQL или специального API;

• поддержка функций администрирования хранимых онтологий: добавление, удаление, модификация и распределение прав доступа.

Эффективное RDF-хранилище должно удовлетворять следующим требованиям:

• высокая производительность - минимизация времени выполнения запросов;

• минимальные затраты памяти (дискового пространства) для хранения онтологий;

• универсальность подхода - возможность хранения онтологий любой структуры.

При разработке конкретных ИС важны время и сложность развертывания RDF-хранилища, а также его стоимость.

Обобщенная архитектура RDF-хранилища

В состав RDF-хранилища входят две основные подсистемы: подсистема хранения онтологий на

RDF -хранилище

Архитектура RDF-хранилища

основе реляционной СУБД и подсистема трансляции входных запросов в SQL-запросы (см. рис.).

В качестве подсистемы хранения онтологий могут использоваться как коммерческие СУБД (Oracle, MS SQL Server и др.), так и свободно доступные (PostgreSQL, MySQL и др.).

Прикладные информационные системы могут взаимодействовать с RDF-хранилищем посредством специального API или структурированных SPARQL-запросов. SPARQL - это стандартный язык запросов к RDF-данным. Например, простой SPARQL-запрос для получения имени и номера паспорта некоторой персоны имеет вид: SELECT ?name ?number WHERE{ ?someone rdf:type :Person.

?someone :name ?name.

?someone :passportNumber ?number.}

Отношение rdf:type является стандартным отношением языка RDF и означает принадлежность элемента классу. Класс :Person, отношения :name и :passportNumber в данном примере взяты из некоторого пространства имен по умолчанию.

Подсистема трансляции входных запросов в общем случае может включать два компонента:

• обработчик API-вызовов, предоставляющий библиотеку классов некоторого языка программирования для работы с онтологиями, включая их загрузку из хранилища;

• транслятор SPARQL^SQL, выполняющий преобразования SPARQL-запросов в SQL-запросы и обратные преобразования результатов, возвращенных SQL-запросами в результат SPARQL-за-проса.

Недостаток специального API состоит в привязке к конкретному языку программирования. Пример такого API - библиотека Jena. Интерфейс SPARQL-запросов является универсальным решением, не зависящим от языка программирования. Поэтому рассмотрим работу с RDF-хранилищем с использованием именно этого интерфейса. Преобразования SPARQL-запросов в набор SQL-запросов будем обозначать SPARQL^{SQL}.

Очевидно, что формальная грамматика преобразования SPARQL^{SQL} зависит от принятой в RDF-хранилище схемы РБД. Вопросы оптимиза-

ции функционирования транслятора SPARQL^ ^SQL рассмотрены, в частности, в [2, 3]. Настоящая статья посвящена определению зависимости производительности RDF-хранилища от принятой схемы РБД.

Организация хранения онтологий в БД

Можно выделить два базовых подхода к организации хранения онтологий в РБД:

1) использование единственной таблицы для хранения всех RDF-триплетов (подход «вертикальная таблица»);

2) отображение иерархии онтологических сущностей (классов, свойств, экземпляров) в схему РБД.

В соответствии с первым подходом все RDF-триплеты хранятся в унифицированной таблице БД, содержащей в общем случае четыре колонки: «граф», «субъект», «объект» и «предикат». Данный подход реализован, в частности, в Jena SDB и 3store. Он характеризуется достаточно высокой временной сложностью выборки RDF-триплетов.

Особенностью второго подхода является определение схемы БД в соответствии с конкретной предметной областью, что позволяет оптимизировать выполнение запросов. Реализация данного подхода для больших онтологий предполагает создание большого числа таблиц БД со сложными связями между ними. Известно несколько частных решений, отличающихся способом формирования схемы БД [4, 5].

Анализ факторов, влияющих на эффективность RDF-хранилищ

Эффективность RDF-хранилища при использовании SPARQL-запросов определяется двумя основными взаимосвязанными факторами: принятой схемой БД и грамматикой преобразования SPARQL^(SQL).

Исходя из представленной на рисунке обобщенной архитектуры RDF-хранилища, время Тsparql обработки SPARQL-запросов в общем виде определяется формулой

Тsparql=Тtrans+Tsql_seq, (1)

где Ttrans - время трансляции SPARQL -запроса в последовательность SQL-запросов в соответствии с принятой трансформационной грамматикой; Tsql_seq - время обработки СУБД построенной последовательности SQL-запросов.

Введем определения и примем базовые допущения, необходимые для анализа временных затрат на обработку SPARQL-запросов.

SQL-запрос в общем случае имеет следующую структуру:

SELECT <кортеж выбираемых полей> FROM <кортеж таблиц> WHERE <кортеж условий>.

Построение SQL-запроса на основе входного SPARQL-запроса предполагает формирование кортежей выбираемых полей и условий. Без существенной потери общности примем равными время формирования одного элемента кортежа выбираемых полей и одного элемента кортежа условий в запросе. Время формирования кортежа таблиц можно считать постоянным и пренебрежимо малым.

Пусть T' - среднее время формирования элементов кортежа выбираемых полей и кортежа условий в процессе построения SQL-запроса. Тогда время формирования SQL-запроса линейно зависит от числа элементов в кортежах выбираемых полей и условий.

Допустим, что обработка SQL-запроса требует последовательного просмотра всех записей таблицы и сравнения анализируемых условий для каждой из них. Тогда время выборки очередной записи из таблицы можно считать равным времени анализа одного условия.

Обозначим T" среднее время выборки записи из таблицы и анализа условия, необходимое для выполнения SPARQL-запроса к СУБД. Будем считать, что T" не зависит от конкретной СУБД и является постоянным. Можно также считать, что время анализа записей в таблице БД линейно зависит от количества записей таблицы, а время анализа условий линейно зависит от количества условий, проверяемых для каждой записи в таблице БД.

Зависимость времени трансляции SPARQL^ {SQL} от принятой трансформационной грамматики оценивается формулой

Ttrans = ^Tsql_defi.

(2)

где N - количество результирующих запросов SQL, получаемых в результате трансляции; Tsql_def i - время построения i-го SQL-запроса.

Зависимость времени формирования очередного SQL-запроса от количества полей, содержащихся в кортеже результата, и количества условий будет следующей:

Tsql def = Nres*Tres def +

(3)

+Ncond * Tcond def.

Исходя из принятых допущений, можно запи-

сать:

T' = Tres_def = Tcond_def.

Подставив (3) и (4) в (2), получим

N

Ttrans =^Tsql_defi =

i=1

N

=^(Nresi + Ncondi)*T'.

(4)

(5)

Аналогично зависимость времени обработки набора ^¿-запросов может быть выражена формулой

Tsql_seq =kjTTsql i,

(6)

где k - коэффициент схемы БД, численно равный количеству таблиц БД (ШЫ); N - количество результирующих ^¿-запросов, построенных при трансляции; Тsql i - время выполнения Ьго SQL-запроса к СУБД.

Время, необходимое на выполнение одного SQL-запроса, может быть оценено по формуле

Тsql = (Тrecord + Тfield), (7)

где Trecord - время на анализ записей в таблице; Tfield - время на сопоставление условий запроса с текущими значениями в строке таблицы.

Исходя из принятых допущений, можно записать:

ТгесоМ = №Ы _гес*Т", (8)

где Ntbl_rec - количество записей в таблице БД;

ТйеМ = №Ы_fld*T'', (9)

где №Ы_1М - количество проверяемых условий в SQL-запросе.

Подставив (7-9) в (6), получим:

Tsql_seq = k^Tsql i =

i =1

N

= Ntbl * Trecord + Tfield) i =

(10)

i =1

N

= Ntbl * £(Ntbl _ rec + Ntbl _fld)i * T".

i=1

Подставив (5) и (10) в (1), получим:

N

Tsparql = ^(Nres i + Ncond i) *T' + Ntbl *

i=1

N

*£(Ntbl_rec + Ntbl_fld)i*T".

(11)

Формула (11) выражает зависимость времени выполнения SPARQL-зaпросa от особенностей принятой схемы БД и соответствующей трансформационной грамматики.

Рассмотрим влияние схемы БД на трансформационную грамматику для двух вариантов схем -«вертикальная таблица» и «таблицы свойств классов». Схема БД «вертикальная таблица» предполагает создание единой таблицы для хранения RDF-триплетов, а схема БД «таблицы свойств

классов» - отдельных таблиц для хранения экземпляров каждого из классов онтологии.

Для сравнения этих вариантов рассмотрим простую онтологию, содержащую четыре класса -с1а^ч'Нитап, с1а^ч'Мап, classWoman, classChildren. Будем считать, что каждый из них имеет два экземпляра, за исключением родительского класса с1а^ч'Нитап. Каждый экземпляр класса обладает свойствами ртрег^уЫате и propertyAge.

Структура хранения данной онтологии на основе схемы «вертикальная таблица» представлена в таблице 1.

Таблица 1

table_Triples

Subject Predicate Object

classHuman subClassOf classThing

classMan subClassOf classHuman

classWoman subClassOf classHuman

classChildren subClassOf classMan

classChildren subClassOf classWoman

classHuman hasProperty propertyName

classHuman hasProperty propertyAge

instanceManl instanceOf classMan

instanceMan2 instanceOf classMan

instanceWomanl instanceOf classWoman

instanceWoman2 instanceOf classWoman

instanceChildl instanceOf classChildren

instanceChild2 instanceOf classChildren

instanceManl propertyName Andry

instanceMan2 propertyName Maxim

instanceWomanl propertyName Maria

instanceWoman2 propertyName Julia

instanceChildl propertyName Michael

instanceChild2 propertyName Regina

instanceManl propertyAge 35

instanceMan2 propertyAge 46

instanceWomanl propertyAge 45

instanceWoman2 propertyAge 33

instanceChildl propertyAge 16

instanceChild2 propertyAge 8

Реализация хранения данной онтологии на основе схемы «таблицы свойств классов» предполагает создание таблицы иерархии классов онтологии (табл. 2) и отдельных таблиц для каждого из классов (табл. 3-5).

Таблица 2

table_Hierarhy

ID Hierarhy subClass Class tableName

1 classHuman classThing

2 classMan classHuman table classMan

3 classWoman classHuman table classWoman

4 classChildren classMan table classChildren

5 classChildren classWoman table classChildren

Таблица 3

table classMan

ID_Man Name Age

1 Andry 35

2 Maxim 46

Таблица 4

table classWoman

ID_Woman Name Age

1 Maria 45

2 Julia 33

Таблица 5

table classChildren

ID_children Name Age

1 Michael 16

2 Regina 8

Примеры преобразования SPARQL^{SQL}

Рассмотрим возможные варианты трансляции SPARQL-запросов к онтологии в набор SQL-запросов в зависимости от используемой схемы БД на конкретных примерах и оценим влияние принятой схемы БД на сложность преобразования SPARQL^fSQL}.

Пример 1.

SELECT ?x {WHERE ?x a classMan} // Определение всех экземпляров класса

Преобразование SPARQL^fSQL} для схемы БД «вертикальная таблица» включает следующие шаги.

1. Определение всех подклассов класса classMan:

SELECT result1(subject) FROM table_Triples

WHERE (predicate='subClassOf AND object='classMan') OR (subject='classMan');

2. Выбор экземпляров классов, определенных на шаге 1 :

SELECT result2(subject) FROM table_Triples

WHERE predicate='instanceOf AND object=result1(subject);

3. Выбор значений свойств propertyName экземпляров, полученных на шаге 2:

SELECT result3(subject, object) FROM table_Triples

WHERE (subject= result2(subject)) AND (predicate='propertyName');

4. Выбор значений свойств propertyAge экземпляров, полученных на шаге 2:

SELECT result4(subject, object) FROM table_Triples

WHERE (subject= result2(subject)) AND (predicate='propertyAge');

5. Объединение результатов, полученных на шагах 3 и 4:

JOIN result3,result4 BY subject;

Аналогичное преобразование SPARQL^fSQL} для схемы БД «таблицы свойств классов» включает следующие шаги.

1. Выбор имен таблиц для класса classMan и его подклассов:

SELECT result1(tableName) FROM table_ Hierarhy

WHERE class='classMan' OR subClass= ='classMan';

2. Выбор значений свойств propertyName, propertyAge из таблиц, определенных на шаге 1:

SELECT result2(name, age) FROM resultl (tableName);

Пример 2.

SELECT ?name WHERE { ?x а classHuman. ?x propertyAge "35". ?x propertyName ?name}

// Определение объектов по значению свойства Преобразование SPARQL^(SQL) для схемы БД «вертикальная таблица» включает следующие шаги.

1. Определение всех подклассов класса classMan:

SELECT resultl(subject) FROM table_Triples WHERE (predicate='subClassOf AND object='classHuman') OR (subject='classHuman');

2. Выбор экземпляров классов, определенных на шаге 1:

SELECT result2(subject) FROM table_Triples WHERE predicate='instanceOf' AND object=resultl(subject);

3. Выбор среди полученных на шаге 2 экземпляров со значением свойства возраст, равным 35:

SELECT result3(subject,object) FROM table_ Triples

WHERE (subject= result2(subject)) AND (predicate='propertyAge') AND (object = '35');

4. Определение имени экземпляров, если результат шага 3 не пустой:

SELECT result4(object) FROM table_Triples WHERE (subject = result3.subject AND predi-cate='propertyName');

Аналогичное преобразование SPARQL^(SQL) для схемы БД «таблицы свойств классов» включает следующие шаги.

1. Выбор имен таблиц для класса classMan и его подклассов:

SELECT resultl(tableName) FROM table_ Hierarhy

WHERE class='Human' OR subClass='Hu-man';

2. Выбор экземпляров со значением поля propertyAge, равным 35, из таблиц, определенных на шаге 1.

SELECT result2(name) FROM resultl(table-Name)

WHERE age=35;

Пример 3.

SELECT ?x WHERE{ ?x subclassOf classHuman} // Определение классов потомком

Преобразование SPARQL^(SQL) для схемы БД «вертикальная таблица» содержит такой шаг, как выбор из таблицы триплетов всех подклассов класса classHuman.

SELECT resultl(subject) FROM table_Triples WHERE (predicate='subClassOf' AND object='classHuman');

Аналогично и преобразование SPARQL^ SQL} для схемы БД «таблицы свойств классов»: выбор из таблицы иерархии классов всех подклассов класса classHuman:

SELECT resultl(subClass) FROM table_Hie-rarhy

WHERE class='Human';

Оценки времени выполнения рассмотренных запросов на основе формул (5) и (10) в сопоставимых условных временных единицах представлены в таблице 6, где ВТ - вертикальная таблица, ТСК -таблица свойств классов. Анализ полученных результатов показывает, что трансляция SPARQL-запросов при втором подходе выполняется приблизительно в три раза быстрее. Время обработки последовательностей SQL-запросов во втором случае в два раза меньше.

Таблица 6 Временные затраты на выполнение SPARQL-запросов

Ус- Эталонный запрос Среднее

Этап ло- Пример Пример Пример значение

вие № 1 № 2 № 3

Ttrans ВТ 17 15 3 11,7

(в T') ТСК 5 5 2 4

Tsql seq ВТ 98 106 26 76,7

(в T") ТСК 44 52 30 42

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

Обратим внимание, что теоретические оценки хорошо согласуются с экспериментальными результатами, представленными в [5-7].

В заключение отметим, что предложенный подход к оценке временных затрат на выполнение SPARQL-запросов позволяет теоретически оценивать эффективность различных подходов к организации RDF-хранилищ и может служить основой для построения более точных теоретических оценок эффективности RDF-хранилищ.

Дальнейшие исследования должны быть направлены на изучение организации эффективных RDF-хранилищ, в частности, на определение рациональных схем БД для хранения онтологий и экспериментальную оценку эффективности предлагаемых подходов, на разработку новых архитектурных принципов построения хранилищ, комбинирующих достоинства различных подходов, а

также на оптимизацию выполнения SPARQL-запросов к хранилищам, обладающим определенной схемой БД.

Литература

1. Пузанков Д.В. [и др.]. Интеллектуальные агенты, мно-гоагентные системы и семантический Web: концепции, технологии, приложения. СПб: Изд-во «Технолит», 2008. 292 с.

2. Chebotko A. [et al.]. Semantics preserving SPARQL-to-SQL translation // Data & Knowledge Engineering. 2009. Vol. 68. Is. 10, pp. 973-1000.

3. Richard Cyganiak. A relational algebra for SPARQL. HP Labs, Bristol, 2005.

4. Velegrakis Yannis. Relational Technologies, Metadata and RDF. Semantic Web Information Management // Springer-Verlag Berlin Heidelberg, 2010, p. 41.

5. Theoharis Yannis, Christophides Vassilis, Karvounarakis Grigoris. Benchmarking Database Representations of RDF/S Stores // Springer-Verlag Berlin Heidelberg, 2005, pp. 685-701.

6. Yuanbo Guo, Zhengxiang Pan, and Jeff Heflin. An Evaluation of Knowledge Base Systems for Large OWL Datasets. Computer Science and Engineering Department, Lehigh University, Bethlehem, USA, 2004.

7. Hondjack Dehainsala, Guy Pierra, Ladjel Bellatreche. OntoDB: An Ontology-Based Database for Data Intensive Applications. Proc. Of Database Systems for Advanced Applications (DASFAA'2007) // Bangkok, Thailand, 2007.

УДК 681.3.07

ПАРАЛЛЕЛЬНЫЙ ВЫВОД В МЕТОДЕ АНАЛИТИЧЕСКИХ ТАБЛИЦ

В.Н. Вагин, д.т.н.; Зо Мьо Хтет

(Московский энергетический институт (технический университет), иадгп@оРРта^- ги)

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

Ключевые слова: аналитические таблицы, параллельный метод, фиктивная переменная, наибольший общий унификатор, подстановка.

Известно, что система дедуктивного вывода в общем случае недетерминирована, и поэтому проблема управления поиском вывода актуальна для построения решателей проблем. При выводе наблюдается экспоненциальный рост затрат на обработку огромного пространства поиска при решении задач практической сложности, а именно, увеличение объема хранимой информации и времени решения задачи. Одним из путей решения этой проблемы является параллелизм, который может быть реализован как мультипоиск и распределенный поиск [1, 2]. Стратегии мультипо-иска приписывают каждому параллельному процессу свой план поиска, в то время как стратегии распределенного поиска выдают каждому параллельному процессу свою порцию пространства поиска. Эти два подхода не являются взаимоисключающими, между ними имеется связь.

Говоря о стратегии поиска, прежде всего следует упомянуть о стратегиях, основанных на упорядочении (ordering-based strategies). Необходимо отметить, что среди них имеются стратегии, ориентированные как на расширение множества дизъюнктов для метода резолюции, так и на его сокращение путем поглощения. Упорядочение здесь понимается как наличие обоснованного порядка выражений, подлежащих процедуре поиска вывода. Стратегии, основанные на упорядочении, используют поиск только наилучшего (с примене-

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

Иной тип стратегий - стратегия редукции подцелей, реализованная в аналитических таблицах. Уже из названия ясно, что вычисление цели состоит в редукции ее подцелей и последующем их разрешении. Если в подходе, который основан на упорядочении, стратегии ограничивают поиск наложением локальных требований на каждый шаг вывода, то стратегии редукции подцелей ограничивают поиск наложением требований на саму форму вывода. Так, в методе аналитических таблиц происходит разложение формулы на подформулы и ищется их невыполнимость, как в методах опровержения. Эти стратегии по сути являются аналитическими.

Главное внимание в статье уделено параллелизму на уровне распределенного поиска. Ключевой фактор в классификации методов с параллельным поиском заключается в дифференциации и комбинировании активности дедуктивных процессов. Принцип разделения пространства поиска