ЦИФРОВАЯ БИБЛИОТЕКА GREENSTONE

РУКОВОДСТВО

Greenstone - пакет прикладных программ, предназначенный для формирования и распространения цифровых фондов библиотек. Это обеспечивается новым способом организации информации и публикации ее в сети Интернет или на CD-ROM. Программное обеспечение Greenstone разработано в Новозеландском университете Вайкато, в рамках Проекта создания цифровых библиотек в сотрудничестве с ЮНЕСКО и НПО Human Info. Исходный продукт - это свободно распространяемое программное обеспечение, которое можно получить по адресу http://greenstone.org. Использование данного продукта оговаривается в Лицензионном соглашении о свободном доступе GNU.

Мы надеемся, что это программное обеспечение работает хорошо. Пожалуйста, сообщите о любых проблемах по адресу: [email protected]

Greenstone gsdl-2.50  Март 2004

Об этой инструкции

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

Раздел 1 дает учетную запись лицу, непосредственно участвующему в процессе формирования коллекций, включая разработку структуры директорий, внутреннего формата документа и файла конфигурации, который управляет структурой каждой коллекции. Раздел 2 описывает части Green¬stone, которые обрабатывают исходные документы (и метаданные) и регламентируют доступ к информации через интерфейс пользователя. Здесь также описываются "внешние" программные компоненты, которые распространяются вместе с Greenstone. В разделе 3 представлено описание структуры системы поддержки выполнения Greenstone, а также дано подробное описание программного обеспечения, призванное помочь пользователю лучше понять, как оно работает и как можно изменить систему, чтобы она удовлетворяла различным потребностям. Раздел 4 описывает файлы конфигурации Greenstone, а в Приложении представлена Стандартная библиотека шаблонов C++.

При работе с программным обеспечением Green¬stone Вы можете столкнуться со ссылками на особенности системы, которые не описаны в настоящем руководстве. Это связано с тем, что Greenstone находится в постоянном развитии. Чтобы быть в курсе текущей работы, подпишитесь на рассылку Greenstone (инструкции на сайте greenstone.org).

Сопутствующие документы

Полный комплект документации к Greenstone состоит из пяти томов:

• Руководство по установке цифровой библиотеки Greenstone
• Инструкция для пользователя (этот документ) цифровой библиотеки Greenstone
• Руководство разработчик а цифровой библиотеки Greenstone
• Цифровая библиотека Greenstone: от Бумаги до Коллекции
• Цифровая библиотека Greenstone: Использование Органайзера

Copyright

Copyright © 2002 2003 2004 2005 2006 2007 by the New Zealand Digital Library Project at the University of Waikato, New Zealand.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled “GNU Free Documentation License.”

Благодарность

Программное обеспечение Greenstone - продукт совместного труда множества людей. Rodger McNab и Stefan Boddie принципиальные разработчики системы. Неоценимый вклад внесли David Bainbridge, George Buchanan, Hong Chen, Michael Dewsnip, Katherine Don, Elke Duncker, Carl Gutwin, Geoff Holmes, Dana McKay, John McPherson, Craig Nevill-Manning, Dynal Patel, Gordon Paynter, Bernhard Pfahringer, Todd Reed, Bill Rogers, John Thompson, и Stuart Yeates. Остальные члены Проекта Новозеландской цифровой библиотеки разработали вдохновенный дизайн всей системы: Mark Apperley, Sally Jo Cunningham, Matt Jones, Steve Jones, Te Taka Keegan, Michel Loots, Malika Mahoui, Gary Marsden, Dave Nichols и Lloyd Smith. Мы также выражаем свою признательность всем тем, кто трудился над созданием пакетов, попадающих под действие лицензии GNU, и включенных в дистрибутив: MG, GDBM, PDFTOHTML, PERL, WGET, WVWARE и XLHTML.

Contents

Понятие процесса формирования коллекций

Создание коллекций из командной строки

Директории Greenstone

Процессы import и build

Архив документов Greenstone

Файл конфигурации коллекции

Получение большего от ваших документов

Приложения

Классификаторы

Выходной формат Greenstone

Управление пользовательским интерфейсом Greenstone

Директория packages

Работа системы Greenstone

Структура процесса

Концептуальная структура

Совместимость концептуальной структуры

Исходный код

Общие типы Greenstone

Collection server

Протокол

Регистратор

Инициализация

Конфигурирование вашего Greenstone - сайта

Основной файл конфигурации

Файл конфигурации сайта

Приложение А: Стандартная библиотека шаблонов C++

Списки (Lists)

Maps

Литература

1 Понятие процесса формирования коллекций

Конечный пользователь Greenstone может создать коллекции, используя Коллектор (Collector), описанный в документе Цифровая библиотека Greenstone: Руководство пользователя (Раздел ). Он позволяет очень просто создавать коллекции на базе уже существующих, но с новым наполнением. Однако невозможно пользоваться Коллектором при создании коллекций с абсолютно новой структурой. В этом случае придется вносить изменения в файл конфигураций, который управляет структурой коллекции, ведь для того, чтобы радикальные изменения возымели эффект, Вам необходимо знать гораздо больше о системе Greenstone. Данный раздел содержит все, что Вам необходимо знать для этого. В этом разделе также описывается структура директорий Greenstone и формат внутреннего хранения документов.

Мы подразумеваем, что на вашем компьютере установлена система Greenstone, сконфигурированная под оболочку Windows или Unix. Если вы еще не установили систему, то сделайте это, воспользовавшись комплектом документации Цифровая библиотека Greenstone: Руководство по установке. Для обращения к основному каталогу Greenstone повсеместно используется имя GSDLHOME, которое для системы Windows выглядит как %GSDLHOME%, а для Unix - $GSDLHOME. Вы создаете этот каталог в процессе установки Greenstone на ваш компьютер.

1.1 Создание коллекций из командной строки

Начав создание коллекций из командной строки, вы пройдете по всей операционной цепочке, что позволит вам лучше понять этот процесс. Разумеется, для наибольшего числа схожих коллекций вы будете пользоваться Коллектором. Для примера мы воспользуемся коллекцией, находящейся на установочном CD-ROM и состоящей из домашних WWW-страниц множества лиц, работавших над проектом создания Новозеландской цифровой библиотеки и системой Greenstone.

Отдельные подразделы практически не отличаются друг от друга, однако они были созданы для работы с Greenstone в различных операционных средах, таких как Windows и Unix. Вам остается только выбрать. на базе операционной системы вашего компьютера. При беглом просмотре некоторые операции могут вам показаться непонятными и таинственными, однако выполните их, близко придерживаясь к инструкциям - подробное описание этих операций будет дано несколько позже. В конце подраздела дано краткое резюме о различиях между процессами формирования коллекций на базе Widows и Unix.

Формирование коллекций под Windows

При формировании коллекций Greenstone в среде Windows через командную строку изначально необходимо запустить "command prompt" - приглашение для ввода ваших команд. Попробуйте посмотреть через основное меню Start -^Programs, найдите MS-DOS Prompt, DOS Prompt, или Command Prompt. Если вы не нашли ничего из описанного выше, запустите Start ~$Run и в диалоговом окне напечатайте command (or cmd). Если запуск команды окончился безуспешно, то обратитесь к своему системному администратору.

Внесите изменения в каталог, в который была установлена система Greenstone. По умолчанию Greenstone устанавливается в каталог, в который можно попасть напечатав

(Вы должны использовать кавычки из-за пробела в имени директории Program Files). Далее, в следующем окне напечатайте

Этот файл (который вы можете просмотреть) указывает системе, где искать программы Greenstone[1]. Если при работе в интерактивном сеансе DOS prompt вы захотите вернуться на верхний уровень каталога Greenstone вы можете сделать это, напечатав cd "%GSDLHOME%" (непременно в кавычках). Если вы закончили работу в окне DOS, а потом запустили новую сессию, то вы должны запустить заново setup.bat.

Теперь вы имеете возможность формировать или переформировывать коллекции. Сначала мы рассмотрим программу mkcol.pl, написанную на Perl, имя которой означает "make a collection" (создание коллекции). Первый запуск этой программы можно осуществить, напечатав perl -S mkcol.pl, при этом на экране появится описание использования и список параметров. Если окружение вашей операционной системы Windows настроено на работу с приложениями Perl, файлами с расширением .pi, то эта процедура не займет много времени. Как вы можете видеть в предоставленном примере, единственный обязательный аргумент - это creator (создатель), который исползуется для описания лица, формирующего коллекцию.

Теперь мы используем эту команду для создания нашей коллекции, состоящей из домашних WWW-страниц участников проекта создания Цифровой библиотеки Greenstone. Для того, чтобы присвоить коллекции имя, я напечатал

(или mkcol.pl —creator me@cs. waikato. ac. nz dlpeople если Perl связан с расширением файла .рГ). Пожалуйста, замените мой email адрес на собственный!

Для просмотра вновь созданных файлов перейдем в только-что созданный каталог коллекции. Для этот печатаем:

Вы можете просмотреть содержимое директории, напечатав dir. В ней должно находиться 7 поддиректорий: archives, building, etc, images, import, index и perllib.

Теперь необходимо заполнить коллекцию документами. Источник материалов для коллекции dlpeople находится на установочном CD-ROM Greenstone в каталоге collect\dlpeople. Сначала вставьте CD-ROM в читающее устройство (например, D:\). Далее скопируйте содержимое каталогаD:\collect\dlpeople в директорию import коллекции dlpeople. Вы можете сделать это в следующем порядке:

В качестве альтернативы вы можете напечатать следующую команду:

В каталоге коллекции etc существует файл с именем collect, cfg. Откройте его, используя любой текстовый редактор, либо используйте редактор, настроенный по умолчанию. В результате вы увидите окно, содержимое которого выглядит так, как показано на рисунке 1, показывая содержимое файла конфигурации коллекции, созданного с использованием команды perl-S mkcol.pl -creator [email protected] dlpeople.

Теперь вы готовы импортировать коллекцию. Это процесс переноса документов в систему Greenstone, стандартизации формата документов, пути спецификации метаданных и структуры файла, в котором будут храниться документы. Напечатайте perl -Simport.pl и в результате вы получите список опций для операции импорта. Для упрощения процесса воспользуйтесь базовой командой:

Не беспокойтесь по поводу быстро бегущего по экрану текста - это отчет о выполнении процедуры импорта. К сведению, процесс импорта этой коллекции занимает около 5 минут на 1 ГТц компьютере и несколько дольше на более медленных машинах. Обратите внимание на то, что вы не должны находиться в директориях collect или dlpeople при запуске этой команды; T.K.GSDLHOME уже определил для работы системы Greenstone местоположение необходимых файлов.

Теперь давайте внесем изменения в файл конфигурации коллекции для модификации его вида. Сначала присвоим коллекции имя. Оно будет воспринято веб-броузером, как заголовок для титульного листа WWW-страницы, и использоваться в качестве иконки при отсутствии рисунка. Изменим строку collectionmeta collectionname "dlpeople" на строку вида collectionmeta collectionname "The People of the NZDL project".

Добавим описание коллекции между кавычками: collectionmeta collectionextra "". Оно будет использовано в качестве материала для описании раздела "About" (о коллекции) на домашней WWW-странице. Я добавил "This collection is made up of the homepages of some of the people who have worked on the NZDL project." Важно вводить это описание одной строкой - не используйте для отбивки клавишу Enter/Ввод. Если вы хотите использовать в вашей коллекции многоязычный интерфейс, то существует способ вывода данного текста в соответствии с выбранным языком. Это описание будет представлено далее в разделе 1.5.

Вы можете использовать изображения, которые будут представлены в качестве иконок на WWW-странице коллекции; изображение, созданное мною, вы можете видеть на рисунке 2. Укажите путь нахождения изображения в кавычках в строке collectionmeta iconcollection "" файла конфигурации. Для краткости и мобильности _httpprefix_ может быть использован в качестве стартового URL указывающего на изображение, находящееся в файловой области Greenstone. Например, вы можете ввести: _httppreflx_/collect/dlpeople/images/icon.gif если вы поместили подходящее изображение в соответствующую директорию коллекции (в нашем примере это: collect\dlpeople\images ).

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

Следующая фаза - "построение" коллекции, в которой будут созданы все индексы и файлы, отвечающие за работу коллекции. Напечатайте в командной строке perl —S buildcol.pl и получите список опций для формирования коллекции. Подробное описание этих опций представлено в Разделе 1.3. Пока же придерживайтесь значений "по умолчанию", напечатав:

И снова не беспокойтесь о быстро бегущем по экрану тексте - это отчет о выполнении команды.

Теперь "оживим" коллекцию:

выделите содержимое каталога building коллекции dlpeople и перенесите его в каталог index.

Так же вв можете проделать эту операцию, напечатав команду:

и изменить имя каталога building на index командой

В заключение напечатайте:

подготовив систему для будущих переформирований. Важно, чтобы все эти команды были выполнены из требуемой директории (в отличие от команд Greenstone mkcol.pl, import.pl and buildcol.pl); если текущая рабочая директория не является dlpeople, напечатайте: cd "%GSDLHOME%\collect\dlpeople" до того, как вы запустите на исполнение команды rd, ren и mkdir.

Вы должны уметь обращаться к вновь созданной коллекции с вашей домашней страницы Greenstone. Если эта страница открыта в вашем броузере, вы должны ее обновить или закрыть окно броузера и перезапустить его (для того, чтобы избежать проблем кэширования). Если вы пользуетесь "локальной версией библиотеки" Greenstone, то должны перезапустить всю программу. Для просмотра новой коллекции щелкните кнопкой мыши по изображению. Полученный результат вы можете увидеть на рисунке 3.

В заключение приведем команды, создающие коллекцию:

Создание коллекции под Unix

Сначала вносим изменения в директорию, в которую была установлена система Greenstone. К примеру, если Greenstone была установлена с именем "по умолчанию, то в директорию верхнего уровня можно попасть, напечатав:

Затем напечатать:

Этого файлы (которые вы можете просмотреть) указывают системе, где искать программы Greenstone. Если позже вы захотите вернуться на верхний уровень директории Green¬stone, напечатайте в командной строке cd $GSDLHOME.

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

Теперь вы имеете возможность формировать или переформировывать коллекции. Сначала мы рассмотрим программу mkcol.pl, написанную на Perl, имя которой означает "make a collection" (создание коллекции). Первый запуск этой программы можно осуществить, напечатав mkcol.pl, при этом на экране появится описание использования и список параметров. Как вы можете видеть в представленном примере, единственный обязательный аргумент - это creator (создатель), который исползьуется для описания лица, формирующего коллекцию.

Теперь используем команду для создания начальных файлов и директорий, необходимых для создания домашней страницы участников проекта создания Цифровой библиотеки Greenstone. Для того, чтобы присвоить коллекции имя dlpeople, я печатаю:

Пожалуйста, измените мой email адрес на свой собственный!

Для просмотра вновь созданных файлов перейдем в директорию созданной коллекции. Для этого напечатаем:

Вы можете просмотреть содержимое этой директории, напечатав Is. Здесь должно быть 7 директорий: archives, building, etc, images, import, index и perllib.

Теперь необходимо заполнить коллекцию документами. Источник материалов для коллекции dlpeople находится на установочном CD-ROM Greenstone в каталоге collect/dlpeople. Для получения информации с CD-ROM под Linux вставьте диск в читающее устройство и напечатайте команду:

(эта команда может отличаться от системы к системе). После устаноки CD-ROM может использоваться, как любая другая директория, и напечатав Is /cdrom/collect, можно получить доступ к директории с именем dlpeople на CD-ROM.

Затем скопируйте содержимое директории /cdrom/collect/dlpeople в директорию $GSDLHOME/collect/dlpeople/import. Для того, чтобы сделать это, напечатайте команду:

Затем наберите:

для того, чтобы закрыть CD-ROM напечатайте

В директории коллекции etc находится файл collect.ucfg. Откройте его, воспользовавшись любым текстовым редактором или наиболее популярным в Linux текстовым редактором - emacs. В результате вы увидите окно, содержимое которого выглядит, как на рисунке 1, показывая содержимое файла конфигурации коллекции, созданного с использованием команды mkcol.pl -creator [email protected] dlpeople.

Теперь вы готовы импортировать коллекцию. Это процесс переноса документов в систему Greenstone, стандартизации формата документов, пути спецификации метаданных и структуры файла, в котором будут храниться документы. Напечатайте команду import.pl и получите полный список опций программы импорта. Для упрощения процедуры воспользуйтесь базовой командой

Не беспокойтесь по поводу быстро бегущего по экрану текста - это отчет о выполнении процедуры импорта. К сведению, процесс импорта этой коллекции занимает около 5 минут на 1 ГГц компьютере и несколько дольше на более медленных машинах. Обратите внимание на то, что вы не должны находиться в директориях collect или dlpeople при запуске этой команды, т.к. GSDLHOME уже определил для работы системы Greenstone местоположение необходимых файлов.

Теперь давайте внесем изменения в файл конфигурации коллекции для модификации ее вида. Сначала присвоим коллекции имя. Оно будет воспринято веб-броузером как заголовок для титульного листа WWW-страницы, и использоваться в качестве иконки при отсутствии рисунка. Изменим строку collectionmeta collectionname "dlpeople" на строку вида: collectionmeta collectionname "The People of the NZDL project".

Добавим описание коллекции между кавычками: collectionmeta collectionextra "". Оно будет использовано в качестве материала для описания раздела "About" (о коллекции) на домашней WWW-странице. Я добавил "This collection is made up of the homepages of some of the people who have worked on the NZDL project." Важно вводить это описание одной строкой - не используйте для отбивки клавишу Enter/Ввод. Если вы хотите использовать в вашей коллекции многоязычный интерфейс, то существует способ вывода данного текста в соответствии с выбранным языком. Это описание будет представлено далее в разделе 1.5.

Вы можете использовать изображения, которые будут фигурировать в качестве иконок на WWW-странице коллекции. Изображение, созданное мною, вы можете видеть на рисунке 2. Укажите путь нахождения изображения в кавычках в строке collectionmeta iconcollection "" файла конфигурации. Для краткости и мобильности _httpprefix_ может быть использован в качестве стартового URL, указывающего на изображение, находящееся в файловой области Greenstone. Например, вы можете ввести: httpprefix_/collect/dlpeople/images/icon.gif если вы поместили подходящее изображение в соответствующую директорию коллекции (в нашем примере это: collect\dlpeople\images ).

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

Следующая фаза - "построение" коллекции, в которой будут созданы все индексы и файлы, отвечающие за работу коллекции. Напечатайте в командной строке buildcol.pl и получите список опций для формирования коллекции. Подробное описание этих опций представлено в Разделе 1.3. Пока же придерживайтесь значений "по умолчанию", напечатав:

И снова не беспокойтесь о быстро бегущем по экрану тексте - это отчет о выполнении команды.

Сделайте коллекцию "оперативной", как только материалы помещены в каталог building, перешлите их в каталог index. Если у вас прежде была уже сформирована коллекция, сначала удалите старые индесы, напечатав в командной строке:

(предполагается, что вы работаете в директории dlpeople). Затем введите:

Вы должны уметь обращаться к вновь созданной коллекции с вашей домашней страницы Greenstone. Если эта страница открыта в вашем броузере, вы должны ее обновить или закрыть окно броузера и перезапустить его (для того, чтобы избежать проблем кэширования). Если вы пользуетесь "локальной версией библиотеки" Greenstone, то должны перезапустить всю программу. Для просмотра новой коллекции щелкните кнопкой мыши по изображению. Полученный результат вы можете увидеть на рисунке 3.

И в заключение приведем распечатку команд для создания коллекции dlpeople:

Различия между Windows и Unix

Создание коллекций в среде Unix и среде Windows очень похожи, за исключением некоторых небольших расхождений, которые были сведены в Таблицу 1.

1.2 Директории Greenstone

На рисунке 4 представлена структура директорий GSDLHOME. В Таблице 2 дано краткое описание содержимого каждой директории, показанной на диаграмме. Некоторые директории будут более детально рассмотрены в последующих разделах настоящего руководства - информация о разделах представлена в Таблице 2.

1.3 Процессы import и build

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

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

Процесс import

Процесс импорта служит для конвертации документов из их первичных форматов в Формат Архива Greenstone, используемый системой Greenstone, и записи в конечный файл (с именем archives, inf), который будет использоваться тогда, когда коллекция уже будет сформирована. Import.pl должен знать, какое приложение должно быть использовано и где находится файл-оригинал документа. В Таблице 3 представлены опции для процессов импорта и формирования; в Таблице 4 даны дополнительные опции, касающиеся только процесса импорта. Опции OIDtype заслуживают более подробного рассмотрения. Каждый документ имеет связанный Object Identi¬fier (Идентификатор Объекта) или OID. Это наилучший способ для хеширования содержимого документа (hash/хеш). Хотя он и очень медленный, но все же является достаточно простой альтернативой накоплению, представляя документы в том порядке, в котором они были импортированы. Вы можете использовать накопление для ускорения работы, но все же используйте хеширование в случае, если позже захотите добавить документы к вашей коллекции (без повторной процедуры импорта).

На рисунке 5 представлен процесс импорта, инициированный процедурой работы программы import.pl. Каждый овал представляетсобой модуль исполняющий задачи определенной части системы Greenstone. Все эти модули находятся в директории GSDLHOME/perllib.

Для шага 3. Обратите внимание, что переменные импортирования, такие как importdir и archivedir могут быть запущены из командной строки или из файла конфигурации коллекции.Если запуск произведен из командной строки, то все установки, сделанные через файл конфигурации, игнорируются.

На 6 шаге был создан файл информационного архива (archives.ini).

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

Большая часть работы в процессе импорта делается приложениями, вызываемыми модулем plugin. Этот модуль создает конвейер приложений, описанных в файле конфигурации коллекции. Он также обслуживает запись документов архива Greenstone, используя объект document.

Процесс build

В течение процесса формирования происходит сжатие текста, по полному тексту производится индексация, описанная в файле конфигурации коллекции. Кроме того, на этом этапе обрабатывется и подключается информация о том, как уже сформированная коллекция будет выглядеть во всемирной паутине -например, данные о заголовках и иконках, классификационные данные и т.д. Buildcol.pl имеет много опций, используемых совместно с import.pl, см. Таблицу 3, и несколько уникальных, представленных в Таблице 5.

На рисунке 6 показана диаграмма пошагового выполнения процесса buildcol.pl. Многие из шагов относятся и к процессу импорта. Первый отличительный шаг - 4. Он производится только в том случае, если установлена опция create_images. Затем изображения создаются и регистрируются в файле конфигурации коллекции функцией скрипта buildcol.pl. Для того, чтобы это сработало, должны быть установлены и сконфигурированы программа GIMP (GNU Image Manipulation Program) и модуль Gimp Perl. Помимо этого, вы должны иметь доступ с правом записи (так же, как и чтения) в файл конфигурации коллекции.

Шаг 5 сначала проверяет наличие определяющей коллекцию процедуры формирования. Некоторые коллекции требуют специальной разовой процедуры формирования, при которой указанный в коллекции составитель должен быть описан, и эта запись (имя файла должно включать название коллекции и приставку "builder") помещена в директорию коллекции perllib. Mgbuilder, в свою очередь, предоставляет информацию о заявленных составителях коллекции. На 5 шаге составитель (либо используя параметры по умолчанию, либо настройки коллекции) устанавливает исходные значения, такие как количество документов, включаемых в коллекцию, должна ли быть сохранена предыдущаяя версия коллекции и где расположены директории building и archive.

На 6 шаге формирования текст документов сжат и проиндексирован, иконки и заголовки помещены в информационную базу данных коллекции, данные структурированы при поддержке классификаторов, впоследствии вызываемых приложениями коллекции. Всеми этими шагами управляет mgbuilder (или уполномоченный коллекцией компановщик), который, в свою очередь, использует для сжатия и индексации программное обеспечение MG ("Man¬aging Gigabytes," см. Witten et al., 1999).

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

Для создания доступа к сформированной коллекции через сеть Интернет вы должны переместить содержимое директории building в директорию index. Коллекция не может быть сформирована непосредственно в директории in¬dex, формирование больших коллекций может длиться несколько часов, а то и дней. Важной особенностью процесса формирования является то, что он не вносит изменений в существующую копию до тех пор, пока коллекция не будет окончательно сформирована.

1.4 Архив документов Greenstone

Все исходные документы, вносимые в систему Greenstone конвертируются в формат, известный как Greenstone Archive Format (Формат Архива Greenstone). Это формат XML, который размечает документы по разделам и поддерживает режим работы метаданных на уровне документа или раздела. Вам не придется создавать файлы архива Greenstone вручную, т.к. этой работой занимается специальное приложение обработки документов, описанное в следующей главе. Однако, т.к. это может помочь в понимании формата файлов системы Greenstone, мы решили поместить это описание ниже.

В XML тэги разметки заключены в знаки о. Формат архива Greenstone преобразует документы, находящиеся в формате HTML и др. вставляя символы <, >, или " в исходный текст и избегая использования стандартных условий &lt;, &gt; и &quot;.

На рисунке 7a вашему вниманю предложен Document Type Definition/ Определение типа документа (DTD) языка XML для формата архива Green¬stone. Изначально документ разбивается на Sections (секции или разделы), которые могут быть вложенными. Каждая Section имеет Description (описание) которое содержит 0 или более элементов Metadata, а также Con¬tent (содержательную часть), которая может быть равна нулю, а фактически это та часть, где находится содержимое документа. Каждому элементу Metadata соответствует имя атрибута и текстовые данные. В XML, PCDATA использует "parsed character сЫ:а"(анализируемые символьные данные): в основном текст.

Рисунок 7b демонстрирует пример документа в этом формате, представляющий собой небольшую книгу с двумя связными изображениями. Эта книга состоит из двух разделов, названных Preface и First and only chapter, которая состоит из двух подразделов. Обратите внимание на то, что нет никакого понятия "chapter": данный раздел представлен просто как раздел верхнего уровня.

Открывающий тэг <Section> обозначает начало каждого раздела документа, аа закрывающий тэг </Section> - конец раздела. За каждым тэгом <Section> следует раздел <Description>. В пределах данного раздела находятся элементы <Metadata>. Таким образом, различные метаданные могут быть связаны с индивидуальными разделами документа. Большинство из них используются в качестве специфических метаданных, таких как <ТШе>. Два значения атрибута name представлены в Таблице 6 и специально разработаны Greenstone; все остальные представляют собой метаданные, прилагаемые к данному разделу.

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

Метаданные документа

Метаданные содержат информацию описательного характера, такую как данные об авторе, заглавие, дату, ключевые слова и т.д., касающуюся конкретного документа. И, как было уже сказано выше, метаданные хранятся вместе с документом. Посмотрев на рисунок 7a, вы можете увидеть, что тэг <Мегай?ага> определяет название типа метаданных и присваивает им значение. Обратимся для примера к строке <Metadataname='"Etle ">First and only chap-ter</Metadata> на рисунке 7b - заголовок документа является частью связанных с ним метаданных. Для определения типов метаданных был использован Dublin Core metadata standard (Dublin Core, 2001, Weibel, 1999; Thiele, 1997).

Таблица 7 демонстрирует, какие из стандартных типов, отмеченные звездочками, доступны сегодня к использованию на веб-сайте New Zealand Digital Library. Если нет возможности подобрать тип, точно описывающий метаданные, то можно использовать другой тип, не описанный в Dublin Core metadata standard. Например, в демонстрационной коллекции содержится метаданные how to и Magazine.

Inside Greenstone archive documents

Within a single document, the Greenstone archive format imposes a limited amount of structure. Documents are divided into paragraphs. They can be split hierarchically into sections and subsections; these may be nested to any depth. Each document has an associated Object Identifier or OID—these are extended to identify sections and subsections by appending section and subsection numbers, separated by periods, to the document's OID. For example, subsection 3 of section 2 of document HASHa7 is referred to as HASHa7.2.3.

When you read a book in a Greenstone collection, the section hierarchy is manifested in the table of contents of the book. For example, books in the Demo collection have a hierarchical table of contents showing chapters, sections, and subsections, as illustrated in Figure 8a. Documents in the Computer Science Technical Reports collection do not have a hierarchical subsection structure, but each document is split into pages and you can browse around the pages of a retrieved document. Chapters, sections, subsections, and pages are all implemented simply as “sections” within the document.

Структура документа также индексируется и используется для поиска. Здесь существует 3 допустимых уровня индексации: document, section ^paragraph, хотя большинство коллекций и не используют все три уровня для индексации. Индекс document содержит полный текст документа - вы пользуетесь им для поиска всех документов, которые содержат определенный набор слов (слова могут быть рассеяны по всему тексту документа). При создании индекса sec¬tion индексируется каждая порция текста от одного тэга <Section> до появления следующего тэга <Section>. Таким образом, глава, сразу же начинающаяся с нового раздела, создаст пустой документ при индексировании. Разделы и подразделы обрабатываются подобным образом: иерархическая структура документа сглаживается с целью создания поисковых индексов. При индексировании на уровне параграфов каждый параграф рассматривается как самостоятельный документ, что обеспечивает в дальнейшем возможность проведения более сфокусированного поиска.

Выпадающее меню на рисунке 8b наглядно демонстрирует поисковые индексы для Демонстрационной коллекции. "Chapters" и "section titles" -представляют собой индексирование на уровне разделов, тогда как "entire books" - индексирование на уровне документа. Индексирование любого вида метаданных может быть осуществлено так же, как индексирование текста. Например, некоторые коллекции предлагают для поиска использовать индексы заголовков раздела, что и показано на рисунке 8b.

1.5 Файл конфигурации коллекции

Файл конфигурации коллекции управляет структурой коллекции и позволяет настроить ее внешний вид, параметры обработки документов и их публикации. Простои файл конфигурации коллекции создается, когда вы запускаете mkcol.pl, который создает запись для адресов E-mail лиц, ответственных за создание и поддержку коллекции. Следует помнить, что создание аргумента creator является принудительным, но если вы отдельно не оговариваете, то информация из этого аргумента автоматически будет перенесена в поле аргумента maintainer.

Каждая строка файла конфигурации коллекции по существу является парой "атрибут, значение". Каждый атрибут несет часть информации о коллекции, которая указывает на то, как документы должны выглядеть или как они должны быть обработаны. В таблице 8 представлены элементы, которые должны быть включены в файл конфигурации коллекции, и для чего они используются. Таким же образом могут быть определены в файле конфигурации коллекции все опции командной строки для import.pl и buildcol.pl - например, при прочтении no_text true для опции buildcol.pl будет установлен атрибут no_text.

Создание файла конфигурации коллекции с помощью скрипта mkcol.pl, показанного в Таблице 9, является очень простым и содержит необходимый минимум информации. Строки 1 и 2 являются значениями атрибута creator, созданными в результате работы программы mkcol.pl, и содержат адреса электронной почты лиц, ответственных за создание и наполнение коллекции (не обязательно один и тот же человек).

Строка 3 указывает на тот факт, будет ли данная коллекция после ее формирования доступна широкому кругу пользователей, и принимает 2 значения: true (по умолчанию, означает, что коллекция будет доступна для публичного пользования) или false (означает, что не будет). Последнее обычно используется во время создания тестовых коллекций или для формирования коллекций документов для собственного использования.

Линия 5 определяет, какие индексы создаются во время построения коллекции: в этом примере проиндексирован только текст документа. Индексы могут быть сконструированы для уровней документа, части, и параграфа. Они могут содержать материал в форме текста или в любом metadata\u2014 наиболее общем Названии. Форма используется для определения индекса level:data. Например, для того чтобы включить так же и заголовок части, вы должны поменять линию 5 на indexes document:текст section:Название. Более, чем один тип данных, могут быть включены в тот же индекс путём разделения данных запятыми. Например, для создания заголовков, текстов и дат на уровне части, линия должна читаться, как indexes section:текст, Название, Дата.. Индекс по умолчанию определён на линии 6, и используется по умолчанию на странице поиска.

Линии 7-13 определяют, какие приставки использовать, когда документы конвертируются в архивный формат Гринстоуна и, когда создаются коллекции из архивных файлов. Часть 2.1 даёт информацию о том, какие приставки доступны. Последовательность приставок в списке – это последовательность, в которой они пытаются обработать докумет. И как только приставка способна обработать найденный документ, все дальнейшие попытки прекращаются.

Линия 14 определяет алфавитный список названий, создающийся с целью просмотра. Эти структуры конструируются при помощи "classifiers". Часть 2.2 даёт информацию о классификаторах и о том, что они могут делать.

Линии 15-18 использованы для определения метаданных на уровне коллекции. Определённая через collectionname, длинная форма названия использована как “название” коллекции для веб браузера. collectionicon даёт URL для иконки коллекции. Если индекс определён (как в линии 18), последующий текст отображается как имя этого индекса на странице поиска. Особенно важная часть метаданных - collectionextra, которая даёт развёрнутый текст, окружённый знаками цитат, описывающий коллекцию. Он будет показан как текст “О коллекции”. Вы можете использовать разные версии collectionextra для разных языков путём добавления спецификации языка в квадратные скобки. Например,

Если установлен язык интерфейса "fr" или "mi", то будет отображена соответствующая версия описания. Для других языков появится версия, заданная по умолчанию.

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

Подколлекции

Greenstone позволяет определять подколлекции и для каждой из них формировать отдельные индексы. Например, в одной коллекции имеется большое подмножество документов, именуемых Food and Nutrition Bulletin. Мы используем эту коллекцию в качестве примера.

В этой коллекции имеются 3 индекса и все на уровне раздела: один - для коллекции, второй - для Food and Nutrition Bulletin и третий - для остальных документов. Ниже приведены соответствующие строки описания в файле конфигурации коллекции.

Вторая и третья строки определяют следующие подколлекции: с именем fn, которая содержит документы Food and Nutrition Bulletin, и с именем other, в которой находятся остальные документы. Третье поле содержит выражение на языке Perl, которое идентифицирует эти подмножества, используя метаданные типа Title: в первом случае ищем заголовки, которые начинаются с Food and Nutrition Bulletin , а во втором - в которых данное описание отсутствует (обратите внимание на знак "!"). Знак i в конце строки означает, что при работе этих приложений регистр символов не учитывается. Поле метаданных, в нашем случае Title, может быть любым допустимым полем, или Filename, соответствущим первоначальному имени файла документа. В четвертой строке, indexsubcollections, определяются три индекса: один - для подколлекции fn, второй - для подколлекции other и третий - для обеих подколлекции (т.е. для всех документов). Обратите внимание на то, что если бы два вхождения были определены в строке indexes, то общее количество сгенерированных индексов было бы шесть, а не три.

Если коллекция содержит документы на разных языках, то индексы должны быть определены отдельно для каждого языка. Язык является инструкцией метаданных; Language is a metadata statement; значения определяются в соответствии со стандартом ISO 639 двухбуквенным кодом, обозначающим язык - например, еп - это English (аглийский), zh - Chinese (китайский), и mi - это Maori (маори). Так как значения метаданных могут быть определены на уровне раздела, отдельные части документа могут быть представлены на разных языках.

Например, если файл конфигурации содержит: текст раздела, заголовок раздела, текст документа и индексы текста параграфа, то для английского, китайского и языка маори были

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

(Эта индексная спецификация могла бы быть определена с использованием средств subcollection, а не средство languages. Однако, в связи с тем, что синтаксис препятствует созданию "подколлекций подколлекций", становится невозможным отдельно индексировать каждый язык в подколлекциях).

Перекрестный поиск по коллекции

Greenstone имеет средство для "перекрестного поиска по коллекции", котороей позволяет производить поиск по нескольким коллекциям сразу с предоставлением объединенных результатов, так, как если бы вы искали по одной объединенной коллекции. Может быть просмотрено любое подмножество коллекций: Preferences page (страница определения предпочтений) позволяет Вам выбирать, какие коллекции должны быть включены в поиск.

Возможность перекрестного поиска оговаривается строкой:

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

2 Получение большего от ваших документов

Коллекции могут быть индивидуализированы таким образом, чтобы разграничить содержащуюся в них информацию различными способами доступа. Настоящая глава описывает, как Greenstone извлекает информацию из документов и представляет ее пользователю: Раздел 2.1 - Обработка документов, Раздел 2.2 - Классификаторы, Разделы 2.3 и 2.4 -инструментальные средства интерфейса пользователя.

2.1 Приложения

Приложения анализируют импортированные документы и извлекают из них метаданные. Например, HTML-приложение конвертирует HTML-страницы в формат архива Greenstone и извлекает метаданные, которые являются явным в формате документа - такие, как заголовки, заключенные тегами <title></title>.

Приложения написаны на языке Perl. Все они происходят от основного приложения BasPlug, которое выполняет книверсальные операции, такие как создание нового документального архива Greenstone для последующей работы с ним, назначение идентификатора объекта (OID), обработка разделов документа. Приложения хранятся в директории perllib/plugins.

Чтобы узнать больше о любом из приложений, напечатайте pluginfo.pl plugin-name в области командной строки. (Сначала, вы должны вызвать соответствующий скрипту setup, если вы этого не делали ранее. Если ваша операционная система не настроена на то, чтобы воспринимать файлы с расширением .рl как выполнимые программы на языке Perl, то в Windows вы должны напечатать perl —S pluginfo.pl plugin-name). В результате на экране появится информация об интересующем вас приложении - какие данному приложению требуются специфичные опции и какие общие.

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

Общие опции

В Таблице 10 приведены опции, принимаемые любым приложеним, полученным от BasPlug.

Приложения Greenstone

Приложения для обработки документов используются программным обеспечением, формирующим коллекцию, для анализа исходного документа в соответствии с его форматом. Файл конфигурации коллекции перечисляет все приложения, используемые при формировании самой коллекции. В процессе импорта каждый файл или директория анализируются каждым приложением до тех пор, пока требуемые не будут обработаны - более ранние приложения имеют приоритет перед более поздними. Если нет приложений, которые смогли бы обработать некий файл, будет выдано предупреждение (стандартное сообщение об ошибке) и процесс обработки перейдет к следующему файлу. (Это тот случай, где может быть использована опция block_exp - предотвращение появления сообщений об ошибке для тех файлов, присутствие которых необходимо в коллекции без их обработки). В процессе формирования используется та же самая процедура, только вместо директории archives используется директория import.

Список стандартных приложений Greenstone представлен в Таблице 11. Для прохождения по дереву директорий необходима рекурсия. Хотя программы импорта и формирования не выполняют явную рекурсию, некоторые приложения пользуются косвенной рекурсией при прохождении имен файлов или директорий через конвейер приложений. Например, стандартное прохождение рекурсии по дереву директорий обеспечивается приложением RecPlug, предназначенными именно для этого, если, конечно, оно будет последним элементом в конвейере. Косвенную же рекурсию вызывают только два первых приложения из Таблицы 11.

Некоторые приложения были написаны для определенных коллекций, имеющих особый формат документов, подобно E-text (электронному тексту), используемому в коллекции Gutenberg. Эти специфичные для коллекций приложения находятся в каталоге коллекции perllib/plugins. Данные приложения могут быть использованы для того, чтобы отменить общие приложения с таким же именем.

Некоторые приложения обработки документов используют внешние программы, которые анализируют определенные частные форматы, например, для обработки текста - Microsoft Word или HTML. Общее приложение ConvertToPlug вызывает соответствующую программу конвертации и передает результат обработки либо TEXTPlug, либо HTMLPlug. Далее мы остановимся на этом более подробно.

Некоторые приложения имеют индивидуальные опции, которые управляют процессами более детально, чем это позволяют общие опции. Они представлены в Таблице 12.

Приложения для импорта частных форматов

Использование нестандартных форматов является трудноразрешимой проблемой для всех цифровых библиотечных систем. И хотя рабочая документация по этим форматам может быть вполне доступной, однако сам предмет внесения изменений остается в ней без отражения, что оставляет трудности при внесении изменений. Система Greenstone пошла по пути использования GPL (GNU Public License) специальных утилит для конвертации, которые были разработаны людьми, специализирующимися именно на таких работах. Утилиты конвертации документов форматов Word и PDF включены в директорию packages. Они конвертируют документы в текст или HTML. Затем HTMLPlug и TEXTPlug преобразуют их в формат архива Greenstone. ConvertToPlug используется для включения этих утилит. И так же как BasPlug, никогда не вызывается непосредственно. На рисунке 9 представлены приложения, написанные для определенных форматов. ConvertToPlug, используя схему динамического распределения Perl запускает TEXTPlug или HTMLPlug в зависимости от формата, в который были конвертированы исходные документы.

Когда ConvertToPlug получает документ, он вызывает gsConvert.pl (находится в директории GSDLHOME/bin/script) для запуска соответствующей утилиты. Как только документ будет проконвертирован, он возвращается к ConvertToPlug, который вызывает приложение обработки текста или HTML. Любое приложение, вызванное ConvertToPlug, имеет опцию convertjto, которая содержит аргумент textvum html, для определения предочтительного формата. Работа с текстом происходит значительно быстрее, однако документ, представленный в формате HTML, выглядит намного интереснее и может содержать иллюстрации.

Иногда для специфического формата существует несколько утилит, и gsConvert может пытаться использовать их. Например, для конвертации Word предпочтительно использовать утилиту wvWare, однако она обрабатывает документы, созданные в редакторе Word не ниже 6 версии, а вот утилиту AnyToHTML, которая no-существу извлекает только текстовые строки, which essentially just extracts whatever text strings can be found, вполне можно использовать для конвертации документов из Word 5.

Шаги загрузки новой конвертационной утилиты для добавления внешних документов:

1. Установить новую утилиту в соответствии с требованиями Greenstone (поместить ее в директорию packages).
2. Внести изменения в gsConvert.pl для последующего использования утилиты. Они заключаются в добавлении нового предложения с оператором if в функцию main, и добавлении функции, вызывающей новую утилиту.
3. W3. Записать приложение на уровень, следущий за ConvertToPlug, для того чтобы перехватить конвертацию в стандартный формат, подменив его на нужный.

Назначение метаданных из существующего файла

Стандартное приложение RecPlug помимо всего, имеет возможность назначать метаданные документу вручную (или автоматически), создавая XML-файлы. Остановимся подробнее на этом для того, чтобы вы сами смогли создавать файлы метаданных для описания ваших форматов. Если определена опция usejnetadatajiles, то RecPlug использует вспомогательный файл метаданных - metadata.xml. На рисунке 10a представлен XML Document Type Definition (DTD) для формата файла метаданных, а на рисунке 10b приведен пример файла метаданных metadata.xml.

В примере показан файл, который содержит две структуры метаданных. В каждой из которых, элемент filename описывает файл, к которому относятся метаданные, в виде стандартного выражения. Таким образом, nugget. * указывает на то, что первая запись метаданных относится ко всем файлам, чье имя начинается с "nugget"[2]. Для этих файлов метаданные типа Title установлены как "Nugget Point Lighthouse".

Элементы метаданных отрабатываются в том порядке, в котором они появляются. Вторая запись устанавливает метаданные типа Title для файла nuggetpoint- l.jpg как "Nugget Point Lighthouse, The Catlins", тем самым отменяя предыдущие указания. Здесь также добавлено поле метаданных Subject.

Иногда метаданные, имеющие уже некоторое множество значений и получая новые, должны их накапливать, вместо того, чтобы отменять предыдущие. Это делается введением атрибута mode=accumulate. В результате опция метаданных Place перемещается на позицию выше и становится способной накапливать значения. Для возврата к единственности значений для элемента метаданных напишите: <Metadata name=“Place” mode=“override”>New Zealand</Metadata>. Фактически, вы можете опустить эту спецификацию режима, поскольку каждый последующий элемент отменяет предыдущий, если это заранее не определено. Для накопления в некотором поле значений метаданных при каждом появлении которых должно быть определно: mode=accumulate.

Когда установлена опция usejnetadatajiles, RecPlug проверяет каждую вводимую директорию для XML файла metadata.xml и применяет его содержимое ко всем файлам директории и поддиректорий.

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

Маркировка файла документа тэгами

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

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

(text of section goes here)

Маркеры <!-- … --> используются в HTML для вставки комментариев; таким образом, эти тэги не будут влиять на общее форматирование документа. В части Description могут быть определены другие виды метаданных, но в нашем случае это сделано не было. Помимо этого, тэги могут быть -вложенными. Так строка помеченная text of section goes here (текст раздела), в дальнейшем может включать в себя подразделы, например,

(text of first part of section goes here)

(text of subsection goes here)

(text of last part of section goes here)

Этими функциональными возможностями обладает любое приложение, использующее HTMLPlug. В частности, Word-приложения конвертируют исходый файл в HTML, так что в случае использования документов формата Word (и RTF), извлечение метаданных происходит по сценарию извлечения их из формата HTML. (В этом случае придется немного поработать, т.к. для нормальной конвертации документов Word в формат HTML требуется удалить побочные символы "<" и ">"; мы произвели их упорядочение, не принимая во внимание приведенные выше спецификации). Обратите внимание на то, что точно такой же формат, как описано выше, используется и в случае Word - файлов, содержащих "<!—" и"~>". Шрифт и интервал игнорируются.

2.2 Классификаторы

Классификаторы используются для создания индексов просмотра коллекции. Примерами являются индексы Titles A-Z коллекции dlpeople, а также индексы Subject, How to, Organisation и Titles A-Z в коллекции Humanity Development Library - одной из подмножества Демонстрационных коллекций. Навигационное меню в верхней части экрана на рисунках 3 и 8а имеет функцию search, которая всегда снабжена кнопками для всех классификаторов, которые были определены. Информация, используемая для поддержки просмотра, сохраняется в информационной базе данных коллекции, куда она помещается классификаторами, вызываемыми на конечной стадии работы buildcol.pl.

Классификаторы, подобно приложениям, определяются в файле конфигурации коллекции. Для каждого существует строка, начинающаяся с ключевого слова classify и сопровождаемая именем классификатора и требуемых опций. Основной файл конфигурации коллекции, обсужденный в Разделе 1.5, включает строку classify AZList —metadata Title, которая создает алфавитный список заголовков, извлекая их из поля метаданных Title, затем сортирует их и разбивает по алфавитным диапазонам. Пример показан на рисунке 11.

Простейший классификатор, названный List, представлен на рисунке 12. Он создает отсортированный список определенного элемента метаданных и отображает его без каких-либо алфавитных подразделов. Примером могут послужить метаданные how to Демонстрационной коллекции, которые созданы строкой classify List —metadata Howto в файле конфигурации коллекции[3]. Другой универсальной классификатор списка DateList, который генерирует список дат, представлен на рисунке 13. (Классификатор DateList используется в коллекции Greenstone Archives).

Другие классификаторы генерируют структуры просмотра, которые являются иерархическими. Иерархические классификации используются в случае предметных классификаций и подклассификаций, а также организационных иерархий. Файл конфигурации Демонстрационной коллекции содержит строку classify Hierarchy —hflle sub.txt —metadata Subject —sort Title, и на рисунке 14 вы можете видеть предметную иерархию, представленную в броузере. Иконка "книжная полка" с выделенным жирным шрифтом заголовком представляет первый уровень; выше вы можете видеть предметную классификацию, к которой принадлежит упомянутый заголовок. В этом примере классификационная иерархия находится в простом текстовом формате в файле sub.txt.

Все классификаторы генерируют иерархическую структуру, которая используется для отображения индекса просмотра. На самом нижнем уровне иерархии (т.е. листе) обычно расположены документы, но в некоторых классификаторах - это разделы. Внутренние узлы иерархии - это Vlist, Hlist, или Datelist. Vlist - это список элементов, показаных вертикально, внизу страницы, подобно индексу "how to" в Демонстрационной коллекции (см.рисунок 12). Hlist располагается горизонтально. Например, AZList, показанный на рисунке 11,- это иерархия с двумя уровнями внутренних узлов, состоящих из Hlist (представлен разделом A-Z ) с дочерними записями Vlists. Эти дочерние записи являются документами. Datelist (см. рисунок 13) является особым видом Vlist, и позволяет производить выборку по году и месяцу.

Строки используют для определения классификаторов в файлах конфигурации коллекции, содержащих аргумент metadata, идентифицирующий метаданные, по которым документы классифицированы и отсортированы. Любой документ в коллекции, которая не определена метаданными, будет избавлен от классификатора (но он все же индексируется, и следовательно, доступен для поиска). Если никакой параметр метаданных не определен, все документы включаются в классификатор в том порядке, в котором они поступают в ходе процесса формирования. Это можно использовать в том случае, если вы хотите получить список всех документов в вашей коллекции.

Текущий набор классификаторов представлен в Таблице 13. Как было рассмотрено ранее, для того, чтобы получить информацию о любом приложении, вы можете использовать программу pluginfo.pl. Также в случае с классификаторами существует программа classinfo.pl, которая дает вам информацию о любом классификаторе и доступных ему опциях.

Все классификаторы принимают аргумент buttonname, определяющий надпись на навигационной кнопке Greenstone, которая вызывает классификатор (по умолчанию используется значение аргумента метаданных). Кнопки существуют для каждого типа метаданных Dublin Core и для некоторых других типов метаданных.

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

Определенные коллекцией классификаторы могут быть написаны сохранены в директории коллекции perllib/classify. Development Library имее определенный коллекцией классификатор по имени HDLList, которы является уменьшенным вариантом AZList.

Список классификаторов

Ниже приведен список классификаторов:

• SectionList—похож на List, но в качестве разделов выступают листы, а к документы. Включает все разделы документа, кроме верхнего уровне Используется для создания списка разделов (статей, глав и т.д.), какколлекции Computists' Weekly (доступна на сайте nzdl.org), где каждый выпуск - это отдельный документ, который содержит несколько независимы статей, находящихся в собственных разделах.
• AZList—генерирует иерархию с двумя уровнями, включающую HLis дочерние записи которого.
• AZSectionList—похож на AZList, но в качестве разделов выступают листы а не документы.
• DateList—похож на AZList, за исключением того, что верхний уровень HLL позволяет делать выборку по году, а его дочерние записи - DateLists, а к VLists. Значения по умолчанию аргумента метаданных - Date.

Классификатор иерархии

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

Аргумент hflle дает имя файла, как показано на рисунке 15, которое определяет иерархию метаданных. Каждая строка описывает одну классификацию, а описания состоят из трех частей:

• Идентификатор, который соответствует значению метаданных (заданного аргументом metadata) по классификации.
• Маркер позиции-в-иерархии, в многпериодной числовой форме, например 2,2.12,2.12.6.
• Название классификации (если оно содержит пробелы, то должно быть заключено в кавычки).

На рисунке 15 представлена часть файла sub.txt, создающего подчиненную иерархию в коллекции Development Library (и в Демонстрационной коллекции). Этот пример - немного запутанный, т.к. номер, указывающий на иерархию, используется дважды на каждой строке. Тип метаданных Hierarchy представлен в документах со значениями в иерархической числовой форме, которая объясняет первое использование. Второе использование номера требуется для определения иерархии, которая осуществляется броузером иерархии.

Классификатор hierarchy имеет опциональный аргумент sort, который определяет, как упорядочиваются документы в листах. Любые метаданные могут быть определены как ключ сортировки. Значение по умолчанию должно создать список в том порядке, в котором документы проходили процесс формирования. Упорядочение во внутренних узлах определено в соответствии с порядком, в котором элементы определены в аргументе hfile.

Как работают классификаторы

Классификаторы являются объектами языка Perl, полученными от BasClas.pm и хранимыми в директории perllib/classijy. Они используются тогда, когда коллекция уже сформирована. При запуске классификаторов выполняются следующие шаги.

1. Метод new создает объект классификатора.
2. Метод init инициализирует объект по таким параметрам, как тип метаданных, название кнопки и критерии сортировки.
3. Метод classify используется один раз для каждого документа и хранит информацию о классификации, произведенной классификатором в пределах объекта.
4. Метод get_classijy_info возвращает локально сохраненную информацию о классификации процессу компоновки, который записывает ее в информационную базу данных коллекции для использования, во время работы с коллекцией.

Метод classify отыскивает OID каждого документа, значение метаданных для классификации документа, и в случае необходимости, значение метаданных для сортировки документов. Метод get_classify_info производит всю сортировку и определенную классификатором обработку. Например, в случае использования классификатора AZList, он разбивает список на алфавитные диапазоны.

Процесс формирования инициализирует классификаторы, как только объект builder будет создан. Классификации создаются в процессе формирования, когда classify.pm, постоянно находящийся в директории perllib Greenstone, создаст информационную базу данных.

2.3 Выходной формат Greenstone

Web-страницы, которые вы видите при использовании Greenstone, не создавались заранее, а были сгенерированы "на лету", по мере необходимости. Настройка внешнего вида многих аспектов страниц производится с использованием "формата строк". Строки формата содержатся в файле конфигурации коллекции и вводятся, используя формат ключевых слов, сопровождаемый названием элемента, к которому формат обращается. Есть два различных вида элементов, которые управляются строками формата. Первый включает инструменты на странице, которые показывают документ или части документов. Второй включает списки, произведенные классификаторами или поисковые списки. Все строки формата интерпретируются во время отображения страницы. В связи с тем, что внесенные вами изменения вступают в силу с момента сохранения их в collect.cfg, эксперимент со строками формата становится быстрым и простым.

В Таблице 14 представлены операторы, задающие формат, которые затрагивают путь просмотра документов. Опция DocumentButtons управляет тем, какие кнопки отображены на странице документа. Здесь string - список кнопок (отделенных друг от друга |), это могут быть Detach, Highlight, Expand Text и Expand Contents (Отделить, Подсветить, Развернуть Текст и Развернуть Содержание).Переупорядочение списка переупорядочивает и кнопки.

Форматирование списков Greenstone

Строки формата, которые управляют просмотром списков, могут применяться на различных уровнях отображения структуры. Они могут изменить все списки некоторого типа в пределах коллекции (например DateList) или всех частей списка (например, все вхождения в списке Search), или определенных частях некоторого списка (например, вертикальная часть списка заголовков классификатора AZList).

Следующий - это format ключевого слова, состоящего из двух частей, одна из которых принудительна. Первая часть идентифицирует список, к которому формат обращается. Список, сгенерированный поиском, называют Search, в то время как списки, сгенерированные классификаторами, называют CL1, CL2, CL3, ... для первого, второго, третьего, ... классификатор указывает это в collect.cfg. Вторая часть ключевого слова - часть списка, к которому должно применяться форматирование - любой HList (для горизонтального списка подобно A-Z селектору в AZList), VList (для вертикального списка,

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

Перевызов всех этих классификаторов создает иерархии. Каждый уровень иерархии отображен одним из четырех возможных способов. Мы уже рассматривали HLIST, VList и DateList. К ним относится также Invisible, который является отображением ксамых верхнх уровней иерархий, т.к. имя классификатора всегда показывают отдельно от навигационного меню Green¬stone .

Примеры классификаторов и строк формата

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

Строка 4 определяет классификатор How To Демонстрационной коллекции. Он является четвертым в файле конфигурации коллекции и поэтому упоминается как CL4. Аналогичноя формулировка формата - строка 7 на рисунке 16. Информация "how to" генерируется классификатором List, а его структура - это простой список заголовков (см. рисунок 12). Заголовки связаны с документами непосредственно: щелчок мышью на заголовке вызывает соответствующий документ. Дочерние записи верхнего уровня иерархии отображены как VList (вертикальный список), который перечисляет разделы вертикально. Поскольку связанный оператор format указывает на то, что каждый элемент списка начинается с новой строки ("<br>") и содержит текст Howto, гиперсвязь с документом происходит непосредственно.

Строка 1 определяет классификацию Subject Демонстрационной коллекции, упомянутую как CL1 (первый в файле конфигурации), строка 3 классификацию Organisation - CL3. Обе строки сгенерированы классификатором Hierarchy и поэтому включают иерархическую структуру VLists.

Строка 2 определяет оставшуюся классификацию для Демонстрационной коллекции, Titles A-Z (CL2). Обратите внимание на отсутствие соответствующих строк формата для классификаторов CL1. CL3. Greenstone имеет встроенные значения по умолчанию для каждого типа строки формата и поэтому нет необходимости устанавливать строку формата, если Вы не собираетесь отменять значение по умолчанию.

Это учетная запись для строки classify (см. рисунок 16). По совпадению, есть также четыре строки format. Одну мы уже обсудили - это CL4VHst. Оставшиеся три - первый тип строки формата, представленный в Таблице 14. Например, строка 8 помещает изображение обложки, в верхнем левом углу каждой страницы документа. Строка 9 форматирует фактический текст документа с указанием заголовка соответствующей главы или раздела, стоящих непосредственно перед текстом. Все это показано на рисунке 17.

Строка 5 на рисунке 16 - скорее сложная спецификация, которая форматирует список результата запроса, возвращенный поиском, части которого представлены на рисунке 18. Упрощенная версия строки формата

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

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

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

К сожалению, если конечный документ - самостоятельная книга, которая не имеет родительского документа, то появится пустая строка, сопровождаемая двоеточием. Чтобы избежать этого, воспользуйтесь условными операторами ifног ... else в строке формата:

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

Возвращаясь к строке 5 Рисунка 16, представляем полный формат строки

Это предшествует спецификации parent с условным выражением, которое проверяет, пуст ли результат, и в противном случае выдает родительскую запись. Кстати, parent может быть определен Тор вместо АИ, который выдает имя документа верхнего уровня, включающее раздел - в нашем случае название книги. Отделение строкой для Тор не требуется.

Некоторые последние примеры иллюстрируют другие особенности. DateList на рисунке 13 используется для классификации Dates в коллекции Computists' Weekly (который является вторым классификатором - CL2). Классификатор и спецификации формата показаны ниже. Классификатор DateList отличается от AZList тем, что всегда сортирует метаданные Dates, а ветви основания иерархии используют DateList вместо VList, который добавляет год и месяц слева от документа.

Формат спецификации показывает VLists соответствующим способом.

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

Соединения с различными версиями документов

Использование механизма [link] ... [/link] в строковом формате создает гиперсвязь с текстом документа. Когда ссылка активируется, на экране отображается HTML- версия документа. В некоторых коллекциях используются возможности отображения других версий документов. Например, в коллекции документов Microsoft Word было бы неплохо отобразить оригинальную версию в формате Word для каждого документа, а не конвертированный в HTML вариант; то же самое касается документов формата PDF.

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

в строку формата, создающего ссылку к HTML-документу. В качестве помещенного текста использован заголовок документа. Приложения Word и PDF генерируют метаданные srclink, так что если Вы поместили

в формат строки, то будет создана ссылка к документу формата Word или PDF; в этом примере в качестве помещенного текста снова использован заголовок документа. Соответствующие иконки для документов Word и PDF также генерируются приложением метаданных srcicon

Оно создает ссылку, которая будет отменена стандартной иконкой Word или PDF (соответственно типу документа), вместо заголовка документа.

2.4 Управление пользовательским интерфейсом Greenstone

Интерфейс пользователя Greenstone управляется макросами, которые постоянно находятся в каталоге GSDLHOME/macros. Они написаны на языке, разработанном специально для Greenstone, и используются во время работы системы для генерирования web-страниц. Трансляция макроязыка в HTML -последний шаг в отображении страницы. Таким образом, изменения в макрофайле немедленно отображаются на экране, предоставляя пользователю быстрый и очень простой инструмент. Все макрофайлы, используемые Greenstone, перечислены в GSDLHOME/etc/main.cfg и загружаются каждый раз, когда их вызывают. Единственное исключение касается использования Windows Local Library - в этом случае необходимо будет перезапустить процесс.

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

Формат макрофайла

Макрофайлы имеют расширение .dm. Каждый файл определяет один или более packages, каждый из которых содержит ряд макросов, используемых с единственной целью. Также, как и в случае с классификаторами и приложениями, существует файл base.dm, предназначенный для формирования макросов; этот файл определяет основное содержание страницы.

Макросы имеют имена, которые начинаются и заканчиваются символом подчеркивания, а их содержание заключается в фигурные скобки. Содержание может быть текстом, HTML (включая ссылки к Java-апплетам и JavaScript), именем макроса или любой комбинацией из вышеперечисленных элементов. Макрокоманда от base.dm определяет содержание страницы, если отсутствует какая-либо макрокоманда отмены:

Страница будет читать "Oops" наверху, и Jextdefaultcontent _, который на английском языке будет выдавать The requested page could not be found. Please use your browsers 'back' button or the above home button to return to the Greenstone Digital Library (Запршенная страница не найдена. Пожауйста, воспользуйтесь кнопкой возврата в вашем броузере или кнопкой возврата на домашнюю страницу Цифровой библиотеки Greenstone), как и на других языках.

_textdefaultcontent_ и _content_ оба постоянно находятся в пакете global, потому что они запрашиваются всеми частями пользовательского интерфейса. Макросы могут использовать макросы из других пакетов, но тогда они должны содержать в префиксе их имена и имя пакета. Например,

исходит из english.dm и используется как заданное по умолчанию описание коллекции. _collectionextra_ - часть пакета global , но _numdocs_ и _builddate_ - оба из пакета about, следовательно следует писать _about:wMsi_.

Зачастую макрос содержит условные инструкции. Они напоминают условное выражение строки формата, описанное выше, хотя их вид немного отличается. Основной формат - _If_ (х, у, z), где х - условие, у -макросодержание, которое используется, если условие истинно, и z -макросодержание, если условие является ложным. Операторы сравнения те же самые, что используются в Perl (меньше чем, больше чем, равно, не равно). В этом примере base.dm используется для решения задачи изображения верней части страницы коллекции about (страница описания коллекции):

Данное описание выглядит немного непонятным. _iconcollection_ отсылает к пустой строке, если коллекция не имеет иконки или имени файла изображения. Перефразируем вышеупомянутую программу: Если есть изображение для коллекции, вывести в заголовке страницы About this Collection (упомянутый Jittppageabout _), а затем изображение; иначе использовать альтернативный вывод _imagecollectionv_.

Макросы могут содержать аргументы. Вот второе определение для _imagecollection_ макрокоманды, которая немедленно следует за определением, данным выше в файле base.dm:

Параметр [v=l] определяет, что второе определение используется, когда Greenstone работает в текстовом режиме. Макрос языка работает похоже -исключение составляет english.dm, потому что является значением по умолчанию, все макросы языка определяют язык как параметр. Например,

появляется в английском макрофайле языка, тогда как для немецкой версии

Английская и немецкая версии находятся в том же самом пакете, хотя и в отдельных файлах (определения пакета могут охватить больше, чем один файл). Greenstone использует /параметр во время запуска, чтобы определить язык отображения.

В заключение приведем рисунок 19, на котором представлен отрывок макрофайла aboutdm, который используется для генерации страницы "About this collection" (О коллекции) для каждой коллекции. Вы можете видеть работу трех макросов _pagetitle _, _content_ и _textabout_.

Using macros

Макрос является мощным инструментом и может быть немного непонятен. Однако, при хорошем знании HTML и небольшом практическом опыте, они становятся быстрым и простым способом настройки вашего Greenstone -сайта.

Например, если вы хотите создать статическую страницу, которая напоминала бы ваш текущий Greenstone-сайт. Вы можете создать новый пакет, названный static, например, в новом файле и отменить макрокоманду _content_ . Добавьте новое имя файла в список макросов в GSDLHOME/etc/main.cfg, который Greenstone загружает каждый раз. Наконец, обратитесь к новой странице, используя ваш правильный URL Greenstone, добавляя в конец параметр ?a=p&p=static (например, http://servername/cgi-bin/library?a=p&p=static).

Чтобы изменять интерфейс Greenstone, вы можете редактировать пакеты base и style. Чтобы изменить домашнюю страницу Greenstone, отредактируйте пакет home (описание можно найти в документации Цифровая библиотека Greenstone: Руководство по установке). Для изменения страницы запросов отредактируйте query.dm.

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

2.5 Директория packages

Директория packages , содержание которой показано в Таблице 16, - это директория, в которой хранятся все программы, используемые Greenstone, но написанные другими исследовательскими группами. Все программное обеспечение, распространяемое совместно с Greenstone, попадает под действие Лицензионного соглашения о свободном доступе GNU. Запускаемые файлы, произведенные этими пакетами, помещены в каталог Greenstone -bin. Каждый пакет хранится в собственном каталоге. Они обладают широким спектром функций, от индексации и сжатия до преобразования документов Microsoft Word в HTML. Каждый пакет имеет README файл, который содержит подробную информацию.

3 Работа системы Greenstone

Эта глава описывает работу системы Greenstone, чтобы вы могли понять, увеличить и расширить ее возможности. Программное обеспечение написано на С ++ и предоставляет большие возможности использования виртуального наследия. Если вы незнакомы с этим языком, вы должны изучить его перед тем, как приступить к работе. Дейтель и Дейтель (1994) предоставили всестороннюю обучающую программу, а Страуструп (1997) - лаконичный справочник.

Мы начинаем рассказ о философии дизайна после описания работы системы, так как он будет напрямую зависеть от этого описания. Теперь приступим к деталям, из которых состоит основная часть главы. Версия Greenstone, описанная здесь - это CGI-версия (Web Library if for Windows users/Web -библиотека для пользователей Windows). Windows Local Library использует ту же самую исходную программу, но имеет встроенный web-сервер. Плюс ко всему, Local Library - постоянно продолжающийся процесс.

3.1 Структура процесса

На рисунке 20 показано, как несколько пользователей (они представлены в виде компьютерных терминалов наверху диаграммы) обращаяются к трем коллекциям Greenstone. Перед тем, как предстать в режиме on-line, эти коллекции проходят процессы импорта и формирования, которые были описаны в предыдущих главах. Сначала документы, показанные внизу рисунка, импортированы в XML-совместимый Формат Архива Greenstone. Теперь для файлов созданы различные доступные для поиска индексы и информационная база данных коллекции, которая включает иерархические структуры поддержки просмотра. Конечная коллекция готова к работе в режиме on-line и способна предоставлять информацию по запросам.

Два центральных компонента обеспечивают работу системы: "receptionists" (регистраторы) и "collection servers" (серверы коллекции). С точки зрения пользователя, регистраторы - точка контакта с цифровой библиотекой. Они принимают запрос пользователя в форме клавиатурного ввода и щелчков мыши, анализируют их, а затем посылают запрос соответствующему серверу (или серверам) коллекции. Здесь определяется местонахождение требуемой части информации и возвращается регистратору для предоставления пользователю. Серверы коллекции действуют как абстрактный механизм, который обрабатывает содержание коллекции, в то время как регистраторы ответственны за интерфейс пользователя.

Как показано на рисунке 20, регистраторы связываются с серверами коллекции, используя определенный протокол. Выполнение этого протокола зависит от конфигурации компьютера, на котором работает система цифровых библиотек. Наиболее простой и подходящий выбор - это один регистратор и один сервер коллекции, которые оба установлены на одном компьютере. Вы получаете именно такую модификацию, когда устанавливаете систему Greenstone с параметрами по умолчанию. В этом случае оба процесса объединены в один запускаемый файл (называемый library), и следовательно, использование протокола сводится к созданияю функциональных запросов. Мы называем это null protocol (нулевым протоколом). Он формирует основу для стандарта out-of-the-box (из блока) цифровой системы библиотек Greenstone. Ее упрощенная конфигурация представлена на рисунке 21 с регистратором, протоколом и сервером совокупности, связанными вместе в один объект программы библиотеки. Цель этой главы состоит в том, чтобы объяснить вам, как все это работает.

Обычно "сервер" - постоянный процесс: единожды запущенный, работает постоянно, отвечая на любые входящие запросы. Несмотря на название, сервер коллекции в конфигурации нулевого протокола не является сервером в привычном смысле слова. Фактически, каждый раз, когда вызывают любую web-страницу Greenstone, запускается программа library (CGI механизмом), которая отвечает на запрос и затем выгружается. Это мы называем "сервером", потому что дополнительно он также предназначен для работы с более общей конфигурацией (см. рисунок 20).

Удивительно, но цикл запуска, обработки и выхода работает не так медленно, как можно было ожидать. Однако, это абсолютно неэффективно. Существует механизм Fast-CGI (www.fastcgi.com), который обеспечивает средний уровень. Используя его, программа library может остаться в памяти в конце первого выполнения и накапливать последующие наборы параметров CGI, таким образом избегая повторных инициализаций и достигая почти такого же уровня работы, как сервер. Fast-CGI в Greenstone используется как опция, допуская повторную компиляцию исходного текста с соответствующими библиотеками.

Как альтернатива нулевому протоколу, протокол Greenstone был также создан с использованием известной схемы CORBA (Slama et al, 1999). Он использует объединенную объектно-ориентированную парадигму, чтобы разрешить различным процессам, выполняющимся на различных компьютерных платформах и созданных нп различных языках программирования, обращаться к одному и тому же набору распределенных объектов в Internet (или любой другой сети). Тогда сценарии, подобно изображенному на рисунке 20, могут быть полностью осуществлены со всеми регистраторами и серверами коллекции, работающими на различных компьютерах.

Это позволяет устанавливать для работы с теми же самыми цифровыми библиотечными коллекциями намного более сложные интерфейсы. В качестве примера рассмотрим один рисунок (см. рисунок 22), который показывает графический интерфейс запроса, основанный на диаграммах Венна, позволяющий пользователям непосредственно управлять Булевыми запросами. Написанный на Java, интерфейс запускается локально на собственном компьютере пользователя. Используя CORBA, он обращается к отдаленному серверу коллекции Greenstone, написанному на C++.

Распределенный протокол все еще совершенствуется и готовится для использования, так что в этом руководстве мы более не станем его обсуждать (для получения дополнительной информации см. Bainbridge et al., 2001).

3.2 Концептуальная структура

Рисунок 23 показывает страницу "about this collection" (о коллекции) специфической коллекции Greenstone (коллекция Проекта Gutenberg). Смотрите URL наверху. Страница сгенерирована в результате выполнения CGI-программы library, которая, как говорилось выше,является выполняемой программой, включающей и регистратор и сервер коллекции, связанный в соответствии с нулевым протоколом. Аргументы library - c=gberg, a=p, и p=about. Они могут интерпретироваться следующим образом:

Рисунок 24 иллюстрирует основные части работы системы Greenstone. Наверху регистратор сначала инициализирует свои компоненты, затем анализирует CGI-аргументы, чтобы решить, какое действие запустить. При запуске действия (которое включает в дальнейшем обработку CGI аргументов), программное обеспечение использует протокол, чтобы обратиться к содержанию коллекции. Ответ используется для генерации web-страницы с помощью компонента формата и макроязыка.

Макроязык, который мы виделив Разделе 2.4, используется, чтобы обеспечить цифровую библиотечную систему Greenstone лаконичным стилем и создавать интерфейсы на различных языках. Взаимодействие с библиотекой генерирует скелет web-страниц; макрос в GSDLHOME/macros наращивает на этот скелет плоть.

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

Внешний вид страницы "about this collection" (рисунок 23) известен до момента запуска и закодирован в макрофайле about.dm. Заголовки, нижние колонтитулы и фоновая заливка даже не упомянуты, потому что они расположены в пакете макрокоманды Global. Однако, определенный "about" текст (текст для страницы "О коллекции") для специфической коллекции не известен заранее, он хранится в информационной базе данных коллекции в течение процесса формирования. Эта информация вызывается использованием протокола и хранится как _collectionextra_ в пакете макрокоманды Global. Обратите внимание на то, что имя макроса - по существу имя, используемое для описания этой информации в файле конфигурации коллекции, описанном в Разделе 1.5. Чтобы сгенерировать содержание страницы, была расширена макрокоманда _content_ в пакете about (рисунок 19) . Она в свою очередь запускает _textabout _, который непосредственно обращается к _collectionextra _, только что динамически помещенной туда.

Следующий важный компонент - объект Format. Операторы задания формата в файле конфигурации коллекции затрагивают представление специфических частей информации, как описано в Разделе 2.3. Они обработаны объектом Format (см. рисунок 24). Основная задача этого объекта состоит в том, чтобы анализировать и оценивать инструкции типа строк формата (рисунок 16). Как стало ясно из Раздела 2.3, они могут включать ссылки на метаданные в квадратных скобках (например, [Title]), которые должены быть найдены сервером коллекции. Взаимодействие происходит между объектом Format и объектом Macro Language, потому что операторы задания формата могут включать макросы, которые в качестве расширения включают метаданные, которые в качестве расширения включают макросы и так далее.

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

Игнорируя пустые строки, регистратор содержит 15 000 строк программы. Сервер коллекции содержит только 5 000 строк (75 % которого занимают файлы заголовка). Сервер коллекции более компактен, потому что релевантный поиск проходит через две предоткомпиляционные программы. Для поиска используется полнотекстовая поисковая система MG, а для поддержки информационной базы даннх коллекции используется СУБД GDBM.

Для обеспечения расширяемости и гибкости Greenstone широко использует порядок следования в пределах Action, Filter, Source и Search. Для простой цифровой библиотеки, специализированной на текстовой коллекции, это означает, что вы должны узнать немного больше, чтобы программировать систему. Однако, это также означает, что MG и GDBM могут быть легко заменены, если возникнет потребность. Кроме того, программная архитектура достаточно богата, чтобы поддержать полные возможности мультимедиа, типа управления интерфейсом через устройство речевого ввода или передачи запросов в виде графическх изображений.

3.3 Совместимость концептуальной структуры

Разделы 3.6 и 3.8 объясняют взаимодействие сервера коллекции и регистратора более подробно, останавливаясь на каждом модуле рисунка 24 и описывая, как это работает. Полезно сначала разобраться на примере пользователя, взаимодействующего с Greenstone, и описывать то, что происходит. Предполагается, что к настоящему моменту все объекты правильно инициализированы. Инициализация - запутанная процедура, к которой мы вернемся в Разделе 3.9.

Поиск

Когда пользователь вводит запрос, нажимая кнопку Begin search на странице поиска, запускается новое действие Greenstone, которое заканчиваясь, генерирует новую HTML-страницу, используя макроязык. На рисунке 25 показан результат поиска в коллекции Project Gutenberg для поискового выражения Darcy. В пределах первоначальной HTML -страницы скрыта инструкция поиска a=q. Когда кнопка поиска нажата, эта инструкция активизируется и устанавливает новое действие - queryaction. Запуск queryaction направляет запрос к объекту Filter/Фильтр (c=gberg), определяемый для коллекции через протокол.

Фильтры - важная основная функция серверов коллекции. Приспособленные для действий поиска и просмотра, они обеспечивают способы выбора подмножества информации из коллекции. В этом случае, queryaction устанавливает запрос фильтра:

• устанавка типа фильтра запроса QueryFilter (Раздел 3.6 описывает различные типы фильтров);
• сохранение установок поиска пользователя в фильтре запроса;
• вызов функции filterQ, используя нулевой протокол.

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

Когда запрос протокола типа QueryFilter сделан, объект Filter (см. рисунок 24) декодирует варианты и запрашивает объект Search, который использует MG для фактического поиска. Роль объекта Search состоит в том, что он должен обеспечить абстрактный интерфейс программы, который поддерживает поиск, независимо от основного используемого средства поиска. Формат, используемый для того, чтобы возвращать результаты, также предписывает абстракцию, требуя от объекта Search транслировать данные, сгенерированные средством поиска в стандартную форму.

Как только результаты поиска возвращены регистратору, дальнейшим действием становится форматирование результатов для отображения, используя объект Format и Макроязык. Как показано на рисунке 25, он выглядит следующим образом: стандартный заголовок Greenstone, нижний колонтитул, навигационная область и фон; повторение основной части страницы запроса только ниже навигационной области; отображение книжного значка, заголовка и автора для каждого найденного документа соответственно. Формат последней части управляется инструкцией format SearchVList в файле конфигурации коллекции. Прежде чем заголовок и метаданные автора будут отображены, они должны быть найдены сервером коллекции. Тут требуется запрос к протоколу, на сей раз используя BrowseFilter.

Retrieving a document

После вышеупомянутого запроса для Darcy, рассмотрим отображаемый документ. Рисунок 26 показывает результат щелчка по иконке около The Golf Course Mystery на рисунке 25.

Исходный текст для коллекции Gutenberg включает один длинный файл книги. Во время компоновки, этот файл разбит на отдельные страницы, каждая по 200 строк или около этого, и необходимая информация для каждой страницы сохранена в индексах и информационной базе данных коллекции. В верхней части рисунка 26 указано, что эта книга содержит 104 создаваемых компьютером страницы, и ниже - начало страницы один: кто ввел информацию, заголовок, автор, начало оглавления (это часть табличной формы исходного текста Gutenberg, она не была сгенерирована Greenstone). В верхней левой части находятся кнопки, которые управляют внешним видом документа: только одна страница или целый документ; подсветка термина запроса вкл. или выкл.; действительно ли книга должна быть отображена в ее собственном окне; отделение поисковой части от окна просмотра. В верхней правой части - навигационная помощь, которая обеспечивает прямой доступ к любой странице в книге: просто напечатайте номер страницы и нажмите кнопку "go to page" (перейти к странице). Дополнительно можно использовать для перехода по страницам стрелки next/previous pages (следующая/предыдущая страница).

Действие поиска документов documentaction определено установкой a=d и имеет несколько дополнительных параметров. Наиболее важный - дпоиск документа: это определено через переменную d. На рисунке 26 это установлено как d=HASH51e598821ed6cbbdf0942b. 1 найти первую страницу документа с идентификатором HASH51e598821ed6cbbdf0942b, зная более дружественый термин The Golf Course Mystery. Остальные переменные определяют: вкл. или выкл. подсветку термина запроса (hi), отобразить информацию о том, какая страница книги отображена (gt). Эти переменные используются для поддержки действий, предлагаемых кнопками на странице (см. рисунок 26), описанной выше. Значения по умолчанию используются, если любая из этих переменных опущена.

Действие следует за процедурой queryaction: оценка CGI -аргумента, доступ к серверу коллекции, используя протокол и результат для генерации web-страницы. Варианты, касающиеся документа, декодированы CGI-аргументом и сохранены в объекте для дальнейшей работы. Чтобы отыскать документ на сервере коллекции, необходим только идентификатор документа, чтобы установить запрос протокола к get_document (). Как только текст найден, должно быть произведено значительное форматирование. Для этого программа доступа к documentaction сохраняет аргумент и использует объект Format и Макроязык.

Просмотр иерархического классификатора

На рисунке 27 показан пример просмотра, где пользователь выбрал Titles А-Z (Заголовки A-Z) и обратился к гиперсвязи для символа К. Это происходит благодаря действию documentaction, которое задается CGI -аргументом a=d. Однако, до подключения переменной d стоит оговориться, что в данном случае она не была использована. Вместо этого использовался узел в пределах доступной для просмотра иерархии классификации, чтобы отобразить определенную переменную cl. В данном примере она представляет заголовки, сгруппированные символом К. Этот список был сформирован во время компановки и сохранен в информационной базе данных коллекции.

Записи, которые представляют узлы классификатора в базе данных, используют префикс CL, сопровождаемый числами, отделенными периодами (.), определяющими их нахождение в пределах вложенной структуры. Игнорируя кнопку поиска (левый край в навигационной области), классификаторы пронумерованы последовательно в порядке возрастания, слева направо, начиная с 1. Таким образом, узел классификатора верхнего уровня для заголовков в нашем примере - CL1, а разыскиваемая страница сгенерирована установкой cl=CLl.ll. Вы можете увидеть это в строке URL наверху рисунка 27.

Для обработки запроса документа cl используется объект Filter, который отыскивает узел по протоколу. возвращенных данных, дальнейшие запросы протокола сделаны для того, чтобы отыскать метаданные документа. В данном случае найдены заголовки книг. Однако, если узел был внутренний, дочерние записи которого - самостоятельные узлы, то были бы найдены заголовки дочерних вершин. С точки зрения программирования, это тоже самое и обработано тем же самым механизмом.

Наконец, вся найденная информация связана с использованием макроязыка и отображена на web-странице, показанной на рисунке 27.

Generating the home page

В качестве последнего примера мы рассмотрим создание домашней страницы Greenstone. Рисунок 28 демонстрирует домашнюю страницу Greenstone, установленную со значениями по умолчанию. Ее URL, который вы можете видеть наверху экрана, включает аргументы а=р np=home. Таким образом, подобно странице "about this collection" (об этой коллекции), она была сгенерированара^еасй'ои (а=р), но на сей раз применялось home (p=home). Поэтому макроязык обращается к содержанию home.dm. В данном случае нет никакой набодности определять коллекцию (с переменной с).

Цель главной страница показать, какие коллекции доступны. Щелчок по иконке приведёт пользователя на страницу “о коллекции” для этой коллекции. Меню создаётся динамически каждый раз, как только страница загружена, и базировано на коллекциях, находящихся в файлах в данное время . Каждая новая коллекция автоматически отображается на главной странице, как только страница перезагружается (если предусмотрено, что коллекция “публичная”)

Для этого регистратор использует протокол (конечно). Как часть оценки CGI аргументов, pageaction запрограммирована для обнаружения особого случая когда p=home. Тогда это действие пользуется протокольным запросом get_collection_list(), чтобы установить текущий набор коллекций. Он вызывает get_collectinfo() для получения информации о каждом из них. Эта информация включает: доступность коллекции публично, URL иконки коллекции (если есть какая-нибудь), и полное название коллекции. Эта информация используется, чтобы сгенерировать правильный вход в коллекцию с главной страницы.

3.4 Исходный код

Исходный код для работающей системы находится в GSDLHOME/src. Он занимает две поддиректории, recpt для регистрационного сервера и colservr для коллекционного сервера. Гринстоун работает во всех версиях Windows вплоть до Windows 3.1, и к несчастью это налагает восьмизнаковый лимит на файл и название директории. Это объясняет почему используются такие загодачные сокращение, как recpt и colservr. Остальные директории включают отдельностоящие утилиты, в основном для порддержки процесса построения. Они перечислены в Таблице17.

Другая директория, GSDLHOME/lib, включает подуровневые объекты, которые используются обоими, регистрационным и коллекционным, серверами . Этот код описан в Секции 3.5.

Greenstone широко использует Standard Template Library (STL)/ Стандартную библиотеку шаблонов С ++,- созданную Silicon Graphics (www.sgi.com), которая является результатом многих лет разработки и развития. Подобно всем библиотекам программирования, она требует некоторого времени на изучение. Приложение А дает краткий обзор ключевых частей, которые используются всюду в программе Greenstone. Для более полного ознакомления обращайтесь к официальному STL справочному руководству, доступному на сайте www.sgi.com, или к одному из многих учебников STL, например Josuttis (1999).

3.5 Общие типы Greenstone

Объекты, определенные в GSDLHOME/lib, являются объектами Greenstone нижнего уровня, основываясь на вершине STL, которые входят в исходную программу. Сначала мы детально рассмотрим бъект text_t, который используется для представления текста в формате Unicode. После чего мы сможем кратко изложить цель каждого файла библиотеки.

Объект text_t

Greenstone работает с многими языками и для поддержки коллекции, и пользовательского интерфейса. Для этого исходная программа повсеместно использует Unicode. Основным объектом, который понимает строку Unicode является text_t.

Unicode использует два байта для хранения каждого символа. На рисунке 29 показаны главные особенности text_t Application Program Interface/ Интерфейс прикладной программы (API). Он позволяет выполнить двухбайтовое требование, используя С ++ встроенный тип short, который определен как двухбайтовое целое число. Центральный тип данных объекта text_t - это динамический массив, сформированный short, используя STL описание vector<unsigned short> и полученное сокращенное название usvector.

Функции конструктора (строки 10-12) явно поддерживают три формы инициализации: конструкция без параметров, которая генерирует пустую строку Unicode; конструкция с целочисленным параметром, которая генерирует версию текста Unicode числового обеспеченного значения; конструкция с параметром char*, который обрабатывает аргумент как строку С ++ с нулевым символом в конце и генерирует версию Unicode.

После этого, большинство элементов (строки 17-28), переходят на обслуживание STL векторного контейнера: beginQ, endQ,push_back(), emptyQ и т.д. Здесь имеется поддержка очистки и добавления строки, а также преобразования целочисленного значения в строку текста Unicode, и возвращения соответствующего целочисленного значения текста, который представляет номер.

Существует множество перегруженных операторов , которые не показаны на рисунке 29. Особо значимые операторы представлены на рисунке 30. Строка 4 поддерживает назначение одного объекта text_t другому, а строка 5 перегружает оператор+ = , чтобы обеспечить более естественный способ добавления одного объекта text_t в конец другого. Также возможно через строку 6 обратиться к специфическому символу Unicode (представленному как short), используя знак массива []. Далее необходимо назначить и добавить в конец операторы, предназначенные для строк C++ и целых чисел. Строки 12-18 представляют Булевы операторы для того, чтобы сравнить два объекта text_t: равно, не равно, предшествует в алфавитном порядке и так далее.

Функция-член, которая берет аргумент const вместо не-const, также имеется (но на рисунке не показана). Такое повторение стандартно для объектов C++, делая API более весомым, но не более концептуальным. В действительности, многие из этих функций представлены как отдельные действующие инструкции. Для более подробного изучения обратитесь к исходному файлу GSDLHOME/lib/text_t.h.

Программа библиотеки Greenstone

Файлы заголовка в GSDLHOME/lib включают смесь функций и объектов, что обеспечивает поддержку работы системы Greenstone. Для большей эффективности отношения, функции и функции-члены объявлены как inline. Для большей части подробности выполнения содержатся в копии файла заголовка .срр.

3.6 Collection server

Теперь детально объясним все объекты в концептуальной структуре рисунка 24. Мы начнем с низа диаграммы, который является также основой системы, и с Search (Поиск), Source (Источник), РШег(Филыр) и продолжим наш путь через уровень протокола к центральным компонентам в регистраторе: Actions (Действия), Format (Формат) и Macro Language (Макроязык). Затем мы сосредоточимся на объектной инициализации, так как это будет проще понять, если уже известна роль различных объектов.

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

Например, предположим, что базовый класс по имени BaseCalc обеспечивает основную арифметику: сложение, вычитание, умножение и деление. Если все его функции объявлены виртуальными, а аргументы и возвратные типы все объявлены как строки, мы можем легко осуществить наследование версии объекта. Один из них, названный FixedPrecisionCalc, мог бы использовать библиотечные функции С, чтобы совершать конвертацию между строками и целыми числами и обратно, осуществляя вычисления, используя стандартные арифметические операторы: +, -, *, и /. Другой, названный InfinitePrecisionCalc, мог бы обращаться к строковым аргументам и символам одновременно, осуществляя арифметические операции с бесконечной точностью. Написанная главная программа использует BaseCalc повсюду, параметры ее работы могут регулироваться переключением между установленной точностью и бесконечной точностью, редактируя только одну строку: пункт, где создан объект - калькулятор.

Объект Search

Рисунок 31 демонстрирует листинг базового классф API для объекта Search (см. рисунок 24). Это определяет две виртуальные функции-члены: search() и docTargetDocument(). Из рисунка видно, что =0, который следует за описанием аргумента, это функция риге, означающая, что класс, который наследует объект, должен осуществить обе функции (иначе компилятор выдаст сообщение).

Класс также включает два защищенных поля данных: collectdir и cache. Объект Search иллюстрируется примерами для специфической коллекции, а поле collectdir используется для хранения системы файлов (и что еще более важно - их файлы индекса) в месте нахождения коллекции. Поле сасйесохраняет результат запроса. Это используется, чтобы ускорить обработку последующих запросов, которые будут дублировать этот запрос (и его параметры). В то время, как идентичные вопросы могут казаться маловероятными, фактически они происходят регулярно. Протокол Greenstone является простым. Чтобы сгенерировать страницу результатов, подобную изображенной на рисунке 25, но для документов с 11 по 20 того же самого запроса, поиск роизводится снова, на сей раз оговорив заранее, возврат документов 11-20. Кэширование делает это эффективным, тот факт, что поиск был уже выполнен, обнаруженные результаты могут быть извлечены прямо из кэша.

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

Поиск с MG

Greenstone использует MG (сокращенно от Managing Gigabytes, CM.Witten et al., 1999) для индексации и восстановления документов, исходная программа включена в директорию GSDLHOME/packages. MG использует методы сжатия, чтобы максимально использовать место на диске, не ставя под угрозу скорость выполнения. Для коллекции документов на английском языке сжатый текст и полный текст индексируются вместе и оычно занимают одну треть места, занимаемого несжатым текстом. Поиск и исправление часто происходят быстрее, чем подобное действие на несжатой версии, потому что производится меньше дисковых операций.

MG обычно используется в интерактивном режиме, печатая команды в командной строке. Один из способов активации mgsearchclass заключается в использовании библиотеки С systemQ, вызываемой с объектом, запуском соответствующей команды MG. Более эффективный подход, однако, состоит в том, чтобы открыть программу MG непосредственно, используя функцию вызова. Однако, для этого требуется более глубокое знание программы MG. Большая часть трудностей может быть скрыта за новым API , который становится точкой соприкосновения для объекта mgsearchclass. Это - роль colserver/mgq. с, чей API показан на рисунке 32.

Способ передачи параметров к MG - через mgq_ask (), который берет варианты текста в формате, идентичном используемому в командной строке:

Это также используется при вызове запроса. К результатам обращаются через mgq_results, который использует указатель на функцию, как ее четвертый параметр. Это обеспечивает гибкий способ преобразования информации, возвращенной в структуру данных MG по требованию mgsearchclass. Вызов mgqjiumdocs О, mgqjiumterms () и mgq_docsretrieved () также возвращает информацию, но на сей раз с более жесткими условиями. Последние два оказывают поддержку при восстановлении.

Обьект Source

Роль Source (см. рисунок 24) - доступ к метаданным и тексту документа. Его базовый класс представлен на рисунке 33. Функция-член наносит на карту к каждой задаче: getjnetadata () и get_document () соответственно. Оба объявлены virtual, так что версию, обеспечивающуюся выполнением базового класса, вызывают во время работы. Одна унаследованная версия этого объекта использует GDBM, чтобы запустить get_metadata 0 и MG, чтобы запустить get_document (): мы детализируем эту версию ниже.

Другая функция-член представлена на рисунке 33 - configure^, init () и translate_OID Q. Первые два касаются процесса инициализации, описанного в Разделе 3.9.

Оставшаяся, translate_OID (), работает с синтаксисом для того, чтобы выразить идентификаторы документа. На рисунке 26 мы видели, как номер страницы мог быть добавлен в конец к идентификатору документа, чтобы вызвать только эту страницу. Это было возможно, потому что страницы были идентифицированы как "разделы" при формировании коллекции. Добавление в конец " . 1" к OID вызывает первый раздел соответствующего документа. Разделы могут быть вложенными и доступны для обращения благодаря определенному номеру, разделенному периодами.

Так же, как иерархические номера разделов, синтаксис идентификатора документа поддерживает форму относительного доступа. Для текущего раздела документа возможно получить доступ к first child, добавляя в конец /с, к last child, добавляя в конец .1с, к parent, добавляя в конец .рг, к next sibling, добавляя в конец .ns и ^previous sibling, добавляя в конец .ps.

Функция translate_OID () использует параметры OIDin и OIDout, чтобы хранить исходный вариант и результат преобразования. Требуется два дополнительных параметра - err и logout. Они сообщают любой статус ошибки, который может возникнуть во время перевода, и решают, когда и куда послать регистрационную информацию. Параметры являются близкими союзниками протокола, мы к этому вернемся в Разделе 3.7.

Исправление баз данных с gdbm

Программа GDBM - менеджер базы данных GNU (www.gnu.org). Она осуществляет простую структуру записей пар ключ/данные и совместима с DBM и NDBM. Операции включают хранение, исправление и удаление записей по ключу, а также пресечение всех незаказанных ключей.

Рисунок 34 представляет фрагмент информационной базы данных коллекции, которая создана при формировании коллекции Gutenberg. Фрагмент был создан, используя утилиту db2txt системы Greenstone, которая конвертирует GDBM двойной формат базы данных в текстовую форму. Рисунок 34 содержит три записи, отделенные горизонтальными линиями. Первый - вход документа, другие два - часть иерархии, созданной классификатором AZList для заголовков коллекции. Первая строка каждой записи - ее ключ.

Запись документа хранит заглавие книги, автора и любые другие метаданные, созданные (или извлеченные) во время формирования коллекции. Запись такжебывает для внутреннего пользования и хранит информацию о том, где находятся файлы, связанные с этим документом (<archivedir>), и номер документа, используемый внутри MG (<docnum>).

Поле <contains> хранит список элементов, отделенных точками с запятой. Это точки, связывающие записи в базе данных. Для записи документа <contains> используется, чтобы указать на вложенные разделы. Последующие ключи записи сформированы, связывая текущий ключ с одним из дочерних элементов (отделенных периодом).

Вторая запись на рисунке 34 - главный узел для иерархии классификации Titles A—Z. Его дети доступны через поле <contains>, включая CL 1.1, CL1.2, CL1.3 и так далее, соответствующие индивидуальным страницам для символов А, В, С и т.д. Имеется только 24 ребенка: классификатор AZList слил Q-R и Y-Z вхождения, потому что они охватили только несколько заглавий.

Дети в поле <contains> третьей записи, CL 1.1,- это конечные документы. Возможны и более сложные структуры - поле <contains> может включать смесь документов в качестве CL узлов. Ключи, выраженные относительно текущего, отличают от абсолютных ключей, потому что они начинаются с кавычек (").

Использование MG и GDBM для реализации объекта Source

Объект, который соединяет MG и GDBM, чтобы реализовать выполнение sourceclass -это mggdbmsourceclass. Рисунок 35 демонстрирует его API. Две новых функции-члена set_gdbmptr () и set_mgsearchptr () хранят указатели на соответствующие им объекты, так, чтобы при выполнении getjnetadata О и get_document () иметь доступ к соответствующим инструментальным средствам для завершения работы.

Объект Filter

API базового класса для объекта Filter (см. рисунок 24) показан на Рисунке 36. Он начинается с защищенных полей данных gsdlhome, collection и collectdir. Они обычно происходят в классах, которые должны обратиться к определенным коллекцией файлам.

• gsdlhome точно такой же, как GSDLHOME, предназначен для того, чтобы объект мог определить местонахождение файлов Greenstone.
• collection - имя каталога, соответствующего коллекции.
• collectdir - полное имя пути к каталогу коллекции (это необходимо, потому что коллекция не должна постоянно находиться в пределах GSDLHOME области).

mggdbsourceclass - другой класс, который включает эти три поля данных.

Функции-члены conflgure() и init() (ранее упоминавшиеся в sourceclass) используются процессом инициализации. Сам объект находится недалеко от соответствующей части фильтра протокола; в особенности getjilteroptions О и fllter() соответствуют один другому.

К центральным опциям фильтра относятся два класса, показанные на рисунке 37. Сохраненные внутри FilterOption_t - это пате опции, ее type и действительно ли это - repeatable. Интерпретация validValues зависит от типа опции. Для Булева типа первым значением переменой является^г/5е,а вторым - true. Для целочисленного типа первое значение - минимальный номер, второй - максимальный. Для перечисляемого типа все значения перечислены. Для строкового типа значение игнорируется. Для более простых ситуаций используется OptionValue_t, в качестве записи как text_t name опции и ее value.

Запрос и ответ объекта проходят как параметры juuLJilterclass. Созданью из них два класса используют ассоциативные массивы, чтобы сохранить набор типов опций, требуемых для InfoFilterOptionsResponseJ. Для детального исследования вопроса смотрите GSDLHOME/src/recpt/comtypes.h.

Объекты наследования Filter

Два уровня наследования используются для фильтров, как показано на рисунке 38. Сначала было сделано различие между фильтрами Query и Browse, а затем первому из них определено выполнение, основанное на MG. Для корректной работы mgqueryfilterclass требуется доступ к MG через mgsearchclass и к GDBM через gdbmclass. browsefllterclass нуждается в доступе только к GDBM. Указатели на эти объекты сохранены как защищенные поля данных в пределах соответствующих классов.

Программа сервера коллекции

Рассмотрим файлы заголовка в GSDLHOME/SRC/COLSERVR с описанием каждого из них. Имя файла вообще повторяет имя объекта, определенное в его пределах.

3.7 Протокол

Таблица 18 представляет список запросов функции к протоколу и резюме для каждого вхождения. Примеры в Разделе 3.3 охватили большинство из них. Функции, не упомянутые предварительно - has_collection (), ping (), get_protocol_name () и get_filteroptions (). Первые две обеспечивают ответы да\нет на вопросы "коллекция существует на этом сервере? " и "это выполняется? ". Цель двух других состоит в том, чтобы поддержать множественные протоколы в пределах архитектуры, которая распределена по различным компьютерам, а не только нулевой протокол, базирующийся на отдельно выполняемой программе, описанной здесь. Одна из них различает, какой протокол используется. Другая позволяет регистратору опрашивать сервер коллекции, чтобы найти, какие варианты поддерживаются, и непосредственно динамически выбирать конфигурации, чтобы использовать все преимущества услуг, предлагаемых специфическим сервером.

Рисунок 39 показывает API для нулевого протокола. Комментарии и некоторые подробности низкого уровня были опущены (см. исходный файл recpt/nullproto.h для получения подробностей).

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

За исключением get_protocol_name (), который не использует параметры и возвращает имя протокола как строку текста Unicode, все функции протокола включают параметр ошибки и выходной поток, как последние два аргумента. Параметр ошибки делает запись любых ошибок, которые происходят в ходе выполнения запроса протокола, а выходной поток используется для регистрации цели. Функции относятся к типу void - они не возвращают информацию как их заключительная инструкция, но вместо этого возвращают данные через определяемые параметры типа уже введенного параметра ошибки. В некоторых языках программирования такие подпрограммы были бы определены как процедуры, а не функции, но C++ не делает никакого синтаксического различия.

Большинство функций использует имя коллекции как параметр. Три функции-члены, get_filteroptions (), filterQ, и get_document (), следуют за обеспечением параметра Request и получением результатов в параметре Response.

3.8 Регистратор

Заключительный уровень концептуальной модели - регистратор. Как только CGI-аргументы будут проанализированы, основная деятельность запускает на выполнение Action, поддерживаемую объектами Format и Macro Language. Они описаны ниже. Хотя они представлены как объекты в концептуальной структуре, объекты Format и Macro Language - не совсем являются объектами с точки зрения C++. В действительности, Format - коллекция структур данных с набором функций, которые оперируют ими, а объект Macro Language сформирован вокруг display class, определен в lib/display.h, с потоковой поддержкой конвертации от lib/gsdlunicode.h.

Действия

Greenstone поддерживает одиннадцать действий, сведенных в Таблице 19.

CGI-аргументы являются необходимыми действиями формально объявленными в функции конструктора, использующими cgiarginfo (определенный в recpt/cgiargs.h). Рисунок 40 показывает выборку из pageaction функции конструктора, которая определяет размер и свойства CGI-аргументов а и р.

Для каждого CGI-аргумента конструктор должен определить его краткое имя (строки 2 и 10), которое непосредственно является именем CGI-переменной; полное имя (строки 3 и 11), которое используется, чтобы обеспечить более значимое описание действия; представляет ли это единственное или множественное символьное значение (строки 4 и 12); возможное значение по умолчанию (строки 5 и 13); что случается, когда задано больше чем одно значение по умолчанию (строки 6 и 14) (так как значения по умолчанию могут также быть установлены в файлах конфигурации); действительно ли значение сохраняется в конце этого действия (строки 7 и 15).

Так как это встроено в программу, web-страницы, которые детализируют информацию, могут быть сгенерированы автоматически. Statusaction производит эту информацию. Вы можете увидеть это, введя URL страницы администрирования Greenstone.

Двенадцать унаследованных действий созданы в main(), функция верхнего уровня для выполняемой программы library, определение которой дается в recpt/librarymain.cpp, там же, где был создан объект регистратора (определенный в recpt/receptionist.cpp). ответственность за все действия передают регистратору, который обрабатывает их, обслуживая как поле данных ассоциативного массива базового класса Action, индексированного названием действия.

Рисунок 41 показывает API для базового класса Action. При выполнении действия, receptionist (регистратор) вызывает несколько функций, начиная с check_cgiargs (). Большинство помогают проверить, установить, и определить значения и макросы; в то время как dojzction () фактически генерирует страницу вывода. В частности, унаследованный объект не имеет никакого определения для специфической функции-члена, это проходит через определение базового класса, которое осуществляет заданное по умолчанию поведение.

Объяснения функций-членов следующие.

• get_action_name() возвращает значение CGI-аргумента, которое определяет это действие. Имя должно быть коротким, но более одного символа.
• check_cgiargs() вызывается прежде get_cgihead_info(),deflne_external_macros() и do_action (). Если ошибка найдена, сообщение информирует о выходе из системы; если это серьезно, функция возвращает значение false и никакая загрузка содержания страницы не производится.
• check_external_cgiargs() вызывается после check_cgiargs () для всех действий. Она предназначена только для того, чтобы отменить некоторое нормальное поведение, например воспроизводя страницу входа в систему, когда требуетя идентификация.
• get_cgihead_info() определяет информацию о заголовке CGI. Если response (ответ) установлен, как location (местоположение), то response_data содержит переадресацию. Если response установлен, как content (содержание), то response_data содержит тип содержания.
• uses_display() возвращает true, если displayclass необходим, для вывода содержания страницы (значение по умолчанию).
• define_internal_macros() определяет все макросы, которые связаны со страницами, сгенерированными этим действием.
• define_external_macros() определяет все макросы, которые могли бы использоваться другими действиями для создания страниц.
• do_action() генерирует страницу вывода обычно в потоке объекта макроязыка display и выводит преобразование объекта textout. Возвращает значение false, если произошла ошибка, которая предотвратила действие какого-нибудь вывода.

В начале определения класса argsinfo - это защищенное поле данных (используемое в выборке программы, см.рисунок 40), которое хранит информацию CGI-аргумента, указанную в унаследованной функции конструктора Action. Другое поле данных, gsdlhome, создает запись GSDLHOME для удобного доступа[4]. Объект также включает conflgure() и init () с целью инициализации.

Форматирование

Хотя на рисунке 24 форматирование представлено как отдельный объект, в действительности оно составляет коллекцию структур данных и функций. Они собраны вместе под файлом заголовка recpt/formattools.h. Основные структуры данных показаны на рисунке 42.

Этот процесс лучше всего объяснить на примере. Когда оператор задания формата

"[link][Title]{If}{[Creator], by [Creator]}[/link]} "

читается из файла конфигурации коллекции, он анализируется функциями в formattools.cpp и формирует связанные структуры данных, показанные на рисунке 43.

Значение для gsdlhome исходит из gsdlsite.cfg, расположенного в том же самом каталоге, что и CGI-выполняемая library, тогда как GSDLHOME устанавливается запуском скрипта setup, который обращается к другому файлу, так как технически это возможно для двух различных значений. Хотя это и возможно, но все же не желательно, и все вышесказанное написано в предположении, что файлы те же самые. Когда оператор задания формата должен быть оценен действием, структура данных пересекается. Маршрут, предпринятый в comIf и comOr узлах, зависит от метаданных, которые возвращают запрос протоколу. Одно осложнение состоит в том, что, когда метаданные найдены, они могут включать последующие макросы и формат синтаксиса. При необходимости это обрабатывается переключеним назад и вперед между синтаксическим анализом и оценкой, как необходимо.

Макроязык

Macro Language, представленный на рисунке 24, так же, как Format не является функцией одного класса C++. В этом случае - это основной класс, но выполнение макроязыка также вызывает функции поддержки и классы.

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

В типичной инсталляции Greenstone, макростаршинство обычно: с (для коллекции) имеет приоритет над v (для графического или текстового интерфейса), который имеет приоритет над / (для языка). Это достигается строкой

в основном файле конфигурации main.cfg. Макроинструкции на рисунке 44 определяют типовой макрос для _header_ в пакете запроса для различных параметров настройки с, v и /. Если CGI -аргумент задан, когда вызванное действие включает c=dls, v=l и 1=еп, макрокоманда Jieader _ [v=l] была бы выбрана для отображения. Она была бы выбрана раньше of _content _ [1=еп], потому что v имеет более высокий приоритет, чем /. А макрокоманда _content_[l=fr, v=l, c=dls] не была бы выбрана вообще, потому что параметр / для страницы задан совсем другой.

Рисунок 45 показывает основную структуру данных, сформированную при чтении макрофайлов, указанных в etc/main.cfg. По существу, это -ассоциативный массив ассоциативных массивов ассоциативных массивов. Высший уровень (показанный слева) - это индексы, которые упаковывают макрокоманду, второй уровень индексирует макроимя. Конечный уровень индексирует любые параметры, которые были определены, сохраняя каждый как тип mvalue, который создает запись, наряду с макрозначением, файла, из которого оно исходило. Например, текст, определенный для Jieader _ [1=еп] на рисунке 44 можно увидеть сохраненным ниже двух записей mvalue на рисунке 45.

Центральный объект, который поддерживает макроязык - displayclass, определенный в lib/display, h. Его открытые функции-члены показаны на рисунке 46. Класс читает указанные макрофайлы, используя loaddefaultmacros (), сохраняя в защищенном разделе класса (не показан) тип структуры данных, показанной на рисунке 45. Для макроса также допустимо быть установленным системой поддержки выполнения, используя setmacro () (в последнем примере Раздела 3.3, pageaction устанавливает _homeextra_ как динамически сгенерированную таблицу доступных коллекций, используя эту функцию). Это поддерживается набором ассоциативных массивов, подобных используемым для представления макрофайлов (они не идентичны, потому что в первом случае не требуется уровень "параметра"). В displayclass чтение макроса из файла упоминается как default macros. Локальный макрос, указанный через setmacro (), упоминается как current macros и удаляется из памяти, как только страница была сгенерирована.

Когда страница должна быть воспроизведена, сначала вызывается openpage О, чтобы сообщить текущие параметры настройки параметров страницы (1=еп и так далее). Следом, текст и макрос потоково проходят через класс, обычно с actionclass, используя строку программы:

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

Программа регистратора

Основные объекты регистратора были описаны. Ниже мы детализируем классы поддержки, которые постоянно находятся в GSDLHOME/SRC/RECPT. Кроме того, там где главным является эффективность, когда определения встроены, подробности выполнения содержатся в пределах копии файла заголовка .срр. Файлы поддержки часто включают слово tool как часть имени файла, как в OIDtools.h nformattools.h.

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

Другая большая группа файлов поддержки включает термин browserclass. Это файлы, связанные через виртуальную иерархию наследования. Как группа, они поддерживают абстрактное понятие просмотра: последовательная генерация страницы документа, разделенного содержанием или метаданными. Просматривающие действия включают просмотр документов, упорядоченных в алфавитном порядке в соответствии с заголовком или хронологически по времени; развитие через заголовки, возвращенные запросом, - десять входов одновременно; доступ к отдельным страницам книги, используя механизм "go to page" (перейти к странице) . Каждое действие просмотра наследовано от базового класса browserclass:

• datelistbrowserclass обеспечивает поддержку хронологическим спискам;
• hlistbrowserclass обеспечивает поддержку горизонтальным спискам;
• htmlbrowserclass обеспечивает поддержку страницам HTML;
• invbrowserclass обеспечивает поддержку невидимым спискам;
• pagedbrowserclass обеспечивает поддержку механизма "go to page" (перейти к странице);
• vlistbrowserclass обеспечивает поддержку вертикальным спискам.

Действия обращаются к объектам browserclass через browsetools.h.

3.9 Инициализация

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

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

Строки файлов конфигурации передают, по одному, для conflgure() два параметра: ключевое слово и массив остающихся слов. Основанная на ключевом слове, специфическая версия выбора configure() решает, представляет ли информация интерес, и если это так то сохраняет ее. Например, collectserver (который показан на рисунке 24), обрабатывает операторы задания формата в файле конфигурации коллекции. Когда формат ключевого слова передают configure(), оператор if запускает сохраненную в объекте копию второго аргумента функции.

После обработки ключевого слова и прежде, чем функция закончит выполнение, некоторые версии conflgure() передают данные функции configure() в других объектах. Объект Receptionist (регистратор) вызывает выбор configureQ для Actions , Protocols и Browsers. Объект NullProtocol вызывает conflgure() для каждого объекта Collection; Collection вызывает Filters и Sources.

В C++ поля данных обычно инициализируются функцией конструктора объекта. Однако, в Greenstone некоторая инициализация зависит от чтения значений из файлов конфигурации, так что необходим второй раунд инициализации. Это - цель init () функции-члена, в некоторых случаях она ведет к последующему вызову conflgure().

На рисуноке 47 показаны диагностические инструкции, сгенерированные Greenstone, увеличенные так, чтобы выделить процесс инициализации. Программа начинается с функции main() в recpt/librarymain.cpp. Она создает объект Receptionist и объект NullProtocol, затем просматривает gsdlsite.cfg (расположенный в том же самом каталоге, что и выполняемая программа library) для gsdlhome и сохраняет его значение в переменной.

Далее mainQ добавляет объект NullProtocol к Receptionist (Регистратору), который сохраняет массив протоколов базового класса в защищенном поле данных, а затем устанавливает несколько конвертеров. main() создает все Actions и Browsers, используемые в выполняемой программе, и добавляет их к Регистратору. В завершение функция вызывает cgiwrapper () в cgiwrapper.cpp, который непосредственно включает существенную объектную инициализацию.

Существуют три этапа cgiwrapper(): конфигурация, инициализация и генерация страницы. Сначала производятся аппаратные запросы conflgure(). Затем читается gsdlsite.cfg и вызывается configure() для каждой строки. То же самое производится для etc/main.cfg.

Второй этап cgiwrapper () делает запросы к init (). Регистратор делает только один запрос к своей функции init (), но действием вызова запускает функции init () в различных объектах, сохраненных в его пределах. Сначала производится аппаратный запрос conflgure(), чтобы установить collectdir, после чего читаются макрофайлы. Для каждого действия вызывают его init () функцию. То же самое происходит для каждого протокола, сохраненного в регистраторе, но в описываемой системе сохранен только один протокол - NullProtocol. Запрос init () для этого объекта вызывает дальнейшую конфигурацию: для каждой коллекции в NullProtocol читаются и обрабатываются определенные коллекцией build.cfg и collect.cfg, с запросом configure() для каждой строки.

На заключительном этапе cgiwrapper () должен проанализировать CGI -аргументы и затем вызвать соответствующее действие. Оба этих запроса производятся при поддержке объекта Receptionist.

Причина для разделения конфигурации, инициализации и программы генерации страницы состоит в том, что Greenstone оптимизирован для работы в качестве сервера (используя Fast-cgi, или протокол Corba, или Windows Local Library). В этом режиме работы конфигурация и программа инициализации запускаются однажды, программа остается в памяти и генерирует множество web-страниц в ответ на запросы от клиентов, не требуя переустановки.

4 Конфигурирование вашего Greenstone - сайта

В системе Greenstone имеется два файла конфигурации, которые используются для того, чтобы формировать различные аспекты вашего Greenstone-сайта. "Основной" файл конфигурации main.cfg находится в GSDLHOME/ETC, и файл конфигурации "сайта" gsdlsite.cfg он находится в GSDLHOME/CGI-BIN. Каждый из этих файлов управляет определенными аспектами конфигурации всего сайта. Оба могут быть просмотрены со страницы администрирования Greenstone.

4.1 Основной файл конфигурации

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

Обслуживание сайта и регистрация

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

Языковая поддержка

Два вида вхождений в файле конфигурации main.cfg затрагивают пути обработки различных языков. Они определяют, какие языки и кодировки являются доступными на странице Preferences page. Строки Encoding определяют различные типы кодировки символов, которые могут быть выбраны. Строки Language определяют, какие языки интерфейса пользователя могут быть выбраны (конечно, для каждого возможного языка должна существовать макрокоманда языка).

Строка Encoding может содержать четыре возможных значения: shortname, longname, map и multibyte. Shortname - стандартная метка набора символов, и должна быть определна для всего кодирования. Longname дает имя кодирования, которое отображено на странице выбора предпочтений -Preferences page. Если это значение отсутствует, то по умолчанию используется shortname. Значение тар принудительно для всех кодировок, кроме utf8, которая обработана внутренне (и всегда должна быть допустима). Значение multibyte должно быть установлено для всех наборов символов, которые требуют больше, чем один байт на символ. Файл main.cfg определяет множество кодировок, большинство из которых было прокомментировано. Чтобы допустить использование кодировок, удалите символ комментария "#".

Каждая строка Language может содержать три возможных значения, shortname, longname, и default_encoding. Shortname - двухбуквенное обозначение языка в соответствии с требованиями ISO 639. Longname -название, которое используется для языка на странице выбора предпочтений - Preferences page. При отсутствии этого значения, по умолчанию используется shortname. Опция default_encoding используется, чтобы определить предпочтительную кодировку для выбранного языка.

Параметры страниц и CGI-аргументов

Параметры страницы и CGI-аргументов могут быть определены внутри файла конфигурации main.cfg. Вернемся к рисунку 40, из которого видно, что большинство CGI -аргументов определено непосредственно в пределах программы библиотеки C++. Однако, иногда полезно определить новые аргументы или отредактировать существующие во время процесса конфигурации, таким образом избегая потребности перетранслировать библиотеку.

Чтобы сделать это, вы должны использовать опцию конфигурации cgiarg. Cgiarg может использовать до шести параметров; shortname, longname, multiplechar, argdefault, defaultstatus и savedarginfo. Эти параметры соответствуют вариантам CGI-аргумента, описанным в Разделе 3.8. Например, в значении по умолчанию main.cfg опция конфигурации cgiarg используется, чтобы установить значения по умолчанию существующих а и р CGI-аргументов дляр и home соответственно.

Параметры страницы - частные случаи CGI-аргументов, которые соответствуют параметрам в файлах макрокоманды Greenstone. Например, CGI-аргумент /непосредственно соответствует параметру / = в макрофайлах. Чтобы определить CGI-аргумент, который также может быть параметром страницы, используйте опцию конфигурации pageparam.

Лучший способ узнать о различных вариантах конфигурации, возможных в файле конфигурации main-cfg, состоит в том, чтобы экспериментировать непосредственно с этим файлом. Обратите внимание на то, что если вы используете локальную Windows-версию библиотеки Greenstone, то прежде чем любые изменения файлов конфигурации вступят в силу, вам необходимо будет перезапустить сервер.

4.2  Файл конфигурации сайта

Файл конфигурации сайта gsdlsite.cfg устанавливает переменные, которые используются программным обеспечением библиотеки и веб-сервером во время выполнения и постоянно находится в том же самом каталоге, что и библиотечная программа. Таблица 21 описывает строки в этом файле; подробнее они рассматриваются в Разделе 5 документации - Цифровая библиотека Greenstone: Руководство по установке.

 Приложение А: Стандартная библиотека шаблонов C++

Стандартная Библиотека Шаблонов (STL) - широко используемая библиотека C++ от Silicon Graphics (www.sgi.com). В данном Приложении представлен краткий обзор ключевых частей, которые используются всюду в программе Greenstone. Для ознаклмления с более полным описанием ознакомьтесь с официальным справочным описанием STL, доступным в режиме on-line на сайте www.sgi.com, или с одним из многих STL-учебников, например Josuttis (1999).

Как предполагает слово "шаблон", STL - не только библиотека объектных модулей plug-and-use (подключай-и-используй). Вместе с механизмом шаблонов в C++, обеспечивается форум для программистов, чтобы разрабатывать их собственные объекты, которые используют алгоритмические возможности, реализованные в пределах STL. В результате добавляется дополнительный уровень сложности, но это стоит того.

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

Списки (Lists)

Сначала мы изучим две программы, которые реализуют целочисленный список. Превоначально используйте основные типы C++ (путь "по проторенной дорожке"), далее используйте STL. Рисунок 48 показывает выполнение исходной программы, которое не использует STL. Строки 5-8 определяют основную структуру данных, которую мы собираемся использовать: поле val сохраняет целочисленное значение, a next указывает на следующий элемент в списке - классическое воплощение списка связей.

Чтобы продемонстрировать использование структуры данных, основная программа (строки 23-32), устанавливает целочисленный список с элементами [5, 4]. Тогда вызывается функция total_int_list (определенная в строках 10-21), которая в качестве ее единственного параметра берет указатель на вершину списка и суммирует значения в нем. Возвращенный ответ (в нашем примере 9) выводится на экран.

Основная работа достигается строками 12-18. Сначала производится небольшая инициализация: локальная переменная total установливает nil и сигг, чтобы указать на начало списка. Тогда цикл с условием добавляет текущий целочисленный элемент в список для общего выполнения (total += curr. >val;) перед переходом к следующему элементу (curr = curr. >next;). Цикл с условием заканчивается, когда curr становится равным nil, показывая, что элементов для обработки больше не осталось.

Рисунок 49 показывает эквивалентную программу, созданную с использованием STL. Больше нет необходимости определять подходящую структуру данных в программе; все, что является необходимым - это ffinclude <list> указание в строке 2, которое включает версию шаблона для списка, определенного в STL. Объект называют "класс-контейнер", потому что, когда мы объявляем переменную этого типа, мы также определяем тип, в котором мы хотим ее сохранить. В строке 19 целочисленный список реализован с использованием оператора list<int> vals;. Элементы можно добавить к объекту, используя функцию-член push_back(), как это сделано в строках 20-21.

Основная работа выполнена строками 6-12. Есть все еще две инициализации и цикл с условием, но отличающийся от представленного в предыдущем случае. Новый синтаксис имеет немного общего со старым. Ключевым моментом этого нового способа обработки является переменная типа iterator (строка 7). В STL много классов включают типы iterator, чтобы обеспечить однородный способ работы через последовательность контейнерных объектов. Первый элемент возвращен с begin(), и только один - последний элемент с end(). Перемещение к следующему элементу достигнуто операцией приращения ++, которая перегружена классом iterator, чтобы осуществить эту задачу, и к значению, сохраненному там, обращаются через разыменование (*сигг на строке 10), который также является перегруженным.

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

Обратите внимание, что параметр для total_int_list на рисунке 49 был реализован как указатель, соответствовавший указателю, используемому в total_int_list на рисунке 48. В STL зачастую более естественно (и более желательно) использовать ссылки, а не указатели. Тогда параметр становится list<int>& head, и его функции-члены вызываются синтаксисом head, begin 0; и так далее.

Maps

При реализации системы цифровой библиотки, полезно иметь возможность сохранения элементов в массиве, индексированном текстовыми строками, а не числовыми индексами. В Greenstone, например, это очень упрощает сохранение макрофайлов, как только они считались, и различных файлов конфигурации. Тип данных, который поддерживает такой доступ, называют associative array (ассоциативным массивом), и он часто встраивается в современные языки высокого уровня. Он также известен под именем hash array (особенно в Perl), так как хеширование - нормальная методика, по обыкновению реализующая текстовый индекс.

В STL ассоциативные массивы достигаются использованием объекта тар. Рисунок 50 показывает придуманный пример, в котором возраст трех человек (Алиса, Питер и Мэри) хранится в ассоциативном массиве под их собственными именами (строки 19-22). Проблема состоит в том, чтобы записать функцию, которая вычисляет полный возраст людей, не зная, сколько их имеется или каковы их имена. Конечно, это могло бы быть решено с использованием стандартных числовых массивов целых чисел. Данный пример был придуман, чтобы продемонстрировать, что особенности тар производят подобие обработки с объектом list совместно с iterator.

Подобно list, map относится к классу-контейнеру. Однако, при объявлении переменной этого типа мы должны определить две[5] вещи: индексный тип, и тип элемента. Как вы могли заметить в строке 19, мы получаем ассоциативный массив, который сохраняет целые числа, используя char* (который является строкой, объявленной в C++) как индексный тип, сопровождаемый int в качестве типа элемента.

Есть несколько способов сохранить элементы в ассоциативном массиве. В данном примере в строках 20-22 перегруженный массив описывается, используя [], чтобы инициализировать таблицу с возрастами этих трех человек. Подобно total_int_table, который исполняет основное вычисление в программе, на рисунке 48 используется total_int_list Фактически, они почти идентичны, и это не никакое совпадение. STL трудно использовать наследование так, чтобы различные объекты все еще использовали те же самые фундаментальные операции. Это особенно точно в отношении итераторов. Небольшие различия между двумя функциями состоят в том, что итератор теперь получен из map<char*, int> и доступ к его элементам происходит совместно с curr .>second(), потому что разыменование переменной (*сигг) определено, чтобы возвратить объект типаршг. Он создает запись и индексного имени (first), и значения элемента (second), но мы хотим иметь только последнее. Кроме этого, программа остается тойже самой. Единственное остающееся отличие - это изменение единственного аргумента функции с указателя на ссылку - является незначительным.

Два других типа STL, широко используемые в программе Greenstone - это vector и set. Первый облегчает поддержание динамических массивов, а последний поддерживает математические операции установки типа объединения, пересечения и различия.

 Литература

Aulds, C. (2000) Linux Apache Web Server Administration. Sybex.

Bainbridge, D., Buchanan, G., McPherson, J., Jones, S., Mahoui, A. and Witten, I.H. (2001) “Greenstone: A platform for distributed digital library development.” Research Report, Computer Science Department, University of Waikato, New Zealand.

Christiansen, T. Torkington, N. and Wall, L. (1998) Perl Cookbook. O'Reilly and Associates.

Coar, K.A.L. (1998) Apache Server For Dummies. IDG Books.

Deitel, H.M. and Deitel, P.J. (1994) C++: How to Program. Prentice Hall, Englewood Cliffs, New Jersey.

Dublin Core (2001) “The Dublin Core Metadata Initiative” at http://purl.org/dc/, accessed 16 January 2001.

Josuttis, N.M. (1999) The C++ standard library: a tutorial and reference. Addison-Wesley, 1999.

Keller, M. and Holden, G. (1999) Apache Server for Windows Little Black Book. Coriolis Group.

Schwartz, R.L. and Christiansen, T. (1997) Learning Perl(2nd Edition). O'Reilly and Associates.

Slama, D., Garbis, J. and Russell, P. (1999) Enterprise CORBA. Prentice Hall, Englewood Cliffs, New Jersey.

Stroustroup, B. (1997) The C++ Programming Language. Addison-Wesley.

Thiele, H. (1997) “The Dublin Core and Warwick Framework: A Review of the Literature, March 1995—September 1997.” D-Lib Magazine, January. <http://www.dlib.org/dlib/january98/01thiele.html>

Wall, L., Christiansen, T. and Orwant, J. (2000) Programming Perl(3rd Edition). O'Reilly and Associates.

Weibel, S. (1999) “The State of the Dublin Core Metadata Initiative.” D-Lib Magazine, Volume 5 Number 4; April. <http://www.dlib.org/dlib/april99/04weibel.html>

Witten, I.H., Moffat, A. and Bell, T.C. (1999) Managing gigabytes: compressing and indexing documents and images. Morgan Kaufmann, San Francisco.

[1] Для операционных систем Windows 95/98 запуск setup.bat может закончиться неудачно, и система выдаст сообщение об ошибке "Out of environment space". Если это призошло, то вам необходимо отредактировать системный файл config.sys (обычно он находится в C:\config.sys) и добавить в него строку shell=C:\command.com /e:4096 /p (где С: имя вашего системного диска). Для того, чтобы эти изменения вступили в силу, необходимо перезагрузить ваш компьютер и повторить все шаги для запуска Greenstone.

[2] Обратите внимание, что в системе Greenstone стандартные выражения интерпретируются языком Perl, который несколько отличается от других. Например, "*" соответствует нулю или большему количеству повторений предыдущего символа, в то время как "."-паре любых символов. Так, nugget.* соответствует любой строке с префиксом "nugget," содержит ли она или нет пробел после префикса. Чтобы учесть этот пробел, необходимо его обойти, для этого нужно написать nugget\.. *.

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

[4] начение для gsdlhome исходит из gsdlsite.cfg, расположенного в том же самом каталоге, что и CGI-выполняемая library, тогда как GSDLHOME устанавливается запуском скрипта setup, который обращается к другому файлу, так как технически это возможно для двух различных значений. Хотя это и возможно, но все же не желательно, и все вышесказанное написано в предположении, что файлы те же самые.

[5] Технически есть четыре типа, но последние два являются дополнительными. Так как мы только даем основное введение в этот класс STL, подробности об этих последних двух типах опущены.