CC BY
300
УДК 004.9, 004.5
П.А. Ломов, М.Г. Шишаев, В.В. Диковицкий
Институт информатики и математического моделирования Кольского НЦ РАН,
Кольский филиал ПетрГУ
УПРОЩЕННОЕ ПРЕДСТАВЛЕНИЕ OWL-ОНТОЛОГИЙ ДЛЯ ИХ ПРИМЕНЕНИЯ В ГРАФИЧЕСКИХ ПОЛЬЗОВАТЕЛЬСКИХ ИНТЕРФЕЙСАХ*
Аннотация
Визуализация и использование OWL-онтологий при разработке и функционировании на их основе пользовательских интерфейсов может требовать существенных затрат труда и времени разработчиков, а также наличия у них особых знаний и навыков работы с онтологиями, базирующихся на дескрипционных логиках. В статье предлагается технология создания для произвольной OWL-онтологии ее упрощенного представления, ориентированного на визуализацию в виде графовой структуры при разработке пользовательских интерфейсов программных средств. Рассматривается структура такого представления, а также порядок отображения в ней аксиом исходной OWL-онтологии.
Ключевые слова:
онтология, OWL, SKOS, SPARQL, интерфейс.
P.A. Lomov, M.G. Shishaev, V.V. Dikovitsky SIMPLIFIED REPRESENTATION OF OWL OF ONTOLOGIES FOR THEIR USE IN GRAPHIC USER INTERFACES
Abstract
Use of OWL ontologies as the base of graphical user interface of information systems and web resources is difficult work, which demand from the developer except programming skills some knowledge of ontology engeneering and description logics. The paper is devoted to technology of OWL ontology simplification and creating as the result the user presentation ontology, which could be derectly use as the base of graphical user interface. Structure of user presentation ontology and process of mapping of primary OWL ontology axioms to it are described.
Keywords:
ontology,OWL, SKOS, SPARQL, interface.
Введение
На сегодняшний день использование онтологий является ключевым аспектом в семантическом представлении и обработке информации. Круг технологий, связанных с применением онтологических моделей, весьма широк и включает в себя мультиагентные системы, автоматическое извлечение знаний из текстов на естественном языке, поиск информации, интеллектуальное аннотирование и другие. Как правило, онтологии рассматриваются как машинопонимаемые спецификации предметной области или задачи, которые позволяют обеспечить использование единой системы понятий людьми и/или программными агентами. В этой связи очень привлекательным является также
Работа выполнена в рамках проекта № 2.8 программы фундаментальных исследований ОНИТ РАН «Интеллектуальные информационные технологии, системный анализ и автоматизация».
использование онтологий при разработке и функционировании пользовательского интерфейса [1-4], что так или иначе предполагает визуализацию совокупности элементов онтологии, как правило, в виде графовой структуры. Это дает возможность пользователю оперировать известными ему понятиями, осуществлять интуитивно понятную навигацию между ними и итеративно формировать сложный запрос, внося в него дополнительные объекты поиска, определяя ограничения и не используя при этом каких-либо искусственных поисковых языков.
В то же время большую популярность, благодаря богатым выразительным свойствам и вместе с тем формальной разрешимости, получил язык веб-онтологий (OWL, Ontology Web Language). Предложенный и развиваемый консорциумом W3C, OWL на сегодняшний день является де-факто стандартом описания онтологий для их использования в Интернет. Однако онтологии, описанные с помощью данного языка (OWL-онтологии), являются, по сути, системой логических утверждений (аксиом) дескрипционной логики. В этой связи их визуальное представление в виде графовой структуры далеко не всегда тривиально и требует от разработчика, так называемого понимания онтологии (ontology comprehension) [5, 6], что может потребовать существенных усилий, а также взаимодействия с автором онтологии.
Целью данной работы является снижение трудоемкости визуального представления OWL-онтологий для их использования в качестве основы ГПИ информационных систем или веб-ресурсов. Преодолеть трудности, связанные с визуализацией OWL-онтологий, можно двумя способами. Первый заключается в упрощении OWL-онтологии при ее визуальном представлении, то есть учитывать только те аксиомы, которые могут быть представлены в виде вершин и ребер графа. Такой способ применяется в большинстве современных программных средств визуализации онтологий GraphViz [7], TGVizTab [8], OWLViz [9], OntoSphere [10]. Второй способ, напротив связан с излишним усложнением визуального представления, что затруднит его понимание пользователем.
Для устранения приведенных недостатков существующих подходов в данной работе предлагается технология создания для произвольной исходной OWL-онтологии ее упрощенной модификации - онтологии пользовательского представления (ОПП), визуализация которой в рамках ГПИ не требовала бы от разработчика сложного анализа исходной OWL-онтологии, но в то же время сохраняла ее семантику и тем самым позволяла формировать вложенные запросы. Рассматривается структура ОПП, а также порядок представления в нем системы OWL аксиом и формирование на ее основе поисковых запросов.
Онтология пользовательского представления
Ввиду того, что понятие онтологии может трактоваться достаточно широко, заметим, что в данной работе под OWL-онтологией понимается логическая теория, явно частично отражающая подразумеваемое значение формального словаря [13]. Формальный словарь образует множество классов или концептов, обозначающих понятия предметной области, и отношения (как правило, бинарные), определяемые между классами. С каждым классом и отношением сопоставляется функция интерпретации, отображающая класс во
множество объектов реального мира, а отношение - в декартовое произведение такого множества на самого себя. В OWL функции интерпретации задаются неявно через утверждения дескрипционной логики. Последние в свою очередь формально ограничивают множества интерпретации классов и отношений и, тем самым, частично определяют их семантику.
Таким образом, OWL-онтологию можно рассматривать как совокупность утверждений дескрипционной логики, задающих ограничения на множества интерпретаций классов и отношений. Полагается, что эти утверждения, (ввиду того, что формулируются специалистом предметной области) верно, отражают смысл понятий, поэтому их называют аксиомами, а онтологию, которую они составляют - логической теорией. Среди основных аксиом, определяющих формальную семантику понятий, можно выделить:
- аксиомы тождественности (equivalent-to), далее обозначаются знаком «=». Формально они определяют равенство множеств интерпретации классов. Например, ЭВМ = КОМПЬЮТЕР, декларирует то, что любая сущность, отнесенная к классу «ЭВМ», будет также отнесена к классу «КОМПЬЮТЕР» и наоборот;
- аксиомы наследования (subclass/superclass), далее обозначаются «с» и «з». Определяют вхождение множества интерпретации одного класса (подкласса) во множество другого (суперкласса). Например, «ЭВМ» с «ФИЗИЧЕСКИИ-ОБЪЕКТ» означает, что если сущность принадлежит к классу «ЭВМ», то она также будет отнесена и классу «ФИЗИЧЕСКИИ-ОБЪЕКТ», но не на оборот;
- аксиома несвязности (disjoint) классов, указывает на то, что множества итерпретации классов не пересекаются. Например, аксиома «ЭВМ» disjoint «МАШИНА» означает, что если сущность будет причислена к классу «ЭВМ», то она не будет входить в класс «МАШИНА» и наоборот;
- аксиома перечисления (enumeration), позволяет задать класс экстенсионально, то есть путем перечисления всех его экземпляров. Это предполагает, что данный класс не содержит других экземпляров, кроме, указанных непосредственно.
Для того чтобы использовать какую-либо OWL-онтологию в программных разработках или исследованиях следует ясно представлять интерпретации ее классов и отношений. В противном случае любая ее модификация может привести к появлению противоречивых аксиом и, как следствие, возможности получения неверных результатов ее логического анализа и ошибкам или сбоям в работе основанных на ней программ. В свою очередь проблема понимания онтологии (ontology comprehension), как это отмечено в работе [5], является на данный момент достаточно новой и требует дальнейшего исследования.
Для использования OWL-онтологии в качестве основы ГПИ предлагается формировать на ее основе более простую для понимания онтологию пользовательского представления (ОПП). ОПП должна быть изоморфна исходной онтологии в следующем (не строгом математическом) смысле: с одной стороны ОПП должна включать элементы исходной онтологии, существенные для визуализации в рамках ГПИ, и быть достаточно простой, для того чтобы ее визуализация являлась чисто технической задачей. C другой
стороны - набор ее элементов должен позволять формировать не только простые (поиск подклассов/экземпляров класса), но и вложенные запросы к исходной онтологии. Наряду с этим в нее также можно включить элементы, позволяющие отразить информацию о поисковых потребностях пользователя, и на ее основе определить предпочтительный способ визуального представления понятийной системы предметной области. Это позволит должным образом персонифицировать ГПИ и тем самым повысить удобство работы с ним конечного пользователя.
Разработку онтологии пользовательского представления (ОПП) имеет смысл производить не «с нуля», а взяв за основу какую-либо из уже существующих моделей представления знаний. Это облегчит создание ОПП, а также позволит при оперировании ее элементами использовать существующие для выбранной в качестве основы модели инструментальные средства.
С точки зрения авторов на роль такого основания подходит модель простой системы организации знаний (Simple Knowledge Organisation Scheme, SKOS). Ее основными элементами являются:
- концепт (Concept) - обозначает какое-либо понятие предметной области, близок по смыслу с классом или экземпляром класса в OWL;
- коллекция (Collection) - набор концептов, схожих по некоторому признаку;
- отношения «шире»/«уже» (broader/narrower) - вместе со своими транзитивными вариантами «broaderTransitive» и «narrowerTransitive» позволяют задавать иерархию на концептах, схожи с отношениями «подкласс»/«суперкласс» (subclass/superclass) в OWL;
- метки «prefLabel», «altLabel» и «hiddenLabel» - представляют основное, альтернативное и служебное наименование концепта.
Отношения семантической близости (Mapping relation) определяют различные варианты указания близости концептов, принадлежащих различным концептуальным схемам (Concept scheme). В OWL для этой цели используется аксиома тождественности (equivalentTo), указывающая на равенство множеств интерпретации классов.
Необходимо заметить, что сама модель SKOS описывается ее авторами языком OWL и представляет собой простую OWL-онтологию [12]. Ее категории элементов, такие как концепт (Concept), коллекция (Collection), концептуальная схема (ConceptScheme), представляются в виде OWL классов, а отношения между ними и различные описательные элементы в виде объектных отношений и аннотационных свойств OWL соответственно. Конкретные элементы SKOS модели представляются экземплярами, соответствующих OWL классов. Такое представление SKOS позволяет осуществлять взаимодействие с ней через те же программные интерфейсы, что ориентированы на работу с OWL-онтологиями, например, OWL API [13]. Кроме того, модель SKOS имеет статус рекомендации W3C, которая является куратором развития стандартов и технологий, используемых в сети Интернет.
Что же касается визуализации элементов SKOS, то в данном случае их совокупность достаточно просто представляется в виде графа, вершинами которого являются SKOS концепты, а дугами отношения между ними. В свою очередь для аксиом OWL, включающих пересечение, объединение, отрицания OWL классов, а также различные ограничения на свойства, определение соответствующих
элементов графа требует их предварительного анализа.
Таким образом, модель SKOS является удобной основой для построения из исходной OWL-онтологии изоморфной ей онтологии пользовательского представления.
Отображение в онтологии пользовательского представления элементов OWL-онтологий
Несмотря на то, что наборы элементов OWL и SKOS являются схожими, далеко не всегда OWL-онтологию можно непосредственно представить в виде модели SKOS. Главным образом это связано с тем, что язык OWL является более выразительным языком, чем язык модели SKOS. Поэтому при отображении синтаксических конструкций первого в конструкции второго неизбежно приходиться опускать некоторые элементы, тем самым обедняя семантику исходного выражения. Решения же вопроса о том, чем необходимо пожертвовать из исходного выражения следует принимать с учетом того обстоятельства, что из визуализации результата пользователь смог бы понять смысл понятия и смог бы составить запрос на поиск его экземпляров.
С точки зрения способов представления в SKOS аксиомы OWL разделим на две группы - простые и составные. Простые аксиомы имеют в правой части один именованный или неименованный класс, определенный ограничением на одно свойство, а составные - несколько именованных и/или неименованных классов. Для ясности заметим, что в языке OWL неименованным или анонимным является класс, не имеющий интернационализированного идентификатора ресурса (IRI, Internationalized Resource Identifier) и заданный через ограничение его экстенсионала, например, в виде объединения, пересечения классов, ограничений на свойство, а также их комбинаций. Простые аксиомы могут быть непосредственно представлены в виде совокупности элементов SKOS модели, тогда как в случае составных необходим их предварительный анализ. В ходе такого анализа происходит выявление компонентов аксиомы, значимых при визуализации, а также определение соответствующих им совокупностей элементов модели SKOS (рис. 1).
Рис. 1. Представление в SKOS и визуализация: a) простых; б) составных аксиом OWL
Исходя из изложенного, определим общий порядок формирования ОПП на основе исходной OWL-онтологии, состоящий из следующих шагов:
1. Обработка машиной логического вывода исходной онтологии и сохранения в ней выведенных утверждений в явном виде.
2. Создание для каждого именованного класса исходной OWL-онтологии, соответствующего SKOS-концепта в ОПП.
3. Задание отношений иерархии на множестве полученных концептов ОПП путем определения между ними транзитивных отношения SKOS «шире» (broaderTransitive), в соответствии с иерархией между именованными классами исходной OWL-онтологии.
4. Создание для каждого свойства в исходной OWL-онтологии аналогичного свойства в ОПП.
5. Определение принадлежности свойств к классам в исходной OWL-онтологии и привязка соответствующих свойств в ОПП к SKOS концептам.
6. Анализ оставшихся сложных аксиом в формальных определениях классов и свойств в исходной OWL-онтологии и их представление в ОПП.
Начальная обработка исходной онтологии машиной вывода позволит производить последующий ее анализ с учетом выведенных утверждений, которые являются не менее важными при визуализации, чем определенные явно. Шаг 5 необходим ввиду возможного наличия неименованных классов в областях значений и/или определений свойств, так как в модели SKOS отношение может быть привязано только к SKOS концептам, которые соответствуют именованным классам OWL-онтологии. Рассмотрим принципы разбора и визуализации составной аксиомы на примере аксиомы:
СЕРВЕР е= ЭВМ п (>4имсстМодульПамяти.(ООЯЗ п 3 имеет Объем.ЮB) и 3 и мс ст П |ю и з во д итс л я. 8с г\ с гС о гр).
Опуская формальную сторону можно сказать, что она определяет понятие «Сервер» как ЭВМ, которая либо имеет не менее 4 модулей памяти типа DDR3 и объемом 1 гигабайт, либо произведена некоторой фирмой {^^г^ф». Исходя из этого, можно предположить, что поиск экземпляров данного класса в исходной онтологии можно производить двумя способами:
- искать среди экземпляров класса «ЭВМ» те, что имеют отношения принадлежности с экземплярами, представляющими необходимые модули памяти;
- искать среди экземпляров класса «ЭВМ» те, что имеют отношение «имеетПроизводителя» с экземплярами класса «ServerCorp».
Визуальное представление данных альтернатив даст возможность пользователю легко интерпретировать смысл понятия и сформулировать критерии поиска экземпляров данного класса в исходной онтологии. Рассмотрим далее подробно разбор данной аксиомы и ее представление в ОПП. Введем понятие «Субаксиома», которым будем обозначать часть какой-либо аксиомы, заданной именованным или неименованным классом, а также их комбинацией. Разложим аксиому на несколько субаксиом, приведя ее предварительно к дизъюнктивной нормальной форме. В этом случае аксиома будет состоять из одной или нескольких субаксиом, соединенных дизьюнкцией (рис. 2).
Рис. 2. Разделение аксиомы на субаксиомы
Каждая субаксиома определяет альтернативные способы трактовки смысла некоторого понятия, а также разные способы поиска экземпляров, соответствующего ему класса. Субаксиомы представляются в виде SKOS концептов, которые связываются отношением «related» со SKOS концептом, соответствующим именованному классу, определяемому ими. Имя SKOS концепта, представляющего субаксиому (далее SKOS концепт-субаксиома) формируется путем конкатенации имен, входящих в субаксиому классов. В нашем примере (рис. 3) имена концептов будут иметь вид «ЭВМ - имеетПроизводителя» и «ЭВМ -имеетМодульПамяти». В свою очередь аксиому целиком представим как именованную SKOS коллекцию, членами которой будут соответствующие SKOS концепты-субаксиомы. В качестве имени такой коллекции назначается имя класса, определяемого аксиомой.
Рис. 3. Пример представления аксиомы в виде SKOS концептов-субаксиом
С каждой субаксиомой связывается также список свойств, который составляют свойства, присущие классам, входящим в нее. Если в субаксиоме присутствует неименованный класс, заданный в виде ограничения на свойство, то его следует рассматривать как именованный, которому присуще данное свойство. Рассмотрим пример привязки свойств к субаксиоме (рис. 4).
В данном случае в исходной OWL-онтологии производится поиск аксиом, задающих объектные и типизированные свойства, у которых в область определения входит класс «ЭВМ». Найденные свойства «привязываются» к концепту-субаксиоме. Далее рассматривается неименованный класс «3имеетПроизводителя.
8егуегСогр», который определяет сущности, имеющие хотя бы одно отношение «имеетПроизводителя» с сущностями, отнесенными к классу «8егуегСогр». Данный неименованный класс рассматривается как именованный «имеетПроизводителя» с присущим ему свойством «имеетПроизводителя», которое также добавляет в список свойств концепта-субаксиомы.
Рис. 4. Разбор субаксиомы
Заметим также, что для прикрепляемых свойств рекурсивно запускается анализ их области значения (property range), которую также может определять простая или составная аксиома. В случае простой аксиомы, включающей только один именованный класс, рекурсия завершается, а SKOS концепт, соответствующий классу в области значений, связывается со свойством. В противном случае аксиома в области значений разбивается на субаксиомы, каждая из которых привязывается к свойству как альтернативное значение. Для субаксиом в свою очередь также запускается процесс поиска присущих им свойств (рис. 5).
Субакс. 1: ЭВМ п >4имеетМодульПамяти.(00РЗ п Зимеет0бъем.1СВ)
Анализируем область значений свойства «имеетМодульПамяти» как сложную аксиому
// имеетОбъем —С 16В-сарасКу
Рис. 5. Разбор аксиомы в области значений (property domain) объектного OWL свойства
Заметим, что концепты SKOS, созданные в процессе анализа областей значений прикрепленных свойств, также включаются в SKOS коллекцию, представляющую исходную анализируемую аксиому. В рассматриваемом примере такой SKOS коллекцией является коллекция «Сервер» (рис. 5).
Далее рассмотрим представление в ОПП основных видов аксиом (тождественности, наследования, несвязности и перечисления) для задания OWL классов. Аксиомы тождественности, определяющие классы, представляются в виде отношения SKOS «related» между SKOS концептом, соответствующим OWL
классу, и с субаксиомами, как это было показано ранее (рис. 3). Аксиомы наследования, если являются простыми и включают один именованный класс, то представляются иерархическими транзитивными SKOS отношениями «шире» (broaderTransitive) и «уже» (narrowerTransitive). Если они являются составными, то анализируются и представляются также как аксиомы тождественности.
Если при задании OWL класса использована аксиома несвязности, то ее можно рассматривать как аксиому тождественности, включающей отрицания, которая представляется в ОПП способом, представленный на рис. 6.
ЭВМ
Рис. 6. Представление аксиомы разделения (disjoint)
Что касается классов, заданных путем перечисления, то они представляются в ОПП аналогично именованным классам, заданным с помощью аксиомы «equivalent-to», то есть в виде SKOS концептов, с которыми связываются отношением «related» SKOS концепты, соответствующие перечисляемым экземплярам данного класса.
Рассмотренный порядок в данном разделе, представления OWL-онтологии в ОПП, позволяет явно отразить в последней семантику OWL аксиом в виде совокупностей SKOS элементов. Визуализация всей ОПП сводиться к отображению в виде графовой структуры SKOS концептов и отношений между ними. При общем отображении онтологии можно скрыть концепты, которые являются членами каких-либо SKOS коллекций, ввиду того, что они соответствуют неименованным OWL классам исходной онтологии, и их отображение усложнит понимание структуры онтологии. При выборе же конкретного SKOS концепта имеет смысл отобразить их, чтобы позволить пользователю получить более полное представление о понятии.
Формирование поисковых запросов на основе онтологии пользовательского представления
Основным средством формулировки запросов к массивам данных, представленным в модели RDF и в том числе OWL-онтологиям, а также протоколом для передачи ответов на такие запросы в рамках инициативы Semantic web является SPARQL (Protocol and RDF Query Language). Принимая во внимание, что ОПП будет использоваться как основа ГПИ, необходимо обеспечить возможность формирования SPARQL запросов на ее основе к исходной OWL-онтологии.
Данный раздел посвящен описанию элементов языка OWL и SKOS, используемых для хранения информации, необходимой для формирования запроса, а также общий порядок его компоновки. Заметим, что рассматривается формирование SPARQL запросов типа «SELECT», нацеленных на извлечение
данных из массива RDF в виде подграфов - наборов элементов, связанных между собой отношениями. Такие подграфы также называют решениями (Solutions).
Рассмотрим принципы формирования запроса на основе представления в ОПП понятия «Сервер» (рис. 7).
Представление понятия в ОПП:
имеетЦ'ену
Число
имеетМодель
Строка
TFPRFP —^''1 • ; •
1 related- - ЭВМ - имеетПроизводителя \ ServerCorp
Переменные и фрагменты запроса:
/ ч- /
і ?имеетЦену
г «http://ontology.owl#MM00TLleHy
7СЕРВЕР
7СЕРВЕР rdf:type «http://ontology.owl#CepBep»
7СЕРВЕР
І ?имеетМодель /
і «http://ontology.ovy#HMeeTMoflenb
1 v-
?ServerCorp
?ServerCorp rdf:type «http://ontology.owl#ServerCorp»
«Мр://оп1оІоду.о\/і/І#имеетПризводителя
7CEPBEP rdf:type «http://ontology.owl#3BM» - -
Итоговый запрос:
1. SELECT DISTINCT ?CEPBEP ?имеетЦену ?имеетМодель FROM http://ontology.owl WHERE
С
{
OPTION {7CEPBEP <http://ontology.owl#HMeeTl4eHy> ?имеетЦену .} OPTION {7CEPBEP <http://ontology.owl#HMeeiMoflenb> ?имеетМодель. } 7CEPBEP rdf:type <http://ontology.owl#CepBep> .
9. }
10. UNION
11. {
12. OPTION {7CEPBEP <http://ontology.owl#MMeeTL|eHy> ?имеетЦену .}
13. OPTION {7CEPBEP <http://ontology.owl#HMeeTMoflenb> ?имеетМодель. }
14. ?CEPBEP rdf:type <http://ontology.owl#3BM>>. ‘
15. ?CEPBEP <ЬНр://оп1о1оду.ош(#имеетПризводителя> ?ServerCorp.
16. ?ServerCorp rdf:type <http://ontology.owl#ServerCorp>. }}
Рис. 7. Формирования запроса на основе ОПП
Запрос формируется программным модулем - компоновщиком запроса, которому передаются элементы ОПП, выбранные пользователем с помощью ГПИ. Компоновщик в свою очередь формирует запрос из фрагментов и SPARQL переменных, которые были сгенерированы и сопряжены с элементами ОПП на этапе отображения в нее исходной OWL-онтологии в виде аннотационных свойств (Annotation property) языка OWL. Генерация переменных происходит по следующим правилам:
- для SKOS концепта, соответствующего именованному классу, SPARQL переменная определяется, как сокращенный IRI. Наряду со SKOS концептом сопрягается фрагмент запроса, определяющий соответствующий ему
l9
именованный класс. Например, SKOS концепту, представляющему
именованный класс с IRI <http://ontology.com#СЕРВЕР> будет соответствовать переменная ?СЕРВЕР и фрагмент запроса: ?СЕРВЕР rdf:type
<http://ontology.com#СЕРВЕР>;
- для SKOS концептов, соответствующих субаксиомам, определяется такая же переменная, что и для SKOS концептов, с которыми они связаны отношением «related», а фрагмент запроса может содержать несколько строк, определяющих все именованные классы, входящие в субаксиому;
- с объектными свойствами переменные не сопрягаются, а в качестве фрагмента запроса выступает IRI свойства. В этом случае, формирование строки запроса, определяющей объекта-носителя свойства и объекта-значения, является задачей компоновщика;
- для типизированных свойств переменная определяется аналогичным способом, что и для SKOS концептов, то есть как сокращенный IRI свойства. В запросах она будет использоваться для хранения конкретного значения свойства. В качестве фрагмента запроса, как и в случае объектных свойств, будет выступать полный IRI типизированного свойства.
Сформированный компоновщиком запрос может содержать внутри части WHERE несколько секций, между которыми указывается ключевое слово «UNION». Далее будет называть их UNION-секциями. UNION-секции представляют разные способы поиска экземпляров в соответствии с теми субаксиомами, которые выбрал пользователь. Результаты, полученные в ходе выполнения различных способов поиска, объединяются. Например, на рис. 7 в запросе определено 2 способа поиска экземпляров, как членов класса «Сервер» (строки 5-9) и как членов класса «ЭВМ», имеющих отношение с экземплярами класса «ServerCorp» (строки 11-17). При выборе каждой дополнительной субаксиомы пользователем компоновщик будет подставлять в запрос дополнительную UNION-секцию, «соединяя» ее с предыдущей ключевым словом «UNION». Заметим, что различные способы поиска могут вернуть одинаковые результаты. Для предотвращения этого в часть «SELECT» подставляется модификатор запроса «DISTINCT» (строка 1), предотвращающий дублирование.
В ходе формирования запроса пользователь, помимо способов поиска, также определяет данные для представления в результате выполнения запроса. Таковыми могут являться значения типизированных свойств и IRI экземпляров, к которым они привязаны. В этом случае компоновщик добавляет SPARQL переменные, соответствующие значениям типизированных свойств и экземплярам, в часть «SELECT», а также добавляет одинаковые секции «OPTION» (далее OPTION-секции), реализующие получение искомых значений свойств, во все UNION-секции. Заметим, что ключевое слово «OPTION» указывает на то, что указанное после него условие необязательно должно быть удовлетворено, то есть если для некоторого подграфа-решения оно не выполняется, то такой подграф все равно будет являться одним из результатов выполнения запроса. Для наглядности рассмотрим пример на рис. 7. В данном случае пользователь выбрал SKOS концепт для поиска экземпляров соответствующего ему класса исходной OWL-онтологии. В ответ на это компоновщик добавил переменную «?СЕРВЕР», сопряженную со SKOS концептом «СЕРВЕР» в часть «SELECT» (строка 1). Наряду с этим пользователь
выбрал для отображения значения типизированных свойств «имеетЦену» и «имеетМодель» у найденных экземпляров. Компоновщик в свою очередь добавил в часть «SELECT» переменные ?имеетЦену и ?имеетМодель (строка 1), а в UNION-секции одинаковые наборы строк (строки 6-7 и 12-13). Использование модификатора «OPTION» в данном случае позволит представить информацию об экземплярах, для которых, например, определена только цена, а указание модели отсутствует и наоборот.
Наряду с данными для представления пользователь при формировании запроса может также указывать дополнительные ограничения поиска в виде требования наличия отношения между объектами запроса, а также наличия у объекта запроса типизированного свойства с некоторым значением. Компоновщик в этом случае определяет SPARQL переменные, которые соответствуют элементам ОПП, определяющим область определения и область значения объектного или типизированного свойства и формирует строку запроса. Например (рис. 7), в ответ на выбор отношения «имеетПризводителя» и SKOS концепта «ServerCorp» компоновщик во второй UNION-секции сформировал фрагмент запроса (строки 15-16), ограничивающий выборку экземпляров теми, которые имеют отношение «имеетПризводителя» c экземплярами класса «ServerCorp».
Следует заметить, что рассмотренные в данном разделе принципы также применяются и для формирования вложенных запросов. Например, если бы пользователь в запросе (рис. 7), выбрал бы концепты-субаксиомы для «ServerCorp», то во второй UNION-секции (строки 11-17) были бы заданы вложенные UNION-секции, соответствующие способам поиска экземпляров класса «ServerCorp».
Программная реализация предложенной онтологии
Для практического применения представленной в работе технологии было разработано программное средство, осуществляющее преобразование произвольной OWL - онтологии в ОПП и визуализацию последней в виде графовой структуры. Разработка программного средства была выполнена на языке программирования JAVA в интегрированной среде разработки Eclipse. Программное средство включает модуль создания ОПП - ontologyConverter (рис.8) и ее визуализации - upo2Prefuse.
Модуль upo2Prefuse осуществляет графическое представление полученной в результате ОПП. Данный модуль использует в своей работе фреймворк для получения интерактивной визуализации данных Prefuse, а также java-библиотеку OWL2Prefuse -конвертер OWL-онтологии в структуры данных Prefuse.
£j| Axiom ^jjSubAxIom
Q ахТуре: AMomType<OVVLA){.orn> QisCGI: Boolean QlSdeOfAs Affaybst<SuMMOcn> QontOWL: Ontology QontUPO: llserPresenOnt Q rS«deOfA)C ArrsyL<Sl< SubAxoro5' QralatonTypelRI IRI Studi QcfeLfet ArrayLst<OWLClass> Q SComp*ex: Boolean QontOWL: Ontology QontUPO: имгРгемпОп* Q sparqKJueiyPart: String Q sparqiVar String Q title: String
АхютО Q addSubaxToListf) Q getSriesOfAwoml) Ц рагЮ1А:«отТоО^РГ) ГУ Su№»om[) Ц SutAMOmC) Щ SutAj«m[) Щ ®Compte*:SubAx:[)
3UI\
£2
ion
Studio ev:
AX_COMP: String AX_SIMPLE: Sirtng IRI.OWL String IRI_RDF: Sting IRI_RDFS: Strirg UPO_H*S_TYPE: String UPO_IRI:Sfmg
UPO„NEGATION_LA BE LJTBH PLATE: String UPO_SPARQL_Q UERY_FRAG MENT_LAB EL: Strir llPO_SPARQL_VARIABLE_LABEL: Stung UPO_TEM PLATE JRI_OF_COML EX SB AXIOM: Stri UPO_TEM PLATE J Rl_0 F_DAТА RANGE: String UPO_THING: Sting UPO_TITLE_LABEL: Stung
A
jjrj Sim pleSubAxi om
FJ SimptoSubMomO Ц SimpteSubAjwmf)
getConoepWfSubAxitimFi'omUPOO Ц gst C'j-hklI OfSj uA w F -<j - U P OuylRI ч H ±k- iL
Ц getSpafqiQiiefvPMOiSiibA>5om| юглСопсер!:;
Q getSparqWarOfSuCAxomF rcm Concept ()
Ц getTi IteOfSu bAsom Fro mConcepli)
CjJComplexSubAxlom
Ц «Negation Boolean
Comp texS ub Axomf)
ackJToFfpLftt()
addTo Subeof ropLfetJ)
getDataPrpopertyResfrction RANGEQ
getDatatypePfopeitieaCifMamedCiassO
get I в rator О f Data P гор erty Listf)
getlleratorOfOtJiectPropertyListO
get I lerator О fppFromAxUsty)
getNameddeaaFromExpQ
getO tpctP ropertiesOfNamedC la&si)
getObjectPrpoperty Restrict on RANGED
getSparqiQueryPartO
gatsparqruar()
gatsparqruar()
getTrtteOfSuhAwomO
1a
УивегР
Q jsedSua-q Va-Na'-
CJ UserPresenQntQ □ UserPresenQntO Q acklConosoToUP Q а11Г:пплег«ГОиП Q a,±JDa1a"y;KPoo
BaddDatatypeRangil
addOb^ctPropertj П ackJSybAjromToU Щ change Base IRK)
Й change Base IRI() getConceptBylRlir gatsnortlRH)
Щ gatShortlRll )
enOrrt
iSomCounler int es: HashSet<String>
prtyTolJPOli
ToUPOO
ToUPOO
>O0
AnnotationVaine))
Рис. 8. Диаграмма классов java-пакета ontologyConverter
Визуальное представление тестовой OWL-онтологии, полученное в результате ее обработки с помощью разработанного программного средства, представлено на рис. 9.
Рис. 9. Визуализация тестовой онтологии с разработанного программного средства
При сравнении с результатами визуализации той же онтологии с помощью плагина OntoGraph (рис. 10) можно отметить наличие представления составных аксиом, а также неявных отношений между классами, которые следуют из таких аксиом.
Рис. 10. Визуализация тестовой онтологии с помощью инструмента OntoGraph
Таким образом, можно сделать вывод о том, что предлагаемая технология позволяет получить более полное графическое представление OWL-онтологии, а соответственно более функциональный графический интерфейс на ее основе.
Заключение
В данной работе рассмотрена технология создания для OWL-онтологии ее упрощенной модификации - онтологии пользовательского представления (ОПП), направленной на непосредственную визуализацию ее элементов в рамках ГПИ. В качестве основы ОПП используется модель SKOS, совокупности элементов которой могут быть легко представлены в виде графовой структуры. Основное внимание в статье уделено процессу разбора и отображения основных видов аксиом исходной OWL-онтологии в ОПП. Авторы полагают, что предлагаемая технология создания и использования ОПП позволит упростить проектирование и разработку ГПИ информационной системы или веб-ресурса, в основе которого используется сложная OWL-онтология предметной области, за счет отсутствия необходимости анализа составных аксиом и определения способа их визуализации.
К основным направлениям дальнейшей работы можно отнести исследование возможностей хранения в ОПП данных о поисковых потребностях пользователя, а также определение с их учетом различных способов визуального отображения элементов ОПП. Это позволит специфицировать представление знаний об одной или нескольких предметных областях для конкретных пользователей в соответствии с их задачами, что является особенно важным для мультипредметных веб-ресурсов, в которых могут использоваться несколько онтологий с большими системами понятий.
ЛИТЕРАТУРА
1. An Ontology-based Visual Tool for Query Formulation Support / T. Catarci и др. // In Proceedings of the 16th European Conference on Artificial Intelligence, 2004.
2. Guiding the user: An ontology driven interface / S. Bechhofer и др. // UIDIS, 1999. -pp.158-161.
3. Feikje, H. Evaluating an Ontology-Driven WYSIWYM Interface / H. Feikje, M. Chris, E. Peter // Proceedings of the 5th International Conference on Natural Language Generation, 2008. -pp.138-146.
4. Грибова, В.В. Управление проектированием и реализацией пользовательского интерфейса на основе онтологий / В.В. Грибова, А.С. Клещев // Проблемы управления, 2006. -№2. -С.58-62.
5. Bergh, J. R., Ontology comprehension / J.R. Bergh //University of Stellenbosch, Master Thesis, 2010.
6. Bauer, J. Model exploration to support understanding of ontologies / J. Bauer // Master’s thesis, Technische Universitat Dresden, 2009.
7. Graphviz. Open source graph drawing tools proceedings / J. Ellson и др. // Graph Drawing, 2002. - pp.483-484.
8. Ontology visualization methods - A survey / A. Katifori и др. // ACM computing surveys, 39(4):10, 2007.
9. Alani, H. TGVizTab: An Ontology Visualisation Extension for Protege / H. Alani // Knowledge Capture 03 - Workshop on Visualizing Information in Knowledge Engineering Sanibel Island, FL: ACM (2003). - рp.2-7.
10. Bosca, А., OntoSphere: More than a 3D ontology visualization tool / A. Bosca, D. Bonino, P. Pellegrino. // In SWAP, the 2nd Italian semantic web workshop, 2005.
11. Guarino, N. Formal Ontology and Information Systems/ N. Guarino // Proc. 1st Int’l Conference on Formal Ontology in Information Systems, 3-15. IOS Press/Ohmsha, 1998.
12. Jupp, S., SKOS with OWL: Don't be Full-ish! / S. Jupp, S. Bechhofer, R. Steens.
- Режим доступа:
http://www.webont.org/owled/2008/papers/owled2008eu_submission_22.pdf
13. Bechhofer, S. Cooking the Semantic Web with the OWL API / S. Bechhofer, P. Lord, R. Volz // In 2nd International Semantic Web Conference, ISWC, volume 2870 of Lecture Notes in Computer Science, Sanibel Island, Florida, October 2003. Springer.
Сведения об авторах
Ломов Павел Андреевич - к.т.н., младший научный сотрудник,
е-mail: [email protected]
Pavel A. Lomov - Ph.D. (Tech. Sci.), junior researcher
Шишаев Максим Геннадьевич - д.т.н., зав. лабораторией,
е-mail: [email protected]
Maksim G. Shishaev - Dr. of Sci (Tech.), head of laboratory
Диковицкий Владимир Витальевич - стажер-исследователь, е-mail: dikovitsky @iimm. kolasc.net.ru Vladimir V. Dikovitsky - junior researcher
