Скачать 287.37 Kb.
ATTLIST article
id ID #REQUIRED
about CDATA #IMPLIED
type (actual | review | teach ) 'actual' ''
>
В данном примере для элемента article определяются три атрибута: id, about и type, которые имеют типы ID (идентификатор), CDATA и список возможных значений соответственно. Параметр #REQUIRED определяет обязательный атрибут, а параметр #IMPLIED задает атрибут, не являющийся обязательным.
Сущность (entity) в DTD (Слайд 13.9) представляет собой определение, содержимое которого может быть повторно использовано в документе (в языках программирования подобные элементы называются макроопределениями).
DTD-сущности создаются при помощи инструкции !ENTITY:
Добрый день!' >
Программа-анализатор, просматривая содержимое области DTD-определений, обработает эту инструкцию и при дальнейшем разборе документа использует содержимое DTD-сущности в том месте, где будет встречаться ее название. Таким образом, в документ можно вставлять выражение &hello; , которое будет замещено строкой «Добрый день!».
В общем случае, внутри DTD можно задать три типа сущностей:
внутренние сущности - предназначены для определения строковой константы. Внутренние сущности включаются в документ при помощи амперсанта «&»;
внешние сущности - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования сущности будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются, а используются внешними программами:
макроопределения правил - макроопределения параметров, могут использоваться только внутри области DTD и обозначаются специальным символом «%», вставляемым перед названием сущности. При этом содержимое сущности будет помещено непосредственно в текст DTD- правила
Спецификация RDF
Спецификация XML-схем предоставляет более полный и строгий метод определения модели информационного наполнения документа XML, чем определения DTD. Но и она не обеспечивает поддержку необходимого уровня семантической совместимости. Например, если два приложения должны обмениваться информацией с помощью XML, то назначение и подразумеваемый смысл используемых при этом документов должны быть согласованы с той структурой данных, которая формируется при обмене, для чего необходимо создать модель предметной области с описанием данных, которые требуются для одного и другого приложения.
Такую модель обычно принято описывать в терминах объектов или отношений (например, для этой цели может использоваться язык универсальный язык моделирования - UML). А поскольку схема XML описывает только синтаксическую структуру документа, одна и та же модель предметной области может быть представлена в виде схемы XML разными способами, т.к. в общем случае невозможно определить непосредственное соответствие между моделью предметной области и определенной схемой. Эта проблема становится еще более сложной, если в обмене информацией должны участвовать не два, а несколько приложений.
Для решения описанной выше задачи необходимо пройти следующие три этапа:
восстановить первоначальные модели предметных областей из схем XML;
определить соответствия между объектами моделей предметных областей;
определить механизмы преобразования для документов XML.
Эти этапы на практике иногда становятся очень сложными, поэтому может оказаться, что язык XML хорошо подходит для обмена данными только между приложениями, для которых уже известна модель информационного наполнения, но плохо подходит для тех ситуаций, когда к обмену данными присоединяются все новые и новые приложения.
Инфраструктура описания ресурсов (Resource Description Framework — RDF), разработанная под эгидой W3C, представляет собой информационную среду, которая обеспечивает кодирование, обмен и повторное применение структурированных метаданных. Эта инфраструктура обеспечивает функциональную совместимость метаданных различных приложений за счет применения таких проектных механизмов, которые позволяют создавать общепринятые соглашения по семантике, синтаксису и структуре документов. RDF не определяет семантику каждой предметной области, но предоставляет возможность создавать, по мере необходимости, элементы метаданных для предметных областей. В инфраструктуре RDF в качестве общего синтаксиса для обмена и обработки метаданных применяется язык XML. С помощью средств языка XML создаются модели данных RDF, позволяющие описывать семантику и обеспечивать обмен стандартизированными метаданными.
При использовании формата RDF документом может считаться любой электронный ресурс, даже ресурс, хранимый в электронном виде, но не представленный в Internet. В любом случае идентификатором ресурса будет его Uniform Resource Identifier (URI).
В основе RDF лежит модель представления именованных свойств и их значений. В контексте модели данных RDF свойства могут рассматриваться как атрибуты ресурса (т.е. как традиционная пара «атрибут-значение») или как отношения между двумя ресурсами (тогда модель RDF может быть интерпретирована как диаграмма «сущность-связь»). Если применить терминологию объектно-ориентированного подхода, то можно сказать, что ресурсы соотносятся с объектами, а свойства — с переменными (экземплярами объекта).
Базовая модель данных RDF состоит из трех объектов: ресурс, свойство, оператор.
Ресурс – все, что может быть описано в RDF-выражениях. Это может быть содержимое Web-страницы или целого Web-сайта. Ресурсом может считаться некоторая часть Web-страницы, в том числе определенные HTML или XML элементы, являющиеся частью Web-страницы. Кроме того, ресурсом может быть также объект, недоступный в Internet, например печатное издание. Однозначным идентификатором ресурса считается его URI.
Свойство — специфический аспект, характеристика, атрибут или отношение, используемое для описания ресурса. Каждое свойство имеет свой смысл, определяющий допустимые значения свойства, типы возможных описываемых ресурсов и отношения их к другим ресурсам. Например, атрибут Author может использоваться для описания лица, подготовившего конкретный документ XML.
Оператор — конструкция, состоящая из ресурса, свойства и значения этого свойства, определенного для данного ресурса. Эти три части утверждения называются "субъект", "предикат" и "объект". Объектом утверждения (значением свойства ресурса) может быть другой ресурс, определенный своим URI; литерал - строка символов (кроме зарезервированных для RDF); данные другого типа, разрешенного в XML.
Рассмотрим простой пример. Пусть необходимо средствами RDF-модели выразить следующее отношение:
"Автором Документа 1 является Иван Петров"
"Иван Петров – автор документа 1"
Для человека эти утверждения имеют одинаковый смысл (Иван Петров – автор конкретного документа), т. к. человек, в отличие от компьютера, способен извлечь смысл из различных синтаксических конструкций. Для компьютера, однако, это два разных значения. Используя тройку «ресурс-свойство-значение», RDF пытается обеспечить однозначный метод для выражения семантики в машиночитаемых кодах.
RDF обеспечивает механизм связывания свойств с ресурсами. Таким образом, прежде чем можно будет сказать что-либо о Документе 1, по правилам модели необходимо определить сам ресурс, представляющий Документ 1. Модель, описывающая выражение из примера, будет иметь один ресурс (Документ 1), одно свойство (Автор) и значение этого свойства («Иван Петров»). Для определения характеристик модели данных спецификация модели RDF предлагает описывать отношения между ресурсами и свойствами в виде направленного графа. В этом случае ресурсы описываются как узлы, свойства - как ребра графа, а значения - как строки, заключенные в кавычки. Графически рассматриваемый пример изображен на слайде (Слайд 13.10).
В случае, когда требуется дополнительная информация, например, об авторе (место работы, телефон и т.д.), предыдущая схема может быть детализирована описательной информацией об Иване Петрове. Как было сказано в первом примере, прежде чем давать описание ресурса, необходимо обозначить сам ресурс, в данном случае Ивана Петрова. Взяв за основу граф из предыдущего примера, можно графически описать Ивана Петрова (Слайд 13.10).
Теперь значение "Иван Петров" заменено уникально идентифицированным ресурсом, обозначенным как Автор 1, с соответствующими свойствами и их значениями. Использование уникальных идентификаторов позволяет однозначно связать свойства и ресурсы. Это важно, так как строка "Иван Петров" может быть значением различных свойств. Иван Петров может быть автором Документа 1, но с другой стороны, это значение может быть использовано при описании членов спортивного клуба. Однозначная идентификация ресурсов обеспечивает повторное использование явной описательной информации.
В приведенном примере был создан уникально идентифицируемый ресурс для автора, но не для имени, телефона или других свойств. RDF-модель позволяет создавать множественные уровни описания ресурсов. Например, свойство "Имя" вполне можно рассматривать как отдельный ресурс, содержащий свойства "Фамилия", Имя" и "Отчество". Очевидно, что при использовании более сложных элементов такое выделение ресурсов может продолжаться сколь угодно глубоко.
OWL (Web Ontology Language) — язык представления онтологий, расширяющий возможности XML, RDF, RDF Schema и DAML+OIL. Этот проект предусматривает создание мощного механизма семантического анализа.
Онтологии отличаются от XML-схем тем, что это представления знаний, а не форматы сообщений (большинство Web-стандартов состоят из комбинации форматов сообщений и спецификаций протоколов).
1.3. Типология и структура распределенных ИР
Документальные АИПС по своим возможностям различаются достаточно существенно. Это связано не столько с решениями тех или иных разработчиков, сколько с многочисленными факторами, в той или иной степени, ограничивающими или даже исключающими некоторые функциональные возможности. Такими факторами являются, например, назначение и область применения, масштабность и интенсивность использования ИР, характер распределения информационных компонент (для сетевых систем), тип информации, источники и режим пополнения, предполагаемый профессиональный уровень потребителей и т.д.
По архитектуре, определяющей физическую доступность ресурсов, информационно-поисковые системы (в том числе и Internet-машины) могут быть разделены на следующие классы:
локальные системы – локализованные данные и их обработка;
частично-распределенные – локальная обработка распределенных данных;
полностью распределенные системы, где реализуются принципы распределенных вычислений и распределенного хранения данных.
Локальные системы обеспечивают доступ удаленных пользователей к ресурсам, сосредоточенным на поисковом сервере. Эти системы в большинстве случаев функционально эквивалентны локальным системам, например, на CD-ROM-носителях.
Ко второму типу относятся системы, использующие данные, находящиеся на Web-серверах в качестве распределенных первичных ИР; вторичные и индексные данные сосредоточены на поисковом сервере, осуществляющем обслуживание пользователей. Это такие системы, как AltraVista, Google, Yandex и пр.
К третьему типу относятся системы, в которых процесс поиска реализуется на совокупности серверов, распределенных по сети, которые при обработке запроса опрашивают друг друга, причем исходные и промежуточные данные поиска также имеют распределенный характер.
По тематическому и видовому спектрам ИР могут быть однородными (иметь четко выраженную тематику и работать с документами определенного типа и состава) и гетерогенными (политематическими и не имеющих требований к составу и форме документов).
По способу формирования ИР подразделяются на те, которые используют предопределенные источники, например публикации издательств, рецензирующих материалы, и те, которые используют все свободно доступные материалы. Примерами здесь, соответственно, являются базы данных научной информации и поисковые машины Internet, индексирующие открытые HTML-страницы.
Если рассматривать информационные ресурсы и системы в этом контексте, то можно заметить, что в качестве компонентов здесь выступают электронные каталоги (библиографические и реферативные базы данных), полнотекстовые массивы (электронные журналы, фактографические базы данных, хранилища электронных копий источников в том или ином виде и т.д.), справочно-нормативные файлы (рубрикаторы, тезаурусы, авторские, предметные, географические и другие указатели), возможно связанные между собой ссылками, указателями хранения или условиями поиска, хотя уже по своей сути эти компоненты всегда были и будут связаны, по крайней мере, на концептуальном уровне. Например, записи электронных каталогов содержат указания местоположения книг, а справочно-нормативные файлы традиционно используются в качестве "точек входа" в библиографические и реферативные базы данных.
С точки зрения характера и формы представления информации (и, соответственно, логики организации поиска) архитектура ИР включает три уровня: уровень собственно документов (полных текстов), уровень поисковых образов и метаинформационный уровень. Характер и логика взаимосвязей информационных элементов отдельных уровней отражен схемой на слайде 13.11, где в скобках даны примеры, характерные для автоматизированных или традиционных информационных систем.
Взаимосвязь между компонентами разных уровней может быть реализована как для компонентов в целом, так и для их элементов. Иллюстрацией служит, например, такая связь, как "библиографическая запись электронного каталога - запись полнотекстовой базы данных" или "библиографическая запись - оцифрованная копия источника (изображение)". К другому типу - на уровне элементов - могут относиться такие связи, как "пристатейная ссылка - библиографическая запись" или "фрагмент библиографической записи - запись нормативной базы данных" и т.д.
Рассматривая эту схему как «технологию» поиска, можно видеть, что ссылки вполне узнаваемы и представляют собой традиционные правила и приемы отыскания информации в условиях “бумажной” библиотеки, когда поиск начинается с классификационной схемы или указателя, далее через библиографические карточки к первоисточнику, где, используя пристатейные ссылки и указатели, снова продолжается с метаинформационного уровня.
С широким внедрением телекоммуникационных сетей и некоторой стандартизации представления данных в Internet задача взаимосвязи становится еще более сложной. Ее решение путем создания статичных связей практически невозможно, даже если бы все компоненты имели свои уникальные идентификаторы и незыблемое место в информационном пространстве (чего зачастую невозможно добиться даже для локальных массивов). Что уж говорить о, скажем, информационных объектах, появляющихся на многочисленных сайтах Internet. Любое изменение местоположения информационного объекта влечет за собой возникновение "ложных" связей в распределенных электронных библиотеках. И число этих связей с течением времени возрастает. Поэтому на смену статичным связям приходят динамические, связи. Их особенностью является то, что они генерируются программно, по предопределенным алгоритмам во время обращения к объекту. Таким образом, можно связать информационные объекты, но при условии достаточной определенности (специфицированности) элементов.
Связи внутри могут быть построены на таких идентификаторах, как давно применяемые ISBN и ISSN или сравнительно недавно возникшие DOI (Digital Object Identifier). В тех случаях, когда такие идентификаторы отсутствуют (а таких случаев большинство), одним из решений может быть генерация динамических связей. В качестве основы для построения идентификаторов здесь могут выступать либо уникальные элементы записи, либо их свертки.
Кроме того, в качестве идентификаторов, используемых для установки активных связей, могут служить части элементов библиографического описания, организованные, например, в виде поисковых индексов. Таким способом можно связывать, скажем, компоненты справочно-нормативных файлов и массивов библиографических записей. Конечно, это возможно лишь при достаточно строгой структуризации компонентов баз данных и применении алгоритмов свертки, допускающих минимальный процент дублирования.
Отметим в заключение, что именно эти различия архитектуры, стратегии комплектования и организации доступа в итоге определяют не только функциональные возможности средств поиска конкретного ИР, но и круг потенциальных пользователей, а так же результативность решаемых ими задач.
13.4. Проектирование распределенных
документальных информационных ресурсов
Одна из главных задач, которую призваны решать системы управления - это интеграция данных из различных источников, в том числе со слабоструктурированными данными. Системы интеграции данных должны обрабатывать запросы, для ответа на которые может потребоваться извлечение и обобщение данных из различных источников. При этом возможны следующие варианты:
Регулярные источники, где представление и организация данных в той или иной степени формализованы, хотя при этом могут использоваться различные модели данных и интерфейсы доступа к ним, или данные источника могут быть не структурированными.
Источники уникальные, т.е. взаимодействовать с источником можно только через предоставляемый им интерфейс и нет никакой возможности повлиять на его внутренние процессы.
Теоретически и практически возможны два подхода к решению задачи интеграции данных – хранилища данных и виртуальные хранилища (или «витрины данных»).
Для построения систем объединяющих большое количество источников, содержание которых часто изменяется (например, Web-ресурсы), наиболее предпочтительным является виртуальный подход.
Рассматривая типичную организацию виртуального хранилища, выделим два уровня логический и физический.
Логический уровень определяется выбором модели данных и языка запросов для этой модели. Выбранная модель используется для представления данных, извлекаемых из всех источников. Таким образом, пользователь системы интеграции получает возможность унифицированного доступа ко всем данным. Важным требованием к модели данных является обеспечение прозрачности доступа к внешним источникам, т.е. пользователь видит внешние данные как локальные и в выбранной им модели, не заботясь об управлении доступом к источнику.
Физический уровень. Ключевым понятием организации виртуального хранилища являются средства преобразования данных. На слайде 13.12 приведена типичная архитектура, основанная на распространенной концепции посредников.
Основными компонентами, обеспечивающими возможность интегральной обработки распределенных данных, являются «оболочка» и «посредник».
Оболочка используется для хранения информации о внешнем источнике и организации доступа к нему. При получении запроса оболочка обращается к источнику через предоставляемый им интерфейс. Полученные от источника данные конвертируются во внутренний формат данных хранилища.
Посредник осуществляет интеграцию данных из различных источников (используя различные оболочки). Посредник может взаимодействовать как с оболочками, так и с другими посредниками. Таким образом, предоставляется возможность построения сложной сети взаимодействующих между собой посредников, что позволит обобщать данные различными способами для удовлетворения нужд различных приложений.
Существо проектирования распределенных документальных ИР имеет свои особенности. В следствие того, что основное назначение документальных ресурсов - долговременное хранение и ретроспективный поиск информации, практически каждый ресурс имеет свою историю и, часто, создается как уникальный. Поэтому объектом проектирования является не архитектур обобщенного ресурса, для в результате проектирования которой определяются свойства составляющих, а скорее их информационные взаимосвязи, которые можно установить исходя из возможностей уже существующих решений.
Для распределенных информационных систем характерны огромные объемы и низкая структурированность данных, неоднородность, независимость и разные условия управления и политики доступа. При этом возникают вопросы информационной совместимости, в частности на техническом, синтаксическом и семантическом уровнях.
Для преодоления этой «анархии» используется унификация метаданных, описывающих содержимое ресурса в виде набора именованных значений, в том числе связей с другими ресурсами (одним из средств в этом случае является использование спецификации Namespaces, которая решает задачу унификации имен в XML-документах и разделения имен между различными системами управления ресурсом вместо многочисленных переопределений).
Метаданные могут относиться к различным предметным областям, в рамках одной иметь разные выражение и интерпретацию. Создание и согласование стандартных прикладных профилей метаданных и онтологий упростит интеграцию разнообразных систем, позволит автоматизировать обмен метаданными, их обработку и преобразование, повысить точность и эффективность поиска.
На этапе проектирования необходимо специализировать общие схемы метаданных под потребности конечных приложений, разработать набор элементов метаданных для общей части ПрО и профили метаданных конкретных научных областей, согласуя их с отраслевыми и международными стандартами; обеспечить выделение и согласование общепринятых классификаторов ресурсов и тезаурусов.
Другой аспект проектирования распределенной ИС - маршрутизация запросов и объединение ответов. При этом используются “предварительные знания” – информацию, используемую с целью обоснованной рассылки поисковых запросов, и формируемую на основе локальных индексов.