Ontology-oriented data integration on the Semantic Web

This paper is devoted to the problem of data integration in the Semantic Web. The process of integration, its main components, namely, construction of integration schemes, the development of mappings between models, the development of ways of manipulation are considered.Prombles in programming 2014;...

Повний опис

Збережено в:
Бібліографічні деталі
Дата:2025
Автор: Chystyakova, I.S.
Формат: Стаття
Мова:Russian
Опубліковано: PROBLEMS IN PROGRAMMING 2025
Теми:
Онлайн доступ:https://pp.isofts.kiev.ua/index.php/ojs1/article/view/711
Теги: Додати тег
Немає тегів, Будьте першим, хто поставить тег для цього запису!
Назва журналу:Problems in programming
Завантажити файл: Pdf

Репозитарії

Problems in programming
id pp_isofts_kiev_ua-article-711
record_format ojs
resource_txt_mv ppisoftskievua/98/b2f9b15ce8e05f7ffa16bb82abcab298.pdf
spelling pp_isofts_kiev_ua-article-7112025-04-09T22:22:32Z Ontology-oriented data integration on the Semantic Web Онтолого-ориентированная интеграция данных в Семантическом Вебе Chystyakova, I.S. UDC 004.62 УДК 004.62 This paper is devoted to the problem of data integration in the Semantic Web. The process of integration, its main components, namely, construction of integration schemes, the development of mappings between models, the development of ways of manipulation are considered.Prombles in programming 2014; 2-3: 188-196 Работа посвящена проблеме интеграции данных в Семантическом Вебе. Рассматривается процесс интеграции, основные его составляющие, а именно: выработка схем интеграции, выработка отображений между моделями, выработка способов манипулирования.Prombles in programming 2014; 2-3: 188-196 PROBLEMS IN PROGRAMMING ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ ПРОБЛЕМИ ПРОГРАМУВАННЯ 2025-04-09 Article Article application/pdf https://pp.isofts.kiev.ua/index.php/ojs1/article/view/711 PROBLEMS IN PROGRAMMING; No 2-3 (2014); 188-196 ПРОБЛЕМЫ ПРОГРАММИРОВАНИЯ; No 2-3 (2014); 188-196 ПРОБЛЕМИ ПРОГРАМУВАННЯ; No 2-3 (2014); 188-196 1727-4907 ru https://pp.isofts.kiev.ua/index.php/ojs1/article/view/711/763 Copyright (c) 2025 PROBLEMS IN PROGRAMMING
institution Problems in programming
baseUrl_str https://pp.isofts.kiev.ua/index.php/ojs1/oai
datestamp_date 2025-04-09T22:22:32Z
collection OJS
language Russian
topic
UDC 004.62
spellingShingle
UDC 004.62
Chystyakova, I.S.
Ontology-oriented data integration on the Semantic Web
topic_facet
UDC 004.62

УДК 004.62
format Article
author Chystyakova, I.S.
author_facet Chystyakova, I.S.
author_sort Chystyakova, I.S.
title Ontology-oriented data integration on the Semantic Web
title_short Ontology-oriented data integration on the Semantic Web
title_full Ontology-oriented data integration on the Semantic Web
title_fullStr Ontology-oriented data integration on the Semantic Web
title_full_unstemmed Ontology-oriented data integration on the Semantic Web
title_sort ontology-oriented data integration on the semantic web
title_alt Онтолого-ориентированная интеграция данных в Семантическом Вебе
description This paper is devoted to the problem of data integration in the Semantic Web. The process of integration, its main components, namely, construction of integration schemes, the development of mappings between models, the development of ways of manipulation are considered.Prombles in programming 2014; 2-3: 188-196
publisher PROBLEMS IN PROGRAMMING
publishDate 2025
url https://pp.isofts.kiev.ua/index.php/ojs1/article/view/711
work_keys_str_mv AT chystyakovais ontologyorienteddataintegrationonthesemanticweb
AT chystyakovais ontologoorientirovannaâintegraciâdannyhvsemantičeskomvebe
first_indexed 2025-12-02T15:45:36Z
last_indexed 2025-12-02T15:45:36Z
_version_ 1850411950549237760
fulltext Моделі і засоби систем баз даних і знань © И.С. Чистякова, 2014 188 ISSN 1727-4907. Проблеми програмування. 2014. № 2–3. Спеціальний випуск УДК 004.62 ОНТОЛОГО-ОРИЕНТИРОВАННАЯ ИНТЕГРАЦИЯ ДАННЫХ В СЕМАНТИЧЕСКОМ ВЕБЕ И.С. Чистякова Институт программных систем НАН Украины, 03187, Киев-187, проспект Академика Глушкова, 40. Тел. +38(044)526 6249. E-mail: inna_islyamova@ukr.net Работа посвящена проблеме интеграции данных в Семантическом Вебе. Рассматривается процесс интеграции, основные его со- ставляющие, а именно: выработка схем интеграции, выработка отображений между моделями, выработка способов манипулирова- ния. This paper is devoted to the problem of data integration in the Semantic Web. The process of integration, its main components, namely, con- struction of integration schemes, the development of mappings between models, the development of ways of manipulation are considered. Определение проблемы интеграции Интеграция данных является одним из наиболее востребованных направлений в современной информа- ционной индустрии. За все годы существования Интернет-пространства в нем скопилось большое количество информации, объем которой с каждым днем возрастает в геометрической прогрессии, а релевантность – в арифметической. Это порождает множество проблем связанных с использованием и хранением данных инфор- мационного пространства. Огромные объемы разнородных данных в гетерогенных источниках представляют информацию различными способами и имеют разнообразное функциональное назначение. Интеграция и сов- местное использование информации из множества таких источников данных является сложной задачей, оста- ющейся неизменно актуальной на протяжении последних десятилетий. Можно выделить несколько порождающих причин гетерогенности: 1) различные модели данных. Согласно разным сведениям от 75% до 90% (в зависимости статистиче- ского источника) информации хранится в РБД. Однако, на оставшиеся проценты приходится немалое количе- ство данных, хранящихся в структурах, которые определяются совершенно другими моделями данных со своей специфической семантикой. В этих условиях не представляется возможным иметь согласованный доступ одно- временно ко всем источникам информации; 2) различные способы хранения данных (файлы, БД, хранилища и т. д.). Физическая организация хране- ния информации создает дополнительные препятствия к ее использованию. Интеграция данных должна предо- ставить единый логический формат организации данных таким образом, что независимо от способа их физиче- ского хранения, конечный пользователь имеет единый механизм доступа к содержимому; 3) существенная распределенность данных. Источники информации изолированы друг от друга, каждый из которых подчиняется концепции «замкнутого мира». Такой подход значительно затрудняет введение прин- ципиально новых понятий различных предметных областей, порождает дублирование данных, что приводит к увеличению объема, но уменьшению релевантности искомой информации. Интеграция данных способна устра- нить такую изолированность источников друг от друга, тем самым способствуя согласованному использованию уже существующих данных, устранение дубликатов, а также оперативному возникновению новой информации; 4) неполнота и противоречивость данных. Отсутствие семантической составляющей современных ис- точников порождает проблему неполноты сведений каждого из них в отдельности. А при рассмотрении сово- купности этих источников возникает проблема противоречивости. Интегрция данных призвана устранить эти недостатки путем введения единого семантического контекста для всех информационных ресурсов, хранящих- ся в интегрированных источниках; 5) различные способы оперирования данными (манипулирование, поиск, выборка и т. д.). Существую- щие возможности поисковых систем общего назначения не позволяют обеспечить эффективный поиск инфор- мации. Каждая модель данных предполагает существоввания своих собственных средств манипулирования, что порождает их разнообразие, приводящее к гетерогенности данных. Ввиду всего вышесказанного становится очевидной важность решения комплексной проблемы инте- грации. Проблема интеграции данных заключается в таком логическом объединении данных, принадлежащих разнородным источникам, которое обеспечивает единое представление и оперирование этими данными. Систе- ма интеграции данных позволяет освободить пользователя от необходимости самостоятельно отбирать источ- ники, в которых находится интересующая пользователя информация, обращаться к каждому источнику по от- дельности и вручную сопоставлять и объединять данные из различных источников. Моделі і засоби систем баз даних і знань 189 Акцентируя внимание на разнородности данных, следует прояснить это понятие. Данные разнородны не с точки зрения их физического хранения, а с точки зрения модели их представления. То есть, вне зависимости от места их расположения и способа их хранения, для решения проблемы интеграции важную роль играет мо- дель представления данных со своей специфической семантикой, которая предоставляет механизмы организа- ции работы с данными для конечного пользователя. В работе [4] авторы выделили следующие признаки неоднородности данных: 1. Модель. Структурные различия моделей данных порождают схематическую гетерогенность. 2. Синтаксис. Порождается в связи с наличием различных языков описания моделей данных. 3. Семантика. Порождается различным определением данных в различных контекстах. При этом, каждый из этих признаков может присутствовать независимо от двух остальных, например, семантическая гетерогенность может возникать даже в том случае, если схематическая и синтаксическая разно- родности отсутствуют (именование концептов и т. д.). В связи с тем, что далее мы будем много раз говорить о моделях данных, следует дать определение этому понятию. Данные – представление фактов и идей в формализованном виде, пригодном для передачи и обработки в некотором информационном процессе. Данные, могут подвергаться обработке, и результаты обработки фикси- руются в виде новых данных. Модель данных – интегрированный набор понятий для описания и обработки данных, связей между ними и ограничений, накладываемых на данные в некоторой организации. Цель построения модели данных заключается в представлении данных в понятном виде. Можно по-разному характеризовать понятие модели данных. С одной стороны, модель данных – это спо- соб структурирования данных, которые рассматриваются как некоторая абстракция в отрыве от предметной области. С другой стороны, модель данных – это инструмент представления концептуальной модели предмет- ной области и динамики ее изменения. На этапе выработки схем интеграции данных, модель является представлением "реального мира" объек- тов и событий, а также существующих между ними связей. Это некоторая абстракция, в которой акцент делает- ся на самых важных и неотъемлемых аспектах ПО, а все второстепенные свойства игнорируются. Модель должна отражать основные концепции, представленные в таком виде, который позволит проектировщикам и пользователям обмениваться конкретными и недвусмысленными мнениями о роли тех или иных данных в ПО. Модель данных можно рассматривать как сочетание указанных ниже компонентов [7]:  структурная часть (набор правил, определяющих типы и характеристики логических структур дан- ных);  управляющая часть, определяющая типы допустимых операций с данными (описываются правила со- ставления структур более общего типа из структур более простых типов, сюда относятся операции обновления и извлечения данных, а также операции изменения структуры экземпляра модели);  набор ограничений поддержки целостности данных, гарантирующих корректность используемых данных. Сюда входят возможные действия над структурами и правила их выполнения, включающие:  средства контроля относительно простых условий корректности ввода данных (ограничения);  средства контроля сколь угодно сложных условий корректности выполнения определенных дей- ствий (правила). Модели данных подразделяются на три категории [9]: 1. Объектные модели данных (описание данных на концептуальном и внешнем уровнях). При создании объектных моделей данных используются следующие понятия:  сущность — это отдельный концептуальный элемент ПО  атрибут — это свойство, которое описывает некоторый аспект объекта и значение которого следует зафиксировать.  связь — это ассоциативное отношение между сущностями. Наиболее общие типы объектных моделей данных:  ER-модель (Entity-Relationship model);  семантическая модель (онтология);  функциональная модель;  объектно-ориентированная модель (расширяет определение сущности с целью включения в него не только атрибутов, которые описывают состояние объекта, но и действий, которые с ним связаны, т. е. его поведение) 2. Модели данных на основе записей (описание данных на концептуальном и внешнем уровнях). В модели на основе записей база данных состоит из нескольких записей фиксированного формата, кото- рые могут иметь разные типы. Каждый тип записи определяет фиксированное количество полей, каждое из ко- торых имеет фиксированную длину. Существуют три основных типа логических моделей данных на основе записей:  реляционная модель данных; Моделі і засоби систем баз даних і знань 190  сетевая модель данных;  иерархическая модель данных. 3. Физические модели данных (описание данных на внутреннем уровне). Физические модели данных описывают то, как данные хранятся в компьютере, представляя информацию о структуре записей, их упорядоченности и существующих путях доступа. Физических моделей данных не так много, как логических, а самыми популярными среди них являются обобщающая модель (unifying model) и мо- дель памяти кадров (frame memory). Возвращаясь к проблематике интеграции, следует обратить внимание, что согласно [1] проблема инте- грации является комплексной и многоаспектной. В то время, как ее основной целью является обеспечить гомо- генное, унифицированное представление данных различных источников, конкретная задача интеграции может зависить от множества факторов. Среди них: архитектурное представление информационной системы; содер- жимое и функциональность систем; вид информации, которой оперируют системы (числовые данные, мульти- медийные данные; структурированные, полу-структурированные, неструктурированные данные); и т. д. На сегодняшний день мы выделяем три основных составляющих проблемы интеграции данных:  выработка схем интеграции данных;  выработка отображений между моделями;  выработка способов манипулирования, суть которых раскрывается далее. Выработка схем интеграции данных Опираясь на исследования [1], а также фундаментальную работу [3] мы рассматриваем 2 типа схем инте- грции данных: Р2Р (peer-to-peer) схема (ещё её называют одноранговой) и централизованая схема. В Р2Р схеме (рис. 1) не существует глобальных точек контроля. В основе каждого узла, принимающего участие в схеме, лежит своя модель данных. Каждый узел равноправен и может принимать запросы пользо- вателя к информации, распределенной по всей системе. Преимущества этой схемы заключаются в следую- щем: где бы ни был выполнен запрос на информацию, в какой из точек данные ни находились бы, узел, пр и- нявший запрос, имеет прямой и непосредственный доступ к каждой точке системы, вследствие чего ему от- крывается абсолютно вся информация, хранящаяся в ней. Существенным недостатком можно назвать следу- ющее: при добавлении нового узла в схему, необходимо установить соответствия с ним существующих уз- лов. При небольшом объеме это сделать нетрудно, но с последующим увеличением количество точек, воз- растает количество взаимодействий, которые требуется установить внутри схемы, возрастает сложность этих взаимодействий, увеличивается трудоемкость работы проектировщика. Система, основаная на такой схеме становится все более громоздкой и хрупкой, гетерогенность моделей налагает дополнительные сложности на установление связей друг с другом, исходя из особенностей собственных структурных отличий, а также осо- бенностей своих компонент. Рис. 1. Одноранговая (Р2Р) схема интеграции данных Данные недостатки породили развитие другого подхода – централизованой схемы. На сегодняшний день она является наиболее успешной для решения комплексной проблемы интеграции данных. Применяется во многих системах и лежит в основе подходов к выработке отображений между моделями системы, а также к разработке способов манипулирования. В централизованной схеме (рис. 2) обычно присутствует одна глобальная точка контроля. В основе этого узла лежит своя модель данных. В работе [3] ее называют глобальной схемой, а все остальные модели – ло- кальными схемами, или схемами источников. Мы также будем придерживаться этой терминологии в дальней- шем. Основная роль глобальной схемы – предоставление пользователю единого интерфейса для доступа к ин- формации, хранящейся в реальных источниках данных. Преимуществом такой системы является возможность объедининения любого количество узлов без существенных потерь, т. к. сами локальные схемы могут взаимо- действовать между собой любым доступным способом. Главным остается связь с глобальной схемой, обеспе- Моделі і засоби систем баз даних і знань 191 чивающей единое согласованое представление данных пользователю и предоставление централизованого по- иска. Критическим моментом централизованой схемы остается разработка отображений между моделями, а именно схемами источников и глобальной схемой. При рассмотрении подходов взаимодействия глобальной и локальных схем будут рассмотрены недостатки каждого из подходов, которые в целом являются недостатками всех централизованой схемы интеграции данных. Рис. 2. Централизованая схема интеграции данных В своих исследованиях, при выработке схем мы остановились именно на втором подходе, а именно на централизованой схеме интеграции данных. Развивая далее эту тему, возникает вопрос, а какую же модель дан- ных выбрать в качестве глобальной схемы? Рассмотрев современные модели данных, наиболее подходящей для выполнения задачи предоставления пользователю единого согласованого представления данных, является он- тологическая модель или онтология. В свое время было сформулировано понятие семантической интеграции данных как процесса исполь- зования концептуального представления данных, а также их взаимоотношений для ликвидации возможных не- однородностей [4]. Мы уточнили это определение следующим образом. Семантическая (онтолого-ориентированная) интеграция данных – использование онтологии в каче- стве объединяющей модели для:  описания и поддержания отображений между различными моделями данных;  унифицированного манипулирования данными. Использование онтологий для семантической интеграции данных аргументируется следующими факто- рами:  онтология является самой развитой моделью данных;  онтологии обладают более развитой семантикой;  онтологии предоставляют самые мощные механизмы вывода;  онтологии имеют четкую формальную спецификацию (дескриптивная логика). Мы понимаем онтологию в ее стандартном, классическом определении, которые сформулировано много лет назад, а именно. Онтология – это формальная, явная спецификация согласованной концептуализации [5]. Онтология, как модель данных, представляется следующими компонентами: 1. Структура.  классы – концептуальное представление некоторых общих понятий;  индивиды – конкретные экземпляры класса;  свойства – позволяют утверждать общие факты о классах и специфические факты об индивидах. 2. Ограничения целостности.  отношения – таксономия классов, таксономия свойств, принадлежность индивида классу, область определения и область значений свойства (способы, с помощью которых классы и индивиды могут быть связа- ны друг с другом);  правила – способ задания других видов ограничений, которые не поддерживаются отношениями. 3. Операции  теоретико-множественные операции на классах и свойствах (объединение, пересечение, дополне- ние);  ограничения свойств по существованию и общности (квантификация свойств);  численные ограничения свойств (функциональные, количественные, качественные);  и другие. Моделі і засоби систем баз даних і знань 192 Как видно из всего выше сказанного, используя централизованую схему интеграции данных для решения комплексной проблемы интеграции, онтология наилучшим образом подходит в качестве глобальной схемы, что позволяет в качестве локальной схемы использовать любую модель данных. Вопрос взаимодействия внутри такой системы относится к следующей общей проблеме интеграции – выработке отображений между моделя- ми. Выработка отображений между моделями Рассмотрим абстрактную систему интеграции данных, основанную на архитектуре централизованой схемы. Задача такой системы, называемой также посредником, заключается в том, чтобы предоставить инте- грированный доступ к множеству распределенных, разнородных, автономно разработанных источников, без необходимости централизовано хранить всю информацию из источников. Система предоставляет пользователю возможность формулировать запросы на выборку информации из таких источников в терминах глобальной схемы данных (общей системы понятий), которая проектируется «сверху» исходя из интересующих пользова- теля аспектов предметной области. При этом в каждом источнике информация может представляться в терминах собственной схемы данных (системы понятий), соответственно, при включении источника в систему указывается некоторое семантическое отображение между терминами глобальной схемы данных и терминами различных схем данных источников. В работе [3] дается следующее определение системы интеграции данных (СИД). СИД І представляется тройкой  MSG ,, , где  G – глобальная схема, описанная в языке GL над алфавитом GA . Алфавит содержит символы каждо- го элемента G (отношения, если G – реляционная, классы, если G – объектно-ориентированная). В нашем случае, алфавит содержит символы, соответствующие всем концептам и ролям онтологии.  S – схема источника, описанная в языке SL над алфавитом SA . Алфавит содержит все символы ис- точника.  M – отображения между G и S , образованные набором утверждений в форме Sq ↝ Gq , Gq ↝ Sq где Gq и Sq – два запроса одинаковой арности, сформулированных в языке GML , и SML  соответственно. За- пись Sq ↝ Gq означает, что каждый концепт источника, представленный запросом Sq соответствует концепту глобальной схемы, представленной запросом Gq (аналогичным образом трактуется утверждение Gq ↝ Sq ). По утверждению автора, данное определение охватытвает все подходы, известные в литературе, но каж- дый специфический подход зависит только от характеристик отображений и выразительной мощности схем и языков формулирования запросов. Предлагается два подхода, определяющие отображения в СИД. Они называются LAV (Local-as-view) и GAV(Global-as-view). LAV В СИД I =  MSG ,, , основанной на LAV-подходе, отображение M связывает каждый элемент s схемы источника S с запросом Gq к схеме G . Другими словами, язык запросов SML , разрешает только выражения, образованные одним символом алфавита SA . Таким образом, LAV отображение – это набор утверждений, по одному на каждый элемент s из схемы S , в форме s↝ Gq . С точки зрения моделирования, подход LAV основывается на идее, что каждый элемент источника s должен быть связан запросом qG с соответствующим элементом глобальной схемы. Запрос формулируется в языке источника с последующим переформулированием в терминах G . Добавление нового источника сводится к обогащению набора отображений новыми утверждениями без прочих изменений. GAV В GAV-подходе отображения M связывают каждый элемент g схемы данных G запросом Sq с элемен- том источника S . Другими словами, язык запросов GML , разрешает только выражения, образованные одним символом алфавита GA . Таким образом, GAV-отображение – это набор утверждений, по одному на каждый элемент g из схемы G , в форме g↝ Sq . С точки зрения моделирования, подход GAV основывается на идее, что каждый элемент g глобальной схемы должен быть связан запросом Sq с соответствующим элементом c выбранным источником данных. Отображение говорит нам, как нужно извлечь данные из источника, когда кто-то хочет оценить различные дан- ные глобальной схемы. Главным в подходе является обработка запросов, т. к. с их помощью система знает как использовать ис- точники для извлечения данных. Однако, добавление нового источника является серьезной проблемой, т. к. некоторые элементы глобальной схемы должны быть переопределены. У каждого из этих подходов есть свои преимущества и недостатки. Моделі і засоби систем баз даних і знань 193 1. В подходе LAV сложно сформулировать запрос. Представление элемента в ГС одно, а запрос форми- руется в терминах ИД (алфавит ИД, язык ИД). Но добавление нового ИД не является проблемой, т. к. формули- рование запросов – задача самого источника. 2. В подходе GAV легко сформулировать запрос, т. к. мы сразу знаем, какой запрос к ИД соответствует элементу ИД. Представление элемента едино, алфавит и язык формулирования запросов един. Но добавление нвого источника является проблемой, т. к. некоторые представления необходимо бедт переопределить для формулирования запросов и к новому источнику тоже. 3. В то время, как проектировщик LAV концентрируется на том, как представить данные источника в терминах ГС, проектировщик GAV решает проблему, как извлечь необходимые данные из предоставленных источников. 4. Подход LAV нужен для задач, в которых много разнородных ИД, но объем данных не сильно велик. Подход GAV нужен для задач с небольшим количеством источников, но с очень большим объемом данных. Принципиально новым является суть понятия отображения. Оно представляет собой запрос, а не оче- редное отношение между элементами моделей. Это означает, что в основе взаимодействия между элементами моделей лежит некоторый логический аппарат конкретного языка формулирования запроса. В своей работе [6] автор предлагает создавать так называемые «обертки» для каждого из источников си- стемы. Они представляют собой локальные схемы, представленные в той же самой модели данных, что и гло- бальная схема. Предполагается, что каждый информационный источник «обернут» промежуточным компонен- том-адаптером, который отвечает за выборку сведений из источника в рамках единой модели данных, а также за предоставление стандартного технического интерфейса для обращения к источнику (сетевой протокол, язык запросов). Пользователь не взаимодействует с источниками напрямую, а обращается к выделенному компонен- ту-посреднику, который отвечает за обслуживание пользовательских запросов и взаимодействие с источника- ми. «Обертывание» каждого источника информации в локальную онтологию позволяет развиваться онтологии- источнику вне зависимости от других онтологий. Следовательно, задача интеграции может быть упрощена и добавление или удаление источников можно легко поддерживать. Выработка способов манипулирования После выработки отображений между моделями данных возникает вопрос применимости таких систем, то есть каким образом можно манипулировать созданными глобальными схемами и управлять данными, распо- ложенными внутри различных систем. «Обертывание» источников данных углубляет этот вопрос тем, что дает возможность использовать эти источники вне существующей системы, а также расширяет возможности мани- пулирования данными на уровне единой принятой модели. Поскольку мы сводим всю комплексную проблему интеграции данных к онтологической модели, то вви- ду этого остро возникает проблема манипулирования онтологиями. Решая эту проблему, мы решаем в полной мере общую проблему интеграции. В проблеме манипулирования онтологий важны следующие два аспекта: выработка подходов по инте- грации онтологий и определение множества операций манипулирования онтологиями, которые обсуждаются далее. Интеграции онтологий В работе [2] дается три определения интеграции онтологий: 1. Интеграция как повторное использование. В данном случае, интеграция онтологий рассматривается как процесс создания новой онтологии с по- мощью повторного использования уже существующих, доступных онтологий (путем сборки, расширения, спе- циализации, адаптации) (рис. 3). Рис. 3. Интеграция онтологий: повторное использование В процессе интеграции существуют одна или несколько первоначальных онтологий ),...,,( 21 nOOO , а также итоговая онтология O , которая образуется в результате процесса интеграции. Домены ),...,,( 21 kDDD могут отличаться от результирующего домена D , но между ними могут существовать связи. При этом, обычно nk  , но такое может быть не всегда, так как в процессе интеграции могут участвовать несколько различных Моделі і засоби систем баз даних і знань 194 онтологий принадлежащих одному и тому же домену. В результате процесса интеграции образуется онтология O такая, что аналогичной не существует. В противном случае одна из них должна будет повторно использо- вать другую. 2. Интеграция как объединение. В данном случае, интеграция онтологий рассматривается как процесс создания новой онтологии с помо- щью объединения нескольких онтологий в одну которая обобщает их все (рис. 4). Рис. 4. Интеграция онтологий: объединение В процессе интеграции участвуют несколько первоначальных онтологий онтологий ),...,,( 21 SOOO , а также итоговая онтология O , которая образуется в результате процесса интеграции, которую в этом случае иногда называют объединением. Начальные онтологии принадлежат одному и только одному домену S, кото- рому также принадлежит результирующая онтология. Целью данного процесса является создание более общей онтологии на заданном домене, собирая в единое целое знания нескольких онтологий этого домена. Уровень обобщенности первоначальных онтологий может отличаться. 3. Интеграция как использование в программном обеспечении. В данном случае, интеграция онтологий рассматривается как процесс создания программного приложе- ния, основанного на использовании нескольких онтологий. Рис. 5. Интеграция онтологий: использование В процессе интеграции участвуют несколько первоначальных онтологий онтологий ),...,,( 21 nOOO , но в результате не создается никакой новой онтологии. Некоторое приложение A просто использует готовые онто- логии, а результат зависит от архитектуры и назначения самого приложения. Онтологии должны быть совме- стимы между собой по следующим критериям: язык описания, онтологические соглашения, уровень детализа- ции, уровень обобщения, модульность, контекст и т. д. Операции над онтологиями. Что касается операций манипулирования онтологиями, то можно выделить следующие два вида опера- ций над онтологиями: сопоставление и оперирование. Сопоставление решает проблему установления различно- го рода (семантических) соответствий между онтологиями. Оперирование – это набор унарных и бинарных операций создания новых онтологий из существующих. Мы кратко представим только операции сопоставления, как наиболее важные при решении проблемы интегра- ции онтологий. Уточнение (refinement). Под уточнением онтологий понимают такое сопоставление онтологии A с другой онтологией B , что каждому понятию из онтологии A ставится в соответствие эквивалентное ему поня- тие в B . Примитивные понятия из онтологии A могут соответствовать непримитивным понятиям онтологии B (рис. 6). Моделі і засоби систем баз даних і знань 195 Рис. 6. Уточнение Унификация (unification). Онтология приводится к некоему каноническому (эталонному) представле- нию. Для унификации должна задаваться исходная онтология, которая приводится к результирующей согласно заданной канонической онтологии. Задача унификации множества исходных онтологий становится актуальной при работе с гетерогенными онтологиями (рис. 7). Рис. 7. Унификация Отображение (mapping). Отображение одной онтологии в другую – это функция преобразования од- ной онтологии в другую (способ перевода объектов одной онтологии в другую), либо сам результат такого преобразования. Часто это означает перевод между понятиями и отношениями. Отображение может быть частичным в том смысле, что не все понятия исходной онтологии отображаются в результирующую. В част- ности, это означает, что в исходной онтологии существует подонтология, для которой существует полное отображение (рис. 8). Рис. 8. Отображение Согласование (alignment). Это процесс отображения онтологий в обоих направлениях. Согласование, как и отображение, может быть лишь частичным. Спецификация согласования называется артикуляцией (articulation) (рис. 9). Моделі і засоби систем баз даних і знань 196 Рис. 9. Согласование Интеграция (integration). Это процесс поиска одинаковых частей двух разных онтологий, A и B , при разработке новой онтологии C , которая позволяет выполнить перевод между онтологиями A и B , и, таким образом, позволяет взаимодействие между двумя системами, где одна использует онтологию A , а другая – он- тологию B . Новая онтология C может заменить онтологии A и B или может использоваться в качестве про- межуточной онтологии для перевода между двумя онтологиями. Интеграция может меняться от согласования к унификации. Наследование (inheritance). Означает, что онтология A наследует все из онтологии B . Она наследует все понятия, отношения и ограничения или аксиомы, и дополнительные знания, содержащиеся в онтологии, не внося при этом какой-либо несогласованности. Выводы Интеграция данных в информационном пространстве является важной научной проблемой. Существует множество подходов к её решению. Было выявлено три составляющие комплексной проблемы интеграции, в процессе рассмотрения которых мы остановились на централизованой схеме интеграции данных и онтологиче- ской модели, в качестве единой модели на роль глобальной схемы данных. Приведена аргументация данного выбора, дана характеристика онтологии как модели данных, проанализированы способы манипулирования он- тологиями. Были определены операции манипулирования онтологиями, а именно уточнение, унификация, отображение согласование, интеграция, наследование. 1. Patrick Ziegler, Klaus R. Dittrich Three Decades of Data Integration // All Problems Solved? Database Technology Research Group, Depart- ment of Informatics, University of Zurich Winter thurerstrasse 190, CH-8057 Zürich, Switzerland. 2. H. Sofia Pinto Some Issues on Ontology Integration. Proceedings of the IJCAI-99 workshop on Ontologies and Problem-Solving Methods (KRR5) Stockholm, Sweden, August 2, 1999. 3. Lenzerini M. Data Integration: A Theoretical Perspective // Proc. of the 21st ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems (PODS 2002). N. Y.: ACM Press, 2002. P. 233–246. 4. Isabel F. Cruz, Huiyong Xiao The Role of Ontologies in Data Integration. Jounal of Engineering Intelligent Systems – 2005. - №4. 5. Guarino N. and Giaretta P. Ontologies and Knowledge Bases: Towards a Terminological Clarification. In N. Mars, editor, Towards Very Large Knowledge Bases: Knowledge Building and Knowledge Sharing, IOS Press, Amsterdam, 1995. – P. 25–32. Nicola Guarino1, Daniel Oberle2, and Steffen Staab3. 6. Бездушный А.А. Математическая модель системы интеграции данных на основе онтологий // Журнал «Вестник НГУ», серия «Инфор- мационные технологии» – Новосибирск, 2008. – Т. 6, вып. 2. – С. 15–40. 7. Пасічник В.В., Резніченко В.А. Організація баз даних та знань: підручник для ВНЗ. – К.: Видавнича група BHV, 2006. – 384 c. 8. http://ru.wikipedia.org/wiki/Данные. 9. http://wiki.auditory.ru/ БД: Лекция_№ 07