19281

Использование коммуникативных форматов и протоколов. Объектная модель до-кумента (DOM). XML, RDF, OWL

Лекция

Информатика, кибернетика и программирование

Лекция 13. Использование коммуникативных форматов и протоколов. Объектная модель документа DOM. XML RDF OWL. Многоуровневые и многокомпонентные информационные ресурсы. Типология и структура распределенных ИР. Проектирование распределенных документальных информационных...

Русский

2013-07-11

287.37 KB

10 чел.

Лекция 13.

Использование коммуникативных форматов и протоколов. Объектная модель документа (DOM). XML, RDF, OWL.

Многоуровневые и многокомпонентные информационные ресурсы. Типология и структура распределенных ИР. Проектирование распределенных документальных информационных ресурсов.

Этап предобработки документальных ИС предполагает преобразование документов в машиночитаемую форму, пригодную не только для обработки в АИС, но и для унифицированного обмена между различными АИС. Формализация процессов получения машиночитаемых форм документов основана на стандартизованных в настоящее время решениях –использовании коммуникативных форматов и специализированных языков разметки, поддерживающих объектную модель документа.

13.1. Коммуникативные форматы для обмена

библиографическими данными

Впервые задача создания машиночитаемых каталогов была поставлена и решена Библиотекой Конгресса США. В 1965 –гг. в Библиотеке Конгресса был разработан проект, направленный на исследование возможности получения библиографического описания в машиночитаемой форме. Этот проект положил начало созданию семейства форматов MARC (Machine-Readable Catalogue), ориентированных на обмен всеми видами документов и решение разнообразных информационно-библиотечных задач, включая каталогизацию и применение в различных автоматизированных системах.

Структура формата была зафиксирована американским национальным стандартом Z39.2, а позднее на основе формата MARC был создан международный стандарт ISO 2709. По мере развития информационно-поисковых систем и создания электронных ресурсов, ориентированных на семантический поиск, были разработаны стандарты, предопределяющие повышенные требования к поисковому образу документа. Примерами таких форматов являются форматы международной службы INIS-AtomIndex, фирм Dervent и INSPEC, отечественный формат обмена научно-технической информацией МЕКОФ.

Стандарты семейства коммуникативных форматов для обмена библиографическими и другими данными на машиночитаемых носителях определяют структуру записи и ее наполнение. При этом разные национальные и фирменные стандарты имеют практически одинаковую структуру (соответствующую требованиям ISO-2709) и достаточно разнообразные требования к наполнению, где основные различия касаются набора элементов данных и их представлений.

Структура библиографической записи ISO-2709

Библиографическая запись в коммуникативном формате ISO-2709 - это совокупность полей, описывающая одну или несколько библиографических единиц, рассматриваемых как единое целое. Структура формата может быть охарактеризована как «самоопределенная». Каждый экземпляр записи может иметь свой состав полей переменной длины и свой вариант представления данных. Это достигается тем, что запись имеет три блока: заголовок, справочник, область элементов данных. Размещение полей данных определяется справочником переменной длины. В свою очередь структура справочника и элементов данных определяется заголовком.

Отдельная запись коммуникативного формата схематично может быть представлена структурой, изображенной на слайде 13.2.

Заголовок представляет собой часть записи, имеющую фиксированную длину и содержащую данные для ее обработки. Фиксированная структура заголовка позволяет унифицировать процедуры доступа как к записи в целом, так и к ее отдельным полям.

Заголовок состоит из следующих компонентов (слайд 13.2):

длина записи (позиции 0-4) - количество символов в записи, включая маркер и разделитель записи;

статус записи  (позиция 5) - один символ, который должен быть определен в нормативно-технических документах по применению данной структуры записи, например, «новая» или «исправленная и пересмотренная» запись;

коды применения (позиции 6-9) - коды, которые могут быть определены в нормативно-технических документах по применению данной структуры;

длина индикатора (позиция 10) - десятичная цифра, определяющая количество символов индикатора.;

длина идентификатора (позиция 11) - десятичная цифра, определяющая количество символов идентификатора –разделителя подполей.;

базовый адрес данных  (позиции 12-16) - десятичное число, указывающее общую длину в символах маркера записи и справочника, включая разделитель поля в конце справочника;

план справочника  (позиции 20-23):

позиция 20 - десятичная цифра, указывающая длину в символах компонента «длина поля данных» каждой статьи справочника;

позиция 21 - десятичная цифра, указывающая длину в символах компонента «позиция начального символа» каждой статьи справочника.

позиция 22 - десятичная цифра, указывающая длину в символах компонента «часть, определяемая при применении» каждой статьи справочника;

позиция 23 - зарезервирована.

Справочник состоит из переменного числа статей, каждая из которых идентифицирует соответствующее поле данных. Все статьи справочника имеют одинаковую структуру, задаваемую в плане справочника.

Первые 3 позиции статьи справочника всегда занимает трехзначная метка поля. Метки полей определяются конкретным форматом, но всегда имеют трехсимвольное числовое значение.

Следующий обязательный компонент статьи справочника задает длину поля данных. Размер компонента указан в 20-й позиции плана заголовка.

Позиция начального символа - десятичное число, определяющее позицию первого символа поля данных, идентифицируемого меткой, относительно базового адреса данных. Длина компонента в символах задается в 21-й позиции заголовка.

На слайде 13.2 представлена статья справочника, заданного планом ‘4500’.

Справочник заканчивается специальным символом-разделителем.

Поля данных переменной длины следуют за справочником и содержат библиографические данные. Поле может состоять из одного или более элементов данных или подполей. Длина полей в символах определяется количеством символов, необходимых для хранения текстовых данных, индикаторов, идентификаторов подполей и разделителя поля. Метки не содержатся в полях данных, а приводятся только в справочнике.

Пример записи в формате МЕКОФ представлен на слайде 13.3.

13.2. Технологии интеграции распределенных данных

на основе XML

Проблема интеграции информации из различных источников (в том числе и из Internet) прежде всего в том, что во многих случаях данные слабо структурированы: нет схемы, которая была бы задана заранее, а данные из разных источников могут иметь как различный набор атрибутов, так и различные типы. Более того, каждый из источников может иметь свою степень автономности и характеризоваться своими метаданными (Слайд 13.4).

Слабоструктурированными называются данные, обладающие непостоянной либо не полностью определенной структурой. Коллекции таких документов иногда называют «не имеющими схемы» (schema-less) или «самоопределенными» (self-describing). Характерной особенностью слабоструктурированных данных является то, что описательная информация, которая обычно выделяется в отдельную схему, в той или иной форме присутствует в самих наборах данных. В некоторых формах представления слабоструктурированных данных не предусмотрено применение отдельной схемы, а в других она существует, но накладывает на представленные в ней данные очень слабые ограничения.

Схема слабоструктурированных данных может быть как предписывающей, так и описывающей.

Примером предписывающей схемы слабоструктурированных данных является Document Type Definition (DTD). Если разбираемый документ не соответствует DTD, процессор прекращает его разбор и сигнализирует об ошибке. Таким образом, предписывающая схема накладывает ограничения на структуру данных.

Предписывающей является также XML-схема, которая определяет структуру XML-документа, а XML-процессоры используют это определение при разборе. XML-схемы (по сравнению с DTD) обладают более широкими возможностями для определения типов данных и интеграции пространства имен, реализуя тем самым открытую модель данных. Безусловным достоинством XML-схем является также то, что они позволяют представлять правила формирования XML-документа средствами самого XML.

XML (Extensible Markup Language) - язык разметки, описывающий класс объектов данных, называемых XML- документами. XML изначально является средством обмена данными и практически не зависит от платформы, операционной системы, языка программирования и т. д. XML —это стандарт, утвержденный World Wide Web Consortium (W3C), и поэтому анализаторы для чтения XML-документов имеются почти для всех основных платформ, включая MS Windows, UNIX.

Для обработки XML-документов можно использовать ряд связанных стандартов, таких как: Document Type Definitions (DTD) и XML-схемы, позволяющие определять XML-документы; спецификация Namespaces; язык указателей XML (XML Pointer Language - XPointer); язык ссылок XML (XML Linking LanguageXLink); язык запросов XQuery; объектная модель (Document Object Model - DOM); интерфейсы API; язык преобразования Extensible Stylesheet Language (XSLT).

При рассмотрении модели слабоструктурированных данных обычно выделяют две основные проблемы: во-первых, структура данных обычно известна лишь частично, во-вторых, она является глубоко вложенной или даже циклической. Соответственно, большинство подходов к управлению слабоструктурированными данными основано на использовании языков запросов, обеспечивающих прохождение по древовидному размеченному графу, который служит для идентификации данных путем указания позиции элемента данных в коллекции. Это означает, что способы выполнения запросов к данным теряют свой традиционный декларативный характер и становятся в большей степени навигационными.

Объектная модель документа (DOM) предполагает представление структуры и содержания документа в виде совокупности узлов, каждый из которых имеет свои свойства (имя, тип, значение, число дочерних узлов) и методы (создание, удаление, вставка). DOM определяет стандартный набор объектов для представления HTML- и XML-документов, методы и алгоритмы комбинирования этих объектов, а также интерфейс для доступа к ним и выполнения операций над ними.

Основы XML

XML –это средство для описания грамматики представления и контроля правильности составления документов. 

Инструкции языка, заключенные в угловые скобки, называются тэгами и служат для разметки основного текста документа.

Если XML-документ не нарушает правила синтаксиса XML, он называется формально-правильным или хорошо оформленным документом, и разборщики XML-документов будут работать с ним корректно.

Хорошо оформленные XML-документы, удовлетворяющие также требованиям DTD или XML-схем, определяющих их структуру и содержание, называются состоятельными.

Правильные, хорошо оформленные XML-документы должны удовлетворять следующим требованиям (Слайд 13.5):

1). В XML все элементы должны иметь закрывающий тэг, т.е. в отличие от HTML, XML не разрешается опускать конечные тэги элементов

2). В тэгах XML учитывается регистр. Например, <Book> отличается от <book>. Таким образом, начальные и конечные тэги должны быть записаны в одном регистре.

). Элементы XML должны быть правильно вложены друг в друга, например:

<b><i>Этот текст пишется полужирным курсивом</i></b>

Перекрывание элементов возникает тогда, когда закрывающий тэг внешнего элемента располагается перед закрывающим тэгом внутреннего элемента.

4). XML-документы должны иметь единственный корневой элемент. Все остальные элементы должны быть вложены в корневой элемент.

) Значения атрибутов всегда должны быть заключены в кавычки.

6) Все пробелы являются значимыми, т.е. при отображении пробелы в XML-документе не будут устраняться. 

) В XML есть несколько зарезервированных символов, которые используются только как элементы синтаксиса XML. Такими зарезервированными символами являются пять следующих знаков:  <, >, &, , .

XML-документы имеют два раздела: пролог и тело документа (Слайд 13.6) 

Пролог, предваряющий любой XML-документ, включает объявление XML и объявление типа документа. Объявление XML заключается между парами символов <? и ?> и может включать указание программе-анализатору текущего стандарта, объявление кодировки и самостоятельности, а объявлению типа документа предшествует ключевое слово DOCTYPE, например, объявление XML-документа с внешним DTD-определением в файле sample.dtd:

<?xml version=”1.1” encoding=”UTF-8” standalone=”yes”?>

<!DOCTYPE sampledoc SYSTEM “sample.dtd”>

К телу документа относится все кроме пролога.

Тело XML-документа состоит из элементов разметки и непосредственно содержимого документа –данных и представляет собой набор элементов и атрибутов, секций CDATA, директив анализатора, комментариев, спецсимволов, текстовых данных.

Помимо элементов и атрибутов, обеспечивающих структурированное представление текстовой информации, языки разметки могут оперировать и двоичными данными (специальные символы, графика и т.д.) - сущностями, которые представляют собой поименованные фрагменты данных.

Элементы данных - это структурные единицы XML-документа, например (Слайд 13.7):

<flower> rose </flower>

<root>

<child>

 <subchild>.....</subchild>

</child>

</root>

В общем случае в качестве содержимого элементов могут выступать как текст, так и другие, вложенные, элементы документа, заключенные между начальным и конечным тэгами.

Элементы могут иметь подэлементы (дочерние элементы). Подэлементы должны быть правильно вложены внутри родительского элемента (в примере - <root>, <child>).

Элементы XML в свою очередь могут иметь собственные характеристики, задаваемые атрибутами.

Атрибуты определяют собственные характеристики элемента и задаются парой название = «значение» при определении элемента, например:

<color RGB="true">#ff08ff</color>

<color RGB="false">white</color>

DTD –описания

DTD-правила определения XML-документа должны быть представлены либо в виде отдельного внешнего файла, либо в виде последовательности деклараций в прологе документа (Слайд 13.8).

В первом случае в документе указывается имя файла, содержащего DTD-описания:

<?xml version="1.0"?>

<! DOCTYPE journal SYSTEM "journal.dtd">

Внутри документа DTD-декларации включаются следующим образом:

<!DOCTYPE journal [

<!ELEMENT journal (contacts, issues, authors)>

...

]>

При проверке документа XML-процессор в первую очередь ищет DTD внутри документа. Если DTD-декларации внутри документа не определены и не задан атрибут standalone ="yes", то будет загружен указанный внешний файл. Если же атрибут standalone имеет значение "yes", то использование внешних DTD описаний будет запрещено. В том случае, если используются одновременно внутренние и внешние описания, то программой-анализатором будут сначала рассматриваться внутренние, т.е. их приоритет выше.

Элемент в DTD определяется с помощью инструкции !ELEMENT, в которой указывается название элемента и структура его содержимого (Слайд 13.9).

Например, для элемента <flower> можно дать следующее определение:

<!ELEMENT flower  PCDATA>

Ключевое слово ELEMENT указывает, что данной инструкцией будет описываться элемент XML. Внутри этой инструкции задается название элемента (flower) и тип его содержимого - PCDATA. Специальный тип PCDATA (Parseable character data) означает любую информацию, с которой может работать программа-анализатор.

Существует еще две инструкции, определяющие тип содержимого: EMPTY, ANY. Первая указывает на то, что элемент должен быть пустым (например, <red/>), вторая - на то, что содержимое элемента специально не описывается.

Последовательность дочерних для текущего элемента объектов задается в виде списка разделенных запятыми названий элементов. При этом для того, чтобы указать количество повторений включений этих элементов, могут использоваться следующие символы:

  •  "+" означает, что соответствующий элемент может встречаться один или более раз;
  •  "?" означает, что может быть не более одного элемента, или же элемент может отсутствовать вообще;
  •  "*" означает, что элемент может отсутствовать или появляться один или более раз.

Например:

<!ELEMENT issue (title, author+, table-of-contents?)>

В этом примере указывается, что внутри элемента <issue> должны быть определены элементы title, author и table-of-contents, причем элемент title является обязательным элементом и может встречаться лишь однажды, элемент author может встречаться несколько раз, а элемент table-of-contents может отсутствовать. В том случае, если существует несколько возможных вариантов содержимого определяемого элемента, их следует разделять при помощи символа "|" :

<!ELEMENT flower (PCDATA | title )*>

Символ «*» в этом примере указывает на то, что определяемая последовательность внутренних элементов может быть повторена несколько раз или же совсем не использоваться.

Атрибуты элемента (Слайд 13.9) определяются списком с помощью ключевого слова ATTLIST. В списке задаются названия атрибутов, типы их значений и дополнительные параметры. Например, для элемента <article> могут быть определены следующие атрибуты:

<!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:

<!ENTITY hello 'Добрый день!' >

Программа-анализатор, просматривая содержимое области DTD-определений, обработает эту инструкцию и при дальнейшем разборе документа использует содержимое DTD-сущности в том месте, где будет встречаться ее название. Таким образом, в документ можно вставлять выражение &hello; , которое будет замещено строкой «Добрый день!». 

В общем случае, внутри DTD можно задать три типа сущностей:

  •  внутренние сущности - предназначены для определения строковой константы. Внутренние сущности включаются в документ при помощи амперсанта «&»;
  •  внешние сущности - указывают на содержимое внешнего файла, причем этим содержимым могут быть как текстовые, так и двоичные данные. В первом случае в месте использования сущности будут вставлены текстовые строки, во втором - бинарные данные, которые анализатором не рассматриваются, а используются внешними программами:

<!ENTITY logotype SYSTEM "/image.gif" NDATA GIF87A>

  •  макроопределения правил - макроопределения параметров, могут использоваться только внутри области DTD и обозначаются специальным символом «%», вставляемым перед названием сущности. При этом содержимое сущности будет помещено непосредственно в текст DTD- правила

Спецификация RDF

Спецификация XML-схем предоставляет более полный и строгий метод определения модели информационного наполнения документа XML, чем определения DTD. Но и она не обеспечивает поддержку необходимого уровня семантической совместимости. Например, если два приложения должны обмениваться информацией с помощью XML, то назначение и подразумеваемый смысл используемых при этом документов должны быть согласованы с той структурой данных, которая формируется при обмене, для чего необходимо создать модель предметной области с описанием данных, которые требуются для одного и другого приложения.

Такую модель обычно принято описывать в терминах объектов или отношений (например, для этой цели может использоваться язык универсальный язык моделирования - UML). А поскольку схема XML описывает только синтаксическую структуру документа, одна и та же модель предметной области может быть представлена в виде схемы XML разными способами, т.к. в общем случае невозможно определить непосредственное соответствие между моделью предметной области и определенной схемой. Эта проблема становится еще более сложной, если в обмене информацией должны участвовать не два, а несколько приложений.

Для решения описанной выше задачи необходимо пройти следующие три этапа:

  •  восстановить первоначальные модели предметных областей из схем XML;
  •  определить соответствия между объектами моделей предметных областей;
  •  определить механизмы преобразования для документов XML.

Эти этапы на практике иногда становятся очень сложными, поэтому может оказаться, что язык XML хорошо подходит для обмена данными только между приложениями, для которых уже известна модель информационного наполнения, но плохо подходит для тех ситуаций, когда к обмену данными присоединяются все новые и новые приложения.

Инфраструктура описания ресурсов (Resource Description FrameworkRDF), разработанная под эгидой 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 является Иван Петров"
  2.  "Иван Петров –автор документа 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-документах и разделения имен между различными системами управления ресурсом вместо многочисленных переопределений).

Метаданные могут относиться к различным предметным областям, в рамках одной иметь разные выражение и интерпретацию. Создание и согласование стандартных прикладных профилей метаданных и онтологий упростит интеграцию разнообразных систем, позволит автоматизировать обмен метаданными, их обработку и преобразование, повысить точность и эффективность поиска.

На этапе проектирования необходимо специализировать общие схемы метаданных под потребности конечных приложений, разработать набор элементов метаданных для общей части ПрО и профили метаданных конкретных научных областей, согласуя их с отраслевыми и международными стандартами; обеспечить выделение и согласование общепринятых классификаторов ресурсов и тезаурусов.

Другой аспект проектирования распределенной ИС - маршрутизация запросов и объединение ответов. При этом используются “предварительные знания” –информацию, используемую с целью обоснованной рассылки поисковых запросов, и формируемую на основе локальных индексов.


 

А также другие работы, которые могут Вас заинтересовать

41404. Разработка программного обеспечения информационных систем 194.5 KB
  Основные причины успеха и провала проектов В отчете группы Стендиша 1994 указано три наиболее часто встречающихся ключевых фактора создающих проблемы в проектах. Некое свойство программного обеспечения необходимое пользователю для решения проблемы при достижении поставленной цели. Подход к управлению требованиями Область проблемы Как правило мы находимся во владениях пользователячужестранца. Таким образом наша задача состоит в том чтобы понять их проблемы в их предметной области и на их языке и построить системы удовлетворяющие их...
41405. Управление требованиями. Объектно-ориентированный анализ и проектирование 240 KB
  Вторую категорию составляют непрямые пользователи а также те на кого воздействуют только бизнес последствия разработки. Этих заинтересованных лиц можно найти в соответствующей бизнес области или в окрестностях среды конкретного приложения. Ограничения налагаемые на систему ввода заказов на покупку Источник Ограничение Объяснение Эксплуатационный Копия данных заказа на покупку должна оставаться в унаследованной базе данных в течение одного года Риск потери данных слишком высок; нам необходимо работать параллельно в течение года...
41406. МЕТОДЫ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ 85.5 KB
  Пять этапов анализа проблемы Достижение соглашения об определении проблемы Выделение основных причин проблем стоящих за проблемой Выявление заинтересованных лиц и пользователей Определение границ системырешения Выявление ограничений налагаемых на решение 5. Синдром неоткрытых руин Синдром пользователя и разработчика Функции продукта или системы Потребности заинтересованных лиц и пользователей Функции Управление сложностью путем выбора уровня абстракции Атрибуты функций продукта 9. Предельно недорога ...
41407. Обыгрывание ролей 196.5 KB
  Проблема требований Цель Статистика Основные причины успеха и провала проектов Высокая цена ошибок требований 2. Инженерия систем интенсивно использующих программное обеспечение Задача выявления требований 7. Преграды на пути выявления требований Синдром да но. МЕТОДЫ ВЫЯВЛЕНИЯ ТРЕБОВАНИЙ Совещания посвященные требованиям Мозговой штурм и отбор идей Раскадровка Применение прецедентов 9.
41408. Документ Delta Vision 225 KB
  Он представляет собой достаточно подробное описание на естественном языке поэтому основным участникам проекта легко с ним работать. Разработка документаконцепции и работа с ним являясь центром приложения действий многих участников заказчиков пользователей представителей руководства проекта и маркетинга могут играть заметную роль в успехе или неудаче программного проекта. При создании первой версии документа это не так уж сложно так как практически все пункты в перечне будут новыми для данного проекта или по крайней мере должны...
41409. Промышленные технологии проектирования ИС 152.5 KB
  По степени использования типовых проектных решений различают следующие методы проектирования: оригинального индивидуального проектирования когда проектные решения разрабатываются с нуля в соответствии с требованиями к ЭИС; типового проектирования предполагающего конфигурацию ЭИС из готовых типовых проектных решений программных модулей. Итеративному подходу присуща внутренняя гибкость позволяющая включать в бизнесцели новые требования или тактические изменения. Хотя ни один отдельно взятый процесс не способен удовлетворить...
41410. ТИПОВОЕ ПРОЕКТИРОВАНИЕ ИС 250.5 KB
  В качестве примеров широко распространенных функциональных ППП можно назвать: 1С Предприятие автоматизация бухгалтерского учета расчета заработной платы складского учета Фолио Склад автоматизация складских операций Project Expert бизнеспланирование ИНЭК финансовый анализ и др. Таким образом вместе с программным продуктом пользователи приобретают базу знаний knowhow об эффективных методах организации и управления бизнеспроцессами которые можно адаптировать в соответствии со спецификой конкретного экономического...
41411. Рецепция «вечных» образов в современной литературе. Своеобразие трактированния образов Каина та Авеля в притче Х.Л. Борхеса «Каин и Авель» 26.86 KB
  Своеобразие трактированния образов Каина та Авеля в притче Х. Борхеса Каин и Авель. Борхеса притча писателя Каин и Авель.Своеобразие трактированния образов Каина та Авеля в притче Х.
41412. Объектно-ориентированный анализ и проектирование 80 KB
  Введение в объектно-ориентированный анализ и проектирование. Объектно-ориентированный анализ и проектирование Основная идея объектно-ориентированного анализа и проектирования objectoriented nlysis nd design состоит в рассмотрении предметной области и логического решения задачи с точки зрения объектов понятий или сущностей как показано на рис. В процессе объектно-ориентированного анализа основное внимание уделяется определению и описанию объектов или понятий в терминах предметной области.