CC BY
52
УДК 681.3
РЕДАКТОР ОНТОЛОГИИ ДЛЯ ОНТОЛОГОУПРАВЛЯЕМОИ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Грегер Сергей Эдуардович, доцент, Уральский федеральный университет имени первого
Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия.
Нижний Тагил, [email protected]
Ахметов Даниил Равилевич, студент, Уральский федеральный университет имени первого
Президента России Б.Н.Ельцина, Нижнетагильский технологический институт (фил.), Россия.
Нижний Тагил, [email protected]
На 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
СИСТЕМЫ МАТРИЧНЫХ УНИВЕРСАЛЬНЫХ ОБЪЕКТНО-РЕЛЯЦИОННЫХ БАЗ
ДАННЫХ
Микляев Иван Александрович, канд. физ.-мат. наук, доцент, Филиал Северного (Арктического) федерального университета в Северодвинске “СевмашВТУЗ”, Россия, Северодвинск,
Введение
При рассмотрении условий работы в системе МЧС на первый план выходят условия неопределённости основного места источника информации, т.к. место происшествия нельзя определить заранее. Т.к. каждое происшествие особенно по-своему, то неопределённость структуры информации налицо. С другой стороны, предъявляются максимальные требования по скорости и полноте передаваемой информации для формирования управленческого решения, поэтому требуется максимально быстро и максимально подробно получить информацию с места происшествия.
Всё это требует наличия простой локальной информационной системы на месте происшествия, которая может быстро принять любую форму информации, не упуская малейшие нюансы, независимо от наличия и формы связи с центром. Сотрудник, вносящий информацию, должен быть минимально загружен знанием системы, при этом иметь возможность максимально подробно предоставить информацию в центр.
В центре, куда стекается информация, она должна быть максимально структурирована и нормализована, что является необходимым требованием автоматизированной обработки.
Такие задачи достаточно актуальны в наше время и в военных структурах, пожарных, скорой помощи и даже лесном хозяйстве, где лесник достаточно просто может иметь ноутбук при обходе вверенной территории, при этом необходимо не зависеть от того, есть связь с центром или её нет.
Очевидным решением в данной ситуации является использование объектноориентированных информационных систем, с динамическим расширением структуры.
Примеры систем, предназначенных для решения подобных задач, представлены на основе матричной универсальной объектно-реляционной базы данных [1].
1. Универсальное приложение для работы с МУОРБД
Универсальное приложение представляет собой один исполняемый файл размером в несколько мегабайт, который не требует какой либо предустановки и может быть скопирован на любой носитель информации в любом месте.
После запуска основной программы развёртывается МУОРБД со всем своим инструментарием, которая по умолчанию располагается в директории рядом с программой, либо в месте указанном пользователем.
Пользователь может приступать к работе в МУОРБД сразу после запуска программы, без какой-либо дополнительной подготовки или каких-либо дополнительных настроек.
Универсальное приложение для работы с МУОРБД представляет собой всего две формы: форма администрирования МУОРБД и рабочая форма [1].
Форма администрирования МУОРБД предназначена для управления метаданными.
Рабочая форма универсального приложения МУОРБД таблиц предназначена для работы с основными данными МУОРБД.
2. Универсальный сервер универсального приложения МУОРБД
Универсальное приложение переходит в режим сервера выбором соответствующего пункта меню, после чего оно готово отвечать на запросы клиентских приложений.
Система взаимодействия сервера и клиентского приложения определяется внешним файлом параметров у клиентского приложения, в котором находится лишь местонахождение
83
