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

РУКОВОДСТВО

David Bainbridge, Dana McKay and Ian H. Witten

Факультет Компьютерных Наук
Университет Вайкато, Новая Зеландия

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

Мы надеемся, что это программное обеспечение работает хорошо. Пожалуйста, сообщите о любых проблемах по адресу: greenstone@cs.waikato.ac.nz

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 устанавливается в каталог, в который можно попасть напечатав

cd "C:\Program Files\gsdl "

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

setup.bat

Этот файл (который вы можете просмотреть) указывает системе, где искать программы 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. Для того, чтобы присвоить коллекции имя, я напечатал

perl —S mkcol.pl —creator me@cs.waikato.ac.nz dlpeople

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

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

cd "%GSDLHOME%\collect\dlpeople "

Figure 1  Конфигурационный файл коллекции создан при помощи mkcol.pl
creator             me@cs.waikato.ac.nz
maintainer          me@cs.waikato.ac.nz
public              true
beta                true
indexes             document:text
defaultindex        document:text
plugin              ZIPPlug
plugin              GAPlug
plugin              TEXTPlug
plugin              HTMLPlug
plugin              EMAILPlug
plugin              ArcPlug
plugin              RecPlug
classify            AZList -metadata "Title"
collectionmeta collectionname    "dlpeople"
collectionmeta iconcollection    ""
collectionmeta collectionextra   ""
collectionmeta .document:text    "documents "

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

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

выделите содержимое каталога dlpeople и переместите в директорию import коллекции dlpeople.

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

xcopy /s d:\collect\dlpeople\* import

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

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

perl —S import.pl -removeold dlpeople

Не беспокойтесь по поводу быстро бегущего по экрану текста - это отчет о выполнении процедуры импорта. К сведению, процесс импорта этой коллекции занимает около 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. Пока же придерживайтесь значений "по умолчанию", напечатав:

perl —S buildcol.pl dlpeople

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

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

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

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

rd /s index # on Windows NT/2000
deltree /Y index # on Windows 95/98

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

ren building index

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

mkdir building

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

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

Figure 2  Иконка коллекции


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

cd "C:\Program Files\gsdl " # assuming default location
setup.bat
perl —S mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
cd "%GSDLHOME%\collect\dlpeople "
xcopy /s d:\collect\dlpeople\* import # assuming D drive
perl —S import.pl dlpeople
perl —S buildcol.pl dlpeople
rd /s index # on Windows NT/2000
deltree /Y index # on Windows 95/98
ren building index
mkdir building

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

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

cd ~/gsdl

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

source setup.bash # if you're running the BASH shell
source setup.csh # if you're running the C shell

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

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

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

Figure 3  Страница коллекции "About" (о коллекции)


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

mkcol.pl —creator me@cs.waikato.ac.nz dlpeople

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

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

cd $GSDLHOME/collect/dlpeople

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

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

mount /cdrom

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

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

cp —r /cdrom/collect/dlpeople/* import/

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

umount /cdrom

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

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

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

import.pl dlpeople

Не беспокойтесь по поводу быстро бегущего по экрану текста - это отчет о выполнении процедуры импорта. К сведению, процесс импорта этой коллекции занимает около 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. Пока же придерживайтесь значений "по умолчанию", напечатав:

buildcol.pl dlpeople

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

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

rm —r index/*

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

mv building/* index/

Table 1  Различия в процессах построения коллекций для Windows и Linux Windows

Windows

Linux

Linux Запустите setup, bat, чтобы сделать программы Greenstone доступными

Запустите setup, bat, чтобы сделать Запустите setup, bash или setup, csh, чтобы программы Greenstone доступными

Скопируйте файлы с CD-ROM, используя менеджер файлов или с помощью команд Windows

Скопируйте файлы с CD-ROM, используя mount и команды Unix

Замените индексы старой коллекции, напечатав rd /s index, потом ren building index затем mkdir building, или воспользуйтесь менеджером файлов

Замените индексы старой коллекции, напечатав rm –r index/* , а затем mv building/* index


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

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

cd ~/gsdl # assuming default Greenstone in home directory
source setup.bash # if you're running the BASH shell
source setup.csh # if you're running the C shell
mkcol.pl —creator me@cs.waikato.ac.nz dlpeople
cd $GSDLHOME/collect/dlpeople
mount /cdrom # assuming this is where CD-ROM is mapped to
cp —r /cdrom/collect/dlpeople/* import/
umount /cdrom
import.pl dlpeople
buildcol.pl dlpeople
rm -r index/*
mv building/* index

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

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

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

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

Figure 4  Струкура директории GSDLHOME


Table 2  Структура директорий

содержание

раздел

bin

Исполняемый двоичный код в директории с именем вашей ОС.

bin/script

Скрипты языка Perl, используется для формирования и ведения коллекций (например, import.pl and buildcol.pl). Для получения описания этих программ напечатайте их имя в командной строке.

1.3

perllib

Модуль языка Perl, используется во время формирования и импорта.

2.1

perllib/plugins

Программа на языке Perl - приложение для обработки документов.

2.1

perllib/classify

Программа - классификатор на языке Perl (например, код AZList, который создает список документов в алфавитном порядке по некоторому атрибуту).

2.2

cgi-bin

Все CGI -скрипты системы Greenstone, которые помещены в cgi-bin каталог.

tmp

Директория, используемая Greenstone для временного хранения файлов.

etc

Файл конфигураций, инициализации и отчета об ошибках, база авторизации пользователей.

src

Программа на C++, используется для обслуживания коллекций через web-сервер.

3

src/colservr

Программа на C++, используется для обслуживания коллекции –ответы на запросы и т.п.

3.7

src/recpt

Программа на C++, используется для передачи запроса через интерфейс пользователя и формирования ответа на запрос.

3.9

packages

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

2.5

packages/mg

Исходная программа MG, используется Greenstone для сжатия и индексации.

2.5

mappings

ования символов Unicode (например, для установки китайской раскладки символов).

macros

Макрофайлы, используются для пользовательского интерфейса.

2.4

collect

Collections being served from this copy of Greenstone

1.1

lib

исходная программа на C++, используемая как сервером коллекции, так и регистратором

3.1

images

Изображения, используются для пользовательского интерфейса.

docs

Документация


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

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

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

Table 3  Опции для процессов import и build

Аргумент

Функция

-verbosity

Число 0-3

Контроль за тем, сколько данных о процессе значится как стандартная ошибка; 0 - мало, 3 - много.

-archivedir

Имя директории

Указывает на место хранения архивных файлов Greenstone, на то, куда import.pl может их поместить и где buildcol.pl может их найти. По умолчанию используется директория GSDLHOME/collect/col name/archives

-maxdocs

Число >0

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

-collectdir

Имя директории

Указывает на место нахождения коллекции. По умолчанию используется GSDLHOME/collect

-out

Имя файла

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

-keepold

Отсутствует

Не удаляет результат предыдущих запусков процессов import или build; в процессе импорта не удаляет содержимое директории archives', в процессе формирования не очищает содержимое директории building.

—debug

Отсутствует

Печать результатов работы приложений отладки.


Процесс import

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

Table 4  Дополнительные опции для процесса

Аргумент

Функция

-importdir

Имя директории

Указывает на то, где могут быть найдены импортированные документы. По умолчанию: GSDLHOME/collect/coljiame/import.

-removeold

Отсутствует

Очищает содержимое директории archives перед процессом импорта.

-gzip

Отсутствует

Zip архивирует документы Greenstone, полученные в результате процесса импорта (ZIPPlug должен быть включен в список приложений, a gzip должен быть установлен на вашем компьютере).

-groupsize

Число Х

Количество документов, группируемых в один архивный файл Greenstone, по умолчанию 1 (означает 1 документе 1 файл).

—sortmeta

Имя тэга

Сортирует документы в алфавитном порядке по имени тэга метаданных метаданных. Однако, если коллекция имеет более 1 группы в одном архивном файле (т.е. groupsize >1), эта функция будет заблокирована.

-OIDtype

Хэширование

Метод создания ОШ для документов: хэширование содержания, очень или наполнение медленный метод; метод наполнения работает гораздо быстрее и заключается в простом присваивании входящим документам последовательного номера


Figure 5  Пошаговое выполнение процесса import


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

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

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

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

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

Процесс build

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

Table 5  Дополнительные опции для процесса

Аргумент

Функция

-builddir

Имя директории

Определяет, где будет храниться результат формирования (по умолчанию: GSDLHOME/collect/col_name/building).

-index

Индексное имя

Определяет индексы процесса формирования. Данная (например '.Title) процедура по умолчанию присваивает индексы, обозначенные в файле конфигураций коллекции.

-allclassifications

Отсутствует

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

-create_images

Отсутствует

Автоматически создает коллекцию иконок (для пользования этой опцией у вас должны быть установлены GIMP и модуль Gimp Perl).

-mode

all,
compress_text,
infodb, или
build index

Определяет, что должен сделать процесс формирования (по умолчанию all). All производит полное формирование, compress_text только сжатие текста документа, infodb создает базу данных информации, относящейся к коллекции - имя, файлы, связные файлы, классификационная информация и т.п., - build index -формирует индексы, указанные в файле конфигурации колекции или в командной строке.

—no_text

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


Figure 6  Пошаговое выполнение процесса build


На рисунке 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;.

Figure 7 (a)   Формат архива Greenstone: а) Document Type Defini¬tion /Определение типа документа (DTD); б) Пример документа
<!DOCTYPE GreenstoneArchive [
   <!ELEMENT Section (Description,Content,Section*)>
   <!ELEMENT Description (Metadata*)>
   <!ELEMENT Content (#PCDATA)>
   <!ELEMENT Metadata (#PCDATA)>
   <ATTLIST Metadata name CDATA #REQUIRED>
]>

Figure 7 (b)  
<?xml version="1.0"?>
<!DOCTYPE GreenstoneArchive SYSTEM
"http://greenstone.org/dtd/GreenstoneArchive/1.0/GreenstoneArchive.dtd" >
<Section>
   <Description>
       <Metadata name= "gsdlsourcefilename">ec158e.txt</Metadata>
       <Metadata name= "Title">Freshwater Resources in Arid Lands</Metadata>
       <Metadata name= "Identifier">HASH0158f56086efffe592636058</Metadata>
       <Metadata name= "gsdlassocfile">cover.jpg:image/jpeg:</Metadata>
       <Metadata name= "gsdlassocfile">p07a.png:image/png:</Metadata>
   </Description>
   <Section>
       <Description>
           <Metadata name= "Title">Preface</Metadata>
       </Description>
       <Content>
               This is the text of the preface
       </Content>
   </Section>
   <Section>
       <Description>
           <Metadata name= "Title">First and only chapter</Metadata>
       </Description>
       <Section>
           <Description>
               <Metadata name= "Title">Part 1</Metadata>
           </Description>
           <Content>
               This is the first part of the first and only chapter
           </Content>
       </Section>
       <Section>
         <Description>
             <Metadata name= "Title">Part 2</Metadata>
         </Description>
         <Content>
                 This is the second part of the first and only chapter
         </Content>
       </Section>
   </Section>
</Section>

На рисунке 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": данный раздел представлен просто как раздел верхнего уровня.

Table 6  Формат архива Greenstone: Значения для атрибута name тэга Metadata

gsdlsourcefilename

Исходный файл, из которого файлом архива Greenstone был сгенерирован

gsdlassocfile

Файл, связанный с документом (например, файл изображения)


Открывающий тэг <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.

Table 7  Dublin Core metadata standard

Имя

Подтэг
метаданных

Описание

*Title

Title

Имя ресурса

*Creator

Creator

Лицо, ответственное за формирование содержимого ресурса

*Subject and keywords

Subject

Тема содержимого ресурса

*Description

Description

Описание содержания ресурса

*Publisher

Publisher

Лицо, ответственное за доступ к ресурсу

Contributor

Contributor

Лицо, ответственное за пополнение содержимого ресурса

*Date

Date

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

Resource type

Type

Характер или жанр содержимого ресурса

Format

Format

Физическое или цифровое представление ресурса

*Resource identifier

Identifier

Однозначная ссылка на ресурс это может быть идентификатор объекта или OID

*Source

Source

Ссылка на источник, из которого был получен ресурс

*Language

Language

Язык содержимого ресурса

Relation

Relation

Ссылка на связный ресурс

*Coverage

Coverage

Область охвата содержимого ресурса

Rights

Rights

Информация о праве владенияи распространения ресурса management


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.

Figure 8 (a)   Иерархическая структура Демонстрационной коллекции


Figure 8 (b)   Иерархическая структура Демонстрационной коллекции


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

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

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

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

Table 8  Элементы файла конфигурации коллекции
creator

E-mail создателя коллекции

maintainer

E-mail службы поддержки коллекции

public

Должна ли быть опубликована коллекция

beta

Является ли настоящая публикация beta-версией коллекции

indexes

Список индексов формирования

defaultindex

Индексы по умолчанию

subcollection

Определяет коллекцию, основанную на метаданных

indexsubcollections

Указывает на подколлекцию для индексирования

defaultsubcollection

Индексы по умолчанию для подколлекций

languages

Список языков для индексирования

defaultlanguage

Язык для индексирования, установленный по умолчанию

collectionmeta

Определяет метаданные на уровне коллекции

plugin

Определяет приложения, участвующие в процессе формирования

format

Строковый формат (объяснение следует)

classify

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


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

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

Table 9  Файл конфигурации колекции, созданный mkcd.pl

Атрибут

Значение

1
creator

username@email.com

2
maintainer

username@email.com

3
public

True

4
beta

True

5
indexes

document:text

6
defaultindex

document:text

7
plugin

ZIPPlug

8
plugin

GAPlug

9
plugin

TextPlug

10
plugin

HTMLPlug

11
plugin

EMAILPlug

12
plugin

ArcPlug

13
plugin

RecPlug

14
classify

AZList metadata Title

15
collectionmeta

collectionname "sample collection"

16
collectionmeta

iconcollection ""

17
collectionmeta

collectionextra ""

18
collectionmeta

.document:text "documents"


Строка 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 для разных языков путём добавления спецификации языка в квадратные скобки. Например,

collectionmeta collectionextra "collection description"

collectionmeta collectionextra [l=fr] "description in French"

collectionmeta collectionextra [l=mi] "description in Maori"

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

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

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

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

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

indexes section:text
subcollection fn "Title/^Food and Nutrition Bulletin/i "
subcollection other "!Title/^Food and Nutrition Bulletin/i "
indexsubcollections fn other fn,other

Вторая и третья строки определяют следующие подколлекции: с именем 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 (маори). Так как значения метаданных могут быть определены на уровне раздела, отдельные части документа могут быть представлены на разных языках.

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

indexes section:text section:Title document:text paragraph:text
languages en zh mi

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

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

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

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

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

supercollection col _1 col _2 ….

где коллекции, вовлеченные в поиск, именуются 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.

Table 10  Опции, применяемые для всех приложений
input_encoding

Кодировка символов исходных документов. Значение по умолчанию должно автоматически решить проблему кодировки для каждого индивидуального документа. Иногда полезно установить это значение, хотя, например, если вы точно знаете, что все ваши документы находятся в ASCII, установка входной кодировки ascii значительно увеличивает скорость импорта и формирования вашей коллекции. Существует множество допустимых значений. Для получения их полного списка воспользуйтесь pluginfo.pl BasPlug.

default_encoding

Кодировка, которая используется в случае, если для опции input encoding установлено значение auto или обнаружены сбои автоматического кодирования.

process_exp

Обычное Perl-выражение для согласования имен файлов (например, для определения местонахождения файлов с определенным расширением). Оно указывает на файл, который обрабатывается приложением . Каждое приложение имеет значение по умолчанию (значение по умолчанию HTMLPlug - (? i) .html? - т.е. файл с раширением .htm или .html).

block_exp

Обычное выражение для согласования имен файлов, которые не должны быть переданы последующим приложениям. Это может предотвратить появление сообщений об ошибках в файлах, которыми вы не интересуетесь. Некоторые приложения по умолчанию имеют выражения блокирования значения, например, HTMLPlug блокирует файлы с расширениями .gif .jpg .jpeg .png .rtf и .css расширениями.

cover_image

Ищет jpg файл (с таким же именем, что и обрабатываемый файл) и связывает его с документом в качестве обложки.

extract_acronyms

Extract acronyms from documents and add them as metadata to the corresponding Greenstone archive documents.

markup_acronyms

Добавляет информацию об аббревиатуре в текст документа.

extract_language

Identify each document's language and associate it as metadata. Note that this is done automatically if input_encoding is auto.

default_language

В случае сбоя при автоматическом определении языка метаданные установят это значение.

first

Извлекает участок текста, заключенный между запятыми, как метаданные FirstNNN (часто используется в качестве замены для Title).

extract_email

Извлекает адрес электронной почты и добавляет его в качестве метаданных документа

extract_date

Извлекает из документов даты, касающиеся исторических событий, и добавляет их в качестве метаданных Coverage.


Приложения Greenstone

Table 11  Greenstone plugins

Цель

Типы файлов

Игнорируемые файлы

Общие

ArcPlug

Обработка файлов указанных в файле archives.inf которые используются для связи процессов импорта и формирования. Должен быть включен(если import.pl не будет использоваться).

RecPlug

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

GAPlug

Обрабатывает сгенерированные import.plфайлы архива Greenstone. Должен быть включен (если import.pl не будет использован).

.xml

TEXTPlug

Обрабатывает текст, помещая его между тэгами (предформатная обработка).

.txt, .text

HTMLPlug

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

.htm, .html, .cgi, .php, .asp, .shm, .shtml

.gif, .jpeg, .jpg, .png, .css, .rtf

WordPlug

Обрабатывает документы Microsoft Word, извлекает данные об авторе и заголовке и сохраняет диаграммы и изображения в надлежащих местах. Конверсионные утилиты, используемые этим приложением, иногда создают HTML, который плохо отформатирован. Мы рекомендуем, чтобы для просмотра Вы предоставляли оригиналы документа, если формируете свою коллекцию из файлов WORD. Текст, который извлекается из докумета, является адекватным для поиска и целевого индексирования.

.doc

.gif, .jpeg, .jpg, .png, .css, .rtf

PDFPlug

Обрабатывает PDF документы, извлекая первую линию текста, как заголовок. Рdftohtml программа терпит неудачу с некоторыми PDF файлами. В этом случае процесс конвертации занимает необычно долгое время, и зачастую, на экране появляется сообщение об ошибке. Если это происходит, единственное решение, которое мы можем предложить – удалить этот документ из коллекции и попытаться имопртировать снова.

.pdf

.gif, .jpeg, .jpg, .png, .css, .rtf

PSPlug

Обработка документов PostScript, производится извлечение метаданных: даты, заголовка и номера страниц.

.ps

.eps

EMAILPlug

Обработка E-mail сообщений путем распознания автора, темы, даты и т.д. Данное приложение пока не обрабатывает должным образом сообщения в кодировке MIME - зачастую они выглядят несколько странно.

Должен заканчиваться цифрами или цифрами, заканчивающимися .Email

BibTexPlug

Обработка файлов библиографии в формате BibText

.bib

ReferPlug

Обработка файлов библиографии в формате refer

.bib

SRCPlug

Обработка исходных программ

Makefile, Readme, .c, .cc, .cpp, .h, .hpp, .pl, .pm, .sh

.o, .obj, .a, .so, .dll

ImagePlug

Обработка файлов изображений для создания библиотеки изображений. Работает только в UNIX.

.jpeg, .jpg, .gif, .png, .bmp, .xbm, .tif, .tiff

SplitPlug

Подобно BasPlug и ConvertToPlug, данное приложение не может быть вызвано непосредственно, однако оно может последовать за byplugins в случае, если требуется обработка файла, содержащего несколько документов.

FOXPlug

Обработка файлов dbt FoxBASE

.dbt, .dbf

ZIPPlug

Разархивация gzip, bzip, zip и tar файлов, если доступны соответствующие средства GNU.

.gzip, .bzip, .zip, .tar, .gz, .bz, .tgz, .taz

Особенности
коллекции

PrePlug

Обработка конечной HTML, используя PRESCRIPT, разбиение документов на страницах коллекции Computer Science Technical Reports.

.html, .html.gz

GBPlug

Обработка E-text (электронного текста) Project Gutenberg (Проекта Гутенберг), включающая ручной ввод информации о заголовках.

.txt.gz, .html, .htm

TCCPlug

Обработка E-mail документов, поступивших от еженедельника Computists’ Weekly

Обязана начинаться с tcc или cw


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

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

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

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

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

Table 12  Опции, специфичные для приожений

Опция

Цель

HTMLPlug

nolinks

Не обрывать ссылки внутри коллекции. Это ускоряет процессы импорта/формирования, однако некоторые ссылки могут быть оборваны.

description_tags

Интерпретировать файлы документа, как описано ниже.

keep_head

Не отбрасывать заголовки HTML.

no_metadata

Не искать метаданные (это может увеличить скорость процессов импорта/формирования).

metadata_fields

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

hunt_creator_metadata

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

file_is_url

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

assoc_files

Представить обычное выражение на языке Perl, описывающее типы файлов, которые будут использованы как связные файлы. По умолчанию это .jpg, .jpeg, .gif, .png, .css

rename_assoc_files

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

HTMLPlug and
TEXTPlug

title_sub

Выражение замены на языке Perl для изменения заголовков.

PSPlug

extract_date

Извлечь дату создания из заголовка PostScript и сохранить как метаданные.

extract_title

Извлечь заголовок документа из заголовка PostScript и сохранить как метаданные заголовка.

extract_pages

Извлечь номера страниц из документа PostScript и добавить их к соответствующим разделам как метаданные с тэгом Pages.

RecPlug

use_metadata_files

Назначить метаданные для файла, как описано ниже.

ImagePlug

Various options

См. ImagePlug.pm.

SRCPlug

remove_prefix

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


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

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

Figure 9  Иерархическая структура наследования приложений


Когда 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.

Figure 10 (a)   Формат XML. a) Document Type Definition (DTD); б) пример файла
<!DOCTYPE GreenstoneDirectoryMetadata [
<!ELEMENT DirectoryMetadata (FileSet*)>
<!ELEMENT FileSet (FileName+,Description)>
<!ELEMENT FileName (#PCDATA)>
<!ELEMENT Description (Metadata*)>
<!ELEMENT Metadata (#PCDATA)>
<ATTLIST Metadata name CDATA #REQUIRED>
<ATTLIST Metadata mode (accumulate|override) "override">
]>

Figure 10 (b)  
<?xml version="1.0" ?>
<!DOCTYPE GreenstoneDirectoryMetadata SYSTEM
"http://greenstone.org/dtd/GreenstoneDirectoryMetadata/
1.0/GreenstoneDirectoryMetadata.dtd">
<DirectoryMetadata>
<FileSet>
<FileName>nugget.*</FileName>
<Description>
<Metadata name="Title">Nugget Point Lighthouse</Metadata>
<Metadata name="Place" mode="accumulate">Nugget Point</Metadata>
</Description>
</FileSet>
<FileSet>
<FileName>nugget-point-1.jpg</FileName>
<Description>
<Metadata name="Title">Nugget Point Lighthouse , The Catlins </Metadata>
<Metadata name="Subject">Lighthouse</Metadata>
</Description>
</FileSet>
</DirectoryMetadata>

В примере показан файл, который содержит две структуры метаданных. В каждой из которых, элемент 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, которая обрабатывает тэги в тексте:

<!--
<Section>
<Description>
<Metadata name="Title"> Realizing human rights for poor people: Strategies for achieving the international development targets</Metadata>
</Description>
-->

(text of section goes here)

<!--
</Section>
-->

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

(text of first part of section goes here)

<!--
<Section>
<Description>
<Metadata name="Title"> The international development targets</Metadata>
</Description>
-->

(text of subsection goes here)

<!--
</Section>
-->

(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.

Figure 11  Классификатор AZList


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

Figure 12  Классификатор List


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

Figure 13  Классификатор DateList


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

Figure 14  Классификатор Hierarchy


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

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

Table 13  Классификаторы Greenstone

Аргумент

Действие

Hierarchy

Иерархическая классификация

hfile

Файл классификации

metadata

Элемент метаданных для тестирования вопреки идентификатору hfile

sort

Элемент метаданных, сортирующий документы в пределах листа (по умолчанию - Title)

buttonname

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

List

Алфавитный список документов

metadata

Включение документов, содержащих этот элемент метаданных

buttonname

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

SectionList

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

AZList

Список документов, разбитых на алфавитные диапазоны

metadata

Включение всех документов, содержащих этот элемент метаданных

buttonname

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

AZSectionList

Подобно AZList,но включает все разделы документов

DateList

Подобно AZList, но сортирует по дате


Текущий набор классификаторов представлен в Таблице 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.

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

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

Figure 15  Part of the file sub.txt
1 1 "General reference"
1.2 1.2 "Dictionaries, glossaries, language courses, terminology
2 2 "Sustainable Development, International cooperation, Pro
2.1 2.1 "Development policy and theory, international cooperatio
2.2 2.2 "Development, national planning, national plans"
2.3 2.3 "Project planning and evaluation (incl. project managem
2.4 2.4 "Regional development and planning incl. regional profil
2.5 2.5 "Nongovernmental organisations (NGOs) in general, self-
2.6 2.6 "Organisations, institutions, United Nations (general, d
2.6.1 2.6.1 "United Nations"
2.6.2 2.6.2 "International organisations"
2.6.3 2.6.3 "Regional organisations"
2.6.5 2.6.5 "European Community - European Union"
2.7 2.7 "Sustainable Development, Development models and example
2.8 2.8 "Basic Human Needs"
2.9 2.9 "Hunger and Poverty Alleviation"

Аргумент 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, создаст информационную базу данных.

Table 14  Элементы “формата строки”

[Text]

Текст документа

[link] … [/link]

HTML для связи непосредственно с документом

[icon]

Соответствующая иконка (например, небольшая текстовая иконка в строке Search Results)

[num]

Номер документа (используется для отладки).

[metadata-name]

Значение этого элемента метаданных для документа, например [Title]


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

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

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

Table 15  Опции format

format DocumentImages true/false

Если true, отображает рисунок обложки в верхнем левом углу страницы документа (по умолчанию -false)

format DocumentHeading formatstring

formatstring Если Documentlmages - false, формат строки контролирует отображение заголовка в верхней левой части страницы (по умолчанию [Title]).

format DocumentContents true/false

Если документ имеет иерархию, то показывает содержание, если нет, то стрелки next /previous section (к следующему/ предыдущему разделу) и текст “page k of n” (страница № k из n).

format DocumentButtons string

Контролирует кнопки меню на странице документа (по умолчанию Detach\Highlighf).

format DocumentText formatstring

Форматирует текст, отображаемый на странице документа: по умолчанию

<center><table width=537>
      <tr><td>[Text]</td></tr>
      </table></center>

format DocumentArrowsBottom true/false

Отображает стрелки next/previous section (к следующему/ предыдущему разделу) в конце страницы документа (по умолчанию true)

format DocumentUseHTML true/false

Если true, каждый документ отображается в отдельном фрейме. Preferences page (страница выбора) тоже слегка именится, добавятся опции, применимые к совокупности коллекции HTML-документов, включая возможность непосредственного перехода к исходному документу (где-нибудь в Web), а не к копии Greenstone.


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

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

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

format CL4VList ... применяет ко всем VLists в CL4

format CL2HList ... применяет ко всем HLists в CL2

format CL1DateList ... применяет ко всем DateLists в CL1

format SearchVList ... применяет ко всем Search Results list

format CL3 ... применяет ко всем узелкам в CL3, если дополнительно не определено

format VList ... применяет ко всем VLists во всех классификаторах, если не определено дополнительно.

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

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

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

Figure 16  Выборка из файла collectcfg Демонстрационной коллекци
1  
classify Hierarchy -hfile sub.txt -metadata Subject -sort Title
2  
classify AZList -metadata Title
3  
classify Hierarchy -hfile org.txt -metadata Organisation -sort Title
4  
classify List -metadata Howto
5  
format SearchVList " <td valign=top [link][icon][/link]</td><td>{If}
6  
{[parent(All':'):Title],[parent(All':'):Title]:}
7  
[link][Title][/link]</td> "
8  
format CL4Vlist "<br>[link][Howto][/link] "
9  
format DocumentImages true
10  
format DocumentText "<h3>[Title]</h3>\\n\\n<p>[Text]"
11  
format DocumentButtons " Expand Text|Expand contents|Detach|Highlight"

На рисунке 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 имеет встроенные значения по умолчанию для каждого типа строки формата и поэтому нет необходимости устанавливать строку формата, если Вы не собираетесь отменять значение по умолчанию.

Figure 17  Форматирование документа


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

Figure 18  Форматирование результатов поиска


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

<td valign=top>[link][icon][/link]</td>
<td>[link][Title][/link]</td>

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

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

<td valign=top>[link][icon][/link]</td>
<td>{[parent(All': '):Title]: }[link][Title][/link]</td>

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

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

{If}{[metadata], action-if-non-null, action-if-null}
{Or}{action, else another-action, else another-action, etc}

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

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

<td valign=top>[link][icon][/link]</td>
<td>{If}{[parent(All': '):Title],
[parent(All': '):Title]:}
[link][Title][/link]</td>

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

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

classify AZSectionList metadata=Creator
format CL2Vlist "<td>[link][icon][/link]</td>
<td>[Creator]</td>
<td>&nbsp;&nbsp;[Title]</td>
<td>[parent(Top):Date]</td> "

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

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

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

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

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

[link][Title][/link]

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

[srclink][Title][/srclink]

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

[srclink][srcicon][/srclink]

Оно создает ссылку, которая будет отменена стандартной иконкой 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 определяет содержание страницы, если отсутствует какая-либо макрокоманда отмены:

_content_ {<p><h2>Oops</h2>_textdefaultcontent_}

Страница будет читать "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, потому что они запрашиваются всеми частями пользовательского интерфейса. Макросы могут использовать макросы из других пакетов, но тогда они должны содержать в префиксе их имена и имя пакета. Например,

_collectionextra_ {This collection contains _about:numdocs_ documents. It was last built _about:builddate_ days ago.)

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

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

_imagecollection_ {
_If_( "_iconcollection_ " ne "",
<a href = "_httppageabout_ ">
<img src = "_iconcollection_ " border = 0>
</a>,
_imagecollectionv_)
}

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

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

_imagecollection_[v=1]{_imagecollectionv_}

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

_textimagehome_ {Home Page}

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

_textimagehome_ [l=de] {Hauptaseite}

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

Figure 19  Part of the about.dm macro file
package about
##############################################
# about page content
###############################################
_pagetitle_ {_collectionname_}
_content_ {
<center>
_navigationbar_
</center>
_query:queryform_
<p>_iconblankbar_
<p>_textabout_
_textsubcollections_
<h3>_help:textsimplehelpheading_</h3>
_help:simplehelp_
}
_textabout_ {
<h3>_textabcol_</h3>
_Global:collectionextra_
}

В заключение приведем рисунок 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

Table 16  Директория packages

Пакет

URL

mg

MG, сокращенно от “Managing Gigabytes.” Сжатие, программное обеспечение индексирования и поиска использовалось для управления текстовой информацией в коллекциях Greenstone.

www.citri.edu.au/mg

wget

Программное обеспечение web зеркалирования для Greenstone. Написано на C++.

www.tuwien.ac.at/~prikryl/ wget.html

w3mir

Программа web-зеркалирования, написанная на Perl. Не является предпочтительной программой зеркалирования Greenstone, потому что основана на определенной устарелой версии некоторого Perl-модуля (который представлен в директории w3mir). Пакеты используются при запуске под Windows.

www.math.uio.no/~janl/w3mir

windows

Пакеты используются при запуске под Windows.

windows/gdbm

Версия GNU Database Manager для среды Windows. GDBM является стандартной частью Linux.

windows/crypt

Программа кодирования для создания паролей на уровне администрирования Greenstone.

windows/stlport

Standard Template Library (Стандартная библиотека шаблонов) используется при компиляции Greenstone совместно с некоторыми компиляторами Windows.

wv

Конвертер Microsoft Word (для формирования коллекций из документов формата Word).

sourceforge.net/projects/ wvware

pdftohtml

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

www.ra.informatik.uni-stutt gart.de/
~gosho/pdftohtml

yaz

Z39.50 программа клиента, используемая для исследования совместимости Greenstone с Z39.50. О прогрессе сообщают в файле README.gsdl.

www.indexdata.dk


Директория 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 Структура процесса

Figure 20  Краткий обзор работы системы Greenstone


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

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

Figure 21  Система Greenstone, использующая нулевой протокол


Как показано на рисунке 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, могут быть полностью осуществлены со всеми регистраторами и серверами коллекции, работающими на различных компьютерах.

Figure 22  Графический интерфейс запроса Greenstone


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

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

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

Figure 23  Генерация страницы "about this collection"


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

Для коллекции Проект Gutenberg (c=gberg) действие генерирует страницу (а=р), сгенрированная страница названа "about" (p=about).

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


Рисунок 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.

Поиск

Figure 25  Поиск по запросу Darcy в коллекции Gutenberg


Когда пользователь вводит запрос, нажимая кнопку 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.

Figure 26  The Golf Course Mystery


Исходный текст для коллекции 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. В данном примере она представляет заголовки, сгруппированные символом К. Этот список был сформирован во время компановки и сохранен в информационной базе данных коллекции.

Figure 27  Просмотр заголовков коллекции Gutenberg


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

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

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

Generating the home page

Figure 28  Генерация домашней страницы


В качестве последнего примера мы рассмотрим создание домашней страницы 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 Исходный код

Table 17  Независимые программы, включённые в Гринстоун

setpasswd/

Поддержка пароля для Windows

getpw/

Поддержка пароля для Юникса

txt2db/

Конвертировать текстовой ASCII формат, подобный XML, в формат базы данных Gnu

db2txt/

Конвертировать формат базы данных Gnu в текстовой ASCII формат, подобный XML.

phind/

Инструмент для просмотра иерархической фразы

hashfile/

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

mgpp/

Переписанная и обновлённая версия Managing Gigabytes пакета в C++.

w32server/

Локальный сервер библиотеки для Windows.

checkis/

Специфическая поддержка для инсталляции Гринстоун в Windows.


Исходный код для работающей системы находится в 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.

Figure 29  text_t API (в сокращены)
1  
typedef vector<unsigned short> usvector;
2  
3  
class text_t {
4  
protected:
5  
usvector text;
6  
unsigned short encoding; // 0 = unicode, 1 = other
7  
8  
public:
9  
// constructors
10  
text_t ();
11  
text_t (int i);
12  
text_t (char *s); // assumed to be a normal c string
13  
14  
void setencoding (unsigned short theencoding);
15  
unsigned short getencoding ();
16  
17  
// STL container support
18  
iterator begin ();
19  
iterator end ();
20  
21  
void erase(iterator pos);
22  
void push_back(unsigned short c);
23  
void pop_back();
24  
25  
void reserve (size_type n);
26  
27  
bool empty () const {return text.empty();}
28  
size_type size() const {return text.size();}
29  
30  
// added functionality
31  
void clear ();
32  
void append (const text_t &t);
33  
34  
// support for integers
35  
void appendint (int i);
36  
void setint (int i);
37  
int getint () const;
38  
39  
// support for arrays of chars
40  
void appendcarr (char *s, size_type len);
41  
void setcarr (char *s, size_type len);
42  
};

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, и возвращения соответствующего целочисленного значения текста, который представляет номер.

Figure 30  Перегруженные операторы text_t
1  
class text_t {
2  
// ...
3  
public:
4  
text_t &operator=(const text_t &x);
5  
text_t &operator+= (const text_t &t);
6  
reference operator[](size_type n);
7  
8  
text_t &operator=(int i);
9  
text_t &operator+= (int i);^ \\
10  
text_t &operator= (char *s);
11  
text_t &operator+= (char *s);
12  
13  
friend inline bool operator!=(const text_t& x, const text_t& y);
14  
friend inline bool operator==(const text_t& x, const text_t& y);
15  
friend inline bool operator< (const text_t& x, const text_t& y);
16  
friend inline bool operator> (const text_t& x, const text_t& y);
17  
friend inline bool operator>=(const text_t& x, const text_t& y);
18  
friend inline bool operator<=(const text_t& x, const text_t& y);
19  
// ...
20  
};

Существует множество перегруженных операторов , которые не показаны на рисунке 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. Для большей части подробности выполнения содержатся в копии файла заголовка .срр.

cfgread.h

Функции для чтения и записи файла конфигурации. Например, read_cfg_line () как аргумент для использования берет входной поток и text_tarray (обработанный для vector<text_t>), чтобы заполнить данными для чтения.

display.h

Сложный объект, используемый регистратором для установки, хранения и расширения макроса, плюс поддержки типов. Подробности вы можете найти в Разделе 3.8.

fileutil.h

Функция поддержки независимости нескольких файловых утилит в операционной системе. Например, fllename_cat () берет до шести text_t параметров и возвращает textjt, который является результатом связывания элементов, используя соответствующий директивный разделитель для текущей операционной системы.

gsdlconf.h

Системно-специфические функции, которые отвечают на вопросы типа: операционная система, используемая для трансляции, должна обратиться к strings.h так же, как string.ht Действительно ли все соответствующие значения для закрытия файла, правильно определенного?

gsdltimes.h

Функция поддержки дат и времени. Например, time2text () берет компьютерное время, выраженное в количестве секунд, которые прошли с 1 января 1970, конвертирует их в форму YYYY/MM/DD (ГГГГ/ММ/ДД), hh:mm:ss (чч:мм:сс) и возвращает как тип textjt.

gsdltools.h

Различная поддержка работы системы Greenstone: объясняет, если HttleEndian или bigEndian; проверяет, доступен ли Perl; выполняет системную команду (с несколькими ненужными свойствами программы) и избавляет от специальных макросимволов в text_t строке.

gsdlunicode.h

Ряд унаследованных объектов, которые поддерживают обработку Unicode text_t строки через потоки Ю, типа Unicode к UTF-8 и наоборот; удаление пространств нулевой ширины. Поддержка тар-файлов обеспечена через объект mapconvert с распределениями, загруженными из GSDLHOME/mappings.

text_t.h

Прежде всего это объект текста Unicode, описанный выше. Но также обеспечивает два класса для преобразования потоков: inconvertclass и outconvertclass. Это - базовые классы, используемые в gsdlunicode.h.


3.6 Collection server

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

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

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

Объект Search

Figure 31  Search базовый класс API
class searchclass {
public:
searchclass ();
virtual ~searchclass ();
// the index directory must be set before any searching
// is done
virtual void setcollectdir (const text_t &thecollectdir);
// the search results are returned in queryresults
// search returns 'true' if it was able to do a search
virtual bool search(const queryparamclass &queryparams,
queryresultsclass &queryresults)=0;
// the document text for 'docnum' is placed in 'output'
// docTargetDocument returns 'true' if it was able to
// try to get a document
// collection is needed to see if an index from the
// collection is loaded. If no index has been loaded
// defaultindex is needed to load one
virtual bool docTargetDocument(const text_t &defaultindex,
const text_t &defaultsubcollection,
const text_t &defaultlanguage,
const text_t &collection,
int docnum,
text_t &output)=0;
protected:
querycache *cache;
text_t collectdir; // the collection directory
};

Рисунок 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 использует методы сжатия, чтобы максимально использовать место на диске, не ставя под угрозу скорость выполнения. Для коллекции документов на английском языке сжатый текст и полный текст индексируются вместе и оычно занимают одну треть места, занимаемого несжатым текстом. Поиск и исправление часто происходят быстрее, чем подобное действие на несжатой версии, потому что производится меньше дисковых операций.

Figure 32  API для прямого доступа к MG (сокращенный вариант)
enum result_kinds {
result_docs, // Return the documents found in last search
result_docnums, // Return document id numbers and weights
result_termfreqs, // Return terms and frequencies
result_terms // Return matching query terms
};
int mgq_ask(char *line);
int mgq_results(enum result_kinds kind, int skip, int howmany,
int (*sender)(char *, int, int, float, void *),
void *ptr);
int mgq_numdocs(void);
int mgq_numterms(void);
int mgq_equivterms(unsigned char *wordstem,
int (*sender)(char *, int, int, float, void *),
void *ptr);
int mgq_docsretrieved (int *total_retrieved, int *is_approx);
int mgq_getmaxstemlen ();
void mgq_stemword (unsigned char *word);

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

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

mgq_ask( ".set casefold off ");

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

Обьект Source

Figure 33  Source базовый класс API
class sourceclass {
public:
sourceclass ();
virtual ~sourceclass ();
// configure should be called once for each configuration line
virtual void configure (const text_t &key, const text_tarray &cfgline);
// init should be called after all the configuration is done but
// before any other methods are called
virtual bool init (ostream &logout);
// translate_OID translates OIDs using " .pr " , . " fc " etc.
virtual bool translate_OID (const text_t &OIDin, text_t &OIDout, comerror_t &err, ostream &logout);
// get_metadata fills out the metadata if possible, if it is not
// responsible for the given OID then it return s false.
virtual bool get_metadata (const text_t &requestParams, const text_t &refParams,
bool getParents, const text_tset &fields, const text_t &OID,
MetadataInfo_tmap &metadata, comerror_t &err, ostream &logout);
virtual bool get_document (const text_t &OID, text_t &doc,
comerror_t &err, ostream &logout);
};

Роль 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. Операции включают хранение, исправление и удаление записей по ключу, а также пресечение всех незаказанных ключей.

Figure 34  GDBM база данных для коллекции Gutenberg (фрагмент)
[HASH01d7b30d4827b51282919e9b]
<doctype> doc
<hastxt> 0
<Title> The Winter's Tale
<Creator> William Shakespeare
<archivedir> HASH01d7/b30d4827.dir
<thistype> Invisible
<childtype> Paged
<contains> " .1; " .2; " .3; " .4; " .5; " .6; " .7; " .8; " .9; " .10; " .11; " .12; \
" .13; " .14; " .15; " .16; " .17; " .18; " .19; " .20; " .21; " .22; \
" .23; " .24; " .25; " .26; " .27; " .28; " .29; " .30; " .31; " .32; \
" .33; " .34; " .35
<docnum> 168483
———————————————————————-
[CL1]
<doctype> classify
<hastxt> 0
<childtype> HList
<Title> Title
<numleafdocs> 1818
<thistype> Invisible
<contains> " .1; " .2; " .3; " .4; " .5; " .6; " .7; " .8; " .9; " .10; " .11; " .12; \
" .13; " .14; " .15; " .16; " .17; " .18; " .19; " .20; " .21; " .22; \
" .23; " .24
———————————————————————-
[CL1.1]
<doctype> classify
<hastxt> 0
<childtype> VList
<Title> A
<numleafdocs> 118
<contains> HASH0130bc5f9f90089b3723431f;HASH9cba43bacdab5263c98545;\
HASH12c88a01da6e8379df86a7;HASH9c86579a83e1a2e4cf9736; \
HASHdc2951a7ada1f36a6c3aca;HASHea4dda6bbc7cdeb4abfdee; \
HASHce55006513c47235ac38ba;HASH012a33acaa077c0e612b9351;\
HASH010dd1e923a123826ae30e4b;HASHaf674616785679fed4b7ee;\
HASH0147eef4b9d1cb135e096619;HASHe69b9dbaa83ffb045d963b;\
HASH01abc61c646c8e7a8ce88b10;HASH5f9cd13678e21820e32f3a;\
HASHe8cbba1594c72c98f9aa1b;HASH01292a2b7b6b60dec96298bc;\
...

Рисунок 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

Figure 35  API для sourceclass базовой версии MG и GDBM (сокращенный вариант)
class mggdbmsourceclass : public sourceclass {
protected:
// Omitted, data fields that store:
// collection specific file information
// index substructure
// information about parent
// pointers to gdbm and mgsearch objects
public:
mggdbmsourceclass ();
virtual ~mggdbmsourceclass ();
void set_gdbmptr (gdbmclass *thegdbmptr);
void set_mgsearchptr (searchclass *themgsearchptr);
void configure (const text_t &key, const text_tarray &cfgline);
bool init (ostream &logout);
bool translate_OID (const text_t &OIDin, text_t &OIDout,
comerror_t &err, ostream &logout);
bool get_metadata (const text_t &requestParams,
const text_t &refParams,
bool getParents, const text_tset &fields,
const text_t &OID, MetadataInfo_tmap &metadata,
comerror_t &err, ostream &logout);
bool get_document (const text_t &OID, text_t &doc,
comerror_t &err, ostream &logout);
};

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

Объект Filter

Figure 36  API for the Filter base class
class filterclass {
protected:
text_t gsdlhome;
text_t collection;
text_t collectdir;
FilterOption_tmap filterOptions;
public:
filterclass ();
virtual ~filterclass ();
virtual void configure (const text_t &key, const text_tarray &cfgline);
virtual bool init (ostream &logout);
// returns the name of this filter
virtual text_t get_filter_name ();
// returns the current filter options
virtual void get_filteroptions (InfoFilterOptionsResponse_t &response,
comerror_t &err, ostream &logout);
virtual void filter (const FilterRequest_t &request,
FilterResponse_t &response,
comerror_t &err, ostream &logout);
};

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

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

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

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

Figure 37  Как хранится опция filter
struct FilterOption_t {
void clear (); \ void check_defaultValue ();
FilterOption_t () {clear();}
text_t name;
enum type_t {booleant=0, integert=1, enumeratedt=2, stringt=3};
type_t type;
enum repeatable_t {onePerQuery=0, onePerTerm=1, nPerTerm=2};
repeatable_t repeatable;
text_t defaultValue;
text_tarray validValues;
};
struct OptionValue_t {
void clear ();
text_t name;
text_t value;
};

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

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

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

Figure 38  Иерархия наследования Filter


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

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

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

browsefilter.h

Унаследованный mfilterdass, этот объект обеспечивает доступ к GDBM (Описан выше).

collectserver.h

Этот объект связывает вместе Filters и Sources для одной коллекции, формируя объект Collection, показанный на рисунке 24.

colservrconfig.h

Функциональная поддержка для чтения определенных коллекцией файлов etc/'collect, cfg и index/build, cfg. Первый из них - файл конфигурации коллекции. Последний - файл, сгенерированный процессом формирования, который делает запись времени последней успешной компоновки, карту индексного списка, показывает сколько документов было индексировано и как сколько байт они занимают (в распакованном виде).

filter.h

Объект базового класса Filter fllterclass описан выше.

maptools.h

Определяет класс, названный stringmap, который обеспечивает отображение и быстрый просмотр, помнит первоначальный порядок карты text_t. Использется в mggdbmsourceclass и query'fllterclass.

mggdbmsource.h

Унаследованный от sourcedass, этот объект предоставляет доступ к MG и GDBM (описан выше).

mgppqueryfilter.h

Унаследованный от query'filterclass, этот объект обеспечивает выполнение QueryFilter, основанного на MG++, улучшенной версии MG, написанной на C++. Обратите внимание, что Greenstone установлены, чтобы использовать MG по умолчанию, так как MG++ находится все еще в развитии.

mgppsearch.h

Унаследованный от searchclass, этот объект обеспечивает выполнение Search /Поиска, используя MG++. Подобно mgppqueryfllterclass, он не используется по умолчанию.

mgq.h

Интерфейс функционального уровня к пакету MG. Основные функции mg_ask() и mg_results().

mgqueryfilter.h

Унаследованный от queryfllterclass, этот объект обеспечивает выполнениеОиегуРШег, основанного на MG.

mgsearch.h

Унаследованный от searchclass, этот объект обеспечивает выполнение Search, используя MG (описан выше.)

phrasequeryfilter.h

Унаследованный от mgqueryclass, этот объект обеспечивает выполнение запроса, основанного на фразе. Он не используется в заданной по умолчанию инсталляции. Вместо этого mgqueryfllterclass обеспечивает эту возможность через функциональную поддержку от phrasesearch.h.

phrasesearch.h

Функциональная поддержка проведения поиска по фразе, как операция постобработки.

querycache.h

Используется searchclass и его унаследованными классами для кэширования результатов запроса, при генерации страниц поисковых результатов наиболее эффективен (описан выше.)

queryfilter.h

Унаследованный от базового класса Filter filterclass, этот объект основывает базовый класс для объектов Query filter (описан выше.)

queryinfo.h

Поддержка поиска: структуры данных и объекты содержат параметры запроса, результаты поиска документа и частоту встречаемости термина.

search.h

Базовый класс Search объект searchclass (описан выше.)

source.h

Базовый классЗоигсе объект sourceclass (описан выше.)


3.7 Протокол

Table 18  Список запросов протокола

get_protocol_name()

Возвращает имя этого протокола. Выборы включают nullproto, corbaproto и z3950proto. Используется во время работы системы чувствительными к протоколу частями, чтобы решить, какие программы запустить на выполнение.

get_collection_list()

Возвращает список коллекций, о которых этот протокол имеет сведения.

has_collection()

Возвращает значение истины, если протокол может связаться с названной коллекцией, то есть это - в пределах списка коллекции.

ping()

Возвращает значение истины, если успешно была установлена связь с названной коллекцией. В нулевом протоколе выполнение идентично has_collection().

get_collectinfo()

Получает общую информацию о названной коллекции: когда она была сформирована, сколько документов она содержит и т.д. Также включает метаданные файла конфигурации коллекции: текст для страницы"аЪои1 this collection"; иконку коллекции и т.д.

get_filterinfo()

Получает список всех Filters для названной коллекции. get

get_filteroptions()

Получает все варианты для специфического Filter в пределах названной коллекции.

filter()

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

get_document()

Получает документ или раздел документа.


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

Figure 39  Нулевой протокол API (сокращенный вариант)
class nullproto : public recptproto {
public:
virtual text_t get_protocol_name ();
virtual void get_collection_list (text_tarray &collist,
comerror_t &err, ostream &logout);
virtual void has_collection (const text_t &collection,
bool &hascollection,
comerror_t &err, ostream &logout);
virtual void ping (const text_t &collection,
bool &wassuccess,
comerror_t &err, ostream &logout);
virtual void get_collectinfo (const text_t &collection,
ColInfoResponse_t &collectinfo,
comerror_t &err, ostream &logout);
virtual void get_filterinfo (const text_t &collection,
InfoFiltersResponse_t &response,
comerror_t &err, ostream &logout);
virtual void get_filteroptions (const text_t &collection,
const InfoFilterOptionsRequest_t &request,
InfoFilterOptionsResponse_t &response,
comerror_t &err, ostream &logout);
virtual void filter (const text_t &collection,
FilterRequest_t &request,
FilterResponse_t &response,
comerror_t &err, ostream &logout);
virtual void get_document (const text_t &collection,
const DocumentRequest_t &request,
DocumentResponse_t &response,
comerror_t &err, ostream &logout);
};

Рисунок 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.

Действия

Table 19  Actions в системе Greenstone

action

Базовый класс для виртуального наследования.

authenaction

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

collectoraction

Генерирует страницы для Collector (Создателя).

documentaction

Отыскивает документы, разделы документа, части иерархии классификации или информацию для форматирования .

extlinkaction

Переносит пользователя непосредственно к URL, который является внешним для коллекции, no-возможности сначала генерируя аварийную страницу (продиктованную установками Preferences).

pageaction

Генерирует страницу вместе с макроязыком. pingaction Выясняет, интерактивна ли коллекция. queryaction Выполняет поиск.

pingaction

Checks to see whether a collection is online.

queryaction

Произвести поиск.

statusaction

Генерирует страницы администрирования.

tipaction

Выдает случайный совет для пользователя.

usersaction

Добавляет поддержку, удаление и управление пользовательским доступом.


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

Figure 40  Использование cgiargsinfoclass из pageaction.cpp
1  
cgiarginfo arg_ainfo;
2  
arg_ainfo.shortname = " a " ;
3  
arg_ainfo.longname = " action" ;
4  
arg_ainfo.multiplechar = true;
5  
arg_ainfo.argdefault = " p" ;
6  
arg_ainfo.defaultstatus = cgiarginfo::weak;
7  
arg_ainfo.savedarginfo = cgiarginfo::must;
8  
argsinfo.addarginfo (NULL, arg_ainfo);
9  
10  
arg_ainfo.shortname = " p" ;
11  
arg_ainfo.longname = " page" ;
12  
arg_ainfo.multiplechar = true;
13  
arg_ainfo.argdefault = " home" ;
14  
arg_ainfo.defaultstatus = cgiarginfo::weak;
15  
arg_ainfo.savedarginfo = cgiarginfo::must;
16  
argsinfo.addarginfo (NULL, arg_ainfo);

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, индексированного названием действия.

Figure 41  Action базовый класс API
class action {
protected:
cgiargsinfoclass argsinfo;
text_t gsdlhome;
public:
action ();
virtual ~action ();
virtual void configure (const text_t &key, const text_tarray &cfgline);
virtual bool init (ostream &logout);
virtual text_t get_action_name ();
cgiargsinfoclass getargsinfo ();
virtual bool check_cgiargs (cgiargsinfoclass &argsinfo,
cgiargsclass &args, ostream &logout);
virtual bool check_external_cgiargs (cgiargsinfoclass &argsinfo,
cgiargsclass &args,
outconvertclass &outconvert,
const text_t &saveconf,
ostream &logout);
virtual void get_cgihead_info (cgiargsclass &args,
recptprotolistclass *protos,
response_t &response,
text_t &response_data,
ostream &logout);
virtual bool uses_display (cgiargsclass &args);
virtual void define_internal_macros (displayclass &disp,
cgiargsclass &args,
recptprotolistclass *protos,
ostream &logout);
virtual void define_external_macros (displayclass &disp,
cgiargsclass &args,
recptprotolistclass *protos,
ostream &logout);
virtual bool do_action (cgiargsclass &args,
recptprotolistclass *protos,
browsermapclass *browsers,
displayclass &disp,
outconvertclass &outconvert,
ostream &textout,
ostream &logout);
};

Рисунок 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 () с целью инициализации.

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

Figure 42  Основные структуры данных в Format
enum command_t {comIf, comOr, comMeta, comText, comLink, comEndLink,
comNum, comIcon, comDoc,
comHighlight, comEndHighlight};
enum pcommand_t {pNone, pImmediate, pTop, pAll};
enum dcommand_t {dMeta, dText};
enum mcommand_t {mNone, mCgiSafe};
struct metadata_t {
void clear();
metadata_t () {clear();}
text_t metaname;
mcommand_t metacommand;
pcommand_t parentcommand;
text_t parentoptions;
};
// The decision component of an {If}{decision,true-text,false-text}
// formatstring. The decision can be based on metadata or on text;
// normally that text would be a macro like
// _cgiargmode_.
struct decision_t {
void clear();
decision_t () {clear();}
dcommand_t command;
metadata_t meta;
text_t text;
};
struct format_t {
void clear();
format_t () {clear();}
command_t command;
decision_t decision;
text_t text;
metadata_t meta;
format_t *nextptr;
format_t *ifptr;
format_t *elseptr;
format_t *orptr;
};

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

Figure 43  Структуры данных, сформированные для выборки оператора /ormutf


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

format CL1Vlist

"[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, макрообъекта верхнего уровня.

Figure 44  Иллюстрация макро старшинства
package query
_header_ [] {_querytitle_}
_header_ [l=en] {Search page}
_header_ [c=demo] {<table bgcolor=green><tr><td>_querytitle_</td></tr></table>}
_header_ [v=1] {_textquery_}
_header_ [l=fr,v=1,c=hdl] {HDL Page de recherche}

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

macroprecedence c,v,l

в основном файле конфигурации 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] не была бы выбрана вообще, потому что параметр / для страницы задан совсем другой.

Figure 45  Структуры данных, представляющие макрос, заданный по умолчанию


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

Figure 46  Displayclass API (сокращенный вариант)
class displayclass
{
public:
displayclass ();
~displayclass ();
int isdefaultmacro (text_t package, const text_t &macroname);
int setdefaultmacro (text_t package, const text_t &macroname,
text_t params, const text_t &macrovalue);
int loaddefaultmacros (text_t thisfilename);
void openpage (const text_t &thispageparams,
const text_t &thisprecedence);
void setpageparams (text_t thispageparams,
text_t thisprecedence);
int setmacro (const text_t &macroname,
text_t package,
const text_t &macrovalue);
void expandstring (const text_t &inputtext, text_t &outputtext);
void expandstring (text_t package, const text_t &inputtext,
text_t &outputtext, int recursiondepth = 0);
void setconvertclass (outconvertclass *theoutc) {outc = theoutc;}
outconvertclass *getconvertclass () {return outc;}
ostream *setlogout (ostream *thelogout);
};

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

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

cout << text_t2ascii << display << "_amacro_ "
<< "_anothermacro_ ";

Результат - макрос, расширенный согласно настройкам параметров страницы. Если требуется, эти параметры настройки могут быть отчасти изменены, используя 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.

OIDtools.h

Функциональная поддержка оценки идентификаторов документа по протоколу.

action.h

Базовый класс для объекта Actions , изображенного на рисунке 24.

authenaction.h

Унаследованное действие для идентификации пользователя.

browserclass.h

Базовый класс для резюме действия просмотра.

browsetools.h

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

cgiargs.h

Определяет cgiarginfo используемый на рисунке 40, при поддержке структуры данных для CGI-аргументов.

cgiutils.h

Функциональная поддержка CGI-аргументов, используя структуры данных, определенные в cgiargs.h.

cgiwrapper.h

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

void cgiwrapper (receptionist &recpt, text_t collection);

которая является единственной функцией, объявленной в файле заголовка. Все остальные функции - .срр копии, лексически ограниченные, чтобы быть локальными по отношению к файлу (используя ключевое слово C++ static). Если функция выполняется для специфической коллекции, тогда collection должна быть установлена, иначе это должна быть пустая строка " ". Программа включает поддержку Fast-CGI.

collectoraction.h

Унаследованное действие, которое облегчает формирование коллекции конечного пользователя через Collector. Сгенерированная страница исходит из collect.dm и управляется параметром CGI -аргумента p=page.

comtypes.h

Основные типы протоколов.

converter.h

Объектная поддержка потоковым конвертерам.

datelistbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку просмотра хронологических списков, типа виденного нами ранее в коллекции Greenstone Archives просмотра по "датам" в навигационном меню.

documentaction.h

Унаследованное действие, используемое для восстановления документа или части иерархии классификации.

extlinkaction.h

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

formattools.h

Функциональная поддержка анализа и оценки конфигурации коллекции операторами/ormutf. Подробное описание в Разделе 3.8.2.

historydb.h

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

hlistbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку просмотра горизонтальных списков.

htmlbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку просмотра страниц HTML.

htmlgen.h

Функция поддержки подсветки терминов запроса в text_t строке.

htmlutils.h

Функциональная поддержка, которая конвертирует text_t строку в эквивалентный HTML. Символы ", &, <, и > преобразовываются в ", &атр;, < и > соответственно.

infodbclass.h

Определяет два класса: gdbmclass и infodbclass. Первый обеспечивает Greenstone API к GDBM; последний - объектный класс, используемый для хранения записей элементов чтения из GDBM базы данных, а по существу - ассоциативный массив индексированных целым числом массивов text_t строк.

invbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку просмотра списков, которые не предназначены для просмотра (невидимые).

nullproto.h

Унаследованный от recptproto, этот класс понимает нулевой протокол, реализованный через функциональные запросы от регистратора на сервер коллекции.

pageaction.h

Унаследованное действие, которое вместе с макрофайлом, названным sp=page, генерирует web-страницу.

pagedbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку механизма просмотра "go to page" (перейти к странице), например, в Gutenberg коллекции.

pingaction.h

Унаследованное действие, которое выясняет, отвечает ли частная коллекция.

queryaction.h

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

querytools.h

Функциональная поддержка запросу.

receptionist.h

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

recptconfig.h

Функциональная поддержка читения сайта и основных файлов конфигурации.

recptproto.h

Базовый класс для протокола.

statusaction.h

Унаследованное действие, которое вместе со status.dm генерирует различные страницы администрирования.

tipaction.h

Унаследованное действие, которое производит вместе с tip.dm web-страницу, содержащую совет, взятый наугад из списка подсказок, сохраненных в tip.dm.

userdb.h

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

usersaction.h

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

vlistbrowserclass.h

Унаследованный от browserclass, этот объект обеспечивает поддержку просмотра для вертикальных списков, основы классификаторов. Например, дочерние записи узла для заголовков, начинающихся с символа N предусмотрены в VList.

z3950cfg.h

Структура данных, поддерживающая протокол Z39.50. Используемый z3950proto. cpp, который определяет основной класс протокола (унаследованный от базового класса recptproto) и синтаксический анализатор файла конфигурации zparse.y (письменное использование YACC).

z3950proto.h

Унаследованный от recptproto, этот класс реализует протокол Z39.50 так, чтобы регистратор Greenstone мог обратиться к отдаленным библиотечным сайтам, работающим на серверах Z39.50.

z3950server.h

Дополнительная поддержка для протокола Z39.50.


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().

Figure 47  Инициализация Greenstone, с использованием, нуль-протокола
============
Main program
============
Statically construct Receptionist
Statically construct NullProtocol
Establish the value for 'gsdlhome' by reading gsdlsite.cfg
Foreach directory in GSDLHOME/collect that isn't "modelcol":
Add directory name (now treated as collection name) to NullProtocol:
Dynamically construct Collection
Dynamically construct Gdbm class
Dynamically construct the Null Filter
Dynamically construct the Browse Filter
Dynamically construct MgSearch
Dynamically construct the QueryFilter
Dynamically construct the MgGdbmSource
Configure Collection with 'collection'
Passing 'collection' value on to Filters and Sources:
Configure Receptionist with 'collectinfo':
Passing 'collectinfo' value on to Actions, Protocols, and Browsers:
Add NullProtocol to Receptionist
Add in UTF-8 converter
Add in GB converter
Add in Arabic converter
Foreach Action:
Statically construct Action
Add Action to Receptionist
Foreach Browsers:
Statically construct Browser
Add Browser to Receptionist
Call function cgiwrapper:
=================
Configure objects
=================
Configure Receptionist with 'collection'
Passing 'collection' value on to Actions, Protocols, and Browsers:
NullProtocol not interested in 'collection'
Configure Receptionist with 'httpimg'
Passing 'httpimg' value on to Actions, Protocols, and Browsers:
NullProtocol passing 'httpimg' on to Collection
Passing 'httpimg' value on to Filters and Sources:
Configure Receptionist with 'gwcgi'
Passing 'gwcgi' value on to Actions, Protocols, and Browsers:
NullProtocol passing 'gwcgi' on to Collection
Passing 'gwcgi' value on to Filters and Sources:
Reading in site configuration file gsdlsite.cfg
Configure Recptionist with 'gsdlhome'
Passing 'gsdlhome' value on to Actions, Protocols, and Browsers:
NullProtocol passing 'gsdlhome' on to Collection
Passing 'gsdlhome' value on to Filters and Sources:
Configure Recptionist with ...
... and so on for all entries in gsdlsite.cfg
Reading in main configuration file main.cfg
Confiugre Recptionist with ...
... and so on for all entries in main.cfg
====================
Initialising objects
====================
Initialise the Receptionist
Configure Receptionist with 'collectdir'
Passing 'collectdir' value on to Actions, Protocols, and Browsers:
NullProtocol not interested in 'collectdir'
Read in Macro files
Foreach Actions
Initialise Action
Foreach Protocol
Initialise Protocol
When Protocol==NullProtocol:
Foreach Collection
Reading Collection's build.cfg
Reading Collection's collect.cfg
Configure Collection with 'creator'
Passing 'creator' value on to Filters and Sources:
Configure Collection with 'maintainer'
Passing 'maintainer' value on to Filters and Sources:
... and so on for all entries in collect.cfg
Foreach Browsers
Initialise Browser
=============
Generate page
=============
Parse CGI arguments
Execute designated Action to produce page
End.

На рисуноке 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 подробно представлены некоторые доступные опции; остальные описаны в следующих разделах.

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

Значение

Цель

maintainer

NULL или E-mail адрес

Адрес электронной почты лица, обслуживающего сайт, который используется с целью уведомления. Если NULL, E-mail события заблокированы

MailServer

NULL или имя сервера

Сервер исходящей почты для этого сайта. ЕслиNULL, то используется mail. домен-обслуживающего сайт лица (например, если обслуживает сайт - help@example.com, то значение по умолчанию - mail.example.com). Если это не разрешено допустимым SMTP-сервером, то E-mail события не будут работать

status

enabled или disabled

Определяет, должна ли страница "Обслуживание и администрирование" быть доступной

collector

enabled или disabled

Определяет, доступна ли коллекция конечного пользователя, формирующая средство "коллектора"

logcgiargs

true или false

Если true, регистрация пользования хранится в usage.txt. Если true, информация о пользователях сайта

usecookies

true или false

собрана (используя cookies) и записана в usage.txt(это работает только в том случае, если logcgiargs принимает значение true)

LogDateFormat

LocalTime или
UTCTime или
Absolute

Формат, в котором информация о времени приписана к файлу регистрации. LocalTimeпроизводит формат "четверг 07 декабря 12:34 NZDT 2000 ", UTCTIME - тот же самый формат, но в GMT (среднем времени по Гринвичу), и absolute- целое число, представляющее количество секунд с момента 00:00:00 01/01/1970 GMT

LogEvents

AllEvents или
CollectorEvents
или disabled

Регистрация некоторых событий в events.txt. AllEvents регистрирует все события Greenstone, CollectorEvents регистрирует только события, связанные с Collector (Коллектором), a disabled не регистрирует никаких событий.

EmailEvents

enabled или disabled

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

EmailUserEvents

enabled или disabled

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

macrofiles

список макро имен файлов

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


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

Два вида вхождений в файле конфигурации 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  Файл конфигурации сайта

Table 21  Линии в gsdlsite.cfg

Линия

Функция

gsdlhome

Путь в директорию GSDLHOME.

httpprefix

Веб адрес GSDLHOME. Вам не нужна эта линия, если корневой документ на вашем веб серевере установлен как GSDLHOME.

httpimage

Веб адрес содержит графику для интерфейса пользователя. Если кореневой документ веб сервера установлен как GSDLHOME, то это будет /images.

gwcgi

Веб адрес этого cgi скрипта (обычно имеет окончание library. Это не требуется, если ваш веб сервер устанавливает переменную SCRIPT_NAME.

maxrequests

(Применяется только, если использован fast-cgi.) Должно произойти определённое число запросов fast-cgi, до того, как он выйдет. Это должно быть малое число для регулирования библиотеки, и, в других случаях - крупное.


Файл конфигурации сайта 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)

Figure 48  Программирование списка целых чисел
1  
#include <iostream.h>
2  
3  
#define nil 0
4  
5  
struct intlist {
6  
int val;
7  
struct intlist* next;
8  
};
9  
10  
int total_int_list(intlist* head)
11  
{
12  
int total = 0;
13  
intlist* curr = head;
14  
while (curr!=nil)
15  
{
16  
total += curr->val;
17  
curr = curr->next;
18  
}
19  
20  
return total;
21  
}
22  
23  
void main()
24  
{
25  
intlist node1 = { 5, nil };
26  
intlist node2 = { 4, nil };
27  
node2.next = &node1;
28  
29  
int total = total_int_list(&node2);
30  
cout << " List items total to: " << total << endl;
31  
}

Сначала мы изучим две программы, которые реализуют целочисленный список. Превоначально используйте основные типы 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, показывая, что элементов для обработки больше не осталось.

Figure 49  Программирование списка целых чисел с использованием STL
#include <iostream.h>
#include <list>
int total_int_list(list<int>* head)
{
int total = 0;
list<int>::iterator curr = head->begin();
while (curr!=head->end())
{
total += *curr;
curr++;
}
return total;
}
void main()
{
list<int> vals;
vals.push_back(5);
vals.push_back(4);
int total = total_int_list(&vals);
cout << " List items total to: " << total << endl;
}

Рисунок 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), так как хеширование - нормальная методика, по обыкновению реализующая текстовый индекс.

Figure 50  Использование ассоциативных массивов в STL
1  
#include <iostream.h>
2  
#include <map>
3  
4  
int total_int_table(map<char*, int>& table)
5  
{
6  
int total = 0;
7  
map<char*, int>::iterator curr = table.begin();
8  
while (curr!=table.end())
9  
{
10  
total += (curr->second);
11  
curr++;
12  
}
13  
14  
return total;
15  
}
16  
17  
int main()
18  
{
19  
map<char*, int> table;
20  
table["Alice"] = 31;
21  
table["Peter"] = 24;
22  
table["Mary"] = 47;
23  
24  
int total = total_int_table(table);
25  
cout << " Age total: " << total << endl;
26  
}

В 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, подробности об этих последних двух типах опущены.


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.”