СОЗДАНИЕ СИСТЕМЫ ПРЕДСТАВЛЕНИЯ БАЗЫ ЗНАНИЙ О БАЙКАЛЕ
В.С. Ульянов

Постановка задачи
Целью проекта является создание системы представления базы знаний о Байкале на основе метаописаний и концепции семантического программирования. Это означает создание программного комплекса, предназначенного для манипулирования документами различных типов. Универсальность механизма обработки различных ресурсов основывается на их абстрактном представлении в формате онтологий. Центральное место в данном проекте отводится созданию пользовательского интерфейса для предметных областей произвольной структуры. Это сложная задача, так как структура предметной области заранее не известна и является входным параметром системы. Поэтому необходимо, чтобы пользовательский интерфейс предоставлял полноценные возможности управления любыми знаниями в формате онтологий. Также необходимо, чтобы все онтологические структуры были скрыты от пользователя за простым и привычным графическим интерфейсом. Универсальность нашего подхода основывается на гибкости построения элементов интерфейса системы: деревьев, окон, форм, списков и т.д. В результате создается единая рабочая среда пользователя, которая может уточняться в соответствии с его личными представлениями, адаптироваться под его нужды. Данные технологии планируется использовать для создания базы знаний об озере Байкал и организации информационного пространства пользователя.

Задачи проекта
1. Разработка архитектуры системы. К этому относится описание различных модулей, функциональностей, а также их взаимосвязей, интерфейсов. Дополнительными требованиями к системе являются: 
•	совместимость со стандартными языками представления онтологий (в частности OWL) посредством механизма экспорта импорта;
2. Разработка форматов классификации ресурсов на основе спецификации OWL/XML [1]. Необходимо построить расширяемую систему концептов, описывающих типы ресурсов, обладающую выразительностью, гибкостью и естественностью.
3. Разработка основных подходов к построению интерфейса системы ориентированной на массового пользователя. Данный раздел включает в себя 
•	анализ принципов распределения рабочего пространства пользователя
•	выработка базовых сценариев работы пользователя с онтологиями на пользовательском и экспертном уровнях
•	классификация базовых типов элементов GUI для работы с онтологиями
В качестве объектов исследования предполагается рассмотреть организацию пользовательского интерфейса таких систем как Windows, Google Mail, Mozilla и др. систем, ставших популярными засчет продуманного пользовательского интефрейса. Разработка сценариев является связующим звеном  между всеми частями проекта, так как предполагается использование системы как экспертами, для описания предметной области, так и простыми пользователями в процессе использования и развития созданной базы знаний. Уровень профессиональных знаний, опыт работы с компьютером и цели использования системы сильно отличаются среди разных целевых групп. Это диктует различные подходы к организации взаимодействия пользователя и системы, различные подходы к выстраиванию пользовательского интерфейса.
4. Разработка модуля представления сетевых графов в виде «ленивых» деревьев. Так как в основе онтологий лежат иерархии классов и объектов, то очень важно иметь возможность строить различные виды деревьев, как по отношению наследования, так и по свойствам объекта. К функциям данного модуля относятся: реализация концепции представления сетевых графов в виде деревьев с помощью правил. Также необходимо разработать базовый набор правил для организации гибкой настройки предметной области под конкретные задачи. Под настройкой предметной области в рамках данного модуля понимается представление сетевого графа в виде дерева посредством работы с высокоуровневыми графическими интерфейсами.
5. Разработка технологий работы с коллекциями ресурсов. Наибольшую ценность системы управления базами знаний представляют возможности оперирования большими объемами информации. Представленная в онтологиях в виде объектов, информация может группироваться по тем или иным признакам. Богатство онтологической конструкции предполагает различные критерии для группирования объектов онтологии в коллекции. Для того, чтобы предоставить пользователю такие возможности, необходимо разработать достаточно гибкий механизм для построения коллекций. Причем данный механизм должен быть инвариантным к способу представления коллекций – будь то стандартное представление коллекции в виде списка, таблицы, набора иконок или специфическое, предназначенное только для единственного типа.
6. Разработка технологий работы с отдельными объектами. Данная задача состоит в создании различных способов редактирования свойств объекта с помощью форм. Она требует разработки системных интерфейсов для графических элементов управления с возможностью дальнейшего их добавления в систему в виде подключаемых модулей. Данная задача также предполагает разработку методов размещения компонентов на форме в зависимости от типа объекта и от особенностей его свойств.
7. Разработка формата системных настроек в формате онтологии. . Так как наша идея заключается в самоприменимости системы, все настройки предполагается хранить в формате онтологий. Для этого необходимо разработать структуру онтологии настроек с учетом того, чтобы подключаемые модули также могли сохранять свои настройки. 
8. Апробация системы. Данный этап необходим для тестирования системы на ряде образовательных и информационных задач связанных с озером Байкал.

Актуальность проекта
Актуальность данной системы заключается в том, что она позволит осуществить переход к работе со сложными онтологическими конструкциями большому числу простых пользователей. Архитектура и концепция системы строится так, чтобы обеспечить возможности настройки под определенную предметную область, под определенные задачи. Единообразие иерархических классификаций позволяет строить единые интерфейсы для любых видов знаний в формате онтологий. Все это в совокупности позволяет говорить о создании единой рабочей среды, которая будет строиться динамически, и расширяться пользователем, согласно его собственным представлениям и решаемым задачам. В контексте работ по НОЦ «Байкал» это позволит создать единое информационное пространство, обеспечивающее возможности междисциплинарных исследований и взаимодействий по изучению озера.

Новизна проекта
Данная система по своей сути является системой управления онтологиями. Существует ряд систем для обработки аналогичных форматов представления информации и знаний. Схожие задачи выполняет в частности система Protégé. Однако, данная система имеет несколько другое предназначение и ориентирована на пользователей со знаниями математической логики и заточена под задачи логического вывода. Существует еще ряд проектов, ориентированных на оперирование  онтологиями, но большинство из них предоставляют низкоуровневые возможности по редактированию структуры онтологии в форматах OWL и RDF. Наша система разрабатывается с расчетом на простого пользователя и вся сложная математическая начинка скрывается за простым и привычным интерфейсом. Продвинутые пользователи, в свою очередь могут использовать полные возможности системы по манипулированию онтологиями. Они даже могут создавать собственные модули и интегрировать их в систему. Качественно иной подход к использованию онтологий в информационных системах позволяет говорить об уникальности данной разработки на текущий момент. 

Задел
Мною была придумана теория представления семантической сети в виде деревьев особого вида. Ситуация осложняется существованием циклов в графе в общем случае. Это потребовало организации их представления в виде бесконечных деревьев с особой технологией их представления в памяти компьютера. Механизм построения деревьев является ключевым для организации всего интерфейса, так как большинство элементов GUI, так или иначе, зависит от текущего узла дерева или же от дерева в целом.
Дерево задается с помощью указания вершины и набора правил. Наш подход заключается в том, что вершиной может быть любой узел. Под узлом мы понимаем некоторое отождествление элемента онтологии (класса, объекта, свойства) его графическому представлению в GUI-компоненте. Чаще всего таким узлом является класс Thing, общий класс для всех классов онтологии. В системе предусмотрено использование различных видов шаблонных деревьев, которые имеют характерную структуру для различных предметных областей: иерархия классов, иерархия по включению и др. Чаще всего, класс Thing является корнем этих деревьев. Этот факт логически вписывается в сценарии работы с типовыми деревьями с помощью правил.
 Под правилом в нашей системе подразумевается некоторый принцип построения дочерних узлов текущего узла. Т.е. деревья строятся транзитивно, последовательно применяя данный набор правил к узлам одного типа. С технической точки зрения, правило представляет собой определенный интерфейс, поэтому в систему можно добавлять собственные правила. То же самое относится и к узлам. Правило определяет тип узлов, на котором оно работает, а также непосредственно механизм построения дочерних узлов.
Приведем пример. Возьмем  стандартный вид дерева – иерархию классов. Чтобы создать данное дерево в нашей системе необходимо:
1.	указать корнем класс Thing.
2.	добавить правило «подкласс» с учетом транзитивности
  Здесь нужно отметить, что «с учетом транзитивности» означает один из видов настройки правила. Правила в нашей системе представляют собой не детерминированные какие-то единицы, а настраиваемые механизмы. Стандартный пакет включает набор правил с минимально-необходимым набором настроек. То, что настроек немного, на самом деле является большим плюсом. Это означает, что правила просты в использовании и создании, не умаляя при этом их гибкости и функциональности. Стандартный набор правил позволяет строить деревья различных типов и сложности. Нужно отметить, что благодаря нашему подходу была реализована возможность построения деревьев по объектным свойствам. Такая возможность построения деревьев никогда нами ранее не встречалась, хотя она имеет большую практическую значимость. 
Для примера возьмем генеалогическое дерево некоторого человека. Person – это класс онтологии. У данного класса есть свойство parent со значениями из класса Person (в стандартах описания онтологий, таких как OWL, область значения свойства обозначается словом «ранг»). Нетрудно видеть, что генеалогическое дерево есть ни что иное, как транзитивное замыкание свойства parent. Таким образом, в качестве корня дерева указывается конкретный объект класса Person и используется единственное правило «значение объектного свойства» с учетом транзитивности.
Данный способ построения деревьев имеет большую практическую значимость, так как многие существующие иерархии (например УДК) строятся по данному принципу. Следует отметить, что исследования в этой области были отмечены дипломом 1-ой степени на всероссийском конкурсе инновационных проектов аспирантов и студентов [3].

Мною также разрабатывались технологии привязки методов к элементам онтологий [2].
Общий подход к привязке методов к онтологии, который я предлагаю, основывается на технологиях мультиметодов. 
Описания методов производятся посредством задания имени метода, количества аргументов и их типизации.
method(arg1@type1, arg2@type2,..)
В качестве типов аргументов могут выступать как классы онтологии, так и объекты. При вызове метода в качестве аргументов подаются произвольные объекты онтологии и необходимо из имеющихся предопределенных методов получить наилучший с точки зрения механизма наследования, или сгенерировать ошибку, если запрашиваемый метод неизвестен, или имеются два метода, соответствующие запросу, из которых нельзя выбрать единственный.  Рассмотрим механизм определения метода на примере (см. рис. 1).

Рис. 1. Демонстрация механизма определения метода по запросу
На данной схеме изображено дерево наследования классов онтологии и методы, соответствующие определенному классу. Для каждого метода определено его название и типизация аргументов (в том случае, когда типизация аргумента не указана, предполагается, что типом аргумента является класс Thing, «самый общий» класс для всех классов онтологии).
Рассмотрим, каким образом, работает механизм поиска метода по запросу. На следующей таблице приведены примеры запросов (вызов определенного метода с фактическими параметрами) и результатов (имеющийся в системе метод с типизацией аргументов).
Запрос	Результат	
m1(ABC,XYZ)	m1(i@A,j@XZ)	
m2(ABC,XYZ)	m2(J@AB,k)	
m4(AB,XY)	“метод не существует”	
m6(ABC,XYZ)	“запрос не однозначен”	
В первом запросе методу с именем «m1» подаются в качестве первого аргумента объект ABC, а в качестве второго – XYZ. Для запроса с таким именем и количеством параметров существуют два предопределенных метода:
m1(i@A, j@X)
m1(i@A,j@XZ)
Так как ABC наследует A, данное значение аргумента удовлетворяет обоим выражениям. XYZ также более специфичен чем X и XZ (т.е. наследован от них). Таким образом, оба данных описания удовлетворяют сигнатуре запроса, однако второй метод является предпочтительнее, так как XZ более специфичен, чем X, а тип первого аргумента у них совпадает.
Рассмотрим ситуацию, когда запрашиваемый метод не существует. Это третий запрос: m4(AB,XY). Для данного запроса определен лишь один метод с именем m4 и двумя параметрами, это метод m4(k@ABC, l@X). AB – не является ABC с точки зрения механизма наследования, AB менее специфичен и не имеет предопределенного метода с именем «m4». Следовательно, имеющиеся методы не соответствует сигнатуре запроса и запрашиваемый метод не известен, не существует. 
Рассмотрим третий вид ответа на запрос – когда запрос не однозначен. Это последний запрос: m6(ABC,XYZ). Для запроса с такими характеристиками существуют два определенных метода:
m6(i@AC, j)
m6(i, j@XYZ)
Отсутствие типизации означает, что в качестве аргумента может выступать любой объект. Оба эти метода удовлетворяют сигнатуре запроса, однако невозможно выбрать из данных определений одно единственное. С одной стороны, AC более специфично, чем «любой объект», и следовательно, первый вариант предпочтительнее. С другой стороны XYZ предпочтительнее «любого объекта» и нужно выбирать второй вариант. В итоге получилась ситуация, когда отсутствует метод, все аргументы которого более предпочтительны, чем аргументы  остальных методов.
Обозначим через C множество классов онтологии. Предполагается, что C содержит «самый общий класс» Thing, то есть, . 
Правила сравнения аргументов:
•	
•	, если  наследует 
•	, если  - объект класса  (т.е. )
•	Классы несравнимы (обозначается ), если  и 
•	Объект  не сравним с классом  (обозначается ), если 
Теперь опишем правила определения нужного метода по сигнатуре запроса. Для этого введем отношение предпочтения одного метода другому. Будем говорить, что A предпочтительнее B, если A≤B.
Определение. Пусть имеются два метода с одинаковым именем и одинаковым количеством аргументов. Тогда 

Теперь мы можем описать формальный алгоритм поиска метода по запросу. Пусть M - множество определенных методов. z – запрос. nameOf() – функция, возвращающая имя метода. argsOf() – функция, возвращающая количество аргументов метода.
Алгоритм.
1.	
2.	
3.	 
4.	Если ø  – «метод неизвестен»
5.	Если |M3|>1  – «запрос неоднозначен».
6.	Если |M3|=1  - возвращаем M3.
Далее приводится обзор моей Java-библиотеки, реализующей инструменты для описания методов онтологии, а также для вызова метода по сигнатуре запроса, основанные на реализации приведенного подхода.

Данная библиотека состоит из пакета com.teacode.ontology.methods. Она позволяет создавать методы онтологии неограниченной функциональности, а так как Java является кросс-платформенным языком программирования, то еще и платформонезависимые. 
Создание метода онтологии
В библиотеке имеется интерфейс com.teacode.ontology.methods.OntMethod, реализация которого означает описание метода онтологии. В данном интерфейсе определены три метода, достаточных для описания метода онтологии, типов его аргументов и непосредственно кода метода.
String[] getArgsType() 
          Возвращает массив типов данных для аргументов метода онтологии 
String getName() 
          Возвращает имя метода онтологии, описываемого в данном классе 
Object run(Context ctx, Object[] args) 
          Код метода, запускаемый на выполнение. В качестве параметров передается объект контекста (будет рассмотрен далее) и массив фактических значений аргументов метода онтологии.
Таким образом, для разработки одного метода онтологии достаточно реализовать один класс на Java, реализующий интерфейс OntMethod.
Регистрация методов в системе
Главным классом системы привязки является класс Context. В данном классе реализованы основные методы регистрации онтологических методов в системе, а также взаимодействие с объектной моделью онтологической системы. В частности, для регистрации в системе скомпилированных методов у класса Context существует метод
void addMethods(java.io.File f)
          Данный метод загружает в систему методы, расположенные в определенном каталоге, включая подкаталоги.
Выполнение метода
Для запуска онтологического метода на исполнение в классе контекста (Context) существует три метода:
Object runMethod (Method met, Object[] args)
Запускает на выполнение Java-метод, с массивом аргументов в качестве параметров  
Object runMethod(String name, Object[] args)
Отыскивает подходящий обработчик, зарегистрированный в системе, в соответствии с параметрами запроса. В зависимости от количества и типа передаваемых аргументов, вычисляется метод онтологии, соответствующий идеологии мультиметодов.
Object runMethod(String name, Object[] args, String[] types)
Быстрый вызов метода онтологии с явной типизацией. 

Используемые технологии
В разработке системы предполагается использование технологий: J2EE, баз данных, языка описания онтологий OWL/XML. Фактически создаваемая проект является надстройкой, клиентской частью развивающейся системы МЕТА2-nExt. Данная система уже включает в себя интерфейс метамодели для работы с онтологиями, механизм погружения онтологий в базы данных, адаптер для работы с существующими базами данных, как онтологиями. Формат представления системных настроек будет построен с использованием спецификации OWL. Также OWL будет использоваться для описания базовых типов ресурсов. Пользовательские интерфейсы предполагается создавать с использованием технологий Java, Swing и JSP (для веб-интерфейсов).

Сфера применения
Данную систему можно применять для широкого круга задач, т.к. описание ресурса ничем не ограничено и производится в формате OWL. Онтологии, представленные в этом формате, содержат инструменты для выразительного и гибкого описания предметных областей, и в частности, ресурсов. Наиболее очевидный способ использования системы – для организации единой системы интеллектуальной обработки знаний. Гибкость онтологий позволяет интегрировать данные различной структуры  и природы в единую среду. Интересно было бы опробовать данную технологию для организации базы знаний об озере Байкал. Уникальность НОЦ предоставляет возможность создания хранилища данных об озере по различным направлениям. Это позволит с одной стороны, апробировать технологии семантического программирования на практике. С другой стороны, будет создан гибкий и удобный инструмент для информационной поддержки междисциплинарных исследований. 

Планируемые результаты
Основным планируемым результатом данного проекта является разработка и апробация системы представления знаний на основе онтологий. Также будет разработан модуль для данной системы, производящий ее настройку под предметные области, исследуемые в рамках проекта НОЦ «БАЙКАЛ»

Литература
1.	Web Ontology Language (OWL). http://www.w3.org/2004/OWL/
2.	А.В. Манцивода, В.С. Ульянов. Онтологические системы и задачи управления контентом. XII всероссийская научно-методическая конференция «Телематика 2005»
3.	В.С. Ульянов. Создание пользовательского интерфейса для системы управления онтологиями. // Сборник материалов всероссийского конкурса инновационных проектов аспирантов и студентов по приоритетному направлению развития науки и техники «информационно-телекоммуникационные системы». – М. 2006. – с. 64