Научная статья на тему 'Редактор онтологий для онтологоуправляемой информационной системы'

Редактор онтологий для онтологоуправляемой информационной системы Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
189
52
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему «Редактор онтологий для онтологоуправляемой информационной системы»

УДК 681.3

РЕДАКТОР ОНТОЛОГИИ ДЛЯ ОНТОЛОГОУПРАВЛЯЕМОИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

Грегер Сергей Эдуардович, доцент, Уральский федеральный университет имени первого

Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия.

Нижний Тагил, segreger@gmail.com

Ахметов Даниил Равилевич, студент, Уральский федеральный университет имени первого

Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия.

Нижний Тагил, dan1@liveinternet.ru

На VI конференции “Объектные системы - 2012” нами был представлен доклад на тему: “Редактор метамодели онтологической системы” [1] в котором рассматривалась возможность построения корпоративных порталов на основе CMS Plone с использованием онтологических моделей. Главной особенностью CMS Plone является использование в качестве хранилища контента объектной базы Zope Object Database (ZODB). Таким образом, целью разработки являлось создание редактора онтологий, хранимой в объектной базе ZODB. Перед нами стояла задача создать редактор, управляющий графом объектов и отображающий структуру графа в иерархическом виде.

Для хранения онтологии в объектной базе данных был разработан набор компонент, обеспечивающих представление концептов языка OWL, таких как Class, Data Property, Object Property и их атрибутов [2]. Для хранения индивидов онтологии был использован компонент Individual. Использование таких компонент позволило эффективно хранить онтологию и реализовать выполнение запросов к онтологии. При создании и модификации элементов онтологии сервер запросов манипулирует объектами указанных классов, используя средства управления объектной базы данных ZODB.

К разрабатываемому приложению были предъявлены следующие требования:

1. Редактор должен обладать возможностью загружать и визуализировать любую, представленную на языке OWL, онтологию.

2. Редактор должен предоставлять пользователю дружественный интерфейс, позволяющий быстро создавать и редактировать концепты онтологии.

3. Редактор должен предоставлять гибкий поисковый механизм, позволяющий легко искать и редактировать концепты онтологии.

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

Перечислим основные недочеты предшествующей разработки:

1. Элементы онтологии представлены в виде каскада раскрывающихся списков (дерева), однако такой подход не позволяет увидеть связи между несколькими элементами онтологии.

2. При использовании онтологий больших размеров, редактор показывает очень низкую производительность, связанную с тем, что загружает все данные об онтологии при первом же обращении. Помимо нецелесообразного расходования оперативной памяти, происходит генерация очень большого количества html-разметки, что негативно сказывается на производительности браузера.

3. При изменении или добавлении новых элементов в онтологию происходит полная перезагрузка страницы, после чего данные об онтологии вновь загружаются в оперативную память, и генерируется html-разметка. В процессе моделирования, скорость заполнения онтологии пользователем довольно низка.

4. Не предусмотрены возможности совместной работы над онтологией.

Рассмотрим возможные пути устранения этих недочетов:

1. Для устранения первого недочета было решено добавить несколько дополнительных видов отображения онтологии. Так как онтология представляет собой граф, логично

80

было предложить возможность визуализации элементов онтологии в виде графа (рис. 1):

Попутно, существующее представление в виде дерева было переработано и разделено на 2 подвида (разделенный и обобщенный):

• Разделенный вид. Представляет собой 3 раскрывающихся дерева (на основе вложенных списков), расположенных во вкладках («Classes», «Properties», “Individuals”). Каждое дерево отображает только элементы определенного концептуала.

Вкладка “Classes”

Вкладка “Properties” Ontology Manager

Ontology Manager

^DisplayObject ^ Movie * ^ Bitmap

^ InteractiveObject : *■ ^ DisplayObejctContamer

: : p-1^ Loader

: : !~ u Sprite

‘ ^ Simple Button

: d- JTextField

^ Shape ^Static Text

[Save Ontology]

Вкладка “Individuals” Ontology Manager

[Save Ontology]

Рис. 2 - Раздельный вид

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

• Обобщённый вид. Совмещает в одном дереве все концептуалы и представлен на рисунке.

81

Ontology Manager

4- & Thing j i~ & First

j f Second

| | 4- ’sLj SubSecond

| | 4- £3 SubSecond-2

i 4- Thinglndividual

4- 'Лк Thinglndividual

Рис. 3 - Обобщённый вид

2. Для разрешения второго недочета было решено ещё более активно использовать технологию AJAX. Поскольку любая онтология имеет иерархическую структуру, то при первом обращении к странице представления онтологии можно отображать только родительские элементы, а при развертывании одного из родительских элементов производится асинхронный запрос на сервер. После чего сервер отправляет клиенту информацию о потомках родительского элемента в формате JSON — это в значительной степени повышает производительность, как сервера, так и клиента.

3. Для решения проблемы динамического добавления и изменения элементов онтологии также использовалась технология AJAX. Предлагается 2 режима разработки онтологии: “Online” и “Offline”. Режим “Offline” предполагает работу над онтологией в оперативной памяти клиента. После окончания исправлений пользователь при нажатии на кнопку “Save Ontology” отправляет запрос с информацией обо всех измененных узлах на сервер, а тот в свою очередь производит соответствующие изменения в базе данных. Режим “Online” подразумевает, что при изменении, добавлении или удалении узла онтологии в оперативной памяти клиента производится изменение информации о текущем узле, а также на сервер отправляется соответствующий запрос на изменение информации об узле уже в объектной базе сервера. Вследствие проделанных действий в оперативной памяти клиента изменяется только лишь определенный узел, и перестраивать иерархическую структуру онтологии заново не приходится.

4. Для получения возможности совместной разработки онтологии пригоден только описанный выше режим «Online», поскольку в режиме «Offline» невозможно отслеживание состояния редактирования, вследствие чего возникнут ситуации перезаписи данных и прочие неприятные случайности. Ситуация с режимом «Online» обстоит лучше, однако необходимо постоянно отслеживать состояние редактирования и если один из пользователей пытается получить доступ к редактируемому элементу, то необходимо временно заблокировать доступ к данному объекту.

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

Литература

1. Грегер С.Э. Редактор метамодели онтологической системы // Объектные системы - 2012: материалы VI Международной научно- практической конференции (Ростов-на-Дону, 10-12 мая 2012 г.) / Под общ. ред. П.П. Олейника. — Ростов-на-Дону: ШИ ЮРГТУ (НПИ), 2012. — с. 88-92.

2. Сковородин Е.Ю. Грегер С.Э. Построение онтологического портала с использованием объектной базы // Объектные системы - 2010: Материалы I Международной научнопрактической конференции. — Ростов-на-Дону, 2010 г. — с. 74-78.

82

УДК 004.651.54/004.652

СИСТЕМЫ МАТРИЧНЫХ УНИВЕРСАЛЬНЫХ ОБЪЕКТНО-РЕЛЯЦИОННЫХ БАЗ

ДАННЫХ

Микляев Иван Александрович, канд. физ.-мат. наук, доцент, Филиал Северного (Арктического) федерального университета в Северодвинске “СевмашВТУЗ”, Россия, Северодвинск,

Ivanmia1@rambler.ru

Введение

При рассмотрении условий работы в системе МЧС на первый план выходят условия неопределённости основного места источника информации, т.к. место происшествия нельзя определить заранее. Т.к. каждое происшествие особенно по-своему, то неопределённость структуры информации налицо. С другой стороны, предъявляются максимальные требования по скорости и полноте передаваемой информации для формирования управленческого решения, поэтому требуется максимально быстро и максимально подробно получить информацию с места происшествия.

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

В центре, куда стекается информация, она должна быть максимально структурирована и нормализована, что является необходимым требованием автоматизированной обработки.

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

Очевидным решением в данной ситуации является использование объектноориентированных информационных систем, с динамическим расширением структуры.

Примеры систем, предназначенных для решения подобных задач, представлены на основе матричной универсальной объектно-реляционной базы данных [1].

1. Универсальное приложение для работы с МУОРБД

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

После запуска основной программы развёртывается МУОРБД со всем своим инструментарием, которая по умолчанию располагается в директории рядом с программой, либо в месте указанном пользователем.

Пользователь может приступать к работе в МУОРБД сразу после запуска программы, без какой-либо дополнительной подготовки или каких-либо дополнительных настроек.

Универсальное приложение для работы с МУОРБД представляет собой всего две формы: форма администрирования МУОРБД и рабочая форма [1].

Форма администрирования МУОРБД предназначена для управления метаданными.

Рабочая форма универсального приложения МУОРБД таблиц предназначена для работы с основными данными МУОРБД.

2. Универсальный сервер универсального приложения МУОРБД

Универсальное приложение переходит в режим сервера выбором соответствующего пункта меню, после чего оно готово отвечать на запросы клиентских приложений.

Система взаимодействия сервера и клиентского приложения определяется внешним файлом параметров у клиентского приложения, в котором находится лишь местонахождение

83

i Надоели баннеры? Вы всегда можете отключить рекламу.