Ежедневно, выполняя свои должностные и прочие функции, современный человек сталкивается с задачей анализа большого объема информации и поиска необходимых ему данных. Со временем происходит накопление пользовательских данных в виде документов. Эти документы в сумме составляют некоторое информационное пространство пользователя. С каждым новым документом все острее встает вопрос организации этого пространства: с течением времени из пары – тройки папок с иерархически – расположенными в них файлами получается огромная кипа документов, которую достаточно сложно привести к иерархической форме с линейными связями. Перед нами встает задача конкретизации, категоризации и визуализации информационного пространства пользователя.
Определимся с терминологией: под информационным пространством пользователя в рамках данной статьи будет пониматься набор текстовых (не табличных и графических) документов (файлов), распределенных на файловой системе внутри некоторой иерархии директорий. Для наглядности также упростим описание условий принадлежности документов информационного пространства к одной предметной области, например экономике. Текстовые файлы могут представлять собой экономические статьи, научные труды, учебную литературу и прочие формы представления экономической текстовой информации.
На начальном этапе формирования информационного пространства пользователю может быть достаточно просто ориентироваться в нем ввиду его небольших размеров и, как следствие, довольно четкой структуры и связей между его элементами. С течением времени и выполнении пользователем должностных, научных и повседневных функций, мощность информационного пространства нарастает, вес отдельных связей между узлами (файлами) уменьшается и ориентироваться в нем становится все труднее. С этим растет время поиска необходимой информации, падает качество и продуктивность деятельности пользователя в рамках своего информационного пространства.
Как правило, это связано не только с увеличением объема текстовой информации, но и с низкой скоростью ее восприятия пользователем. Поиск нужного фрагмента во всем массиве также затруднен: пользователь должен правильно составить поисковый запрос для получения адекватной выдачи, а иногда это сделать проблематично ввиду, например, низкой осведомленности пользователя в предметной области или наличия синонимов или фактов, описывающих разные вещи похожими формулировками. Также использование полнотекстового поиска по документам силами операционной системы не предусматривает персонализацию и релевантность поисковой выдачи, что также негативно сказывается на скорости работы пользователя и качестве организации его информационного пространства.
Из рассмотренных выше недостатков стандартного поиска и организации информационного пространства следует, что для оптимизации информационной деятельности пользователя необходимо:
- Разбить предметную область на категории или «зоны»
- Выделить ключевые узлы предметной области
- Визуализировать предметную область для ускорения восприятия ее человеком
- Определить узлы внутри каждого элемента предметной области (формирование онтологий)
- Определить свойства объектов внутри узлов предметной области и их связи (завершение формирования онтологий)
- Определить связи и взаимодействия между узлами предметной области (составление семантической сети из узлов – онтологий)
- Связать между собой уровни визуализации и функционального описания предметной области (наложение Карты Тегов, онтологий и семантической сети друг на друга)
- Реализовать функцию персонализации предметной области и релевантности ее представления на основе итеративного обучения в процессе взаимодействия с пользователем.
Для реализации вышеперечисленного целесообразно использовать три технологии: это Карты или облака тегов, онтологии и семантические сети, т.к. по отдельности ни одна из них не способствует устранению всех имеющихся недостатков в организации информационного пространства, но оптимизирует свою часть, что в результате поможет добиться совершенствования информационной деятельности пользователя.
Картами (облаками) тегов представлен высший уровень детализации предметной области, это своеобразный GUI (Graphic User Interface) предметной области. В данном случае существует некоторое отступление от классического описания карты (облака) тегов: за Тег принимается несколько больше, чем просто текстовая метка – в нашем случае тегом будет считаться именование объекта, являющегося объединением от одной до нескольких онтологий предметной области. Отступление от классического «облака» в сторону «карты» обусловлено наличием деления предметной области на зоны ( как страна разделена областями на политической карте). Данное деление введено для повышения скорости визуального восприятия и интутивности поиска нужных данных среди онтологий (фактов, документов) предметной области для пользователя. Карта тегов является верхним уровнем, для ее формирования используются данные двух следующих уровней: онтологии и семантические сети.
Работая с картами тегов, возможно обеспечить релевантность поисковой выдачи для конкретного пользователя. Для этого целесообразно использовать механизмы протоколирования истории навигации по информационному пространству пользователя по тегам, так называемый «маршрут познания». Этот «маршрут» будет набираться и исправляться со временем — с каждым новым поиском, пользователь своим перемещением по карте тегов будет задавать связи – отношения между ее узлами. И в следующий раз при обращении пользователя к узлу, кроме онтологий, которые он представляет, также будут выданы онтологии, либо узлы ему релевантные. Использование данной методики организации поисковой выдачи позволяет персонализировать информационное пространство пользователя: ему будут предлагаться варианты, нужные именно ему, в соответствии с собранных системой данных о его предпочтениях.
При работе со стандартными облаками тегов был выявлен один существенный недостаток: новые и старые источники данных (по дате добавления) на карте обозначаются одинаково – это не позволяет заранее знать какой по дате добавления узел собирается открыть пользователь. Предлагается добавить к тегу свойство «новизна» — визуальное отображение цветов в соответствии с заранее определенной относительной шкалой (палитрой) времени. Например, для тегов, описывающих узлы добавленные не позднее суток, будет применен белый цвет, для тегов добавленных не позднее недели – желтый и т.д. Добавление данного свойства также позволит добиться более качественной организации информационного пространства пользователя и ускорить получение им требуемой информации.
Онтологиями представлен низший уровень детализации данных. Каждый пользовательский файл рассматривается как отдельная онтология. Такая условность принята для упрощения составления функциональной структуры информационного пространства-ведь исходными данными являются текстовые документы в виде файлов, распределенных на файловой системе в структуре директорий. За онтологию в рамках данной системы будет принято формальное явное описание узла предметной области. Это некоторое отступление от классического определения онтологий в плане того, что там описывается не узел, а целая предметная область – сделано оно для повышения степени персонализации информационного пространства пользователя. Существует несколько готовых онтологий предметной области «экономика» – все они охватывают разный масштаб, имеют разную степень детализации, но они не «заточены» под конкретного пользователя.
Дабы система не была «одноразовой» — за основу должен быть взят некий общий словарь или тезаурус предметной области, который бы описывал все понятия и свойства понятий предметной области «экономика», а также некоторые фундаментальные связи и отношения между ними. Использование такого центрального хранилища классов, слотов и фасетов онтологий позволяет использовать клиент-серверную архитектуру системы, что имеет определенные преимущества перед standalone – версией, а именно:
- отказоустойчивость (объекты онтологий будут храниться на сервере с системой резервирования данных)
- масштабируемость (к системе достаточно быстро можно будет подключить новых пользователей)
- оптимальность использования вычислительных мощностей
- развитие силами группы пользователей (онтология будет пополняться и оптимизироваться не одним, а нескольким людьми, что значительно ускорит ее развитие, позволит нарастить онтологии больших мощностей в сравнительно небольшое время, а также позволит избежать избыточности за счет предоставления возможности поиска дубликатов и синонимов средствами проектирования и поддержки онтологий)
В случае использования клиент-серверной архитектуры на сервере будут храниться: классы предметной области, их слоты, фасеты и фундаментальные связи. На стороне клиента будут храниться экземпляры классов, уточняющие (персонализирующие) связи между классами и экземплярами. Таким образом, система на стороне пользователя сможет использовать уже готовые, хранящиеся на сервере онтологии и их элементы для построения своих собственных, персонализированных, а результаты своей деятельности также отправлять на сервер, обеспечивая тем самым его обновление и эволюцию.
Как было сказано ранее, каждый файл будет приниматься как отдельная онтология, отношения с серверной онтологией будут типа «содержит». Может появиться вопрос: «Зачем использовать такую архитектуру онтологий, почему бы просто не создать одну большую онтологию и работать в ее рамках?». Объяснение следующее: использование множества онтологий позволяет персонализировать систему, информационное пространство при условии клиент-серверной архитектуры, в то же время анализ взаимосвязей между онтологиями ничуть не затрудняется их количеством, благодаря механизму сопоставления онтологий.
Также добавление нового документа в информационное пространство пользователя гораздо легче обработать, если создать из него на основе некоторого универсального алгоритма отдельную небольшую онтологию. Она впоследствии будет сопоставлена с серверной, с учетом сохранения первоначальной онтологии.
На примере рассматриваемой предметной области «экономика» можно с некоторым допущением сказать, что для формирования онтологий-узлов предметной области из пользовательских файлов существует универсальная методология. В общем и целом формирование любой онтологии производится в несколько этапов:
- Определение области и масштаба онтологии
Прежде чем создавать онтологию – необходимо определиться с ее областью и масштабом, для этого необходимо ответить на несколько вопросов:
- Какую область будет охватывать онтология?
- Для чего будет использована онтология?
- На какие типы вопросов должна давать ответы информация в онтологии?
Ответы на эти вопросы могут измениться во время процесса проектирования онтологии, но в любой заданный момент времени они помогают ограничить масштаб модели.
- Рассмотрение вариантов повторного использования существующих онтологий
Необходимо проверить – существует ли возможность использования либо улучшения и расширения источника-сервера онтологий
- Перечисление важных терминов в онтологии
Полезно составить список основных терминов онтологий и их свойств
- Определение классов и иерархии классов
Существует несколько возможных подходов для разработки иерархии классов:
- Процесс нисходящей разработки начинается с определения самых общих понятий предметной области с последующей конкретизацией понятий.
- Процесс восходящей разработки начинается с определения самых конкретных классов, листьев иерархии, с последующей группировкой этих классов в более общие понятия.
- Процесс комбинированной разработки – это сочетание нисходящего и восходящего подходов: Сначала мы определяем более заметные понятия, а затем соответствующим образом обобщаем и ограничиваем их.
- Но какой бы подход не был выбран, начинать требуется с определения классов онтологии
- Определение свойств классов (слотов)
Классы сами по себе не предоставляют достаточно информации о предметной области – после определения классов необходимо описать внутреннюю структуру понятий.,
В онтологии слотами могут стать несколько типов свойств объектов:
- внутренние свойства объекта
- внешние свойства объекта
- части, если объект имеет структуру (могут быть как физическими, так и абстрактными частями)
- отношения с другими индивидными концептами
Слот должен быть привязан к самому общему в иерархии классу, у которого может быть данное свойство.
- Определение фацетов слотов
Слоты могут иметь различные фацеты, которые описывают тип значения, разрешенные значения, число значений (мощность) и другие свойства значений, которые может принимать слот.
Вот некоторые общие фацеты:
- Мощность слота
Мощность слота определяет, сколько значений может иметь слот. В некоторых системах различаются только единичная мощность (возможно только одно значение) и множественная мощность (возможно любое число значений).
- Тип значения слота
Фацет типа значения описывает, какие типы значений можно ввести в слот. Вот список наиболее общих типов значений: строка, число, булевы слоты, нумерованные слоты, слоты-экземпляры (описывают отношения между экземплярами)
- Домен слота и его диапазон значений
Классы, к которым слот привязан, или классы, свойство которых слот описывает, называются доменом слота. В системах, где мы привязываем слоты к классам, домен слота обычно составляют классы, к которым привязан слот. Основные правила определения домена слота и диапазона значений слота схожи друг с другом:
При определении домена или диапазона значений слота найдите наиболее общие классы или класс, которые могут быть соответственно доменом или диапазоном значений слотов.
С другой стороны, не стоит определять слишком общий домен и диапазон значений: все классы в домене слота должны быть описаны слотом, а экземпляры всех классов в диапазоне значений слота должны являться потенциальными заполнителями слота. Не стоит также выбирать слишком общий класс для диапазона значений.
- Создание экземпляров
Последний шаг – это создание отдельных экземпляров классов в иерархии. Для определения отдельного экземпляра класса требуется (1) выбрать класс, (2) создать отдельный экземпляр этого класса и (3) ввести значения слотов.
После формирования онтологий необходимо сопоставлять их с серверной частью для удаления дубликатов, взаимообогащения и пополнения друг друга и т.д. Также сопоставление онтологий позволяет уйти от полнотекстового поиска в информационном пространстве пользователя.
В системе онтологиями будет представлены не только предметная область и пользовательские документы, но и поисковые запросы пользователя. Рассмотрение каждого поискового запроса как онтологию поможет, используя методику сопоставления онтологий добиться при развернутых формулировках запроса высокого уровня соответствия реальной поисковой выдачи к искомой информации. В этом заключается подход работы с поиском, отталкиваясь не от «ответа» (имеющихся в системе данных), но от «вопроса» (попытка понять: что конкретно необходимо найти пользователю?). При использовании данного подхода, между конкретизацией, точностью поисковой выдачи и развернутостью поискового запроса будет установлена прямо пропорциональная связь: чем полнее пользователь опишет то, что ему требуется, тем полнее будет составлена онтология, тем точнее отработает механизм сопоставления онтологий, тем более качественная выдача будет ему предоставлена.
Вкратце метод сопоставления онтологий можно описать следующим образом:
- Строится пересечения терминов онтологий предметной области и запроса T(O)=T(O_s )∩T(O_q )
- Если это пересечение не пусто, для каждого термина из T(O) строятся два множества T_s и T_q — термины, которые связанны с ним в каждой онтологии любыми отношениями
- Для каждого термина из T(O) строится пересечение множеств T_s и T_q.
- Анализ типов отношений между терминами из T(O) и пересечения множеств T_s и T_q. (все отношения онтологии делятся на три типа – иерархические, синонимические и прочие).
- Строится коэффициент сходства онтологий, который является количественным отображением сходства семантики двух онтологий. При этом учитываются следующие факторы: вхождение одного и того же термина в обе онтологии; то, что два термина находятся в разных онтологиях в одном и том же отношении; то, что два термина находятся в разных онтологиях в отношениях одного типа или разных (например, в иерархическом отношении и отношении синонимии); существуют ли вообще любые отношения (прямые или опосредствованные) между одними и теми же терминами.
Низший (онтологии) и высший (карты тегов) уровни детализации информационного пространства пользователя необходимо связать друг с другом. Сделать это можно посредством создания и постоянного расширения семантической сети предметной области. Под семантической сетью будет пониматься информационная модель, имеющая вид ориентированного графа, вершины которого соответствуют объектам системы (тегам и онтологиям), а дуги задают отношения между ними.
Семантическая сеть будет выполнять связующую роль между онтологиями – файлами и указующими на них тегами наподобие гиперссылок, но с более сложной структурой, будет представлять собой «транспорт» системы. Храниться будет на клиентской стороне, так как серверной части ни к чему информация о местоположении и структуре пользовательских документов. Именно посредством этой технологии пользователь, выбрав тег из какой-либо зоны на карте тегов получит информацию о данном теге, данные по онтологии и исходный файл-документ, соотнесенный с данной онтологией. А благодаря возможности создавать сложную структуру, пользователь кроме файла документа сможет получить настраиваемое количество периферийной (уточняющей) информации, такой как связанные с данным документом онтологии, теги и области на карте тегов, документы, релевантные результату.
Система, функционирующая по вышеописанным принципам и алгоритмам должна обладать достаточно большой
обрабатывающей способностью, расширенной масштабируемостью, безопасностью и потенциалом на расширение и эволюцию, благодаря клиент-серверной архитектуре основных ее компонент. Она позволит производить категоризацию, персонализацию, резюмирование и визуализацию пользовательского информационного пространства, что в конечном итоге должно благотворно повлиять на качество его информационной деятельности в целом, а также развить детализированную онтологию предметной области информационного пространства пользователя.
Литература:
1. Гладун А.Я., Несен М.В., Штонда В.Н. Интеллектуальные агентно-ориентированные услуги, базирующиеся на платформах интеллектуальных сетей// Компьютерные средства, сети и системы, 2004, №6, с. 112-122.
2. Гладун А.Я, Рогушина Ю.В., Штонда В.Н. Онтологический анализ web-сервисов в интеллектуальных сетях // International Conference «Knowledge-Dialogue-Solutions» 2007.
3. Дэбора Л.М., Наталья Ф.Н. Разработка онтологий 101: руководство по созданию Вашей первой онтологии// Stanford Knowledge Systems Laboratory Technical Report KSL-01-05 and Stanford Medical Informatics Technical Report SMI-2001-0880, Март 2001.
4. Клещев А.С., Артемьева И.Л. Отношения между онтологиями предметных областей. Ч. 1. // Информационный анализ, Выпуск 1, С.2, 2002. – С.4-9.
Автор: CalmbursT
