5.2Методика описания и согласования структуры информационных ресурсов
Для того чтобы придать смысл модели данных, необходимо воспользоваться словарями, которые задаются при помощи дополнительной технологии – RDF Schema [96]. Под словарем следует понимать совокупность ресурсов, использующихся для описания свойств других ресурсов и ограничений, налагаемых на их значения или наборы допустимых значений.
Язык RDF Schema позволяет описывать на RDF словари классов и свойств; можно описать и контролируемые словари вариантов значений свойств. Поскольку классы, свойства и экземпляры метаданных идентифицируются не просто именем, а URI, то это позволяет разделить их по «профилям», соответствующим разным «пространствам имён». RDFS служит базой для более сложного языка описания «онтологий» предметных областей, Web Ontology Language (OWL), который позволяет определить более сложные ограничения на применение классов и свойств, структуру метаданных.
В настоящее время заметна широкая тенденция по стандартизации RDF-словарей свойств метаданных для конкретных предметных областей – так называемых «обменных схем», или «профилей метаданных». Использование терминов (свойств, словарей значений и пр.), зафиксированных в стандартах, позволяет приложениям легко интегрироваться между собой, обмениваться информацией, понятной им всем. Например, при получении данных из сторонней системы, приложение может найти среди неизвестных ему свойств некоторые свойства, регламентированные стандартом, и соответственно будет уверено в их смысле, семантике, сможет правильно их проинтерпретировать. Это называется «семантической интероперабельностью», и считается одним из основных преимуществ Semantic Web.
Помимо обменных «профилей метаданных», существуют инициативы по построению «онтологий» предметных областей, нацеленных больше на спецификацию большого количества классов и их взаимоотношений, нежели словарей свойств для обмена.
Различные информационные системы могут ориентироваться на различные предметные области. Например, одни имеют дело с научными публикациями, другие с проектами, третьи и с тем, и с другим. Соответственно, каждую конкретную предметную область предлагается описывать отдельной схемой (а точнее, набором схем), возможно, опирающихся друг на друга. Это разбиение схемы по «минимальным предметным областям» мы называем разбиением на «модули». Модули рассматриваются не только как способ деления схемы, но и как способ деления функциональности типовых информационных систем, порталов по отдельным компонентам.
«Минимальные» подсхемы ориентированы в первую очередь на обеспечение максимальной гибкости обмена данными. Здесь не важна спецификация детальной и точной структуры данных (например, разбиение почтового адреса по полям), но важно указать словарь свойств, терминов для обмена информацией в данной предметной области, а также отображение на стандартизованные и уже применяющиеся предложения по профилям метаданных. Рассмотрим методические приёмы, предоставляемые нам для этих целей языками RDF Schema и OWL (язык веб-онтологий):
импорт схем позволяет добавить в разрабатываемую схему термины других схем, в частности, стандартных профилей метаданных. Эти термины могут использоваться как непосредственно, так и специализироваться механизмами подклассов и подсвойств, если их семантика слишком абстрактна для рассматриваемого уровня детализации схемы.
традиционный механизм подклассов позволяет указывать специализацию классов, уточнение семантики термина и набора свойств. Пример: «диссертация» - подкласс «документа». Зная эту информацию, система, не работающая конкретно с диссертациями, получив данные из архива диссертаций, сможет идентифицировать их как данные об абстрактном «документе» и воспользоваться такими свойствами как «автор», «издательство» и пр., проигнорировав информацию об оппонентах, дате защиты и пр.
механизм подсвойств позволяет указать специализацию свойств – для того чтобы, в первую очередь, уточнять их смысл. Приведём пример: «аннотация» – подсвойство «описания», а «альтернативное название» – подсвойство «названия». Этот нетрадиционный для объектно-ориентированных систем механизм играет ключевую роль в обеспечении семантической интероперабельности систем. Предположим, некоторая специализированная система использует понятие «официального названия» (my:legal) для именования организаций и обменивается своими данными с другой системой, которая различает только простой термин «название» из DublinCore (dc:title). Без дополнительной информации, вторая система не имела бы ни малейшего шанса догадаться, что же за информация идёт в текстовом поле my:legal. Теперь допустим, что вместе с данными специализированная система предоставляет также свою RDF-схему, описывающую используемые термины. В частности, в этой схеме указано, что my:legal – это подсвойство dc:title, то есть некоторая специализация стандартизованного в Dublin Core термина «название», и используется для именования ресурса. Благодаря этой дополнительной информации вторая система сможет воспользоваться данными, указанными в поле my:legal. Естественно, она не сможет автоматически воспользоваться информацией о том, что это не просто название, а именно «специализированное официальное название», но эта информация систему и не интересует в рамках её предметной области. Помимо уточнения смыла, подсвойство может уточнять характеристики суперсвойства.
OWL позволяет указывать эквивалентность классов, свойств, либо экземпляров (например, элементов различных словарей значений). Эти механизмы, наряду с механизмами подклассов и подсвойств, позволяют указать отображение схем на стандартные и широко применяющиеся профили метаданных, что гарантирует семантическую интероперабельность.
На этапе перехода от «минимальной» к «базовой» и более специализированным подсхемам встаёт вопрос о более чёткой спецификации структуры данных – в частности, чёткой спецификации типов значений свойств. Это возможно благодаря уже упомянутому механизму введения дополнительных утверждений об импортированных ресурсах, в частности, свойствах. Минимальная схема может не указывать явно тип данных свойства, если он потенциально может быть уточнён впоследствии, тогда более специализированная схема сможет указать специализацию этого типа. Если же тип значений с большой вероятностью подойдёт всем системам, то можно указать его уже в «минимальной» схеме, таким образом, накладывая некоторую резонную «строгость» на формат обмена. Например, можно указать, что «дата выпуска» издания имеет значения типа «дата» (xs:date), в чётко регламентированном формате (W3C-DTF). Это требование обязует все системы экспортировать данные о дате выпуска в этом формате, а не в виде произвольной строчки, и исключит ситуации непонимания формата при импорте данных. Рассмотрим ещё один пример. Если тип свойства – объект, то минимальная схема может указать тип значений как некоторый абстрактный класс, а специализированная схема – уточнить тип значений, указав его подкласс. Пусть мы имеем свойство «публикация выполнена по проекту», позволяющее указать литературу («публикации»), полезную для понимания проекта. В более специализированной схеме введём понятие «отчёта по проекту»: заведём соответствующий класс «Проектный Отчёт» (имеющий дополнительные метаданные, такие как номер отчёта) и свойство «отчёт по проекту», позволяющее сопоставлять проектам «отчёты». Это свойство мы будем считать подсвойством, частным случаем «публикации, выполненной по проекту», но с более специализированным типом значений.
Чтобы достичь семантической интероперабельности, смысл информации, которой обмениваются, должен быть понятен во всех системах. Использование онтологий для объяснения неявного и скрытого знания – возможный подход для достижения этой цели.
Онтологии – больше, чем просто сложный подход к описанию и классификации информации. Они могут использоваться для поддержки функционирования и роста нового вида цифровых ресурсов и других порталов, реализованных как распределенные интеллектуальные системы.
Под онтологией можно понимать [97]:
надежный семантический базис в определении содержания;
общую логическую теорию, которая состоит из словаря и набора утверждений на некотором языке логики;
основу для коммуникации между людьми и компьютерными агентами.
Онтологии позволяют представить новые понятия так, что они становятся пригодными для машинной обработки. С помощью онтологии можно "перекинуть мостик" между новыми понятиями, с которыми система еще не встречалась, и описаниями уже известных классов, отношений, свойств и объектов.
Компоненты, из которых состоят онтологии, зависят от парадигмы представления. Но практически все модели онтологий в той или иной степени содержат концепты (понятия, классы, сущности, категории), свойства концептов (слоты, атрибуты, роли), отношения между концептами (связи, зависимости, функции) и дополнительные ограничения (определяются аксиомами, в некоторых парадигмах фасетами).
Термин экземпляр используются для представления элементов в предметной области, т.е. элемента данного концепта. Онтология вместе с множеством отдельных экземпляров составляет базу знаний.
В настоящее время для создания и поддержки онтологий существует целый ряд инструментов, которые помимо общих функций редактирования и просмотра выполняют поддержку документирования онтологий, импорт и экспорт онтологий разных форматов и языков, поддержку графического редактирования, управление библиотеками онтологий и т.д.
Онтологии позволяют формализовать процесс интеграции распределенных данных.
Понятие «интеграция распределенных данных» подразумевает, как правило, интеграцию информационных ресурсов, которые расположены в уже существующих распределенных репозиториях. В настоящее время большая часть информационных хранилищ представлена реляционными базами данных. Поэтому первая задача, возникающая на пути решения проблемы семантически обоснованной интеграции информационных ресурсов – это представление данных, описанных реляционной моделью, семантически более богатым способом. Таким образом, необходимо наличие механизмов, позволяющих выделить из реляционной модели данных объектную модель и реализовать адаптер для работы с данными существующего хранилища информационных ресурсов через объектные интерфейсы доступа (такие как, например, ODMGAPI или ODMG OQL).
В [98] была предложена методика, которая опиралась на реинжениринг реляционных схем данных существующих реляционных хранилищ данных, создание соответствующих объектных схем данных и возможности формирования «объектной» надстройки над имеющимся реляционным хранилищем информационных ресурсов для того, чтобы работать с его данными посредством технологий Semantic Web в рамках канонической RDFS-модели данных [98]. Предполагается, что реализованные в рамках работы средства будут включать:
1 Автоматизированную пользовательскую среду подготовки унифицированного, ориентированного на поддержку семантической интероперабельности, описания схем данных (RDFS), предоставляемых хранилищами внешних систем, включающую:
реинженеринг (восстановление) исходной реляционной схемы БД учетом специфики провайдеров РСУБД;
преобразование реляционной схемы данных в объектную схему данных;
преобразование объектной схемы данных в RDFS схему данных.
2 Формирование репозитория хранимых RDFS-объектов над реляционной БД внешней системы, включающее:
формирование объектной и RDF прослоек над реляционной БД, параметризованных RDFS-схемой данных репозитория. Соответствующее обеспечение объектно-реляционного и RDF-объектного отображений данных, параметризованных декларативными описаниями соответствующих отображений и схем данных;
поддержку диалекта объектного языка запросов ODMG OQL, обеспечивающую трансляцию OQL запросов в SQL запросы с учетом специфики провайдеров РСУБД;
представление данных хранилищ внешних систем, выбираемых «открытыми запросами», в унифицированной W3C RDF/XML форме, обеспечивающей возможность осуществления семантической интероперабельности данных;
предоставление удаленного обращения с «открытыми запросами» к репозиторию хранимых объектов на основе Web-сервисов, поддерживающих взаимодействие по протоколу SOAP.
Для выделения объектной схемы реляционных баз данных внешних систем в рамках разработанной методики необходимо выполнить следующую последовательность действий:
1 Формирование ER-схемы для БД целевой системы. На первом этапе необходимо получить схему существующей реляционной базы данных для того, чтобы впоследствии преобразовать ее к объектной схеме, внеся дополнительные семантические наполнение и структуризацию.
2 Формирование UML-диаграммы классов по ER-схеме целевой системы. Второй этап в построении объектного репозитория над реляционной базой данных, это преобразование полученной ER-схемы данных к первому приближению RDFS-модели информационных ресурсов Semantic Web. В качестве этого первого приближению удобно использовать UML-диаграмму классов.
3 Запись UML-диаграммы классов в XMI формате. На следующем этапе нам необходимо представить полученную UML-диаграмму классов в некоторой промежуточной, схемо-независимой форме для последующего преобразования к модели данных RDFS. В качестве такого промежуточного представления в данной методике выбран XMI формат представления объектных схем. XMI формат предназначен для обмена метаданными с помощью XML.
4 Преобразование UML-диаграмм классов в XMI форме в RDFS-схему. На данном этапе подготовлены все необходимые входные артефакты для построения первого варианта RDFS-схемы, описывающей схему данных объектной надстройки над реляционной базой данных.
5 Формирование прикладной RDFS-схемы. После выделения первого приближения RDFS-модели данных объектного репозитория необходимо выполнить доработку полученного первого варианта схемы до семантически более корректной формы. На данном этапе предполагается:
доработка RDFS-схемы данных: выделение введение дополнительной иерархии классов и их свойств;
введение системных классов технологической платформы, необходимых адаптеру объектного репозитория.
6 Формирование RDFS схемы, согласованной с совокупностью канонических RDFS подсхем. На данном этапе имеется выделенная RDFS-схема объектной надстройки над реляционным хранилищем данных. Для возможности интеграции информационных ресурсов репозиториев различных внешних систем, описанных подобными схемами, необходимо выделить из них канонические (общие) подсхемы, в рамках которых будут формироваться объектные запросы на доступ к информационным ресурсам и осуществляться интеграция полученных от различных внешних систем ответов. В свете этого на данном этапе пространство имен прикладной RDFS-схемы разбивается на следующие три части:
пространство имен common – каноническая RDFS-подсхема общих классов, свойств, в соответствии с которыми могут формироваться объектные запросы;
пространство имен external – каноническая RDFS-подсхема общих прикладных классов, свойств, в соответствии с которыми пользователю могут возвращаться данные прикладной системы;
пространство имен external_own – RDFS-подсхема общих прикладных классов, свойств, которые поддерживаются репозиторием, но недоступны объектным запросам.
7 Реализация адаптера объектного репозитория – поддержка прикладных RDFS-схем, согласованных с совокупностью канонических RDFS-схем. На данном этапе сформированное полноценное описание объектной схемы данных репозитория, оно используется как входной параметр для реализованного адаптера объектного репозитория, который позволяет [98]:
осуществить объектно-реляционное отображение полученной объектной схемы данных на реляционную схему существующей реляционной БД;
выполнять объектные OQL-запросы к репозиторию, согласованные с канонической RDFS–схемы общих классов;
представлять результаты OQL-запросов к репозиторию в унифицированном RDF/XML формате;
предоставить Web-сервис для выполнения OQL-запросов к сформированному объектному репозиторию и получения RDF/XML ответов.
Таким образом, разработанный метод построения объектных репозиториев над имеющимися информационными хранилищами данных в довольно большой степени решает часть проблемы интеграции данных, обусловленную необходимостью повышения уровня семантического представления данных распределенных информационных систем.
|
