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

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

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

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

<tblcaption table_options_applicable_to_all_plugins|Опции, применяемые для всех приложений></tblcaption>

<tblcaption table_greenstone_plugins|Greenstone plugins></tblcaption>

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

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

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

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

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

<tblcaption table_plugin-specific_options|Опции, специфичные для приожений></tblcaption>

|

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

<imgcaption figure_plugin_inheritance_hierarchy|%!– id:537 –%Иерархическая структура наследования приложений ></imgcaption>

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

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

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

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

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

<imgcaption figure_xml_format|%!– id:547 –%(a) %!– id:546 –%Формат XML. a) Document Type Definition (DTD); б) пример файла ></imgcaption>

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

<imgcaption figure_xml_format_1|%!– id:549 –%(b) %!– id:548 –% ></imgcaption>

<?xml version="1.0" ?>
<!DOCTYPE GreenstoneDirectoryMetadata SYSTEM
"http://greenstone.org/dtd/GreenstoneDirectoryMetadata/<br/>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 описывает файл, к которому относятся метаданные, в виде стандартного выражения. Таким образом, <FileName>nugget. *</FileName> указывает на то, что первая запись метаданных относится ко всем файлам, чье имя начинается с "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.

<imgcaption figure_azlist_classifier|%!– id:566 –%Классификатор AZList ></imgcaption>

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

<imgcaption figure_list_classifier|%!– id:568 –%Классификатор List ></imgcaption>

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

<imgcaption figure_datelist_classifier|%!– id:570 –%Классификатор DateList ></imgcaption>

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

<imgcaption figure_hierarchy_classifier|%!– id:572 –%Классификатор Hierarchy ></imgcaption>

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

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

<tblcaption table_greenstone_classifiers|Классификаторы Greenstone></tblcaption>

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

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

<imgcaption figure_part_of_the_file_sub|%!– id:618 –%Part of the file sub.txt ></imgcaption>

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 дает имя файла, как показано на рисунке <imgref figure_part_of_the_file_sub>, которое определяет иерархию метаданных. Каждая строка описывает одну классификацию, а описания состоят из трех частей:

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

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

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

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

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

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

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

<tblcaption table_items_appearing_in_format_strings|Элементы “формата строки”></tblcaption>

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

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

<tblcaption table_the_format_options|Опции format></tblcaption>

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

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

<imgcaption figure_excerpt_from_the_demo_collection_collect|%!– id:674 –%Выборка из файла collectcfg Демонстрационной коллекци %!– withLineNumber –%></imgcaption>

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"

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

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

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

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

<imgcaption figure_formatting_the_document|%!– id:679 –%Форматирование документа ></imgcaption>

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

<imgcaption figure_formatting_the_search_results|%!– id:681 –%Форматирование результатов поиска ></imgcaption>

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

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

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

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

<td valign=top>[link][icon][/link]</td> <br/><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 Рисунка <imgref figure_excerpt_from_the_demo_collection_collect>, представляем полный формат строки

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

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

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

classify AZSectionList metadata=Creator
format CL2Vlist "<td>[link][icon][/link]</td> <br/><td>[Creator]</td> <br/><td>&nbsp;&nbsp;[Title]</td> <br/><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 использует /параметр во время запуска, чтобы определить язык отображения.

<imgcaption figure_part_of_the_aboutdm_macro_file|%!– id:714 –%Part of the about.dm macro file ></imgcaption>

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

В заключение приведем рисунок <imgref figure_part_of_the_aboutdm_macro_file>, на котором представлен отрывок макрофайла 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.

<tblcaption table_the_packages_directory_1|Директория packages></tblcaption>

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