ЦИФРОВАЯ БИБЛИОТЕКА 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. Оно предназначено для тех, кто хочет самостоятельно создавать и конфигурировать коллекции и поддерживать программное обеспечение. Раздел дает учетную запись лицу, непосредственно участвующему в процессе формирования коллекций, включая разработку структуры директорий, внутреннего формата документа и файла конфигурации, который управляет структурой каждой коллекции. Раздел описывает части Green¬stone, которые обрабатывают исходные документы (и метаданные) и регламентируют доступ к информации через интерфейс пользователя. Здесь также описываются "внешние" программные компоненты, которые распространяются вместе с Greenstone. В разделе представлено описание структуры системы поддержки выполнения Greenstone, а также дано подробное описание программного обеспечения, призванное помочь пользователю лучше понять, как оно работает и как можно изменить систему, чтобы она удовлетворяла различным потребностям. Раздел описывает файлы конфигурации Greenstone, а в Приложении представлена Стандартная библиотека шаблонов C++. При работе с программным обеспечением Green¬stone Вы можете столкнуться со ссылками на особенности системы, которые не описаны в настоящем руководстве. Это связано с тем, что Greenstone находится в постоянном развитии. Чтобы быть в курсе текущей работы, подпишитесь на рассылку Greenstone (инструкции на сайте greenstone.org).

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

Программное обеспечение 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.

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

Начав создание коллекций из командной строки, вы пройдете по всей операционной цепочке, что позволит вам лучше понять этот процесс. Разумеется, для наибольшего числа схожих коллекций вы будете пользоваться Коллектором. Для примера мы воспользуемся коллекцией, находящейся на установочном CD-ROM и состоящей из домашних WWW-страниц множества лиц, работавших над проектом создания Новозеландской цифровой библиотеки и системой Greenstone. Отдельные подразделы практически не отличаются друг от друга, однако они были созданы для работы с Greenstone в различных операционных средах, таких как Windows и Unix. Вам остается только выбрать. на базе операционной системы вашего компьютера. При беглом просмотре некоторые операции могут вам показаться непонятными и таинственными, однако выполните их, близко придерживаясь к инструкциям - подробное описание этих операций будет дано несколько позже. В конце подраздела дано краткое резюме о различиях между процессами формирования коллекций на базе Widows и Unix. При формировании коллекций 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. Если при работе в интерактивном сеансе 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 "

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. Откройте его, используя любой текстовый редактор, либо используйте редактор, настроенный по умолчанию. В результате вы увидите окно, содержимое которого выглядит так, как показано на рисунке , показывая содержимое файла конфигурации коллекции, созданного с использованием команды 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/Ввод. Если вы хотите использовать в вашей коллекции многоязычный интерфейс, то существует способ вывода данного текста в соответствии с выбранным языком. Это описание будет представлено далее в разделе . Вы можете использовать изображения, которые будут представлены в качестве иконок на WWW-странице коллекции; изображение, созданное мною, вы можете видеть на рисунке . Укажите путь нахождения изображения в кавычках в строке collectionmeta iconcollection "" файла конфигурации. Для краткости и мобильности _httpprefix_ может быть использован в качестве стартового URL указывающего на изображение, находящееся в файловой области Greenstone. Например, вы можете ввести: _httppreflx_/collect/dlpeople/images/icon.gif если вы поместили подходящее изображение в соответствующую директорию коллекции (в нашем примере это: collect\dlpeople\images ). Сохраните файл конфигурации коллекции и закройте его - он вам больше не понадобится на данном этапе обучения. Следующая фаза - "построение" коллекции, в которой будут созданы все индексы и файлы, отвечающие за работу коллекции. Напечатайте в командной строке perl —S buildcol.pl и получите список опций для формирования коллекции. Подробное описание этих опций представлено в Разделе . Пока же придерживайтесь значений "по умолчанию", напечатав: 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, то должны перезапустить всю программу. Для просмотра новой коллекции щелкните кнопкой мыши по изображению. Полученный результат вы можете увидеть на рисунке .

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

Теперь используем команду для создания начальных файлов и директорий, необходимых для создания домашней страницы участников проекта создания Цифровой библиотеки 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. В результате вы увидите окно, содержимое которого выглядит, как на рисунке , показывая содержимое файла конфигурации коллекции, созданного с использованием команды 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/Ввод. Если вы хотите использовать в вашей коллекции многоязычный интерфейс, то существует способ вывода данного текста в соответствии с выбранным языком. Это описание будет представлено далее в разделе . Вы можете использовать изображения, которые будут фигурировать в качестве иконок на WWW-странице коллекции. Изображение, созданное мною, вы можете видеть на рисунке . Укажите путь нахождения изображения в кавычках в строке collectionmeta iconcollection "" файла конфигурации. Для краткости и мобильности _httpprefix_ может быть использован в качестве стартового URL, указывающего на изображение, находящееся в файловой области Greenstone. Например, вы можете ввести: httpprefix_/collect/dlpeople/images/icon.gif если вы поместили подходящее изображение в соответствующую директорию коллекции (в нашем примере это: collect\dlpeople\images ). Сохраните файл конфигурации коллекции и закройте его - он вам больше не понадобится на данном этапе обучения. Следующая фаза - "построение" коллекции, в которой будут созданы все индексы и файлы, отвечающие за работу коллекции. Напечатайте в командной строке buildcol.pl и получите список опций для формирования коллекции. Подробное описание этих опций представлено в Разделе . Пока же придерживайтесь значений "по умолчанию", напечатав: buildcol.pl dlpeople И снова не беспокойтесь о быстро бегущем по экрану тексте - это отчет о выполнении команды. Сделайте коллекцию "оперативной", как только материалы помещены в каталог building, перешлите их в каталог index. Если у вас прежде была уже сформирована коллекция, сначала удалите старые индесы, напечатав в командной строке: rm —r index/* (предполагается, что вы работаете в директории dlpeople). Затем введите: mv building/* index/

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

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

	содержание	раздел
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++, используется для обслуживания коллекции –ответы на запросы и т.п.
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	Документация	—

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

	Аргумент	Функция
-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	Отсутствует	Печать результатов работы приложений отладки.

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

	Аргумент	Функция
-importdir	Имя директории	Указывает на то, где могут быть найдены импортированные документы. По умолчанию: GSDLHOME/collect/coljiame/import.
-removeold	Отсутствует	Очищает содержимое директории archives перед процессом импорта.
-gzip	Отсутствует	Zip архивирует документы Greenstone, полученные в результате процесса импорта (ZIPPlug должен быть включен в список приложений, a gzip должен быть установлен на вашем компьютере).
-groupsize	Число Х	Количество документов, группируемых в один архивный файл Greenstone, по умолчанию 1 (означает 1 документе 1 файл).
—sortmeta	Имя тэга	Сортирует документы в алфавитном порядке по имени тэга метаданных метаданных. Однако, если коллекция имеет более 1 группы в одном архивном файле (т.е. groupsize >1), эта функция будет заблокирована.
-OIDtype	Хэширование	Метод создания ОШ для документов: хэширование содержания, очень или наполнение медленный метод; метод наполнения работает гораздо быстрее и заключается в простом присваивании входящим документам последовательного номера

На рисунке представлен процесс импорта, инициированный процедурой работы программы import.pl. Каждый овал представляетсобой модуль исполняющий задачи определенной части системы Greenstone. Все эти модули находятся в директории GSDLHOME/perllib. Для шага 3. Обратите внимание, что переменные импортирования, такие как importdir и archivedir могут быть запущены из командной строки или из файла конфигурации коллекции.Если запуск произведен из командной строки, то все установки, сделанные через файл конфигурации, игнорируются. На 6 шаге был создан файл информационного архива (archives.ini). На 7 шаге был создан объект, который хранит информацию о том, куда были записаны документы, и подчиняется специальным инструкциям для процесса сохранения (таким как sortmeta, которая сортирует документы в соответствии со спецификой тэгов метаданных). Большая часть работы в процессе импорта делается приложениями, вызываемыми модулем plugin. Этот модуль создает конвейер приложений, описанных в файле конфигурации коллекции. Он также обслуживает запись документов архива Greenstone, используя объект document. В течение процесса формирования происходит сжатие текста, по полному тексту производится индексация, описанная в файле конфигурации коллекции. Кроме того, на этом этапе обрабатывется и подключается информация о том, как уже сформированная коллекция будет выглядеть во всемирной паутине -например, данные о заголовках и иконках, классификационные данные и т.д. Buildcol.pl имеет много опций, используемых совместно с import.pl, см. Таблицу , и несколько уникальных, представленных в Таблице .

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

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

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

<!DOCTYPE GreenstoneArchive [    <!ELEMENT Section (Description,Content,Section*)>    <!ELEMENT Description (Metadata*)>    <!ELEMENT Content (#PCDATA)>    <!ELEMENT Metadata (#PCDATA)>    <ATTLIST Metadata name CDATA #REQUIRED> ]>

<?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>

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

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

Открывающий тэг <Section> обозначает начало каждого раздела документа, аа закрывающий тэг </Section> - конец раздела. За каждым тэгом <Section> следует раздел <Description>. В пределах данного раздела находятся элементы <Metadata>. Таким образом, различные метаданные могут быть связаны с индивидуальными разделами документа. Большинство из них используются в качестве специфических метаданных, таких как <ТШе>. Два значения атрибута name представлены в Таблице и специально разработаны Greenstone; все остальные представляют собой метаданные, прилагаемые к данному разделу. В некоторых коллекциях документы разбиты на отдельные страницы. Они означены как разделы. Например, книга может иметь разделы первого уровня, которые соответствуют главам, в пределах каждой из которых определено множество "разделов", которые фактически соответствуют отдельным страницам главы. Метаданные содержат информацию описательного характера, такую как данные об авторе, заглавие, дату, ключевые слова и т.д., касающуюся конкретного документа. И, как было уже сказано выше, метаданные хранятся вместе с документом. Посмотрев на рисунок , вы можете увидеть, что тэг <Мегай?ага> определяет название типа метаданных и присваивает им значение. Обратимся для примера к строке <Metadataname='"Etle ">First and only chap-ter</Metadata> на рисунке - заголовок документа является частью связанных с ним метаданных. Для определения типов метаданных был использован Dublin Core metadata standard (Dublin Core, 2001, Weibel, 1999; Thiele, 1997). Таблица демонстрирует, какие из стандартных типов, отмеченные звездочками, доступны сегодня к использованию на веб-сайте New Zealand Digital Library. Если нет возможности подобрать тип, точно описывающий метаданные, то можно использовать другой тип, не описанный в Dublin Core metadata standard. Например, в демонстрационной коллекции содержится метаданные how to и Magazine.

Имя	Подтэг метаданных	Описание
*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

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 . Documents in the Computer Science Technical Reports collection do not have a hierarchical subsection structure, but each document is split into pages and you can browse around the pages of a retrieved document. Chapters, sections, subsections, and pages are all implemented simply as “sections” within the document.

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

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

creator	E-mail создателя коллекции
maintainer	E-mail службы поддержки коллекции
public	Должна ли быть опубликована коллекция
beta	Является ли настоящая публикация beta-версией коллекции
indexes	Список индексов формирования
defaultindex	Индексы по умолчанию
subcollection	Определяет коллекцию, основанную на метаданных
indexsubcollections	Указывает на подколлекцию для индексирования
defaultsubcollection	Индексы по умолчанию для подколлекций
languages	Список языков для индексирования
defaultlanguage	Язык для индексирования, установленный по умолчанию
collectionmeta	Определяет метаданные на уровне коллекции
plugin	Определяет приложения, участвующие в процессе формирования
format	Строковый формат (объяснение следует)
classify	Определяет классификатор, используемый в процессе формирования

Каждая строка файла конфигурации коллекции по существу является парой "атрибут, значение". Каждый атрибут несет часть информации о коллекции, которая указывает на то, как документы должны выглядеть или как они должны быть обработаны. В таблице представлены элементы, которые должны быть включены в файл конфигурации коллекции, и для чего они используются. Таким же образом могут быть определены в файле конфигурации коллекции все опции командной строки для import.pl и buildcol.pl - например, при прочтении no_text true для опции buildcol.pl будет установлен атрибут no_text. Создание файла конфигурации коллекции с помощью скрипта mkcol.pl, показанного в Таблице , является очень простым и содержит необходимый минимум информации. Строки 1 и 2 являются значениями атрибута creator, созданными в результате работы программы mkcol.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 (означает, что не будет). Последнее обычно используется во время создания тестовых коллекций или для формирования коллекций документов для собственного использования. Line 5 determines what collection indexes are created at build time: in this example only the document text is to be indexed. Indexes can be constructed at the document, section, and paragraph levels. They can contain the material in text, or in any metadata—most commonly Title. The form used to specify an index is level:data. For example, to include an index of section titles as well, you should change line 5 to indexes document:text section:Title. More than one type of data can be included in the same index by separating the data types with commas. For example, to create a section-level index of titles, text and dates, the line should read indexes section:text,Title,Date. The default index defined in line 6 is the default to be used on the collection's search page. Lines 7—13 specify which plugins to use when converting documents to the Greenstone archive format and when building collections from archive files. Section gives information about what plugins are available. The order in which plugins are listed is the order in which they are tried on each document, and once a plugin that is able to process a document is found, no more are tried. Line 14 specifies that an alphabetic list of titles is to be created for browsing purposes. Browsing structures are constructed by “classifiers”. Section gives information about classifiers and what they can do. Lines 15—18 are used to specify collection-level metadata. Specified through collectionname, the long form of the name is used as the collection's “title” for the web browser. The collectionicon entry gives the URL of the collection's icon. If an index is specified (as in line 18), the string following is displayed as the name of that index on the collection's search page. Наиболее важной частью описания коллекции на уровне метаданных является collectionextra, которая дает текст развернутого описания коллекции, заключенный в двойные кавычки. Этот текст будет отображаться в качестве описания для страницы "About this collection" (О коллекции). Вы можете использовать различные варианты collectionextra для мультиязычного интерфейса, путем добавления языкового описания в квадратных скобках. Например, collectionmeta collectionextra "collection description" collectionmeta collectionextra [l=fr] "description in French" collectionmeta collectionextra [l=mi] "description in Maori" Если установлен язык интерфейса "fr" или "mi", то будет отображена соответствующая версия описания. Для других языков появится версия, заданная по умолчанию. Этот простой файл конфигурации коллекции, не включающий ни примеров строк формата, ни подколлекции, ни средств языка, предоставляемых файлом конфигурации. Строковый формат будет подробнее рассмотрен в Разделе , а здесь мы рассмотрим ситуацию с поколлекциями и языками. 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,... Точно такая же строка должна быть и в файле конфигурации тех коллекций, которые используются для перекрестного поиска.

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

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

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.

		Цель	Типы файлов	Игнорируемые файлы
Общие	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	Processes PDF documents, extracting the first line of text as a title. The pdftohtml program fails on some PDF files. What happens is that the conversion process takes an exceptionally long time, and often an error message relating to the conversion process appears on the screen. If this occurs, the only solution that we can offer is to remove the offending document from the collection and re-import.	.pdf	.gif, .jpeg, .jpg, .png, .css, .rtf
	PSPlug	Обработка документов PostScript, производится извлечение метаданных: даты, заголовка и номера страниц.	.ps	.eps
	EMAILPlug	Обработка E-mail сообщений путем распознания автора, темы, даты и т.д. Данное приложение пока не обрабатывает должным образом сообщения в кодировке MIME - зачастую они выглядят несколько странно.	Must end in digits or digits followed by .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 представлен в Таблице . Для прохождения по дереву директорий необходима рекурсия. Хотя программы импорта и формирования не выполняют явную рекурсию, некоторые приложения пользуются косвенной рекурсией при прохождении имен файлов или директорий через конвейер приложений. Например, стандартное прохождение рекурсии по дереву директорий обеспечивается приложением RecPlug, предназначенными именно для этого, если, конечно, оно будет последним элементом в конвейере. Косвенную же рекурсию вызывают только два первых приложения из Таблицы . Некоторые приложения были написаны для определенных коллекций, имеющих особый формат документов, подобно E-text (электронному тексту), используемому в коллекции Gutenberg. Эти специфичные для коллекций приложения находятся в каталоге коллекции perllib/plugins. Данные приложения могут быть использованы для того, чтобы отменить общие приложения с таким же именем. Некоторые приложения обработки документов используют внешние программы, которые анализируют определенные частные форматы, например, для обработки текста - Microsoft Word или HTML. Общее приложение ConvertToPlug вызывает соответствующую программу конвертации и передает результат обработки либо TEXTPlug, либо HTMLPlug. Далее мы остановимся на этом более подробно. Некоторые приложения имеют индивидуальные опции, которые управляют процессами более детально, чем это позволяют общие опции. Они представлены в Таблице .

	Опция	Цель
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, никогда не вызывается непосредственно. На рисунке представлены приложения, написанные для определенных форматов. ConvertToPlug, используя схему динамического распределения Perl запускает TEXTPlug или HTMLPlug в зависимости от формата, в который были конвертированы исходные документы.

Когда ConvertToPlug получает документ, он вызывает gsConvert.pl (находится в директории GSDLHOME/bin/script) для запуска соответствующей утилиты. Как только документ будет проконвертирован, он возвращается к ConvertToPlug, который вызывает приложение обработки текста или HTML. Любое приложение, вызванное ConvertToPlug, имеет опцию convertjto, которая содержит аргумент textvum html, для определения предочтительного формата. Работа с текстом происходит значительно быстрее, однако документ, представленный в формате HTML, выглядит намного интереснее и может содержать иллюстрации. Иногда для специфического формата существует несколько утилит, и gsConvert может пытаться использовать их. Например, для конвертации Word предпочтительно использовать утилиту wvWare, однако она обрабатывает документы, созданные в редакторе Word не ниже 6 версии, а вот утилиту AnyToHTML, которая no-существу извлекает только текстовые строки, which essentially just extracts whatever text strings can be found, вполне можно использовать для конвертации документов из Word 5. Шаги загрузки новой конвертационной утилиты для добавления внешних документов: Установить новую утилиту в соответствии с требованиями Greenstone (поместить ее в директорию packages). Внести изменения в gsConvert.pl для последующего использования утилиты. Они заключаются в добавлении нового предложения с оператором if в функцию main, и добавлении функции, вызывающей новую утилиту. W3. Записать приложение на уровень, следущий за ConvertToPlug, для того чтобы перехватить конвертацию в стандартный формат, подменив его на нужный. Стандартное приложение RecPlug помимо всего, имеет возможность назначать метаданные документу вручную (или автоматически), создавая XML-файлы. Остановимся подробнее на этом для того, чтобы вы сами смогли создавать файлы метаданных для описания ваших форматов. Если определена опция usejnetadatajiles, то RecPlug использует вспомогательный файл метаданных - metadata.xml. На рисунке представлен XML Document Type Definition (DTD) для формата файла метаданных, а на рисунке приведен пример файла метаданных metadata.xml.

<!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"> ]>

<?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". Для этих файлов метаданные типа 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 - файлов, содержащих "<!—" и"~>". Шрифт и интервал игнорируются.

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

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

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

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

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

	Аргумент	Действие
Hierarchy		Иерархическая классификация
	hfile	Файл классификации
	metadata	Элемент метаданных для тестирования вопреки идентификатору hfile
	sort	Элемент метаданных, сортирующий документы в пределах листа (по умолчанию - Title)
	buttonname	Название кнопки, используемой для обращения к классификатору (по умолчанию - значение аргумента метаданных)
List		Алфавитный список документов
	metadata	Включение документов, содержащих этот элемент метаданных
	buttonname	Название кнопки, используемой для обращения к классификатору (по умолчанию - значение аргумента метаданных)
SectionList		Список разделов документов
AZList		Список документов, разбитых на алфавитные диапазоны
	metadata	Включение всех документов, содержащих этот элемент метаданных
	buttonname	Название кнопки, используемой для обращения к классификатору (по умолчанию - значение аргумента метаданных) Подобно AZList,но включает все разделы документов Подобно AZList, но сортирует по дате
AZSectionList		Подобно AZList,но включает все разделы документов
DateList		Подобно AZList, но сортирует по дате

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

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 дает имя файла, как показано на рисунке , которое определяет иерархию метаданных. Каждая строка описывает одну классификацию, а описания состоят из трех частей: Идентификатор, который соответствует значению метаданных (заданного аргументом metadata) по классификации. Маркер позиции-в-иерархии, в многпериодной числовой форме, например 2,2.12,2.12.6. Название классификации (если оно содержит пробелы, то должно быть заключено в кавычки). На рисунке представлена часть файла sub.txt, создающего подчиненную иерархию в коллекции Development Library (и в Демонстрационной коллекции). Этот пример - немного запутанный, т.к. номер, указывающий на иерархию, используется дважды на каждой строке. Тип метаданных Hierarchy представлен в документах со значениями в иерархической числовой форме, которая объясняет первое использование. Второе использование номера требуется для определения иерархии, которая осуществляется броузером иерархии. Классификатор hierarchy имеет опциональный аргумент sort, который определяет, как упорядочиваются документы в листах. Любые метаданные могут быть определены как ключ сортировки. Значение по умолчанию должно создать список в том порядке, в котором документы проходили процесс формирования. Упорядочение во внутренних узлах определено в соответствии с порядком, в котором элементы определены в аргументе hfile. Классификаторы являются объектами языка Perl, полученными от BasClas.pm и хранимыми в директории perllib/classijy. Они используются тогда, когда коллекция уже сформирована. При запуске классификаторов выполняются следующие шаги. Метод new создает объект классификатора. Метод init инициализирует объект по таким параметрам, как тип метаданных, название кнопки и критерии сортировки. Метод classify используется один раз для каждого документа и хранит информацию о классификации, произведенной классификатором в пределах объекта. Метод get_classijy_info возвращает локально сохраненную информацию о классификации процессу компоновки, который записывает ее в информационную базу данных коллекции для использования, во время работы с коллекцией. Метод classify отыскивает OID каждого документа, значение метаданных для классификации документа, и в случае необходимости, значение метаданных для сортировки документов. Метод get_classify_info производит всю сортировку и определенную классификатором обработку. Например, в случае использования классификатора AZList, он разбивает список на алфавитные диапазоны. Процесс формирования инициализирует классификаторы, как только объект builder будет создан. Классификации создаются в процессе формирования, когда classify.pm, постоянно находящийся в директории perllib Greenstone, создаст информационную базу данных.

[Text]	Текст документа
[link] … [/link]	HTML для связи непосредственно с документом
[icon]	Соответствующая иконка (например, небольшая текстовая иконка в строке Search Results)
[num]	Номер документа (используется для отладки).
[metadata-name]	Значение этого элемента метаданных для документа, например [Title]

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

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.

Строки формата, которые управляют просмотром списков, могут применяться на различных уровнях отображения структуры. Они могут изменить все списки некоторого типа в пределах коллекции (например 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, любые метаданные могут заключаться в квадратные скобки: эти значения интерполированы в обозначенном месте. Также любой из элементов в Таблице может применяться в строках формата. Синтаксис для строк также включает условную инструкцию, которая показана в примере ниже. Перевызов всех этих классификаторов создает иерархии. Каждый уровень иерархии отображен одним из четырех возможных способов. Мы уже рассматривали HLIST, VList и DateList. К ним относится также Invisible, который является отображением ксамых верхнх уровней иерархий, т.к. имя классификатора всегда показывают отдельно от навигационного меню Green¬stone .

classify Hierarchy -hfile sub.txt -metadata Subject -sort Title classify AZList -metadata Title classify Hierarchy -hfile org.txt -metadata Organisation -sort Title classify List -metadata Howto format SearchVList " <td valign=top [link][icon][/link]</td><td>{If} {[parent(All':'):Title],[parent(All':'):Title]:} [link][Title][/link]</td> " format CL4Vlist "<br>[link][Howto][/link] " format DocumentImages true format DocumentText "<h3>[Title]</h3>\\n\\n<p>[Text]" format DocumentButtons " Expand Text|Expand contents|Detach|Highlight"

На рисунке представлена часть файла конфигурации для Демонстрационной коллекции. Мы используем его как пример, потому что он имеет несколько классификаторов, которые отлично отформатированы. Обратите внимание, что инструкции в файлах конфигурации коллекции не должны содержать символы новой строки - в Таблице более длинные строки разбиваются для удобочитаемости. Строка 4 определяет классификатор How To Демонстрационной коллекции. Он является четвертым в файле конфигурации коллекции и поэтому упоминается как CL4. Аналогичноя формулировка формата - строка 7 на рисунке . Информация "how to" генерируется классификатором List, а его структура - это простой список заголовков (см. рисунок ). Заголовки связаны с документами непосредственно: щелчок мышью на заголовке вызывает соответствующий документ. Дочерние записи верхнего уровня иерархии отображены как VList (вертикальный список), который перечисляет разделы вертикально. Поскольку связанный оператор format указывает на то, что каждый элемент списка начинается с новой строки ("<br>") и содержит текст Howto, гиперсвязь с документом происходит непосредственно. Строка 1 определяет классификацию Subject Демонстрационной коллекции, упомянутую как CL1 (первый в файле конфигурации), строка 3 классификацию Organisation - CL3. Обе строки сгенерированы классификатором Hierarchy и поэтому включают иерархическую структуру VLists. Строка 2 определяет оставшуюся классификацию для Демонстрационной коллекции, Titles A-Z (CL2). Обратите внимание на отсутствие соответствующих строк формата для классификаторов CL1. CL3. Greenstone имеет встроенные значения по умолчанию для каждого типа строки формата и поэтому нет необходимости устанавливать строку формата, если Вы не собираетесь отменять значение по умолчанию.

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

Строка 5 на рисунке - скорее сложная спецификация, которая форматирует список результата запроса, возвращенный поиском, части которого представлены на рисунке . Упрощенная версия строки формата <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 Рисунка , представляем полный формат строки <td valign=top>[link][icon][/link]</td> <td>{If}{[parent(All': '):Title], [parent(All': '):Title]:} [link][Title][/link]</td> Это предшествует спецификации parent с условным выражением, которое проверяет, пуст ли результат, и в противном случае выдает родительскую запись. Кстати, parent может быть определен Тор вместо АИ, который выдает имя документа верхнего уровня, включающее раздел - в нашем случае название книги. Отделение строкой для Тор не требуется. Некоторые последние примеры иллюстрируют другие особенности. DateList на рисунке используется для классификации 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 (соответственно типу документа), вместо заголовка документа.

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

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_ }

В заключение приведем рисунок , на котором представлен отрывок макрофайла aboutdm, который используется для генерации страницы "About this collection" (О коллекции) для каждой коллекции. Вы можете видеть работу трех макросов _pagetitle _, _content_ и _textabout_. Макрос является мощным инструментом и может быть немного непонятен. Однако, при хорошем знании 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.

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

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

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

Как показано на рисунке , регистраторы связываются с серверами коллекции, используя определенный протокол. Выполнение этого протокола зависит от конфигурации компьютера, на котором работает система цифровых библиотек. Наиболее простой и подходящий выбор - это один регистратор и один сервер коллекции, которые оба установлены на одном компьютере. Вы получаете именно такую модификацию, когда устанавливаете систему Greenstone с параметрами по умолчанию. В этом случае оба процесса объединены в один запускаемый файл (называемый library), и следовательно, использование протокола сводится к созданияю функциональных запросов. Мы называем это null protocol (нулевым протоколом). Он формирует основу для стандарта out-of-the-box (из блока) цифровой системы библиотек Greenstone. Ее упрощенная конфигурация представлена на рисунке с регистратором, протоколом и сервером совокупности, связанными вместе в один объект программы библиотеки. Цель этой главы состоит в том, чтобы объяснить вам, как все это работает. Обычно "сервер" - постоянный процесс: единожды запущенный, работает постоянно, отвечая на любые входящие запросы. Несмотря на название, сервер коллекции в конфигурации нулевого протокола не является сервером в привычном смысле слова. Фактически, каждый раз, когда вызывают любую web-страницу Greenstone, запускается программа library (CGI механизмом), которая отвечает на запрос и затем выгружается. Это мы называем "сервером", потому что дополнительно он также предназначен для работы с более общей конфигурацией (см. рисунок ). Удивительно, но цикл запуска, обработки и выхода работает не так медленно, как можно было ожидать. Однако, это абсолютно неэффективно. Существует механизм Fast-CGI (www.fastcgi.com), который обеспечивает средний уровень. Используя его, программа library может остаться в памяти в конце первого выполнения и накапливать последующие наборы параметров CGI, таким образом избегая повторных инициализаций и достигая почти такого же уровня работы, как сервер. Fast-CGI в Greenstone используется как опция, допуская повторную компиляцию исходного текста с соответствующими библиотеками. Как альтернатива нулевому протоколу, протокол Greenstone был также создан с использованием известной схемы CORBA (Slama et al, 1999). Он использует объединенную объектно-ориентированную парадигму, чтобы разрешить различным процессам, выполняющимся на различных компьютерных платформах и созданных нп различных языках программирования, обращаться к одному и тому же набору распределенных объектов в Internet (или любой другой сети). Тогда сценарии, подобно изображенному на рисунке , могут быть полностью осуществлены со всеми регистраторами и серверами коллекции, работающими на различных компьютерах.

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

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

Рисунок иллюстрирует основные части работы системы Greenstone. Наверху регистратор сначала инициализирует свои компоненты, затем анализирует CGI-аргументы, чтобы решить, какое действие запустить. При запуске действия (которое включает в дальнейшем обработку CGI аргументов), программное обеспечение использует протокол, чтобы обратиться к содержанию коллекции. Ответ используется для генерации web-страницы с помощью компонента формата и макроязыка. Макроязык, который мы виделив Разделе , используется, чтобы обеспечить цифровую библиотечную систему Greenstone лаконичным стилем и создавать интерфейсы на различных языках. Взаимодействие с библиотекой генерирует скелет web-страниц; макрос в GSDLHOME/macros наращивает на этот скелет плоть. Объект Macro Language (макроязык) на рисунке ответственен за чтение файлов и сохранение результата анализа этих файлов в памяти. Любое действие может использовать этот объект, чтобы развернуть макрокоманду. Оно может даже создать новые макросы и отменить существующие, добавляя динамическое распределение в использовании макросов. Внешний вид страницы "about this collection" (рисунок ) известен до момента запуска и закодирован в макрофайле about.dm. Заголовки, нижние колонтитулы и фоновая заливка даже не упомянуты, потому что они расположены в пакете макрокоманды Global. Однако, определенный "about" текст (текст для страницы "О коллекции") для специфической коллекции не известен заранее, он хранится в информационной базе данных коллекции в течение процесса формирования. Эта информация вызывается использованием протокола и хранится как _collectionextra_ в пакете макрокоманды Global. Обратите внимание на то, что имя макроса - по существу имя, используемое для описания этой информации в файле конфигурации коллекции, описанном в Разделе . Чтобы сгенерировать содержание страницы, была расширена макрокоманда _content_ в пакете about (рисунок ) . Она в свою очередь запускает _textabout _, который непосредственно обращается к _collectionextra _, только что динамически помещенной туда. Следующий важный компонент - объект Format. Операторы задания формата в файле конфигурации коллекции затрагивают представление специфических частей информации, как описано в Разделе . Они обработаны объектом Format (см. рисунок ). Основная задача этого объекта состоит в том, чтобы анализировать и оценивать инструкции типа строк формата (рисунок ). Как стало ясно из Раздела , они могут включать ссылки на метаданные в квадратных скобках (например, [Title]), которые должены быть найдены сервером коллекции. Взаимодействие происходит между объектом Format и объектом Macro Language, потому что операторы задания формата могут включать макросы, которые в качестве расширения включают метаданные, которые в качестве расширения включают макросы и так далее. Внизу рисунка , сервер коллекции также проходит процесс инициализации, устанавливая объекты Filter и Source, чтобы ответить на входящие запросы протокола, и объект Search, чтобы облегчить выполнение задачи. В конечном счете они обращаются к индексам и информационной базе данных коллекции, которые сформировались в процессе формирования коллекции. Игнорируя пустые строки, регистратор содержит 15 000 строк программы. Сервер коллекции содержит только 5 000 строк (75 % которого занимают файлы заголовка). Сервер коллекции более компактен, потому что релевантный поиск проходит через две предоткомпиляционные программы. Для поиска используется полнотекстовая поисковая система MG, а для поддержки информационной базы даннх коллекции используется СУБД GDBM. Для обеспечения расширяемости и гибкости Greenstone широко использует порядок следования в пределах Action, Filter, Source и Search. Для простой цифровой библиотеки, специализированной на текстовой коллекции, это означает, что вы должны узнать немного больше, чтобы программировать систему. Однако, это также означает, что MG и GDBM могут быть легко заменены, если возникнет потребность. Кроме того, программная архитектура достаточно богата, чтобы поддержать полные возможности мультимедиа, типа управления интерфейсом через устройство речевого ввода или передачи запросов в виде графическх изображений.

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

Когда пользователь вводит запрос, нажимая кнопку Begin search на странице поиска, запускается новое действие Greenstone, которое заканчиваясь, генерирует новую HTML-страницу, используя макроязык. На рисунке показан результат поиска в коллекции Project Gutenberg для поискового выражения Darcy. В пределах первоначальной HTML -страницы скрыта инструкция поиска a=q. Когда кнопка поиска нажата, эта инструкция активизируется и устанавливает новое действие - queryaction. Запуск queryaction направляет запрос к объекту Filter/Фильтр (c=gberg), определяемый для коллекции через протокол. Фильтры - важная основная функция серверов коллекции. Приспособленные для действий поиска и просмотра, они обеспечивают способы выбора подмножества информации из коллекции. В этом случае, queryaction устанавливает запрос фильтра: устанавка типа фильтра запроса QueryFilter (Раздел описывает различные типы фильтров); сохранение установок поиска пользователя в фильтре запроса; вызов функции filterQ, используя нулевой протокол. Запросы к протоколу синхронны. Регистратор эффективно блокируется, пока запрос фильтра не будет обработан сервером коллекции и все сгенерированные данные будут отображены. Когда запрос протокола типа QueryFilter сделан, объект Filter (см. рисунок ) декодирует варианты и запрашивает объект Search, который использует MG для фактического поиска. Роль объекта Search состоит в том, что он должен обеспечить абстрактный интерфейс программы, который поддерживает поиск, независимо от основного используемого средства поиска. Формат, используемый для того, чтобы возвращать результаты, также предписывает абстракцию, требуя от объекта Search транслировать данные, сгенерированные средством поиска в стандартную форму. Как только результаты поиска возвращены регистратору, дальнейшим действием становится форматирование результатов для отображения, используя объект Format и Макроязык. Как показано на рисунке , он выглядит следующим образом: стандартный заголовок Greenstone, нижний колонтитул, навигационная область и фон; повторение основной части страницы запроса только ниже навигационной области; отображение книжного значка, заголовка и автора для каждого найденного документа соответственно. Формат последней части управляется инструкцией format SearchVList в файле конфигурации коллекции. Прежде чем заголовок и метаданные автора будут отображены, они должны быть найдены сервером коллекции. Тут требуется запрос к протоколу, на сей раз используя BrowseFilter. После вышеупомянутого запроса для Darcy, рассмотрим отображаемый документ. Рисунок показывает результат щелчка по иконке около The Golf Course Mystery на рисунке .

Исходный текст для коллекции Gutenberg включает один длинный файл книги. Во время компоновки, этот файл разбит на отдельные страницы, каждая по 200 строк или около этого, и необходимая информация для каждой страницы сохранена в индексах и информационной базе данных коллекции. В верхней части рисунка указано, что эта книга содержит 104 создаваемых компьютером страницы, и ниже - начало страницы один: кто ввел информацию, заголовок, автор, начало оглавления (это часть табличной формы исходного текста Gutenberg, она не была сгенерирована Greenstone). В верхней левой части находятся кнопки, которые управляют внешним видом документа: только одна страница или целый документ; подсветка термина запроса вкл. или выкл.; действительно ли книга должна быть отображена в ее собственном окне; отделение поисковой части от окна просмотра. В верхней правой части - навигационная помощь, которая обеспечивает прямой доступ к любой странице в книге: просто напечатайте номер страницы и нажмите кнопку "go to page" (перейти к странице). Дополнительно можно использовать для перехода по страницам стрелки next/previous pages (следующая/предыдущая страница). Действие поиска документов documentaction определено установкой a=d и имеет несколько дополнительных параметров. Наиболее важный - дпоиск документа: это определено через переменную d. На рисунке это установлено как d=HASH51e598821ed6cbbdf0942b. 1 найти первую страницу документа с идентификатором HASH51e598821ed6cbbdf0942b, зная более дружественый термин The Golf Course Mystery. Остальные переменные определяют: вкл. или выкл. подсветку термина запроса (hi), отобразить информацию о том, какая страница книги отображена (gt). Эти переменные используются для поддержки действий, предлагаемых кнопками на странице (см. рисунок ), описанной выше. Значения по умолчанию используются, если любая из этих переменных опущена. Действие следует за процедурой queryaction: оценка CGI -аргумента, доступ к серверу коллекции, используя протокол и результат для генерации web-страницы. Варианты, касающиеся документа, декодированы CGI-аргументом и сохранены в объекте для дальнейшей работы. Чтобы отыскать документ на сервере коллекции, необходим только идентификатор документа, чтобы установить запрос протокола к get_document (). Как только текст найден, должно быть произведено значительное форматирование. Для этого программа доступа к documentaction сохраняет аргумент и использует объект Format и Макроязык. На рисунке показан пример просмотра, где пользователь выбрал Titles А-Z (Заголовки A-Z) и обратился к гиперсвязи для символа К. Это происходит благодаря действию documentaction, которое задается CGI -аргументом a=d. Однако, до подключения переменной d стоит оговориться, что в данном случае она не была использована. Вместо этого использовался узел в пределах доступной для просмотра иерархии классификации, чтобы отобразить определенную переменную cl. В данном примере она представляет заголовки, сгруппированные символом К. Этот список был сформирован во время компановки и сохранен в информационной базе данных коллекции.

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

В качестве последнего примера мы рассмотрим создание домашней страницы Greenstone . Рисунок демонстрирует домашнюю страницу Greenstone, установленную со значениями по умолчанию. Ее URL, который вы можете видеть наверху экрана, включает аргументы а=р np=home. Таким образом, подобно странице "about this collection" (об этой коллекции), она была сгенерированара^еасй'ои (а=р), но на сей раз применялось home (p=home). Поэтому макроязык обращается к содержанию home.dm. В данном случае нет никакой набодности определять коллекцию (с переменной с). The purpose of the home page is to show what collections are available. Clicking on an icon takes the user to the “about this collection” page for that collection. The menu of collections is dynamically generated every time the page is loaded, based on the collections that are in the file system at that time. When a new one comes online, it automatically appears on the home page when that page is reloaded (provided the collection is stipulated to be “public”). To do this the receptionist uses the protocol (of course). As part of appraising the CGI arguments, pageaction is programmed to detect the special case when p=home. Then, the action uses the protocol call get_collection_list() to establish the current set of online collections. For each of these it calls get_collectinfo() to obtain information about it. This information includes whether the collection is publicly available, what the URL is for the collection's icon (if any), and the collection's full name. This information is used to generate an appropriate entry for the collection on the home page.

setpasswd/	Password support for Windows.
getpw/	Password support for Unix.
txt2db/	Convert an XML-like ASCII text format to Gnu's database format.
db2txt/	Convert the Gnu database format to an XML-like ASCII text format.
phind/	Hierarchical phrase browsing tool.
hashfile/	Compute unique document ID based on content of file.
mgpp/	Rewritten and updated version of Managing Gigabytes package in C++.
w32server/	Local library server for Windows.
checkis/	Specific support for installing Greenstone under Windows.

The source code for the runtime system resides in GSDLHOME/src. It occupies two subdirectories, recpt for the receptionist's code and colservr for the collection server's. Greenstone runs on Windows systems right down to Windows 3.1, and unfortunately this imposes an eight-character limit on file and directory names. This explains why cryptic abbreviations like recpt and colservr are used. The remaining subdirectories include standalone utilities, mostly in support of the building process. They are listed in Table . Another directory, GSDLHOME/lib, includes low-level objects that are used by both receptionist and collection server. This code is described in Section . Greenstone широко использует Standard Template Library (STL)/ Стандартную библиотеку шаблонов С ++,- созданную Silicon Graphics (www.sgi.com), которая является результатом многих лет разработки и развития. Подобно всем библиотекам программирования, она требует некоторого времени на изучение. Приложение А дает краткий обзор ключевых частей, которые используются всюду в программе Greenstone. Для более полного ознакомления обращайтесь к официальному STL справочному руководству, доступному на сайте www.sgi.com, или к одному из многих учебников STL, например Josuttis (1999).

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

typedef vector<unsigned short> usvector; class text_t { protected: usvector text; unsigned short encoding; // 0 = unicode, 1 = other public: // constructors text_t (); text_t (int i); text_t (char *s); // assumed to be a normal c string void setencoding (unsigned short theencoding); unsigned short getencoding (); // STL container support iterator begin (); iterator end (); void erase(iterator pos); void push_back(unsigned short c); void pop_back(); void reserve (size_type n); bool empty () const {return text.empty();} size_type size() const {return text.size();} // added functionality void clear (); void append (const text_t &t); // support for integers void appendint (int i); void setint (int i); int getint () const; // support for arrays of chars void appendcarr (char *s, size_type len); void setcarr (char *s, size_type len); };

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

class text_t { // ... public: text_t &operator=(const text_t &x); text_t &operator+= (const text_t &t); reference operator[](size_type n); text_t &operator=(int i); text_t &operator+= (int i);^ \\ text_t &operator= (char *s); text_t &operator+= (char *s); friend inline bool operator!=(const text_t& x, const text_t& y); friend inline bool operator==(const text_t& x, const text_t& y); friend inline bool operator< (const text_t& x, const text_t& y); friend inline bool operator> (const text_t& x, const text_t& y); friend inline bool operator>=(const text_t& x, const text_t& y); friend inline bool operator<=(const text_t& x, const text_t& y); // ... };

Существует множество перегруженных операторов , которые не показаны на рисунке . Особо значимые операторы представлены на рисунке . Строка 4 поддерживает назначение одного объекта text_t другому, а строка 5 перегружает оператор+ = , чтобы обеспечить более естественный способ добавления одного объекта text_t в конец другого. Также возможно через строку 6 обратиться к специфическому символу Unicode (представленному как short), используя знак массива []. Далее необходимо назначить и добавить в конец операторы, предназначенные для строк C++ и целых чисел. Строки 12-18 представляют Булевы операторы для того, чтобы сравнить два объекта text_t: равно, не равно, предшествует в алфавитном порядке и так далее. Функция-член, которая берет аргумент const вместо не-const, также имеется (но на рисунке не показана). Такое повторение стандартно для объектов C++, делая API более весомым, но не более концептуальным. В действительности, многие из этих функций представлены как отдельные действующие инструкции. Для более подробного изучения обратитесь к исходному файлу GSDLHOME/lib/text_t.h. Файлы заголовка в GSDLHOME/lib включают смесь функций и объектов, что обеспечивает поддержку работы системы Greenstone. Для большей эффективности отношения, функции и функции-члены объявлены как inline. Для большей части подробности выполнения содержатся в копии файла заголовка .срр. Теперь детально объясним все объекты в концептуальной структуре рисунка . Мы начнем с низа диаграммы, который является также основой системы, и с Search (Поиск), Source (Источник), РШег(Филыр) и продолжим наш путь через уровень протокола к центральным компонентам в регистраторе: Actions (Действия), Format (Формат) и Macro Language (Макроязык). Затем мы сосредоточимся на объектной инициализации, так как это будет проще понять, если уже известна роль различных объектов. Большинство классов, центральных в концептуальной структуре, выражено с использованием виртуального наследования, чтобы помочь расширяемости. При виртуальном наследовании унаследованные объекты можно передать по кругу, как их базовый класс, но когда вызвана функция-член, ее версия определена в призванном унаследованном объекте. Гарантируя, что исходная программа Greenstone использует базовый класс повсюду, кроме точки объекта конструкции, это означает, что различное выполнение - использование возможно на основе радикально различных технологий - может быть легко размещено на месте. Например, предположим, что базовый класс по имени BaseCalc обеспечивает основную арифметику: сложение, вычитание, умножение и деление. Если все его функции объявлены виртуальными, а аргументы и возвратные типы все объявлены как строки, мы можем легко осуществить наследование версии объекта. Один из них, названный FixedPrecisionCalc, мог бы использовать библиотечные функции С, чтобы совершать конвертацию между строками и целыми числами и обратно, осуществляя вычисления, используя стандартные арифметические операторы: +, -, *, и /. Другой, названный InfinitePrecisionCalc, мог бы обращаться к строковым аргументам и символам одновременно, осуществляя арифметические операции с бесконечной точностью. Написанная главная программа использует BaseCalc повсюду, параметры ее работы могут регулироваться переключением между установленной точностью и бесконечной точностью, редактируя только одну строку: пункт, где создан объект - калькулятор.

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 };

Рисунок демонстрирует листинг базового классф API для объекта Search (см. рисунок ). Это определяет две виртуальные функции-члены: search() и docTargetDocument(). Из рисунка видно, что =0, который следует за описанием аргумента, это функция риге, означающая, что класс, который наследует объект, должен осуществить обе функции (иначе компилятор выдаст сообщение). Класс также включает два защищенных поля данных: collectdir и cache. Объект Search иллюстрируется примерами для специфической коллекции, а поле collectdir используется для хранения системы файлов (и что еще более важно - их файлы индекса) в месте нахождения коллекции. Поле сасйесохраняет результат запроса. Это используется, чтобы ускорить обработку последующих запросов, которые будут дублировать этот запрос (и его параметры). В то время, как идентичные вопросы могут казаться маловероятными, фактически они происходят регулярно. Протокол Greenstone является простым. Чтобы сгенерировать страницу результатов, подобную изображенной на рисунке , но для документов с 11 по 20 того же самого запроса, поиск роизводится снова, на сей раз оговорив заранее, возврат документов 11-20. Кэширование делает это эффективным, тот факт, что поиск был уже выполнен, обнаруженные результаты могут быть извлечены прямо из кэша. Оба поля данных применимы к каждому унаследованному объекту, который осуществляет механизм поиска. Это - то, почему они появляются в азовом классе, и объявлены защищенной секцией класса так, чтобы унаследованные классы могли получить доступ к ним непосредственно. Greenstone использует MG (сокращенно от Managing Gigabytes, CM.Witten et al., 1999) для индексации и восстановления документов, исходная программа включена в директорию GSDLHOME/packages. 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 показан на рисунке . Способ передачи параметров к MG - через mgq_ask (), который берет варианты текста в формате, идентичном используемому в командной строке: mgq_ask( ".set casefold off "); Это также используется при вызове запроса. К результатам обращаются через mgq_results, который использует указатель на функцию, как ее четвертый параметр. Это обеспечивает гибкий способ преобразования информации, возвращенной в структуру данных MG по требованию mgsearchclass. Вызов mgqjiumdocs О, mgqjiumterms () и mgq_docsretrieved () также возвращает информацию, но на сей раз с более жесткими условиями. Последние два оказывают поддержку при восстановлении.

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 (см. рисунок ) - доступ к метаданным и тексту документа. Его базовый класс представлен на рисунке . Функция-член наносит на карту к каждой задаче: getjnetadata () и get_document () соответственно. Оба объявлены virtual, так что версию, обеспечивающуюся выполнением базового класса, вызывают во время работы. Одна унаследованная версия этого объекта использует GDBM, чтобы запустить get_metadata 0 и MG, чтобы запустить get_document (): мы детализируем эту версию ниже. Другая функция-член представлена на рисунке - configure^, init () и translate_OID Q. Первые два касаются процесса инициализации, описанного в Разделе . Оставшаяся, translate_OID (), работает с синтаксисом для того, чтобы выразить идентификаторы документа. На рисунке мы видели, как номер страницы мог быть добавлен в конец к идентификатору документа, чтобы вызвать только эту страницу. Это было возможно, потому что страницы были идентифицированы как "разделы" при формировании коллекции. Добавление в конец " . 1" к OID вызывает первый раздел соответствующего документа. Разделы могут быть вложенными и доступны для обращения благодаря определенному номеру, разделенному периодами. Так же, как иерархические номера разделов, синтаксис идентификатора документа поддерживает форму относительного доступа. Для текущего раздела документа возможно получить доступ к first child, добавляя в конец /с, к last child, добавляя в конец .1с, к parent, добавляя в конец .рг, к next sibling, добавляя в конец .ns и ^previous sibling, добавляя в конец .ps. Функция translate_OID () использует параметры OIDin и OIDout, чтобы хранить исходный вариант и результат преобразования. Требуется два дополнительных параметра - err и logout. Они сообщают любой статус ошибки, который может возникнуть во время перевода, и решают, когда и куда послать регистрационную информацию. Параметры являются близкими союзниками протокола, мы к этому вернемся в Разделе . Программа GDBM - менеджер базы данных GNU (www.gnu.org). Она осуществляет простую структуру записей пар ключ/данные и совместима с DBM и NDBM. Операции включают хранение, исправление и удаление записей по ключу, а также пресечение всех незаказанных ключей.

[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;\ ...

Рисунок представляет фрагмент информационной базы данных коллекции, которая создана при формировании коллекции Gutenberg. Фрагмент был создан, используя утилиту db2txt системы Greenstone, которая конвертирует GDBM двойной формат базы данных в текстовую форму. Рисунок содержит три записи, отделенные горизонтальными линиями. Первый - вход документа, другие два - часть иерархии, созданной классификатором AZList для заголовков коллекции. Первая строка каждой записи - ее ключ. Запись документа хранит заглавие книги, автора и любые другие метаданные, созданные (или извлеченные) во время формирования коллекции. Запись такжебывает для внутреннего пользования и хранит информацию о том, где находятся файлы, связанные с этим документом (<archivedir>), и номер документа, используемый внутри MG (<docnum>). Поле <contains> хранит список элементов, отделенных точками с запятой. Это точки, связывающие записи в базе данных. Для записи документа <contains> используется, чтобы указать на вложенные разделы. Последующие ключи записи сформированы, связывая текущий ключ с одним из дочерних элементов (отделенных периодом). Вторая запись на рисунке - главный узел для иерархии классификации Titles A—Z. Его дети доступны через поле <contains>, включая CL 1.1, CL1.2, CL1.3 и так далее, соответствующие индивидуальным страницам для символов А, В, С и т.д. Имеется только 24 ребенка: классификатор AZList слил Q-R и Y-Z вхождения, потому что они охватили только несколько заглавий. Дети в поле <contains> третьей записи, CL 1.1,- это конечные документы. Возможны и более сложные структуры - поле <contains> может включать смесь документов в качестве CL узлов. Ключи, выраженные относительно текущего, отличают от абсолютных ключей, потому что они начинаются с кавычек (").

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. Рисунок демонстрирует его API. Две новых функции-члена set_gdbmptr () и set_mgsearchptr () хранят указатели на соответствующие им объекты, так, чтобы при выполнении getjnetadata О и get_document () иметь доступ к соответствующим инструментальным средствам для завершения работы.

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 (см. рисунок ) показан на Рисунке . Он начинается с защищенных полей данных gsdlhome, collection и collectdir. Они обычно происходят в классах, которые должны обратиться к определенным коллекцией файлам. gsdlhome точно такой же, как GSDLHOME, предназначен для того, чтобы объект мог определить местонахождение файлов Greenstone. collection - имя каталога, соответствующего коллекции. collectdir - полное имя пути к каталогу коллекции (это необходимо, потому что коллекция не должна постоянно находиться в пределах GSDLHOME области). mggdbsourceclass - другой класс, который включает эти три поля данных. Функции-члены conflgure() и init() (ранее упоминавшиеся в sourceclass) используются процессом инициализации. Сам объект находится недалеко от соответствующей части фильтра протокола; в особенности getjilteroptions О и fllter() соответствуют один другому.

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; };

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

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

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()	Получает документ или раздел документа.

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

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); };

Рисунок показывает API для нулевого протокола. Комментарии и некоторые подробности низкого уровня были опущены (см. исходный файл recpt/nullproto.h для получения подробностей). Этот протокол наследовался от базового класса recptproto. Виртуальное наследование используется так, чтобы больше, чем один тип протокола, даже не задуманного, все же мог легко поддерживаться остальной частью исходной программы. За исключением get_protocol_name (), который не использует параметры и возвращает имя протокола как строку текста Unicode, все функции протокола включают параметр ошибки и выходной поток, как последние два аргумента. Параметр ошибки делает запись любых ошибок, которые происходят в ходе выполнения запроса протокола, а выходной поток используется для регистрации цели. Функции относятся к типу void - они не возвращают информацию как их заключительная инструкция, но вместо этого возвращают данные через определяемые параметры типа уже введенного параметра ошибки. В некоторых языках программирования такие подпрограммы были бы определены как процедуры, а не функции, но C++ не делает никакого синтаксического различия. Большинство функций использует имя коллекции как параметр. Три функции-члены, get_filteroptions (), filterQ, и get_document (), следуют за обеспечением параметра Request и получением результатов в параметре Response.

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

action	Базовый класс для виртуального наследования.
authenaction	Поддержка идентификации пользователя: запрос пользователю относительно пароля, если не был введен; проверка правильности; возможность предоставления пользователю повторного входа, если достаточное время истекло между доступами.
collectoraction	Генерирует страницы для Collector (Создателя).
documentaction	Отыскивает документы, разделы документа, части иерархии классификации или информацию для форматирования .
extlinkaction	Переносит пользователя непосредственно к URL, который является внешним для коллекции, no-возможности сначала генерируя аварийную страницу (продиктованную установками Preferences).
pageaction	Генерирует страницу вместе с макроязыком. pingaction Выясняет, интерактивна ли коллекция. queryaction Выполняет поиск.
pingaction	Checks to see whether a collection is online.
queryaction	Performs a search.
statusaction	Генерирует страницы администрирования.
tipaction	Выдает случайный совет для пользователя.
usersaction	Добавляет поддержку, удаление и управление пользовательским доступом.

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

cgiarginfo arg_ainfo; arg_ainfo.shortname = " a " ; arg_ainfo.longname = " action" ; arg_ainfo.multiplechar = true; arg_ainfo.argdefault = " p" ; arg_ainfo.defaultstatus = cgiarginfo::weak; arg_ainfo.savedarginfo = cgiarginfo::must; argsinfo.addarginfo (NULL, arg_ainfo); arg_ainfo.shortname = " p" ; arg_ainfo.longname = " page" ; arg_ainfo.multiplechar = true; arg_ainfo.argdefault = " home" ; arg_ainfo.defaultstatus = cgiarginfo::weak; arg_ainfo.savedarginfo = cgiarginfo::must; argsinfo.addarginfo (NULL, arg_ainfo);

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

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); };

Рисунок показывает 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 - это защищенное поле данных (используемое в выборке программы, см.рисунок ), которое хранит информацию CGI-аргумента, указанную в унаследованной функции конструктора Action. Другое поле данных, gsdlhome, создает запись GSDLHOME для удобного доступа. Объект также включает conflgure() и init () с целью инициализации.

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; };

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

Этот процесс лучше всего объяснить на примере. Когда оператор задания формата format CL1Vlist "[link][Title]{If}{[Creator], by [Creator]}[/link]} " читается из файла конфигурации коллекции, он анализируется функциями в formattools.cpp и формирует связанные структуры данных, показанные на рисунке . Значение для gsdlhome исходит из gsdlsite.cfg, расположенного в том же самом каталоге, что и CGI-выполняемая library, тогда как GSDLHOME устанавливается запуском скрипта setup, который обращается к другому файлу, так как технически это возможно для двух различных значений. Хотя это и возможно, но все же не желательно, и все вышесказанное написано в предположении, что файлы те же самые. Когда оператор задания формата должен быть оценен действием, структура данных пересекается. Маршрут, предпринятый в comIf и comOr узлах, зависит от метаданных, которые возвращают запрос протоколу. Одно осложнение состоит в том, что, когда метаданные найдены, они могут включать последующие макросы и формат синтаксиса. При необходимости это обрабатывается переключеним назад и вперед между синтаксическим анализом и оценкой, как необходимо. Macro Language, представленный на рисунке , так же, как Format не является функцией одного класса C++. В этом случае - это основной класс, но выполнение макроязыка также вызывает функции поддержки и классы. И снова в объяснении используем пример. Сначала мы даем некоторые типовые макроопределения, которые иллюстрируют макростаршинство, затем, при помощи диаграммы, мы описываем основные структуры данных, сформированные, чтобы поддержать эту деятельность. Наконец, мы представляем и описываем открытые функции-члены displayclass, макрообъекта верхнего уровня.

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

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

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. Его открытые функции-члены показаны на рисунке . Класс читает указанные макрофайлы, используя loaddefaultmacros (), сохраняя в защищенном разделе класса (не показан) тип структуры данных, показанной на рисунке . Для макроса также допустимо быть установленным системой поддержки выполнения, используя setmacro () (в последнем примере Раздела , 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. Инициализация в Greenstone - сложная операция, которая обрабатывает файлы конфигурации и присваивает полям данных значения по умолчанию . В дополнение к наследованию и функциям конструктора, основные объекты определяют функции init () и conflgure(), чтобы помочь стандартизовать задачу. Даже в этом случае порядок выполнения может быть затруднен. Настоящий раздел описывает как все это происходит. Greenstone использует несколько файлов конфигурации для различных целей, но все они используют один и тот же синтаксис. Если строка не начинается с хэш-символа (#) или состоит полностью из пустого пространства, первое слово определяет ключевое слово, а остающиеся слова представляют установку частности для того ключевого слова. Строки файлов конфигурации передают, по одному, для conflgure() два параметра: ключевое слово и массив остающихся слов. Основанная на ключевом слове, специфическая версия выбора configure() решает, представляет ли информация интерес, и если это так то сохраняет ее. Например, collectserver (который показан на рисунке ), обрабатывает операторы задания формата в файле конфигурации коллекции. Когда формат ключевого слова передают configure(), оператор if запускает сохраненную в объекте копию второго аргумента функции. После обработки ключевого слова и прежде, чем функция закончит выполнение, некоторые версии conflgure() передают данные функции configure() в других объектах. Объект Receptionist (регистратор) вызывает выбор configureQ для Actions , Protocols и Browsers. Объект NullProtocol вызывает conflgure() для каждого объекта Collection; Collection вызывает Filters и Sources. В C++ поля данных обычно инициализируются функцией конструктора объекта. Однако, в Greenstone некоторая инициализация зависит от чтения значений из файлов конфигурации, так что необходим второй раунд инициализации. Это - цель init () функции-члена, в некоторых случаях она ведет к последующему вызову conflgure().

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

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

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

	Значение	Цель
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-аргументов могут быть определены внутри файла конфигурации main.cfg. Вернемся к рисунку , из которого видно, что большинство CGI -аргументов определено непосредственно в пределах программы библиотеки C++. Однако, иногда полезно определить новые аргументы или отредактировать существующие во время процесса конфигурации, таким образом избегая потребности перетранслировать библиотеку. Чтобы сделать это, вы должны использовать опцию конфигурации cgiarg. Cgiarg может использовать до шести параметров; shortname, longname, multiplechar, argdefault, defaultstatus и savedarginfo. Эти параметры соответствуют вариантам CGI-аргумента, описанным в Разделе . Например, в значении по умолчанию main.cfg опция конфигурации cgiarg используется, чтобы установить значения по умолчанию существующих а и р CGI-аргументов дляр и home соответственно. Параметры страницы - частные случаи CGI-аргументов, которые соответствуют параметрам в файлах макрокоманды Greenstone. Например, CGI-аргумент /непосредственно соответствует параметру / = в макрофайлах. Чтобы определить CGI-аргумент, который также может быть параметром страницы, используйте опцию конфигурации pageparam. Лучший способ узнать о различных вариантах конфигурации, возможных в файле конфигурации main-cfg, состоит в том, чтобы экспериментировать непосредственно с этим файлом. Обратите внимание на то, что если вы используете локальную Windows-версию библиотеки Greenstone, то прежде чем любые изменения файлов конфигурации вступят в силу, вам необходимо будет перезапустить сервер.

Line	Function
gsdlhome	A path to the GSDLHOME directory.
httpprefix	The web address of GSDLHOME. If the document root on your web server is set to GSDLHOME you do not need this line.
httpimage	The web address of the directory containing the images for the user interface. If your web-server's document root is set to GSDLHOME this will be /images.
gwcgi	The web address of this cgi script (usually ends in library). This is not needed if your web server sets the environment variable SCRIPT_NAME.
maxrequests	(Only applies if fast-cgi is in use.) The number of requests fast-cgi should process before it exits. When debugging the library this should be set to a small number, otherwise it should be a large number.

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

Стандартная Библиотека Шаблонов (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.

#include <iostream.h> #define nil 0 struct intlist { int val; struct intlist* next; }; int total_int_list(intlist* head) { int total = 0; intlist* curr = head; while (curr!=nil) { total += curr->val; curr = curr->next; } return total; } void main() { intlist node1 = { 5, nil }; intlist node2 = { 4, nil }; node2.next = &node1; int total = total_int_list(&node2); cout << " List items total to: " << total << endl; }

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

#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; }

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

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

#include <iostream.h> #include <map> int total_int_table(map<char*, int>& table) { int total = 0; map<char*, int>::iterator curr = table.begin(); while (curr!=table.end()) { total += (curr->second); curr++; } return total; } int main() { map<char*, int> table; table["Alice"] = 31; table["Peter"] = 24; table["Mary"] = 47; int total = total_int_table(table); cout << " Age total: " << total << endl; }

В STL ассоциативные массивы достигаются использованием объекта тар. Рисунок показывает придуманный пример, в котором возраст трех человек (Алиса, Питер и Мэри) хранится в ассоциативном массиве под их собственными именами (строки 19-22). Проблема состоит в том, чтобы записать функцию, которая вычисляет полный возраст людей, не зная, сколько их имеется или каковы их имена. Конечно, это могло бы быть решено с использованием стандартных числовых массивов целых чисел. Данный пример был придуман, чтобы продемонстрировать, что особенности тар производят подобие обработки с объектом list совместно с iterator. Подобно list, map относится к классу-контейнеру. Однако, при объявлении переменной этого типа мы должны определить две вещи: индексный тип, и тип элемента. Как вы могли заметить в строке 19, мы получаем ассоциативный массив, который сохраняет целые числа, используя char* (который является строкой, объявленной в C++) как индексный тип, сопровождаемый int в качестве типа элемента. Есть несколько способов сохранить элементы в ассоциативном массиве. В данном примере в строках 20-22 перегруженный массив описывается, используя [], чтобы инициализировать таблицу с возрастами этих трех человек. Подобно total_int_table, который исполняет основное вычисление в программе, на рисунке используется 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. Для операционных систем Windows 95/98 запуск setup.bat может закончиться неудачно, и система выдаст сообщение об ошибке "Out of environment space". Если это призошло, то вам необходимо отредактировать системный файл config.sys (обычно он находится в C:\config.sys) и добавить в него строку shell=C:\command.com /e:4096 /p (где С: имя вашего системного диска). Для того, чтобы эти изменения вступили в силу, необходимо перезагрузить ваш компьютер и повторить все шаги для запуска Greenstone. Обратите внимание, что в системе Greenstone стандартные выражения интерпретируются языком Perl, который несколько отличается от других. Например, "*" соответствует нулю или большему количеству повторений предыдущего символа, в то время как "."-паре любых символов. Так, nugget.* соответствует любой строке с префиксом "nugget," содержит ли она или нет пробел после префикса. Чтобы учесть этот пробел, необходимо его обойти, для этого нужно написать nugget\.. *. Note that more recent versions of the Demo collection use a Hierarchy classifier to display the how to metadata. In this case they will be displayed slightly differently to what is shown in Figure . начение для gsdlhome исходит из gsdlsite.cfg, расположенного в том же самом каталоге, что и CGI-выполняемая library, тогда как GSDLHOME устанавливается запуском скрипта setup, который обращается к другому файлу, так как технически это возможно для двух различных значений. Хотя это и возможно, но все же не желательно, и все вышесказанное написано в предположении, что файлы те же самые. Технически есть четыре типа, но последние два являются дополнительными. Так как мы только даем основное введение в этот класс STL, подробности об этих последних двух типах опущены.