Текст книги "Электронные издания"

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

Браузер создает интерфейс с сервисом запросов и должен обеспечивать следующие функции:

✓ иерархический доступ каталог/файл, аналогичный менеджеру файлов;

✓ интерфейсы для поиска;

✓ просмотр списка ответов, включающего миниатюры;

✓ навигацию по связям между документами.

Если данный клиент обладает правами доступа к хранилищу изданий, он может, выбрав одну из миниатюр, сформировать запрос к хранилищу изданий на получение соответствующего документа. После определенного времени ожидания, связанного с выбором соответствующего информационного носителя в хранилище, сервер доставки начнет передачу клиенту запрошенной информации. Второй главный компонент браузера – средства просмотра для мультимедийных изданий. Для этого компонента существенно, чтобы медиадокументы были представлены в распространенных форматах либо легко преобразовывались в них. Браузер, однако, должен быть способен получать документы в их "родных" форматах и активизировать соответствующие приложения обработки, например, чтобы пользователь мог просматривать, а при необходимости и редактировать документы. В данном случае для воспроизведения медиа-потоков с сервера доставки используется интерфейс MSMC (Media System Manager Client) API (Application Program Interface). Это программный интерфейс пользователя для взаимодействия с сервером Sun MediaCenter. Поддержку этого API обеспечивает менеджер потока (MSM), являющийся агентом клиента на сервере. Скрывая все детали управления и передачи видеопотоков, API MSMC предоставляет пользователю несколько абстракций, в том числе – титулы (наименования медиадокументов) и список титулов для проигрывания. Операции над титулами полностью имитируют управление обычным видеопроигрывателем: воспроизведение, быструю перемотку, обратное проигрывание. Сказанное иллюстрируется рис. 7.11.

Рис. 7.11. Информационная система доставки медиа-изданий из хранилища

Основные свойства API MSMC:

✓ концепция проигрывателя, списка проигрывания, титулов;

✓ различные режимы проигрывания;

✓ проигрывание титулов по расписанию;

✓ контроль доступа к проигрывателю;

✓ параллельный доступ к одному списку проигрывания нескольких клиентов.

При интерпретации удаленных обращений клиентов менеджер потока на сервере MSM опирается на оглавление титулов, через которые осуществляется доступ к системе медиафайлов (MFS). В соответствии с моделью выталкивания MSM лишь инициирует проигрывание, но не производит декодирование потока. Менеджер потока MSM и его протокол API принимает запросы и направляет потоки битов по нужным адресам, где локально выполняется декодирование и визуализация. В будущих реализациях предполагается расширить API MSMC функциями управления титулами.

Простая клиентская программа MSMC выглядит следующим образом. Логическая связь клиента с сервером называется сессией. Чтобы открыть сессию, требуется задать IP-сервера и обратиться к нему. В результате клиентская программа получает логический дескриптор сервера, служащий ключом для всех следующих операций. Далее обычно с сервера извлекается список титулов, доступных для проигрывания, и для тех из них, которые представляют интерес, запрашивается необходимая скорость воспроизведения и возможные режимы проигрывания. Следующий шаг – создание плеера. Плеер – это размещающийся на сервере агрегат данных, состоящий из списка проигрывания, логической головки и списка контроля доступа. Обычно на сервере имеется несколько плееров, каждый из них идентифицируется своим дескриптором. При создании плеера клиентская программа строит список проигрывания, в котором указаны названия и относительное время начала проигрывания. После того как плеер создан, клиент соединяет его со своим IP-адресом и запускает проигрывание титула из списка.

API MSMC позволяет разделять плееры между приложениями, т. е. различными процессами на клиентской машине, а также приложениями на разных машинах. Разделение основывается на уникальности дескриптора плеера. Обладание дескриптором дает приложению полный контроль над всеми его функциями. Дескрипторы могут свободно передаваться между приложениями по любому механизму, сохраняющему битовое представление: через файл, общую память или сокеты (Sockets). Последний представляет собой абстрактный интерфейс сетевого взаимодействия для потоковой системы передачи информации низкого уровня.

Менеджер потока MSM контролирует отдельно доступ к серверу и доступ к плеерам с тремя уровнями прав: на чтение, управление и администрирование. Владелец прав чтения с сервера может получить списки плееров, титулов и текущие состояния плееров. Права администрирования сервера дают возможность создавать/удалять плееры. Доступ по чтению к плееру позволяет получить его список проигрывания. Обладая правами управления плеером, можно изменять скорость и длительность проигрывания титулов. Наконец, администрирование плеера – это установка прав доступа для других пользователей. Пользователь, создавший плеер, имеет на него все права доступа и может определить их для остальных пользователей.

7.6. Публикация содержимого баз данных на Web-страницах

Наряду с хранением подготовленных и опубликованных изданий в электронной форме в базах данных, откуда их всегда можно извлечь и напечатать дополнительный тираж, нередко требуется решить обратную задачу – опубликовать содержимое тех или иных баз данных, например, в виде Web-страницы (ее части или нескольких страниц). Ниже рассматривается возможность таких публикаций в двух вариантах: в виде статических и в виде динамических Web-страниц. В первом случае содержимое опубликованной страницы остается неизменным и отражает состояние базы данных в момент получения ею запроса на извлечение определенной информации. Во втором случае поддерживается непрерывная связь между базой данных и опубликованными ее страницами. В результате при изменении содержимого БД содержимое Web-страниц также изменяется.

Источником для создания статической Web-страницы может служить любой набор записей в базе данных. Обычно на таких страницах публикуется таблица базы данных (или ее некоторая часть) или данные, полученные в результате выполнения некоторого запроса к базе. Вариантом публикации может быть отчет, созданный на основе данных, содержащихся в базе. Такая публикация в дальнейшем просматривается в браузере. Если отчет состоит из нескольких страниц, то формируется несколько HTML-файлов, связанных друг с другом гипертекстовыми ссылками. Однако при этом не сохраняется связь этого файла с источником данных, т. е. Web-страница остается неизменной при изменении содержимого базы данных.

Все такие публикации создаются в результате экспорта соответствующих объектов базы данных. Если для такой операции используется база, созданная в рамках СУБД Access (она входит в состав пакета MS Office), то рекомендуется придерживаться следующего порядка действий:

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

Рис. 7.12. Выбор объекта базы данных для публикации

2. Выбрать объект для публикации, т. е. выбрать соответствующую вкладку диалогового окна, показанного на рис. 7.12 (в примере нажата кнопка Отчеты и выбран отчет Итоги продаж по объему).

3. С помощью команды Экспорт (рис. 7.13) меню Файл открыть диалоговое окно Экспорт объекта, показанное на рис. 7.14.

Рис. 7.13. Интерфейс базы данных Борей с командами меню Файл

Рис. 7.14. Диалоговое окно Экспорт объекта

4. При необходимости указать имя HTML-шаблона в появившемся после нажатия кнопки Сохранить диалоговом окне Параметры вывода в формате HTML.

Полученный HTML-документ может содержать несколько страниц, связанных гиперссылками. Так в нашем примере он состоит из 3 страниц (см. рис. 7.15). Из них первая или основная носит присвоенное отчету имя, а для остальных к этому имени добавляется номер страницы. В качестве примера на рис. 7.16 показана первая страница документа. Гиперссылки в виде переходов к предыдущей, последующей, а также первой и последней страницам, размещены в нижней части полосы. Содержательная часть страниц представлена значениями из учебной базы «Борей», распространяемой совместно с СУБД MS Access.

Рис. 7.15. Пример полученного отчета по продажам в виде 3-страничного HTML-документа

Рис. 7.16. Первая (лицевая) страница отчета

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

✓ использование HTML-форм и CGI-скриптов для их обработки;

✓ динамические публикации страниц в формате IDC/HTX;

✓ публикации динамических Web-страниц в формате ASP;

✓ применение специальных страниц доступа к данным.

Первый вариант связан с пересылкой на сервер запроса в виде HTML-формы, в которой указаны переменные, текущие значения которых требуется узнать. На сервере с помощью CGI-скриптов эти формы обрабатываются и с помощью интерфейса с СУБД, поддерживающей локализованную на нем же базу данных, возвращаются новые значения соответствующих величин, которыми заменяют прежние [11, 15]. Этот способ обеспечивает максимальную гибкость, но требует создания и хранения на сервере CGIскриптов и других пользовательских процедур. Другие варианты организации динамической связи требуют, чтобы на сервере был определен соответствующий источник данных. Технология IDC (Internet Database Connector – средство связи сети Интернет с базой данных)/HTX (HTml eXtension – расширение языка HTML) позволяет передать параметры запроса пользователя к базе данных как часть сообщения от браузера на сервер, получая в ответ динамически сформированную Web-страницу. Запрос, посылаемый серверу, – это текстовый файл в формате IDC, в котором содержится набор операторов языка SQL (Structured Query Language – язык структурированных запросов).

Язык SQL поддерживается практически всеми СУБД. В данном случае с его помощью формируется описание действий, которые выполняются на серверной стороне. Соответственно IDC-файл является исполняемым и на сервере должен размещается в папке Scriots (сценарии), предназначенной для исполняемых процедур. Пользователь обязан иметь возможность занесения файлов в эту папку. В составе IDC-файла должен также находиться шаблон, описывающий Web-страницу, в составе которой находится таблица, форматирование которой определяет, каким образом будут отображаться данные, извлеченные из базы.

Какой же порядок динамического взаимодействия между пользователем и базой данных? Пользователь вводит в адресном окне браузера адрес IDCфайла. Web-сервер отыскивает этот файл в папке Scripts и активизирует динамическую библиотеку httpodbc.dll. Процедуры этой библиотеки просматривают IDC-файл и определяют имя внешнего источника данных (URL базы данных). Из библиотеки выбирается нужный драйвер, который взаимодействует с источником данных, выполняя запрос на языке SQL, и извлекает нужную информацию из этого источника. После этого специальная процедура библиотеки получает из IDC-файла имя шаблона и формирует на основании его гипертекстовый файл, который отсылается браузеру компьютера клиента. Наконец, последний формирует и отображает Web-страницу в своем окне [15].

Технология публикаций ASP (Active Server Pages) подобна рассмотренной первой. Отличие лишь в том, что она адаптирована к использованию Webсервера, работающего в операционной системе Windows и вместо CGIскриптов использует процедуры взаимодействия, написанные на языке VBScript – одной из ветвей языка Bisual Basic.

Самой современной и наиболее эффективной в настоящее время является технология динамической публикации на основе страниц доступа к данным (Data Access Pages – DSP). Страница доступа к данным представляет собой Web-страницу, на которой размещены связанные с внешним источником данных компоненты ActiveX (см. разд. 4.4), а также процедуры, написанные на языке VBScript. Сочетание гибкости управления объектами страниц доступа к данным с мощными функциональными возможностями компонентов ActiveX делает такую технологию чрезвычайно эффективной для организации удаленного доступа к данным и их динамической публикации на Web-страницах.

Страницы доступа к данным интегрированы в СУБД MS Access, причем в окне базы данных им отведена отдельная вкладка "Группы". Они разрабатываются в режиме "Конструктор страниц". Разработанные страницы доступа следует поместить в соответствующую папку Web-сервера. В самой базе данных остаются ярлыки, указывающие на файлы гипертекста, описывающие эти страницы. Использование страниц доступа к данным позволяет создавать интерактивные отчеты, формы для удаленного ввода, редактирования и удаления записей в базе данных, средства для удаленного анализа данных.

Детальное изучение этих технологий не входит в содержание нашей книги. Поэтому мы отсылаем всех интересующихся данным вопросом к книгам [28, 36]. Некоторые сведения по принципам и применению CGI-технологий можно извлечь также из книги [32] и статьи [15].

Контрольные вопросы

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

2. Какими свойствами должна обладать информационная система современного издательства? Можете ли вы привести пример издательства, где все эти свойства реализованы?

3. Зачем в издательстве нужна интрасеть? Какие функции возлагаются на нее? Вы сталкивались с ними?

4. В каких издательствах требуется экстрасеть и какие функции на нее возлагаются? Вам приходилось сталкиваться с экстрасетями? Какое у вас осталось о них впечатление?

5. Какой компонент издательской системы является, по вашему мнению, основным? Почему вы так считаете?

6. Что должно быть сделано в издательской информационной системе для автоматизации ввода публикаций и их атрибутов? Что для этого требуется от самих публикаций?

7. Какие средства для выделения нетривиальной (существенной) информации из текстовых фрагментов и иллюстраций вы знаете? В чем трудности выделения такой информации из аудио– и видеофрагментов?

8. Какие, по вашему мнению, требуются программные и информационные средства доставки публикаций из хранилища на рабочее место пользователя системы? Чем принципиально отличаются средства доставки мультимедиа-информации?

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

10.Какие протоколы для передачи данных используются в интрасетях? Как они согласуются с протоколами в сети Интернет?

11.Какие простейшие способы защиты информации применяются для интрасетей? Что такое "брандмауэр" в информационных технологиях? Как он работает?

12.Что такое "Обеспечение для групповой работы"? Какие его основные функции и в чем состоят его преимущества?

13.Попробуйте сформулировать, в чем состоят основные функции интрасетей?

14.Какие вы можете назвать преимущества использования интрасетей? Попробуйте перечислить главные из них.

15.Какие основные требования предъявляются к издательской базе данных или информационному хранилищу издательства? Попробуйте перечислить основные из этих требований.

16.Какими способами или методами организуется хранение электронных публикаций? В чем вы усматриваете различия между ними? Каковы преимущества и недостатки каждого из них?

17.Для чего нужна поисковая система и какие способы организации поиска вы знаете? В чем различия между ними? Какой поисковой системой вы пользовались и в каких случаях?

18.Какие модели полнотекстового поиска вы знаете? В каких ситуациях вы пользовались этими моделями? В чем отличие между ними? Какая модель более эффективна и в каких случаях?

19.Какие критерии эффективности полнотекстового поиска вы знаете? Что такое "точность" и "охват" как характеристики эффективности поиска в системе? Какими соотношениями они связаны?

20.Как оптимизировать структуру издательской базы данных, чтобы она наиболее полно соответствовала предъявляемым требованиям?

21.Какие вы знаете технические средства для долговременного (многолетнего) хранения информации? Чем они отличаются друг от друга с точки зрения технических и стоимостных характеристик?

22.Какие параметры следует хранить в атрибутивной базе данных? Как и по каким параметрам следует реализовать поиск в такой базе?

23.Как и по каким критериям следует строить интерфейс системы поиска изданий по ключевым словам? Как осуществлять выбор ключевых слов и их соединение в логические конструкции?

24.Какие технические средства для доставки потоковой информации клиенту вы знаете? В чем их отличия от обычных персональных компьютеров?

25.Какие файловые и операционные системы используются для доставки информации клиенту?

26.Какая модель взаимодействия медиа-сервера с клиентом применяется в таких системах?

27.Какие подсистемы используются на клиентском (пользовательском) рабочем месте? Назначение каждой их этих подсистем?

28.Как на практике осуществить публикацию содержимого баз данных в виде статических Web-страниц?

29.В чем состоят особенности публикации содержимого баз данных в виде динамических Web-страниц? Какие вы знаете варианты динамического связывания этих страниц с внешними источниками информации?

30.Какой вариант динамического связывания Web-страниц с внешними источниками представляется вам более предпочтительным? По каким причинам? Приходилось ли вам работать со скриптами? Пытались ли вы использовать в них язык Perl?

Глава 8
Метаинформация и автоматизация извлечения атрибутов и ключевых слов

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

8.1. Роль метаинформации в поисковых стратегиях

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

В настоящее время объем информации, циркулирующей в среде Интернет, приближается или уже даже превысил некий критический предел, в результате чего значительная ее часть остается невостребованной, препятствуя, по существу, эффективному использованию этой среды. Все более актуальной становится задача создания гибкой информационной среды для хранения документов, включая статьи, доклады, книжные издания. Желательно обеспечить возможность сборки таких документов в группы (коллекции) с последующей возможностью включения этих первичных коллекций в состав других групп, стремясь получить в результате иерархическую структуру, упорядочивающую информационное пространство в целом. Наличие такой структуры дозволило бы пользователям по своему усмотрению подбирать содержание искомых документов и форму их отображения. Все перечисленное способствовало бы также и решению проблемы персонификации информации.

Для большинства Web-приложений принятой практикой является хранение документов без соответствующей метаинформации, которая указывает автора произведения, время его создания, срок хранения, права доступа и пр. В этих условиях затрудняется поиск специфической информации. С одной стороны это связано с тем, что контекстный поиск ведет к необходимости анализа большого числа документов, которые даже по тематике никак не могут быть отнесены к требуемому их множеству. С другой стороны, в сети Интернет циркулирует огромное количество устаревших документов, доступ к которым нельзя прекратить из-за отсутствия у них самого понятия «срок хранения».

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

Для описания метаданных консорциумом W3C подготовлен стандартный формат их представления – Resource Description Framework (RDF), который определяет основные принципы обработки метаданных и обеспечивает функциональную совместимость Web-приложений, обменивающихся такой информацией. В RDF использованы принципы объектно-ориентированного программирования и моделирования и элементы языков HTML, SGML и XML. Следует заметить, что с одной стороны язык XML описывает в RDF синтаксис метаданных, а RDF, в свою очередь, позволяет описывать семантическую структуру XML-документов и передавать смысл данных, заключенных между XML-тегами. Видимо, именно с помощью метаданных и стандарта RDF постепенно может начаться процесс постепенного превращения Всемирной паутины в упорядоченную систему хранения и модификации разнообразной информации, полностью пригодную для выполнения эффективного поиска и извлечения данных. С другой стороны с помощью метаданных возможно удастся сделать из WWW информационное хранилище, обеспечивающее не только быстрый поиск и удобный доступ к документам, но и эффективное управление огромными объемами данных.

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

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

Как уже говорилось ранее (см. главу 2), функция описания поискового образа документа была возложена на тэг <META>. До этого в качестве поискового образа документа использовался либо весь документ, либо слова первого абзаца. Тэг <META> имеет 2 параметра: NAME, с помощью которого задается имя атрибута и CONTENT, который определяет значение или содержимое этого атрибута. Например:

<META NAME="author" CONTENT="В. А. Вуль">.

<META NAME="description" CONTENT="Учебное пособие АВТОМАТИЗИРОВАННЫЕ ИЗДАТЕЛЬСКИЕ СИСТЕМЫ И ТЕХНОЛОГИИ"> или

<META NAME="description" CONTENT = "документ посвящен проблемам применения тэга 'МЕТА' для описания атрибутов и ключевых слов, используемых в гипертекстовом документе">.

<META NAME="keywords" CONTENT="метаинформация, поиск по ключевым словам, учебное пособие, HTML-документ, атрибутивный поиск>.

Здесь с помощью параметра NAME="description" тэга <META> можно задать как название документа, так и его описание или реферат, который сохраняется в качестве пояснения в ссылке на документ в базе данных поискового сервера и выдается на экран монитора в ответе на запрос к серверу. С помощью параметров тэга <META> можно также задать: имя автора, название издательства, время выхода документа в свет, срок хранения документа в сети, и даже список ключевых слов, используемых в нем.

Наиболее последовательно использование этого тэга в поисковых стратегиях реализовано на поисковом сервере Webcrawler. При индексировании документа поисковым роботом значения параметра CONTENT тэгов <META> после фильтрации попадет в индекс поисковой машины и может быть использовано для составления запросов. Процесс фильтрации отбракует в них стоп-слова. В составе атрибутов будут учтены автор, название и т. п.

Многие роботы, индексирующие документы HTML, пользуются описанием, которые они находят в параметре "description" при выводе информации о найденных документах. Если этой инструкции в документе не окажется, то в результатах поиска будет содержаться описание документов в виде 256 или 512 первых их символов, разумеется, за вычетом команд языка HTML. Возможность контролировать то, какое описание страницы получит пользователь, позволяет повысить шансы на извлечение этой Web-страницы посетителем, интересующимся именно этой темой. Наличие мета-описания позволяет пользователю поисковой машины даже при беглом просмотре списка обнаружить нужные ему страницы.

Тэг <META> используется многими программами подготовки документов. Они размещают в нем свой идентификатор. В общем случае контейнер <META> и </META> выглядит следующим образом:

<meta [name=имя] [http-equiv=имя_HTTP-оператора] content=текст>

Практика показывает, что при индексировании можно указывать одновременно и атрибут NAME и атрибут HTTP-EQUIV с одинаковыми значениями. Это связано с тем, что одни роботы-индексировщики анализируют содержание META-элемента по атрибуту NAME, а другие – по атрибуту HTTP-EQUIV [42].

В качестве примера на рис. 8.1 приводится заголовочная часть HTML-документа, полученного в результате конвертирования этого раздела, подготовленного в редакторе Word 2000, в HTML-формат с помощью диалогового окна Сохранить как, где в качестве типа файла указано значение Web-страница.

Рис. 8.1. Начало заголовочной части HTML-документа

На рис. 8.1 показана только малая часть содержимого контейнера <HEAD> и </HEAD>. Все содержимое превышает 400 строк текста. Гипертекстовый документ представляется в формате HTML 5.0, который еще не утвержден в качестве стандарта и поддерживается только программными средствами фирмы Microsoft. С помощью самого тега <META> представлена информация о том, что для подготовки исходного документа и его преобразования в HTML-формат использовался редактор Word и что кодировка текста соответствует странице Windows-1251. Затем следует заголовок документа, который совпадает с названием раздела. Далее в тэге комментариев (< !– – >) указаны его свойства (<o:DocumentProperties>). В свойствах размещены сведения о тематике документа (<o:Subject>Учебное пособие для студентов СЗИП ПГУТД </o:Subject>), авторе (o:Author>В. А. Вуль</o:Author>), времени создания документа (2002-01-02), количестве содержащихся в нем страниц, слов и символов, а также строк (125) и абзацев (22). Перечислены также ключевые слова, но, к сожалению, это лишь те ключевые слова, которые автоматически выделяет из текста редактор Word 2000 в режиме команды Автореферат меню Сервис. Попутно отметим, что основную часть содержательных сведений автор занес вручную в диалоговом окне Свойства, вызываемом с помощью одноименной команды меню Файл. Следует также заметить, что поисковые роботы не умеют пока обрабатывать новые тэги языка HTML, представленные в версии 5.0. Таким образом, пока практически вся информация, заносимая в заголовочную часть HTML-документа в данном редакторе, совершенно не используется в поисковых стратегиях, а лишь увеличивает объем гипертекстового документа (см. также главу 4).

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