Интеграция баз данных на основе онтологий

Интеграция баз данных на
основе онтологий
Тузовский А.Ф.
Томский политехнический
университет
(институт Кибернетики )
Интеграция баз данных на
основе онтологий
Развитие систем интеграции
информации
Тузовский А.Ф.
Томский политехнический
университет
(институт Кибернетики )
Постановка задачи интеграции
• Задача интеграции данных заключается в
соединении данных из различных источников и
предоставлении пользователю единого
(унифицированного) представления этих данных, в
том числе возможности извлечения интересующей
пользователя информации по запросу.
• Система интеграции данных позволяет освободить
пользователя от необходимости самостоятельно
отбирать источники, в которых находится
интересующая пользователя информация,
обращаться к каждому источнику по отдельности, и
вручную сопоставлять и объединять данные из
различных источников.
Проблемы задачи интеграции
данных
• Разнородность (гетерогенность) источники
данных используют разные модели (и даже
метамодели).
• Автономность, то есть источники разработаны и
эксплуатируются независимо друг от друга,
независимо спроектированы под решение
конкретных, различных задач, различными
методами.
• Распределенность источники физически или
логически, доступными через только сетевые
протоколы удаленного доступа, в частности,
информационные источники могут быть
распределены в сети Интернет.
Виды разнородности
•
•
•
•
•
•
различие моделей данных – данные в различных источниках могут представляться
разными способами, в различных моделях данных (например, реляционная, объектноориентированная модели данных, XML, слабоструктурированные,
неструктурированные данные, и т.д.);
синтаксическая неоднородность – данные могут по-разному представляться при
передаче их в соответствии с протоколами взаимодействия (например, бинарные,
текстовые, XML, и т.д.);
структурная неоднородность – данные в различных источниках могут по-разному
представлены и организованы в структуру (например, ФИО может быть представлено
одной строкой или тремя строками);
семантическая неоднородность – данные могут быть представлены в различных
системах понятий, схожие понятия могут по-разному интерпретироваться в разных
источниках данных.
техническая неоднородность – интегрируемые информационные системы –
источники данных работают под управлением различных операционных систем, на
различном техническом обеспечении, предоставляют различные способы
коммуникации для доступа к системе, различные интерфейсы и протоколы
взаимодействия, и т.д.;
неоднородность методов доступа к данным - в частности, различное назначение и
выразительность языков запросов для извлечения данных, различные ограничения на
форму запросов;
Обобщенная архитектура систем
интеграции информации
Общие компонентами являются
• Посредники
• Адаптеры
• Дополнительные подсистемы
• Обычно система, основанная на посредниках
не поддерживает работу с данными
(добавление, изменение, удаление данных).
Посредник
(или посредники)
• интерфейс доступа, который используется приложениями
интегрированной системы, либо с помощью промежуточного ПО (Web
Service, SPARQL и т.п.) или с помощью прикладного интерфейса API.
• процессор запросов (query processor), которые отвечает за разделение,
оптимизацию и выполнение запросов поступающих в систему.
• каталог метаданных (metadata catalog) (или база знаний в случае
систем, основанных на онтологиях), который хранит
• глобальную модель данных, которая может описываться (defined) и
поддерживаться явно (defined) или неявно, как объединение всех локальных
моделей данных.
• статистические данные, такие, как селективности (selectivities) или
гистограммы (histograms).
• Компонент регистрации (registry) используемый для регистрации и дерегистрации источников данных (обычно регистрация требует
предоставления метаданных о источнике и отображения модели (model
mapping)).
Процессор запросов
• центральный элемент посредника;
• выполняет следующие действия:
–
–
–
–
–
–
–
–
получения запроса пользователя
разбор запроса;
формирование общего плана выполнения.
формирование под-планов к адаптерам
источников;
оптимизация по времени обработки (стоимости);
отправка под-планов адаптерам источников;
получение результатов;
формирование ответа пользователю.
Адаптеры (wrappers)
• компоненты, связанные с источниками
данных для решения проблем технической
разнородности и разнородностей
метамоделей.
• Регистрация в посреднике.
• принимают запросы к источнику на некотором
языке.
• преобразует запрос в язык источника;
• Выполняет запрос.
• Отправляет результаты посреднику.
Постановка задачи
• Формально систему интеграции данных T можно
описать в виде триплета <G, S, M>, где:
– G – глобальная модель (схема) описанная на языке LG с
использованием алфавита AG, который состоит из символов
для описания элементов схемы в G;
– S – исходная модель (схема) описанная на языке LS с
использованием алфавита AS, который включает символы
для элементов всех источников;
– M – отображение (mapping) между G и S, описанное в
форме утверждений (assertions): qS ⤳ qG и qG ⤳ qS
• Такое определение не ограничивается только
реляционной моделью, т.е., система интеграции,
основанная на RDF будет использовать такие понятия
языка RDF, как классы, свойства и типы данных в
качестве элементов схемы.
Формирование глобальной
онтологии (предметной области)
• Моделирование онтологии конкретных предметных областей,
(domain ontologies) является дорогой и трудоемкой задачей,
требующей участия экспертов
• Однако данная работа должна быть выполнена только один раз
основным сообществом, которое умеет разрабатывать и
поддерживать словари с помощью средств совместной работы
разработанных сообщество Semantic Web.
• Даже не эксперты могут добавлять и отображать (map) новые
источники данных с помощью широко признанных
вспомогательных онтологий, например,Dublin Core, FOAF, SOAP,
DOAP и т.д.).
• Для конкретной прикладной области разумным считается
следующий подход:
– вначале выполнить поиск существующих онтологий,
– затем заполнить разрывы между ними на основе подхода снизувверх (bottom-up, от частных понятий к более общим).
• Эксперименты во многих прикладных проектах
Semantic Web показали, что специальный подход
сверху-вниз часто является не очень многообещающим,
приводящим к долгим философским спорам между
участниками.
• Обычно не практичным является попытка описать сразу
всю предметную область, хотя начальные источники
данных описывают только небольшую часть данной
предметной области.
• Вместо этого, обычно лучше использовать подход снизувверх (bottom-up) и моделировать необходимые
понятия (concepts) на основе существующих онтологий,
в тоже время сохраняя некоторую степень
обобщенности и планируя возможные будущие точки
расширения.
Онтология предметной области
наблюдения за солнцем
Отображение моделей
• Два основных подхода к спецификации семантического
отображения терминов в системах интеграции данных:
– Global-as-view - отдельные глобальные понятия специфицируются
в терминах локальной системы понятий:
qS ⤳ q G
подходит для статичных систем интеграции данных,
проектируемых «снизу вверх»,
– Local-as-view - отдельные локальные понятия специфицируются в
терминах глобальной системы понятий:
qG ⤳ q S
подходит для динамичных систем интеграции данных,
проектируемых «сверху вниз».
• Некоторым компромиссом является гибридный подход GLAV.
Формирование и описание
отображений
• Формальное описание соответствий или логическое
отображение (logical mapping), соответственно, в
действительности зависит от метамоделей и
возможностей системы интеграции в целом.
• Например:
– При работе с реляционными базами данных, в
качестве языка отображения может использоваться
SQL, так как отображения могут быть описаны в виде
SQL представлений (views).
– Язык описания онтологий OWL.
– Язык правил SWRL или RIF.
– Язык D2RQ-Map, используемый сервером D2R-Server
для формирования отображений реляционной модели
на язык RDF.
•
Когда поступает запрос к целевой модели (например, к виртуальной
глобальной модели), то система использует логическое отображение для
формирования локальных запросов и для соответствующего
преобразования всех исходных данных.
• Логическое отображение создается или вручную или
полуавтоматически с помощью алгоритмов формирования
соответствия схем или онтологий.
• Такие алгоритмы также могут использоваться для облегчения
создания интегрированной глобальной модели. Они основываются
на определении соответствия на основе:
– сопоставления лексического сходства (например, с использованием
• расстояния (метрики) Левенштейна,
• n-gram моделей,
• фонетических алгоритмов),
– сопоставления на основе сравнения графов, как, например,
• алгоритм распространения сходства (similarity flooding) предложенный в работе,
– на основе использования таксономии и тезаурусы конкретных
предметных областей.
• Так как эти алгоритмы основываются на эвристиках, то полностью
автоматические подходы работают не достаточно точно.
Двухэтапный подход к
отображению/преобразованию
Прямой или одноэтапный подход к
отображению/преобразованию
Логический вывод глобальных
запросов
• Глобальные запросы формулируются (записываются) на языке
описания глобальных запросов LQ с использованием алфавита
глобальной схемы AG.
• Помимо такого общего определения, природа конкретной
системы интеграции зависит от выразительности и
характеристик языков описания отображения, схем и запросов.
• C логической точки зрения, ответ на глобальный запрос
фактически является задачей логического вывода.
• Система должна создать результирующие кортежи, которые
удовлетворяют глобальному запросу путем логического
объединения промежуточных кортежей из набора источников
на основе заданных отображений.
• Особое внимание требуется в том случае, если
информационная система накладывает дополнительные
глобальные ограничения. Если информационная система
интегрирует данные из автономных источников, то глобальные
ограничения могут приводить к запросам, на которые нет
ответов.
Походы к созданию систем
интеграции на основе посредников
• На основе реляционных моделей данных
(1990 г.г.):
– Основная метамодель: ODMG-93
• На основе онтологий (конец 1990-х начало
2005г.):
– Основная метамодель: языки описания онтологий
• На основе технологий Semantic Web (с 2004 г.):
– Основная метамодель: RDF
СИИ на основе реляционных
моделей данных
Название
Глобальная
модель
Garlic
Язык
запросов
Обработка
запросов
Адаптер
ODMG-93
GQL
Интерфейсы
Sturbust,
(правила,
стоимостная
функция)
Интерфейсы,
продукц.
правила
DISCO
ODMG-93
OQL
Интерфейсы
Станд.
методы
оптимиз. РБД
Поддержка
OQL
Подтипы
, maps,
Views
TSIMMS
OEM (Object
Exchange
Model)
Стоимостные
функции
Параметриз.
правила
OEM
OEM-QL
Отобра
жение
Архитектура системы интеграции
Garlic
Архитектура и процессы в системе
DISCO
Архитектура системы TSIMMIS.
СИИ на основе реляционных
онтологий
Название
Глобальная
модель
Язык
запросов
Обработка
запросов
Адаптер
Infosleuth
(агенты)
Онтология
(базовая
Cyc)
KIF, KQML
агенты
Агент
ресурса
Промежуточ СИНТЕЗ
ный слой
предметных
посредников
(ИПИ РАН)
Syfs
Преобразов
ание Asyfs,
оптимизаци
я
Asyfs ->
язык
источника
Операции
над спецификациями
типов
Yacob-RDF
CQuery
XSLT
XML/XSLT
XSLT
SPARQL (?)
Логический
вывод
DL trio
Логические
запросы
RDFS
Единое
DL trio
научное
информ.
пространство
Отображен
ие
Схема системы InfoSleuth, включающая
агенты для интеграции информации
Архитектура виртуальной
обсерватории (ИПИ РАН)
АРХИТЕКТУРА ПРОМЕЖУТОЧНОГО СЛОЯ ПРЕДМЕТНЫХ ПОСРЕДНИКОВ ДЛЯ РЕШЕНИЯ ЗАДАЧ НАДМНОЖЕСТВОМ
ИНТЕГРИРУЕМЫХ НЕОДНОРОДНЫХ РАСПРЕДЕЛЕННЫХ ИНФОРМАЦИОННЫХ РЕСУРСОВ В ГИБРИДНОЙ ГРИДИНФРАСТРУКТУРЕ ВИРТУАЛЬНЫХ ОБСЕРВАТОРИЙ Д.О. Брюхов, А. Е. Вовченко, В.Н. Захаров, О.П. Желенкова, Л.А.
Калиниченко, Д.О.Мартынов, Н.А. Скворцов, С.А. Ступников
Общая архитектура посредника
Yacob Mediator
Единое научное
информационное пространство
Предлагаемый алгоритм включает следующие
основные этапы:
1. Переформулировка относительно аксиом
глобальной онтологии;
2. Переформулировка относительно
отображений онтологии;
3. Переформулировка относительно аксиом
онтологии источников;
4. Минимизация полученного запроса.
Бездушный Алексей А. (ВЦ РАН) Математическая модель интеграции
данных на основе дескриптивной логики, 2008
Технологии Semantic Web
• Язык описания данных RDF в виде
триплетов (граф).
• Языки описания моделей данных на основе
языков RDFS и OWL (которые сами
описываются в виде наборов триплетов и
графов).
• Язык запросов SPARQL к наборам
триплетов (графам).
Интеграция данных на
основе семантических
технологий
• Различные источники
данных могут быть
объединены в общую
модель с помощью RDF.
• Путем добавления
других технологий
Semantic Web, они могут
быть интегрированы в
общую модель знаний.
Преимущества использования RDF в
качестве глобальной метамодели
• RDF по определению ориентирован на работу в web-сети (Webcentric) и является хорошо масштабируемым, так как
взаимосвязанные RDF онтологии могут быть распределены по сети
World Wide Web;
• RDF онтологии могут быть опубликованы любым пользователем в
web сети для того, чтобы расширить существующие понятия
(concepts) (взаимосвязями) с новыми понятиями, если это
требуется (например, при добавлении нового источника данных к
системе SemWIQ, информация которого не описывается текущей
глобальной моделью, которая по существу является суммой всех
опубликованных онтологий, использованных для описания
источников данных).
• Идентификаторы URI используются в качестве глобальных
идентификаторов для всех понятий (concepts), что облегчает
управление глобальным пространством имен URI (global URI
namespace), путем использования Системы Доменных Имен
(Domain Name System, DNS).
• RDF, RDF-Schema, OWL и другие стандарты W3C разрабатываемые на
их основе являются стандартизированными и широко
используемыми языка представления знаний.
• RDF граф может быть описан простым способом в виде набора
триплетов , что облегчают слияние не полных, фрагментированных
графов из распределенных источников.
• RDF-Schema, OWL и другие словари построенные над RDF Core
предоставляют все типичные средства (mechanisms) описания
понятий, известные из других сред (например, Entity Relationship
Model и UML), которые требуются для моделирующих онтологий.
• RDF-Schema и OWL поддерживают терминологические dscrfpsdfybz(tbox) и утверждающие высказывания (assertional statements) (a-box),
также, как и многие возможности дескриптивные логики, которые
могут использоваться для выполнения логического вывода над
данными и наложения ограничений.
• Для каждого правильной (valid) строки
SPARQL запроса qlex, существует
формально определенный план запроса
(query plan) q, который рекурсивно
описывается объединением отдельных
алгебраических операторов p.
• Алгебраический план часто используется
вместо термина план запроса.
Пример алгебраического плана
• Для примера запроса показан его алгебраический план.
SELECT ?name ?mbox ?i
WHERE {
{
?s rdf:type foaf:Person .
?s foaf:name ?name .
?s foaf:interest ?i
} OPTIONAL {
?s foaf:mbox_sha1sum ?mbox
}
} ORDER BY ?name LIMIT 10
Текстовое описание плана запроса
Slice((0; 10),
Project((?name ?mbox ?i),
Order((?name),
LeftJoin(
BGP((?s rdf:type foaf:Person), (?s foaf:name ?name),
(?s foaf:interest ?i)),
BGP((?s foaf:mboxsha1_sum ?mbox))
)
)
)
)
Подходы к решению задачи формирования
плана выполнения запросов
• Решение задачи математической
(дескриптивной) логики.
• Структурный подход на основе графов.
Соотношение выразительности и
парадигмы интеграции
СИИ на основе семантических
технологий Semantic Web
Название
Глобальная Язык
модель
запросов
Обработка
запросов
Адаптер
Отображе
ние
Virtuoso
Sponger
RDF
(материали
зация)
SPARQL
ISENS
OWL
SPARQL
Логич.
вывод
DARQ
RDF
SPARQL
Распред.
Запросов
Стоимост.
фукция
SPARQL
endpoint
RDF
SemWIQ
Набор
локальных
онтологий
SPARQL
Распред.
Запросов,
Статистика
SPARQL
endpoint
локальная
онтология
в адаптере
картридж
OWL/SWRL
Проект SemWIQ
• распределенные источники данных, отображенные
(mapped to) на распределенные онтологии.
• масштабируемость относительно количества источников
данных и количества и размера онтологий.
• полное использование технологий SW.
Andreas Langegger "A Flexible Architecture for
Virtual Information Integration based on Semantic
Web Concepts", 2010
Системы интеграции информации
SemWIQ
• Цели разработки системы:
– виртуальная интеграция распределенных и
разнородных информационных систем,
– использование концепций Semantic Web,
– применение подхода, использующего обработку
целостного запроса для того, чтобы гарантировать
высокую производительность и
масштабируемость,
– гибкость и низкая начальная стоимость (low entry
cost).
Системы интеграции
информации SemWIQ
• Система SemWIQ способна справится со всеми уровнями
разнородности, включая разнородность метамоделей. В связи с
этим, SemWIQ основывается на классическом подходе,
использующим посредники-адаптеры:
– разнородные источники данных виртуально интегрируются
посредством адаптеров и
– центральный процессора обработки федеративных запросов
(federated query processor) является ответственным за
формирование ответов на запросы, путем делегирования
(передачи) под-запросов адаптерам.
– Процесс обработки запросов (query process) основывается на
использовании каналов (pipelining), что позволяет уменьшить
время ответа и гарантирует масштабируемость системы путем
потоковой передачи результатов через конвейер (pipeline) от
исходных информационных систем до отправившего запрос
клиента (requesting client).
Описание системы SemWIQ
• Глобальная метамодель (Global metamodel) – в системе SemWIQ в
качестве глобальной метамодели используется RDF.
• Глобальный язык запросов (Global query language) – язык SPARQL,
может содержать любые понятия онтологий, но однако, запрос
будет возвращать результаты только в том случае, если они могут
быть получены с помощью глобального виртуального набора
данных, т.е. путем объединения предоставляемых виртуальных
RDF графов.
• Интерфейс и протокол адаптера (Wrapper interface and protocol) –
Интерфейсом взаимодействия между адаптерами и посредником
является SPARQL.
– Каждый адаптер может обрабатывать под-запросы SPARQL и
организовывать поток передачи (stream) отображений
промежуточных решающих соответствий посреднику (потоковая
передача (streaming) результатов обработки SPARQL запросов в
XML формате по протоколу HTTP хорошо работает с
использованием «Streaming API for XML» (StAX), который
используется компонентом Jena ARQ.).
Архитектура системы SemWIQ
Архитектура системы SemWIQ
• Интерфейс (Interface)
• SPARQL Protocol и RDF Query Language (SPARQL) .
• API для Java приложений (mediator API).
• Каталог метаданных (Metadata catalog) – RDF хранилище,
которое содержит информацию о зарегистрированных
источниках данных (описанную с использованием voiD), их
текущее состояние возможности их использования и
статистические данные RDFStats (RDFStats statistics).
– Такие статистические данные используются для интеграции
(federate) и оптимизации глобальных SPARQL запросов.
– Данные каталога метаданных могут быть сохранены в любом,
основанном на Jena RDF хранилище, но лучше Jena TDB
– Система SemWIQ включает много-поточный монитор источников
данных, который наблюдает в фоновом режиме за
зарегистрированными источниками данных, основываясь на
конфигурируемых профайлах и обновляет текущее состояние их
доступности (availability state), а также статистические данные
RDFStats.
Архитектура системы SemWIQ (2)
• Компонент регистрации (Registry component) – новые
источники данных могут быть зарегистрированы и вычеркнуты
(de-registered) в посреднике SemWIQ с помощью registry API и
через REST-вида Web-сервис.
– Источник данных регистрируется в виде соответствующего URI
идентификатора конечной точкой SPARQL предоставляемого
соответствующим адаптером.
– В ходе регистрации монитор источников данных пытается найти
метаданные в формате voiD в web сети, которые могут включать
описание системы, которая поддерживает набор данных,
лицензионную информацию, и предметные термины, связанные с
этим набором данных.
– Кроме этого данный монитор собирает статистические данные
(RDFStats), если она предоставляются системой (natively provided),
а в противном случае он будет использовать встроенный RDFStats
компонент (RDFStats component) и генерировать статистические
данные удаленно.
Архитектура системы SemWIQ (3)
• Процессор запросов (Query processor) – процессор
обработки запросов системы SemWIQ получает
глобальный SPARQL запрос и
• Формирует разделение на под-планы запроса на
основе состояния каталога метаданных.
• Оптимизация
• Выполнение
• Адаптеры (Wrappers) – для каждой системы
информации источника и соответствующей модели
исходных данных используется специфический
адаптер для определения отображения и
преобразования данных в RDF формат за один шаг.
Посредники системы SemWIQ
Схема работы посредника и
адаптера
Федерирование запроса
•
•
•
•
•
Задачей данного федератора (federator) является преобразование плана
запроса таким образом, чтобы ПОЗ могла создать правильные результаты, имея
такой виртуальный глобальный граф, как
GG = GS1 ⋃ GS2 ⋃ . . . ⋃ GSn.
Он также может быть представлен в виде большого набора триплетов, которые
были виртуально объединены (merged) из всех графов источников:
GG = ( ts1,1, ts1,2, . . . , ts1,k1,
ts2,1, ts2,2, . . . , ts2,k1,
...
tsn,1, tsn,2, . . . , tsn,k1,)
Имея шаблон триплета tp (см. Определение 4), федератор должен определить,
какой из виртуальных триплетов tsi,kj будет ему соответствовать. Источник
данных является релевантным, если граф источника GSi (который является
виртуальным в случае источника данных, использующего адаптер ) содержит
триплеты, которые соответствуют (match) шаблону триплетов (triple pattern) tp.
Необходимая для этого информация поддерживается компонентом RDFStats в
форме сводок статистических данных (statistical data summaries).
Для каждого БГШ федератор создает модифицированный под-план, который
содержит операторы Service, чтобы передать локальные планы интерфейсам
обработки запросов зарегистрированным источникам данных.
Выполнение запроса
• После того, как план запроса будет составлен, он может
быть выполнен.
• ПОЗ запускает конвейер (канал, pipeline) итераторов ,
которые далее называются планом выполнения .
• Система Jena ARQ уже предоставляет базовую
функциональность для потокового выполнения SPARQL
запросов и реализует набор итераторов для
выполнения потоковых и материализованных
(materialized) связываний (joins), левых связываний (left
joins), объединений (unions), фильтров (filter) и т.п.
• Начальная реализация была расширена поддержкой
блокировки записей, распределенными полусвязываниями, отслеживанием происхождения.
Итераторы выполнения запросов
Основанный на триплетах
федератор
•
•
•
Федератор, основанный на триплетах (triple-based federator) (TF) может
работать с полным разделением экземпляров по набору распределенных
источников данных (местоположений, multiple distributed locations) и не
типизированных ресурсов (untyped resources). В режиме TF возможно
интегрировать полностью распределенные RDF под-графы без ограничений
на форму под-графов. Но данный подход требует более распределенных
связываний (distributed joins).
Логический пред-оптимизатор уже подготовил план запроса. Все фильтры
протолкнуты (pushed down), как можно ближе к базовому графовому
шаблону (БГШ). Функция Federate-BGP(b) вызывается из Алгоритма 1 для
каждого базового графового шаблона b. Вначале данная функция, выбирается
набор (set) предшествующих (preceding) выражений фильтров (filter
expressions) E (если b имеет предшествующий Filter, в противном случае E =
), и инициализируется отображение (map) PD, которое будет хранить
специфические (specific) для источников данных БГ Шаблоны (BGPs).
Для каждого шаблона триплетов t федератор выбирает релевантные
(relevant) источники данных D на основе сводок статистических данных.
Источник данных является релевантным, если он может добавлять триплеты
для данного шаблона t. Соответствующие функции оценивания
предоставляются компонентом RDFStats.
•
•
•
•
•
Основанные на экземплярах
федераторы
Предполагается, что вся интегрируемая информация организована в виде
множеств экземпляров . Предполагается, что каждый субъект (subject) в
глобальном графе GG имеет, по крайней мере, один связанный с ним (associated)
тип t (который является классом RDF Schema).
Ограничение 1. GG = (s, p, o), s (s, rdf:type, t)
При установке системе SemWIQ, это условие может быть удовлетворено при
отображении источников данных. Если имеется возможность логического вывода
включений, то данный подход в основном работает только с нетипизированными
ресурсами (задано только rdf:Description)), так как СЛВ будет выводить, что данный
ресурс по крайней мере является экземпляром (instance) RDF класса rdfs:Resource.
В результате этого, федератор (federator) может рассматривать (consider) большое
количество или даже все источники данных, так как rdfs:Resource является
наименьшим специфицированным типом (least specific type) для которого все или
потенциально все расширения подклассов (sub-class extensions) являются
релевантными .
В качестве второго ограничения предполагается, что эти экземпляры описываются
только (exclusively) одним источником данных.
Ограничение 2. GSi = (s, p, o), s ∄ GSi = (s, p’, o’)
На основе таких ограничений, глобальный запрос может быть федерирован
(federated) на основе набора (sets) экземпляров SPARQL запросов. Вершины с
одним и тем же субъектом (equal subject nodes) базового графового шаблона
всегда ссылаются на одно и то же множество экземпляры .
Адаптеры системы SemWIQ
•
•
•
•
Система SemWIQ в основном способна интегрировать данные из всех
стандартных конечных точек SPARQL (endpoints). Однако существует
несколько проблем с текущим стандартом SPARQL, что делает крупномасштабную интеграцию на основе стандартys[ конечных точек SPARQL
невозможной.
Во-первых, требуется RDF статистика (RDF statistics), чтобы разделять
(federate) и оптимизировать запросы к системе SemWIQ queries. Генератор
RDFStats статистических данных (statistics) также интегрирован в SemWIQ
посредник (mediator), что позволяет создавать статистические данные
(statistics) удаленно для наборов данных средних размеров.
Во-вторых, язык SPARQL не поддерживает начальные связывания (initial
bindings). В связи с этим невозможна блокировка записей для
распределенных связываний.
В связи с этим, несколько компонент Jena, таких, как базовая библиотека Jena
(core library), ARQ и Joseki были доработаны (patched), чтобы предоставить
требуемую функциональность для адаптеров (wrappers). Каждый SemWIQ
адаптер может эффективно обрабатывать SPARQL под-запросы, чтобы
добавлять (contribute) решающие соответствия (solution mappings) к
результатам глобального запроса.
Отображение нескольких моделей
данных в общую RDF модель
(б) Прямой или одно-этапный подход к
отображению/преобразованию
Реализация адаптеров на основе
Jena ARQ
• Так как Jena ARQ [Jena Community 2009a] реализована в очень
хорошо расширяемым способом (highly extensible manner), то это
хорошая способ начинать разработку любых видов виртуальный
RDF адаптеров (wrapper).
• Имеется много точек расширения (extension points), которые могут
быть использованы для того, чтобы добавить требуемую
функциональность (hook into) к системе обработки запросов (query
engine).
• Например, имеется возможность преобразовать сгенерированный
алгебраический план (путем реализации интерфейса
com.hp.hpl.jena.sparql.algebra.Transform) и заменить стандартные
(default) операторы SPARQL собственными (custom) операторами
(operators).
• Более того, имеется воможность предоставить собственные
(custom) реализации итераторов запроса (query iterators), как для
стандартных (default), так и собственных (custom) алгебраических
операторов (путем переопределения (overriding) метода
com.hp.hpl.jena.sparql.engine.main.OpExecutor).
• Для реализации адаптера RDB-to-RDF может быть реализован
собственный генератор этапов, который будет формировать
решения на основе описания отображений и данных,
поучаемых из базы данных путем выполнения SQL запросов.
• При наличии шаблона триплетов tpi основной трудностью
остается составление правильных и эффективных SQL запросов
на основе tpi и отображения (mapping) M, а также
преобразование полученных SQL результатов в
соответствующие RDF триплеты для tpi.
• Сгенерированный SQL запрос, который является комбинацией
существующих утверждений об отображении
g ↝ qS,
может рассматриваться, как RDF представление (view) схемы
источника S относительно M.
Рабочая группа RDB2RDF W3C
• В сентябре 2009 года была создана рабочая группа RDB2RDF
W3C Working Group, целью работы которой было
“стандартизировать язык для отображения реляционных
данных и схем реляционных баз данных в RDF и OWL”.
• Такая рабочая группа была сформирована достаточно поздно,
так как сервер D2RServer был разработан уже в 2002 году, т.е.
семь лет назад.
• Увеличение важности масштабируемой технологии
отображения RDB-to-RDF привело к созданию в данной области
большого количества разных программных средств
(инструментов) и разных языков описания отображения
(mapping languages).
• Для обеспечения взаимодействия между инструментами
выполнения отображения, консорциум W3C решил
организовать новую рабочую группу для разработки
стандартного языка описания отображений (mapping language).
Адаптеры для реляционных баз
данных
• С момента появления концепции Semantic Web все больше
внимания уделяется отображению реляционных БД в RDF и
возможности оперативного выполнения запросов и
преобразования данных. С уверенностью можно предполагать,
что в настоящее время большинство информации хранится в
реляционных базах данных.
• К современным технологиям разработки адаптеров относятся:
–
–
–
–
D2RQ-Map [Chris Bizer and Richard Cyganiak 2006],
R2O [Rodrнguez et al. 2004],
OpenLink Virtuoso RDF Views [Erling and Mikhailov 2007],
подходы предложенные в [Chen et al. (2005)] и [de Laborda and
Conrad (2006)],
– SquirrelRDF [Steer n.d.].
Отображения D2RQ
• Система D2RQ-Map является средством отображения и преобразования,
которое использует сервер D2R-Server. Хотя средства отображения могут
использоваться в виде библиотеки для приложений Semantic Web,
сервер D2R-Server добавляет конечную точку SPARQL (endpoint), которую
могут использовать Web приложения и интерфейс пользователя,
называемый Snorql. Так как система D2RQ-Map основана на Jena, а
также в связи с тем, что имеются хорошие отношения с ее
разработчиками, то D2RQ-Map использовалась в качестве реляционного
адаптера для системы SemWIQ.
• Технология D2RQ-Map основана на Global-as-View подходе к
отображению (mapping approach). Однако, составление (writing)
отображения D2R является в основном процессом создания
утверждений (assertions) в форме: g ↝ qS, как это было описано в
разделе 3.5.4. Для отдельного глобального понятия g, которое может
быть RDF классом или свойством, описывается (formulated) запрос к qS к
схеме базы данных источника (database source schema) S. D2RQ-Map не
поддерживает непосредственно SQL запросы, однако, она
поддерживает все, что требуется для создания 1 : 1, 1 : n и n : n
соответствий, включая функциональные соответствия (основанные на
SQL выражениях и функциях), таблицы преобразования значений (value
translation tables), и условия (conditions) (с использованием SQL
выражений).
SPARQL запрос и соответствующий
ему план запроса D2RQ
•
Как видно из данного примера, вместо OpBGP операторов, план запроса
содержит OpD2RQ операторы, которые генерируют SQL подпланы и
выполняют связывания решений (solution bindings) на основе описания
отображений.
SQL запросы для OpD2RQ1 и
OpD2RQ2
Возможности системы D2RQ-Map
• Система D2RQ-Map использует достаточно мощные возможности
(формирования) отображения, которые могут справиться (cope) со
следующими видами (aspects) разнородности .
• Техническая разнородность неявно разрешается (совместно с другими
видами) путем выполнения доступа к лежащей в основе базе данных
через SQL и JDBC и путем предоставления интерфейса SPARQL interface
to the user.
• Синтаксическая разнородность может разрешаться путем
использования SQL выражений (expressions) и таблиц перевода
(translation tables).
• Разрешение разнородности метамоделей между реляционной
моделью и RDF является назначением самой системы D2RQ-Map.
• Структурная разнородность может быть разрешена в большинстве
случаев. Информация о схеме базы данных может быть представлена
в RDF, если RDBMS предоставляет доступ каталогу метаданных
посредство SQL запросов. И наоборот, может быть сгенерирована
структура любого RDF графа, включая классы, свойства и частные типы
данных RDF и т.п.
Спасибо за внимание!