Содержание к диссертации
Введение
1 Некоторые аспекты проектирования и анализа информационных систем для науки 13
1.1 Методы моделирования и исследования бизнес-логики поиска информационных систем на основе онтологии предметных областей. 13
1.1.1 Основные понятия 14
1.1.2 Регулярные запросы 17
1.1.3 Модель бизнес-логики поиска ИС 20
1.1.4 Достижимость и зависимость объектов 26
1.1.5 Двухуровневая поддержка ресурсов и интегрированость данных 38
1.2 Таксономии и классификация ресурсов в научной ИС 41
1.2.1 Тезаурус, как средство классификации и поиска ресурсов в ИС 41
1.2.2 Модель тезауруса в ИС на платформе ИСИР 58
2 Общероссийский математический портал Math-Net.RU 63
2.1.1 Предпосылки 63
2.1.2 Цель проекта. 63
2.2 Система Math-Net.RU. Постановка задачи 64
2.2.1 Пользователи системы 64
2.2.2 Информация, хранимая и доступная в системе 65
2.2.3 Функции и возможности системы. 66
2.3 Платформа ИСИР, как основа ИС Math-Net.RU 66
2.3.1 Общая архитектура ИСИР-системы 61
2.4 Онтология предметной области и обобщение опыта существующих математических информационных систем 69
2.4.1 Математические WEB-ресурсы России. 70
2.4.2 Ресурсы российских математических сайтов 71
2.4.3 Существующие зарубежные математические информационные системы и перспективы всемирной ИС Math-Net 74
2.5 Построение онтологии ИС Math-Net.RU. 76
2.5.1 Уровни детализации описания ресурсов 76
2.5.2 Тематическая классификация ресурсов. 78
2.5.3' Принципы построения модели данных ИС. 80
2.5.4 Модель данных Math-Net.RU 81
2.6 Бизнес-логика пользовательских интерфейсов ИС Math-Net.RU 87
2.6.1 Архитектура 87
2.6.2 Защита данных и разграничение доступа 90
2.6.3 Интерфейсы поиска, просмотра и навигации 90
2.6.4 Бизнес-логика поиска 93
2.6.5 Выборка и навигация по тезаурусам и классификаторам. 95
2.6.6 Форматы хранения текста, проблема математических формул...95
2.7 Информационное наполнение системы.. 100
3 Универсальная схемонезависимая подсистема редактирования объектного репозитория ИСИР DBEditor 102
3.1 Введение 102
3.1.1 Общее описание и назначение 102
3.1.2 Принципы работы DBEditor , 102
3.2 Страницы интерфейсов и бизнес-логика 104
3.2.1 Средства выборки ресурсов 105
3.2.2 Названия классов и свойств 105
3.2.3 Однозначная идентификация объектов 106
3.2.4 Страница Allclasses 107
3.2.5 Страница Collection 107
3.2.6 Страница Instance. 107
3.2.7 Страница Choose cIass 109
3.2.8 Страница Choose instance 109
3.2.9 Ограничения DBEditor. 109
3.3 Конфигурация DBEditor ПО
3.3.1 Ограничения функциональности и защита данных 110L
3.3.2 Файл конфигурации DBEditor Ill
4 Интеграция и загрузка структурированных данных в ИС на основе платформы ИСИР 116
4.1 Постановка и анализ задачи 117
4.1.1 Онтология источника данных 117
4.1.2 Проблемы, возникающие при преобразовании данных, классификация ошибок и конфликтов 118
4.1.3 Принятие недостоверных решений, роль эксперта 121
4.2 Архитектура загрузчика-интегратора 122
4.2.1 Модульный принцип построения 122
4.2.2 Процесс нормализации, преобразования, интеграции и загрузки: данных, шестишаговая архитектура 123
4.2:3 Первая и вторая стадии. Преобразование данных, нормализация и вычисление атомарных атрибутов, решение семантических конфликтов 127
4.2.4 Третья стадия. Загрузка данных в репозиторий ИС 128
4.2.5 Четвертая стадия. Идентификация загружаемых ресурсов. 129
4.2.6 Учет ограничений целостности целевой онтологии 131
4.2.7 Пятая стадия. Слияние ресурсов 136
4.2.8 Шестая стадия. Приведение данных в соответствие с ограничениями целостности 137
4.3 Выводы. 137
Заключение 139
Приложение: бизнес-логика поиска ИС Math-Net.RU 141
Основные обозначения 141
Обозначения свойств и классов (сокращенная запись) 141
Используемые типы множеств значений атомарных атрибутов 141
Страницы интерфейсов 142
Литература
- Двухуровневая поддержка ресурсов и интегрированость данных
- Информация, хранимая и доступная в системе
- Принципы работы DBEditor
- Проблемы, возникающие при преобразовании данных, классификация ошибок и конфликтов
Введение к работе
Для обработки и обмена научными знаниями компьютерные системы и сеть Internet использовались почти с самого момента своего. За прошедшие с тех времен десятилетия на электронных носителях под управлением компьютерных систем было накоплено огромное количество научных знаний в самых разных отраслях. Также появилось большое количество информационных систем, обеспечивающих более или менее эффективный поиск и доступ к ней. Все эти системы,сильно различаются между собою по уровню и полноте охвата информации (общенаучные, тематические, узкоспециализированные, национальные, корпоративные и т.д.), кругом пользователей (публичные, внутрикорпоративные и т.д.) и назначением. Более того, значительная часть информации и вовсе не доступна для поиска сетевым пользователями, ибо находится на отдельных источниках с разнородной структурой или вовсе не доступна по сети. Таким образом, можно констатировать, что в настоящий момент научные знания слабо систематизированы, и разрознены, как логически, так и физически, имеют различную логическую и физическую структуру, а потому слабо доступны. Особенно остро эта проблема стоит в России, в силу меньшей" чем в Европе и США, распространенности дорогостоящих современных информационных технологий в научной среде.
В то же время, особенностью электронных и других источников научных знаний и информации о научной деятельности является то, что, несмотря на сильное различие в назначении и функциональности, они предоставляют информацию из одной и той же предметной области - области знаний и ресурсов некоторой науки. Следовательно, их информационные ресурсы описывают часто одни и те же понятия: научные публикации, ученых, работающих в этой отрасли, научные организации, проекты, гранты, опыты, образцы, экспериментальные установки и другие. Все это позволяет говорить о некоторой общей онтологии предметной области [14], в которую складываются модели данных отдельных информационных источников, и выделение которой в явном виде будет необходимо для решения задач интеграции данных между собою. С одной стороны, предметная область научной информации характеризуется большим разнообразием сущностей и сложностью связей между ними. С другой стороны, создание единого научного пространства, интегрирующего в себе всю научную информацию по отдельным наукам или в целом, сделает труд ученых значительно эффективнее и производительнее, поскольку излишне говорить,. насколько важно для научной деятельности полное информационное обеспечение.
Первые информационные системы на основе вычислительных машин создавались программистами-одиночками или небольшими коллективами по нечетко сформулированным техническим заданиям и часто сами рассматривались больше как продукт научной деятельности, чем утилитарный инструмент. Однако уже в 60е-70е годы, по мере распространения вычислительных комплексов в коммерции и промышленности стали критичны многие недостатки тогдашней IT-индустрии, прежде всего, неспособность разработчиков ИС предоставить удовлетворяющий всем требованиям и надежно работающий программный продукт в оговоренные контрактом сроки (которые превышались, как правило, в разы). Для решения этой проблемы были разработаны различные нотации и подходы [55], что потребовало формализации самого жизненного цикла программного продукта, начиная от идеи создания, и кончая полным выводом его из эксплуатации, а также формализации различных этапов цикла.
В соответствии со стандартом ISO/IEC 12207 [56] процессы жизненного цикла программного продукта делятся на 3 группы:
• основные процессы ЖЦ ПО (приобретение, поставка, разработка, эксплуатация, сопровождение); • вспомогательные процессы, обеспечивающие выполнение основных процессов (документирование, управление конфигурацией, обеспечение качества, верификация, аттестация, оценка, аудит, решение проблем);
• организационные процессы (управление проектами, создание инфраструктуры проекта, определение, оценка и улучшение самого ЖЦ, обучение).
В настоящее время разработано большое количество программных продуктов, автоматизирующих каждый из этих процессов, получивших название CASE (Computer Aided Software Engineering)-cpeflCTB, наиблее известные из которых - Designer/2000, Silverrun, ERwin/BPwin, линейка продуктов IBM Rational Software и другие.
Ключевым процессом в формализации жизненного цикла является моделирование программного продукта и различных аспектов его работы. Такое моделирование необходимо для проектирования продукта, а также для формальной спецификации требований к нему, в том числе при согласовании с заказчиком. Разработаны разные нотации описания различных аспектов, такие, как SADT (Structured Analysis and Design Technique - нотация для функциональных диаграмм), DFD (Data Flow Diagrams - диаграммы потоков данных), ERD (Entity-Relationship Diagrams - диаграммы моделирования данных), серия стандартов IDEF (Icam DEFinition - методологии моделирования бизнес-процессов и информационных систем [57]), UCM (Use Case Maps - методология моделирования бизнес-логики ИС [58]), UML (Unified Modeling Language - язык моделирования всех аспектов устройства и работы ПО [22]) и другие. Для всех перечисленных методологий характерен структурный подход, обеспечивающий построение моделей разной детализации. Это позволяет для каждого аспекта сначала определять общую архитектуру, а затем на более поздних этапах проектирования постепенно детализировать отдельные блоки модели, доводя ее при необходимости до уровня детализации программного кода [55]. Получившая в 90е годы объектно-ориентированная парадигма также нашла свое отражение в языках моделирования (UML и другие). По сути, выраженные в них модели являются ориентированными на чтение человеком атрибутированными графами, в которых каждый узел и каждая связь соответствуют какой-либо сущности или связи в предметной области или спецификации создаваемой системы, а семантика атрибутов не всегда четко определена.
Следствием такой ситуации стало появление более узкоспециализированных языков моделирования, расширяющих универсальные нотации новыми элементами с более четкой семантикой, или описывающих модель со структурой, альтернативной графово-объектной. Примером расширений универсальных нотаций являются языки моделирования информационных web-систем WebML, WWM и XWMF [59]. В первой главе настоящей работы представлен подход, реализующий модель бизнес-логики поиска ИС как КС-язык запросов. Как будет показано, такое представление позволяет определить некоторые важные характеристики хранения и обработки данных в ИС.
Важным этапом в проектировании информационной системы, а также в анализе работы существующих систем является анализ информационных, потоков, а также доступности и полезности информации, хранимой в репозитории системы. Структура и семантика такой информации определяется моделью данных репозитория. Традиционно модель данных каждой ИС строится индивидуально, и главным требованием к ней является удобство реализации бизнес-логики требуемой функциональности. В этом случае в онтологию ИС помимо модели данных входят также некоторые правила, определяющие поведение базы знаний системы при ее модификации, включая ограничения целостности, а также правила подчиненности и агрегации объектов.
В последнее время одним из основных направлений работ по интеграции данных стало создание независимых от конкретных ИС онтологии и форматов обмена данными, описывающих определенную предметную область ([1], [2], [3], [4], [18], [20], [21] и другие). Как правило, цель создания таких онтологии - интеграция информации существующих ИС, работатощих в одной предметной области. Логичным следствием такого подхода является создание новых ИС также на основе этих "внешних" онтологии и основанных на них моделей данных.
В 2001 году создатель сервиса WWW и основатель WWW-консорциума [7] Тимоти Бернерс-Ли (Timothy Berners-Lee) опубликовал в журнале Scientific American статью "Семантическая сеть" (The Semantic Web) [8], в которой впервые представил Semantic Web - новое "магистральное" направление развития Internet, одним из главных постулатов которого стала необходимость выделения на веб-ресурсах содержащихся в них знаний в виде уже известной в теории искусственного интеллекта графовой модели. Разработанные для этих целей WWW-консорциумом языки RDF (для описания знаний) и OWL (для описания онтологии) являются хорошей основой для интеграции научных информационных ресурсов и содержащих их систем.
В ВЦ РАН в настоящее время ведется работа по решению этой задачи, а именно, создание ряда интегрированных между собой информационных систем различного назначения и систем автоматизации некоторых областей научной деятельности на основе построенной по стандартам Semantic Web общей масштабируемой и расширяемой онтологии предметной области -"Единого Научного Информационного Пространства" (ЕНИП) [4]. В этой работе принимает участие и автор изложенной ниже диссертационной работы. Одним из компонентов проекта является спроектированная автором и построенная под его руководством ИС Math-Net.RU (версия системы от 17.03.2005) - основа создаваемого Общероссийского математического портала [5].
Двухуровневая поддержка ресурсов и интегрированость данных
Рассмотрим ситуацию, когда пограничный объект является экземпляром одного из классов самоценных в этой ИС объектов. Например, в ИС Math-Net.RU такая ситуация возникает, когда для персоны-математика необходимо указать место работы в нематематической организации, или участие в нематематическом проекте или публикации, в то время как в системе имеются также и математические организации, проекты и публикации. Другим примером является ситуация, возникающая в ЕНИП [4], когда ресурсы общей базы знаний входящих в ЕНИП систем необходимо "разделить" на части, за каждую из которых отвечает соответствующая ИС.
Таким образом, для каждого такого класса онтологии предметной области в ИС возникают 2 подкласса, "своих" и "чужих" объектов, обозначаемых, соответственно, как объекты уровня 1 и уровня 0. Главным отличием этих классов является то, что, как и на все зависимые объекты, на ресурсы уровня 0 вместо требования уникальности в базе знаний ИС налагается требование уникальности в контексте.
Другим следствием зависимого статуса и определения пограничного объекта является то, что контекст пограничного объекта в базе знаний ИС должен состоять только из одного объекта, поскольку если в базе знаний выводимо утверждение вида X.a=Y.b=Z, объект Z по определению перестает быть пограничным. Действительно, это означает, что база знаний ИС уже содержит информацию, не выводимую из факта, что он является значением некоторого свойства некоторого объекта, а именно, информацию о связанности объектов X и Y.
Заметим, что даже если технически возможно создать в базе знаний ИС более одной связи к объекту, имеющему формально уровень 0 (то есть реализовать X.a=Y.b=Z), ответы системы не будут отличаться от случая, когда X.a Y.b, и утверждение X.a=Y.b не будет из них выводимо. В противном случае в бизнес-логике ИС объект Z не будет иметь фактический статус пограничного.
Описанное свойство позволяет в ряде случаев в ИС, реализующей двухуровневую архитектуру, загружать данные с дубликатами, и устранять эти дубликаты позднее, не прерывая работу ИС и не нарушая принципа уникальности самоценных ресурсов. Для этого достаточно объявить ресурсы, потенциально имеющие дубликаты, как ресурсы уровня 0, и по мере слияния дубликатов переводить их на уровень 1. На рисунке ниже показан пример загрузки с отложенной интеграцией информации о публикациях в журналах ОМН РАН и информации Директории российских математиков в ИС Math Net.RU.
В ИС Math-Net.RU объекты уровня 0 не могут являться экземплярами входных точек каких-либо ответов системы. То есть они не находятся запросами атрибутного и полнотекстового поиска ресурсов. Упоминания их как значений свойств других ресурсов не выделяется гиперссылками (для ресурсов уровня 1 такие гиперссылки ведут на интерфейсы просмотра этих ресурсов). В разрабатываемых в настоящее время ИС следующего поколения для ЕНИП гиперссылки для таких ресурсов ведут на страницы других ЕНИП-систем, в которых эти ресурсы являются "своими".
Таксономии и классификация ресурсов в научной ИС
Наиболее общим средством описания структуры информации является классификация информационных объектов с помощью таксономии. В частности, таксономия лежит всегда в основе любой онтологии. Однако часто в ИС необходимо использовать таксономии, реализованные как хранимые данные, а не как часть онтологии. Например, при тематической классификации ресурсов в научных ИС, когда размеры таксономии достигают десятков тысяч понятий, а сам состав понятий может меняться со временем.
Наиболее общей формой таксономии является тезаурус. Заметим, что кроме классификации других ресурсов, тезаурус может быть создан и использоваться как самостоятельная база знаний, показывая место тех или иных понятий в предметной области (например, [24]). В этом разделе описан подход к реализации тезауруса в ИС [23].
Тезаурусом называют совокупность терминов, описывающих данную предметную область, с указанием семантических отношений (связей) между ними является тезаурусом. Такие отношения в тезаурусе всегда указывают на наличие смысловой (семантической) связи между терминами.
Информация, хранимая и доступная в системе
Предполагается, что пользователями системы будут российские и иностранные математики, а также аспиранты и студенты, выбравшие научную работу в области математики в качестве своей будущей профессии. Это означает, что, по крайней мере, часть функций создаваемой системы должна быть доступна широкому кругу любых заинтересованных пользователей, считающих себя в той или иной степени математиками. Пользователями системы также будут административные работники Отделения математики РАН.
Информация, хранимая и доступная в системе
В системе будет храниться любая информация, необходимая для обеспечения научной работы или обучения в области математики. Основными типы хранимых информационных ресурсов являются: 1. Персона. Описывает человека, как ученого, или административного работника; 2: Публикация. Описывает произвольный носитель математической научной информации в виде структурированного математического текста, предназначенный для передачи математических знаний читателям: Например, статья в журнале, журнал, книга, компакт-диск, электронная публикация. В эту группу не включаются математические web-ресурсы (кроме электронной публикации).
3. Организация или подразделение. Описывает научную математическую, организацию или подразделение, а также любую другую организацию или подразделение, деятельность которой связана с научной работой ученых-математиков. Например, издательства, или административные структуры ОМ РАН.
4. Проект или грант. Описывает любые проекты или гранты, в рамках которых осуществляется научная работа в области математики,
5. Конференция или семинар. Описывает любую официальную регулярную или нерегулярную встречу ученых математиков с целью обмена научной информацией. Например, конференцию или семинар.
6. WEB-pecypc. Описывает любой web-pecypc, полезный для ученого-математика в его научной работе (кроме электронных публикаций, поскольку их целесообразнее регистрировать как ресурсы типа публикация).
7. Программное обеспечение. Научное программное обеспечение. Пакеты программ и библиотеки.
Система должна обеспечивать: 1. Поиск ресурсов всех перечисленных выше типов по ключевым словам в значениях их атрибутов, регулярным выражениям и сложным поисковым запросам. 2. Навигацию в пространстве связанных ресурсов по имеющимся связям между ресурсами, а также по рубрикам иерархических тематических рубрикаторов. 3. Разграничение прав доступа к информации между разными категориями пользователей. 4. Возможность пользователям системы самим предоставлять информацию для опубликования в системе или корректировки имеющейся информации. При этом необходимо разграничение прав доступа, а также возможность эффективной обработки вводимой информации редакторами. 5. Пакетный ввод информации разного уровня структурированности из электронных источников, таких как: a. Базы данных. b. Структурированный текст. c. Web-сайты. 6. Актуализация информации из других баз данных. 7. Участие во всемирной математической информационной системе Math-Net в качестве российского узла.
Платформа ИСИР (разрабатывается при участии автора) является универсальной платформой для создания информационных систем разнообразного назначения с web-Интерфейсом [6]. Ниже будут рассмотрены особенности платформы ИСИР 2.0, на основе которой была реализована ИС Math-Net.RU.
В основе ИС, реализованной на платформе ИСИР, лежит так называемое ядро - программное обеспечение, реализующее функции репозитория ИС, а также обеспечивающее поддержку пользовательских сессий и авторизации, включая разграничение доступа разных пользователей к разным объектам базы знаний системы. Ядро предоставляет унифицированные Java интерфейсы для других служб и сервисов платформы, основные из которых:
Сериализацияідесериализация — обеспечивает выгрузку и загрузку данных, сериализованных как RDF/XML-текст.
Индексация и поиск - обеспечивает поатрибутную индексацию заданных текстовых атрибутов ресурсов. По составленному индексу может быть произведен поиск ресурсов с использованием развитого языка запросов.
Web-публикации - средства поддержки публикации данных и реализации пользовательских интерфейсов на основе принципов разделения содержания и представления публикуемых данных.
Аутентификации и взаимодействия с пользователями — обеспечивают средства аутентификации пользователей, их регистрации на сайте, а также включающие реализацию форумов и средств приватного общения.
Принципы работы DBEditor
Подсистема DBEditor является пользовательским интерфейсом нижнего уровня,. то есть работает с классами онтологии, экземплярами и связями между ними полностью абстрагируясь от их семантики. Это позволяет одинаково использовать DBEditor без перекомпиляции и дополнительной настройки в любых информационных системах, построенных на платформе ИСИР. В то же время есть возможность настраивать DBEditor на конкретную информационную систему, устанавливая разные режимы работы с экземплярами разных элементов онтологии исходя из их семантики в модели данных и особенностей работы конкретной ИС.
При извлечении информации об объектной структуре данных DBEditor опирается в большей степени на редактируемые данные, чем на описывающую их онтологию ИС, что позволяет использовать его для контроля правильности и целостности объектных данных.
Подсистема DBEditor может использоваться как инструмент администратора ИС на стороне заказчика, а также как инструмент разработчика для создания и модификации тестовых данных при создании и тестировании программных средств ИС. Подсистема имеет WEB-интерфейс.
Как упоминалось, DBEditor работает с элементами онтологии и их экземплярами, абстрагируясь от их семантики, оперируя такими сущностями, как класс, экземпляр, свойство и величина примитивного типа (литерал). В соответствии с идеологией платформы ИСИР [6] классы делятся на 2 группы: самостоятельных и зависимых объектов (последние могут существовать в хранилище лишь как значения свойств объекта-хозяина). Данные в репозитории ИС с точки зрения подсистемы и ее пользователя представляются как ориентированный граф, в вершинах которого находятся хранимые объекты и значения примитивных типов, а ребрами являются связи (RDF-модель данных). Каждый хранимый объект является экземпляром некоторого класса, и каждая связь описывается в онтологии информационной системы, которая является фиксированной и не модифицируется средствами DBEditor. Кардинальность связей может быть ограничена в онтологии условиями " =1" (обязаетльное свойство), " =1" (однозначное свойство) и — 1" (обязательное и однозначное свойство).
Таким образом, подсистема DBEditor может выполнять следующие операции модификации данных: U Создать новый объект, экземпляр некоторого класса (операция создать). 2. Удалить некоторый объект (операция удалить). 3. Установить связь заданного типа от одного объекта к некоторому другому. существующему объекту (операция добавить для многозначных свойств, или заменить для однозначных). 4. Удалить связь между объектами (операция исключить). 5. Создать литеральный объект как значение некоторого свойства.. 6. Удалить литеральный объект. 7. Изменить значение литерального объекта. Заметим, что операция 7 не является элементарной, ибо является комбинацией операций 5 и 6. Заметим также, что в ряде случаев некоторые операции не могут быть выполнены последовательно. Например, зависимый объект не может быть сначала создан, а затем прикреплен к хозяину, ибо не может существовать самостоятельно. Для решения этой задачи в DBEditor реализована операция создать и добавить (заменить новым для однозначных свойств), делающая обе операции за один шаг. Другим примером является создание экземпляра класса, имеющего обязательные свойства. В этом случае эти связи также должны быть проставлены одновременно с созданием объекта.
Подсистема DBEditor имеет следующие страницы интерфейсов:
1. allclasses - список хранимых классов системы. Эта же страница является стартовой для подсистемы.
2. collection - список коллекции хранимых объектов. Например, результат выборки из репозитория OQL-запросом.
3. instance - хранимый объект, список его свойств и их значений. Используется при создании новых и модификации существующих объектов.
4. choose_class - список допустимых классов - значений некоторого свойства. Служит для выборки типа создаваемого или привязываемого объекта.
5. choose_instance - список экземпляров некоторого класса, доступных для привязки в качестве значения некоторого свойства.
Проблемы, возникающие при преобразовании данных, классификация ошибок и конфликтов
Будем считать, что в репозитории ИС и загружаемых данных каждому ресурсу соответствует один объект реального мира из предметной области ИС. Причем, в загружаемых данных одному объекту реального мира может соответствовать несколько информационных ресурсов (имеются дубликаты), а в целевом репозитории ИС - только один.
При интеграции происходит преобразование информации от исходной онтологии к целевой. Обе эти онтологии (их части, описывающие структуру загружаемых данных) описывают одну предметную область и содержат классы и связи, имеющие сходную семантику. В процессе преобразования новые объекты и связи данных в целевой онтологии вычисляются по объектам и связям загружаемых данных.
Будем исходить из ситуации, когда загружаемые данные заданы как структурированный текст, где каждый синтаксический элемент соответствует некоторому классу онтологии источника, а синтаксические связи и пути между синтаксическими элементами соответствуют связям онтологии источника. Таким образом, онтология источника в нашем случае является концептуальной схемой данных, включающей словарь классов объектов и возможных бинарных отношений с известной семантикой. База знаний, определенная синтаксической структурой, выражена в виде дерева, выделяется средствами синтаксического анализа и представляется как XML-документ.
Связи могут быть выражены не только синтаксически, но и ссылками на объект связи (здесь понятия "связь", "объект" и "субъект" мы понимаем в смысле RDF [10]). Эта ситуация возникает, например, при преобразовании в дерево и сериализации графовых структур, обычно применяемой в репликации данных между разными базами данных и ИС (например - XML-представление RDF-графа базы знаний, где для ссылки используется атрибут rdf:resource). В таких случаях считаем, что в исходной онтологии такое описание связи в загружаемых данных соответствует не только связи, но и ресурсу - объекту связи. Поскольку в загружаемых данных мы допускаем дубликаты, то ограничение, что связями исходной онтологии являются лишь синтаксические связи в структуре текста, не сужает класс решаемых задач.
Таким образом, без ограничения общности считаем, что на входе загрузчика имеем XML-текст с известной структурой и семантикой ее элементов, которую и рассматриваем как. исходную концептуальную схему или онтологию.
Как правило, между исходной и целевой онтологиями нельзя установить взаимно однозначного соответствия по семантике понятий и связей (иначе концептуальные схемы данных совпали бы, и преобразование данных не потребовалось). Обычно существуют различия - конфликты схем данных [52,53].
В наиболее общем виде объекты и связи целевой ОНТОЛОГИИ: представимы как функции от объектов и связей в онтологии источника данных. Такие функции принимают на входе и выдают коллекции из объектов и связей каждого типа. Например, связи представимы как булевские функции, показывающие, есть ли между заданными объектами связь заданного типа. Можно построить преобразователь данных, в котором эти функции будут реализованы на алгоритмическом языке (Java). Но такие функции не могут обладать даже минимальной универсальностью, так как должны быть переписаны даже при незначительных изменениях задачи.
Все классы и связи целевой онтологии имеют свои прототипы в исходной онтологии (классы и связи, по экземплярам которых они вычисляются). Будем считать, что для любых двух ресурсов, связанных между собою в целевой онтологии, можно указать в исходной онтологии соответствующие пути от ресурсов — прототипов субъекта связи, к ресурсам - прототипам объекта связи, и это Xpath-пути в XML-представлении загружаемых данных. Сформулированное ограничение несколько сужает класс задач, решаемых загрузчиком-интегратором. Например, если исходные данные - персоны с указанием возраста, а в репозитории ИС надо проставить связи между теми из них, кто имеет одинаковый возраст — такая задача не входит в рассматриваемый класс задач (указанная связь не имеет прототипа). Многие исследователи, в соответствии со своими потребностями, давали разные классификации конфликтов онтологии (например [52], [53] и [54]). Все эти классификации выделяли, в целом, сходные наборы конфликтов. Применительно к сформулированной выше задаче интеграции на основе существующих работ можно выделить следующий перечень конфликтов:
1. Конфликт типов или форматов атрибутов. Атрибут в одной схеме имеет не тот тип или формат, что у семантически эквивалентного ему атрибута другой схемы. Например, целое число или дата могут быть выражены строкой, дата записана разными способами, а физические величины - в разных единицах измерения.
2. Использование различного набора атомарных атрибутов для описания объектов одного класса. Например, для конференции можно указать даты начала и конца, или дату начала и длительность. Адрес может быть указан как одна строка, либо как набор атрибутов «индекс», «город», «улица» и т.д.
3. Использование различных объектных структур и степени детализации [5] для описания информации об объектах одного класса. Например, персона в одной онтологии может быть представлена строкой, содержащей ее имя, а в другой быть отдельным ресурсом сложной структуры.
Похожие диссертации на Проектирование и реализация научных информационных систем на основе объектной модели данных. Информационная система Math-Net. RU
