След Пред Содержание

4. Gatherer

4.1 Обзор

Gatherer получает информационные ресурсы используя различные стандартные методы доступа (FTP, Gopher, HTTP, NNTP и локальные файлы), а затем суммирует эти ресурсы различными типизированными способами, чтобы создать структурированную индексную информацию. Например, Gatherer может получить технический отчет с FTP архива, а затем извлечь автора, заголовок и краткий обзор текста, чтобы создать резюме (summarize, далее для этого понятия будет использоваться термин ``суммировать'') технического отчета. Брокеры Harvest или другие поисковые сервисы могут затем получать индексную информацию от Gatherer'а для использования ее поисковом индексе, доступном через WWW интерфейс.

Gatherer состоит из большого числа отдельных компонентов. Программа Gatherer считывает конфигурационный файл Gatherer'а и контролирует весь процесс нумерации и резюмирования объектов данных.

Структурированная индексная информация, которую собирает Gatherer, представляется в виде списка пар "атрибут-значение" используя Форматом взаимообменов резюме объектов (Summary Object Interchange Format - SOIF, смотрите раздел The Summary Object Interchange Format (SOIF)). Демон gatherd предоставляет базу данных Gatherer'а Broker"ам. Он запускается в фоновом режиме по завершении процесса собирания. Отдельная программа gather - это клиент для сервера gatherd. Она может использована с командной строки для тестирования и используется Broker'ом. Gatherer использует кэш на локальном диске для хранения полученных объектов. Дисковый кэш описывается в разделе Дисковый кэш.

Несмотря на то, что демон gatherd остается в фоновом режиме, Gatherer не обновляет автоматически свои резюмированные объекты. Каждый объект у Gatherer'а имеет значение Time-to-Live (``время жизни''). Объекты остаются в базе данных до тех пор, пока они не устареют. Смотрите в разделе Периодическое собирание и обновления в реальном времени дополнительную информацию по хранению Gatherer'ом обновленных объектов.

Несколько примеров Gatherer'ов поставляются вместе с дистрибутивом с ПО Harvest (смотрите раздел Примеры Gatherer'ов).

4.2 Начальная установка

Чтобы запустить основной Gatherer, вам нужен только список URL'ов (смотрите RFC1630 и RFC1738), из которых он будет собирать индексную информацию. Этот список указывается в конфигурационном файле Gatherer'а вместе с прочей опциональной информацией, такой как имя Gatherer'а и каталог, в котором он размещен (обратитесь в раздел #Задание значений переменных в конфигурационном файле Gatherer'а за деталями по опциональной информации). Ниже приведен пример конфигурационного файла Gatherer'а:

        #
        #  sample.cf - Sample Gatherer Configuration File
        #
        Gatherer-Name:    My Sample Harvest Gatherer
        Gatherer-Port:    8500
        Top-Directory:    /usr/local/harvest/gatherers/sample

        <RootNodes>
        # Enter URLs for RootNodes here
        http://www.mozilla.org/
        http://www.xfree86.org/
        </RootNodes>

        <LeafNodes>
        # Enter URLs for LeafNodes here
        http://www.arco.de/~kj/index.html
        </LeafNodes>

Как показано в примере конфигурационного файла, можно классифицировать URL на RootNode и LeafNode. Что касается LeafNode URL, Gatherer просто получает URL и обрабатывает его. LeafNode URL'ы - это обычно файлы как документы PostScript или сжатые дистрибутивы ``tar''. Gatherer разложит RootNode URL на ноль или более LeafNode URL'ов, рекурсивно нумеруя их способами, зависящими от метода доступа. Для FTP или Gopher Gatherer представит листинг рекурсивных каталогов на сервере FTP или Gopher для разложения RootNode (обычно имя каталога). Для HTTP RootNode URL разлагается следованием ссылкам HTML на другие URL'ы. Для News нумерация возвращает все сообщения в указанной новостной группе USENET.

ПОЖАЛУЙСТА, БУДЬТЕ ОСТОРОЖНЫ при указании RootNode, так как можно задать гигантский объем работы одним лишь RootNode URL'ом. Чтобы предостеречь плохо сконфигурированный Gatherer от неправильного использования серверов, по умолчанию Gatherer разлагает RootNode на 250 LeafNode'ов, а также включает только те HTML линки, которые указывают на документы, которые находятся на том же сервере, что и оригинальный RootNode URL. Есть несколько опций, которые позволяют изменить эти ограничения и иным способом улучшить спецификации Gatherer'а. За деталями обратитесь к разделу Описание RootNode.

Gatherer - это ``robot'', он собирает URL'ы, начиная с URL'ов, указанных в RootNodes. Он следует соглашению robots.txt и robots META tag. Он также поддерживает протокол HTTP версии 1.1 и отправляет поля User-Agent и запросы From серверам HTTP для идентификации.

После того, как вы написали конфигурационный файл Gatherer'а, создайте каталог для Gatherer'а и скопируйте туда конфигурационный файл. Затем запустите программу Gatherer из командной строки с единственным аргументом -- именем конфигурационного файла, как показано ниже:

        % Gatherer GathName.cf

Gatherer сгенерирует базу данных, содержащую резюме документов, log-файл (log.gatherer) и log-файл с ошибками (log.errors). Он также запустит демон gatherd, который автоматически поставляет индексную информацию брокерам и другим клиентам. Для просмотра экспортируемой индексной информации вы можете использовать клиентскую программу gather, как показано ниже:

        % gather localhost 8500 | more

Опция -info заставляет Gatherer выдавать только краткое описание документов в Gatherer'е, которое состоит из доступных в указанной базе данных Gatherer'а атрибутов, хоста и имени Gatherer'а, список времен обновлений объектов и числа объектов. По умолчанию установлена компрессия, но ее можно отменить опцией -nocompress. Опциональная метка времени говорит Gatherer'у посылать только объекты, которые изменились со времени, указанном в метке (в секундах с начала ``эпохи'' UNIX - 1 января 1970г).

Сбор новостных URL'ов (News) при помощи NNTP

URL'ы News отличаются от других протоколов доступа, потому что URL в основном не содержит имени хоста. Gatherer получает новостные URL'ы от сервера NNTP. Имя сервера должно быть помещено в переменную окружения $NNTPSERVER. Возможно, хорошая идея - добавить ее в ваш скрипт RunGatherer. Если переменная окружения не установлена, Gatherer попытается подсоединиться к хосту с именем news на вашем сайте.

Очистка Gatherer'а

Помните, что базы данных Gatherer'а продолжают существовать между запусками. Объекты остаются в в базе данных, пока не устареют. Эксперементируя с Gatherer'ом, всегда является хорошей идеей ``очистка'' базы данных между запусками. Проще всего это осуществить, выполнив команду из каталога Gatherer'а:

        % rm -rf data tmp log.*

4.3 Описание RootNode

Средства описания RootNode, описанные в разделе Начальная установка, предоставляют основной набор действий нумерации RootNode по умолчанию. Обычно полезно нумеровать, не ограничиваясь пределами по умолчанию, например, чтобы увеличить пределы нумерации (больше 250 URL'ов) или чтобы позволить пересечение границ сайтов при нумерации линков HTML. Можно указать эти и другие аспекты нумерации следующим образом:

        <RootNodes>
        URL EnumSpec
        URL EnumSpec
        ...
        </RootNodes>

где EnumSpec - одна строка (используя ``\'' при переходе на новую строку) со следующим синтаксисом:

        URL=URL-Max[,URL-Filter-filename]  \
        Host=Host-Max[,Host-Filter-filename] \
        Access=TypeList \
        Delay=Seconds \
        Depth=Number \
        Enumeration=Enumeration-Program

Все модификаторы EnumSpec опциональные и имеют следующие значения:

URL-Max

Число, указываемое справа в выражении ``URL='' показывает максимальное число URL'ов LeafNode URLs, которые нужно сгенерировать на всех уровнях глубины индексации, начиная от текущего URL. Заметьте, что URL-Max - это максимальное число URL'ов которые генерируются во время нумерации, а не ограничение на то, сколько URL'ов может пройти через фазу выбора кандидата (смотрите раздел Настройка шага выбора кандидата).

URL-Filter-filename

Это имя файла, содержащего набор фильтров из регулярных выражений (смотрите раздел Фильтры RootNode) для разрешения или запрета отдельных LeafNode при нумерации. По умолчанию используется фильтр $HARVEST_HOME/lib/gatherer/URL-filter-default, который исключает много изображений и звуковых файлов.

Host-Max

Число, указанное справа в выражении ``Host='' показывает максимальное число хостов, которое может быть использовано для нумерации RootNode. Хосты обычно подсчитываются по своим IP-адресам, таким образом хосты, имеющие несколько алиасов учитываются один раз. Но это не работает для хостов, имеющих несколько IP-адресов или хостов, DNS именами которых управляет какая-нибудь программа (например, для уравновешивания загрузки серверов).

Замечание: До версии Harvest 1.2 строка ``Host=...'' называлась ``Site=...''. Мы изменили имя на ``Host='', потому что оно интуитивно более понятно (ограничение на число хостов, а не сайтов). Для совместимости с конфигурационными файлами старых Gatherer'ов мы будем продолжать использовать ``Site='' как алиас для ``Host=''.

Host-Filter-filename

Это имя файла, содержащего набор регулярных выражений - фильтров для разрешения или запрещения определенных хостов в нумерации. Каждое выражение может определять как имя хоста (или IP-адрес), так и номер порта (в случае, если у вас есть несколько серверов на различных портах одной машины, а вы хотите проиндексировать только один из них). Синтаксис - ``hostname:port''.

Access

Если RootNode - это HTTP URL, тогда вы можете указать методы доступа, которыми нужно производить нумерацию. Возможные типы методов доступа: FILE, FTP, Gopher, HTTP, News, Telnet или WAIS. Используйте символ ``|'' между именами типов для разрешения нескольких методов доступа. Например, ``Access=HTTP|FTP|Gopher'' зайдет на URL'ы HTTP, FTP и Gopher при нумерации HTTP URL'а RootNode.

Замечание: Мы не поддерживаем перекрестные методы нумерации в Gopher, потому что трудно убедиться, что указатели Gopher не пересекают границ сайта. Например, URL Gopher gopher://powell.cs.colorado.edu:7005/1ftp3aftp.cs.washington.edu40pub/ получит листинг каталога FTP ftp.cs.washington.edu:/pub, несмотря на то, что часть URL с именем хоста -- powell.cs.colorado.edu.

Delay

Это число секунд ожидания между контактами с серверами. По умолчанию оно равно одной секунде, если не указано другое. Delay=3 позволит Gatherer'у ждать 3 секунды между контактами.

Depth

Это максимальное число уровней нумерации (глубина) во время собирания информации. Depth=0 означает, что нет ограничений на глубину нумерации. Depth=1 означает, что будет получен указанный URL, а также все URL'ы, на которые есть ссылки в указанном URL'е; и так далее для более больших значений Depth. Другими словами, Gatherer будет следовать по ссылкам вплоть до Depth шагов от указанного URL'а.

Enumeration-Program

Этот модификатор добавляет очень удобный способ контролирования Gatherer'а. Enumeration-Program - это фильтр, который считываетs URL'ы, как входные параметры, и записывает новые параметры нумерации на выходе. Обратитесь к разделу Описание настраиваемой программы нумерации за отдельными деталями.

По умолчанию, URL-Max равно 250, URL-Filter не делает ограничений, Host-Max равно 1, Host-Filter не делает ограничений, Access равен HTTP, Delay равен 1 секунде, а Depth равно нулю. Нет способа указать неограниченное значение для URL-Max или Host-Max.

Фильтры RootNode

Файлы-фильтры используют стандартный синтаксис регулярных выражений UNIX (как определено стандартом POSIX), а не синтаксис csh. Например, нужно использовать ``.*abc'' для обозначения любой строки, заканчивающейся на ``abc'', но не ``*abc''. Файл-фильтр имеет следующий синтаксис:

        Deny  regex
        Allow regex

Регулярные выражения в URL-Filter сопостовляются только с той часьтю каждого URL, которая указывает путь (схема, имя хоста и порт не включаются). Например, следующий файл URL-Filter позволит нумеровать все URL'ы, кроме содержащих регулярное выражение ``/gatherers/'':

        Deny  /gatherers/
        Allow .

Другое общее использование фильтров URL заключается в запрещении перехода Gatherer'а в вышестоящий каталог. Автоматически сгенерированные страницы HTML для HTTP и FTP каталогов часто содержат ссылку на родительский каталог ``..''. Чтобы держать Gatherer ниже указанного каталога, используйте файл фильтров URL следующим образом:

        Allow ^/my/cool/sutff/
        Deny  .

Регулярные выражения Host-Filter сопоставляются по части ``hostname:port'' каждого URL. Из-за включения в выражение port, вы не можете использовать ``$'' для выделения конца имени хоста. Начиная с версии 1.3, вместо имени хоста может быть указан IP-адрес. Адрес кдасса B, такой как 128.138.0.0 в регулярных выражениях должен быть написан в виде ``^128\.138\..*''. Например:

        Deny   bcn.boulder.co.us:8080
        Deny   bvsd.k12.co.us
        Allow  ^128\.138\..*
        Deny   .

Важен порядок строк Allow и Deny, так как фильтры применяются последовательно от первой строки к последней. Так, например, если вы укажете сперва ``Allow .*'', никакие последующие выражения Deny не будут обработаны, так как этот фильтр Allow разрешит все записи.

Описание програмы нумерации

Гибкая нумерация может быть достигнута указанием модификатора Enumeration=Enumeration-Program в RootNode URL. Enumeration-Program - это фильтр, который принимает на стандартный вход URL и записывает новые RootNode URL на стандартный выход.

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

        URL
        URL-Max
        URL-Filter-filename
        Host-Max
        Host-Filter-filename
        Access
        Delay
        Depth
        Enumeration-Program

Это те же самые поля, которые описаны в разделе Описание RootNode. Значения должны даваться в каждом поле. Используйте /dev/null для отмены имен файлов URL-Filter и Host-Filter. Испольлзуйте /bin/false для отмены программы Enumeration.

Пример конфигурации RootNode

Ниже приведен пример конфигурации RootNode:

        <RootNodes>
  (1)   http://harvest.cs.colorado.edu/               URL=100,MyFilter
  (2)   http://www.cs.colorado.edu/                   Host=50 Delay=60
  (3)   gopher://gopher.colorado.edu/                 Depth=1
  (4)   file://powell.cs.colorado.edu/home/hardy/     Depth=2
  (5)   ftp://ftp.cs.colorado.edu/pub/cs/techreports/ Depth=1
  (6)   http://harvest.cs.colorado.edu/~hardy/hotlist.html \
                Depth=1 Delay=60
  (7)   http://harvest.cs.colorado.edu/~hardy/ \
                Depth=2 Access=HTTP|FTP
        </RootNodes>

Каждый из приведенных выше RootNode содержит различную конфигурации нумерации:

  1. Этот RootNode будет собирать вплоть до 100 документов, которые пройдут через фильтры URL, содержащиеся в файле MyFilter.
  2. Этот RootNode соберет документы из первых 50 хостов, которые встретятся при нумерации указанного URL без ограничения на глубину ссылок. Он также будет ждать 60 секунд после получения каждого документа.
  3. Этот RootNode соберет документы только с верхнего уровня сервера Gopher на gopher.colorado.edu.
  4. Этот RootNode соберет все документы из каталога /home/hardy и всех подкаталогов /home/hardy.
  5. Этот RootNode соберет документы только из каталога /pub/techreports, который, в данном случае, содержит некоторые библиографические файлы, а не сами технические отчеты.
  6. Этот RootNode соберет все документы, которые находятся в одном шаге от указанного URL с интервалом в 60 секунд. Это удобный способ индексирования вашего ``хотлиста''. Если создать файл HTML, содержащий такие ``горячие'' указатели, как этот RootNode, то процесс нумерации соберет страницы верхнего уровня для каждого указателя.
  7. Этот RootNode соберет все документы, которые находятся не дальше, чем в двух шагах от указанного URL. Более того, он проследует и пронумерует любые HTTP и FTP ссылки, которые встретятся.

Нумерация Gatherer'а и выбор кандидатов

Кроме использования файлов URL-Filter и Host-Filter в механизме определения RootNode, описанного в разделе Описание RootNode, вы можете предотвратить индексацию документов, настроив файл stoplist.cf, описанный в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения представлений и суммирования. Так как эти механизмы включаются в разное время, они могут иметь различные эффекты. Механизмы URL-Filter и Host-Filter вовлекаются программой Gatherer'а нумерации ``RootNode''. Использование этих фильтров, как стоп-списков, может предотвратить скачивание нежелаемых объектов через сеть. Это существенно может уменьшить время собирания и сетевой трафик.

Файл stoplist.cf используется системой извлечения содержания Essence (описана в разделе Извлечение данных для индексации: Подсистема суммирования Essence) после того, как объекты уже получены, чтобы выбрать, из каких объектов должно быть извлечено содержание и какие объекты должны быть проиндексированы. Это может быть полезным, так как Essence предоставляет более мощные средства отклонения кандидатов на индексацию, при помощи которых вы можете настроить выбор объектов не только на основе имен файлов, но и на основе их содержания (например, посмотрев на строчки в начале файла или на ``магические'' числа UNIX). Также можно использовать более сложные схемы группирования файлов (например, решив не извлекать содержание из файлов объектного кода, если доступен исходный код).

В качестве примера комбинирования этих механизмов, предположим, что вы хотите проиндексировать файлы ``.ps'', имеющиеся на вашем WWW сайте. Вы можете сделать это, создав файл stoplist.cf, который содержит ``HTML'' и фильтр RootNode URL-Filter:

        Allow \.html
        Allow \.ps
        Deny  .*

В заключение, независимо от этих настроек, Gatherer попытается избежать скачивание объектов, где это возможно, используя кэш на локальном диске и заголоки HTTP запросв ``If-Modified-Since'' (если есть изменения с такого-то времени). Кэш на локальном диске описан в разделе Дисковый кэш.

4.4 Генерация LeafNode/RootNode URL'ов из программы

Можно генерировать RootNode или LeafNode URL'ы автоматически из программы. Это может оказаться полезным, например, при собирании большого числа новостных групп Usenet. Пргорамма указывается в разделе RootNode или LeafNode, вместе с вертикальной чертой.

        <LeafNodes>
        |generate-news-urls.sh
        </LeafNodes>

Скрипт должен выдавать правильные URL'ы, такие как

        news:comp.unix.voodoo
        news:rec.pets.birds
        http://www.nlanr.net/
        ...

В случае URL'ов RootNode, параметры нумерации могут быть заданы после программы.

        <RootNodes>
        |my-fave-sites.pl Depth=1 URL=5000,url-filter
        </RootNodes>

4.5 Извлечение данных для индексации: Подсистема суммирования Essence

После того, как Gatherer получает документ, он пропускает его через подсистему, называемую Essence, чтобы извлечь информацию для индекса. Essence позволяет Gatherer'у собирать этот индекс из большого разнообразия информации различными способами в зависимости от типа данных и потребностей данного индексируемого блока. В кратце, Essence может определить тип данных, на которые указывает URL (напрмер, PostScript или HTML), ``распутать'' форматы представления (такие как сжатые файлы ``tar''), выбрать, какой тип данных индексировать (например, не индексировать аудио файлы), и потом применить соответствующий алгоритм (называемый summarizer) для генерации резюме содержимого данных. Пользователи могут настроить каждый из этих аспектов, но зачастую в этом нет необходимости. Harvest распространяется со стандартным набором распозавателей типов, архиваторов (извлечение представлений), избирателей кандидатов и summarizer'ов, которые хорошо работают для большинства приложений.

Ниже мы описываем стандартный набор summarizer'ов, компонент текущего дистрибутива, и как пользователи могут настроить summarizer'ы и добавить свои для новых типов данных. Если вы разрабатывате summarizer, который, вероятно, может быть полезен другим пользователям, пожалуйста, сообщите нам по e-mail'у на lee@arco.de, так что мы сможем включить его в наш дистрибутив Harvest'а.

Тип             Функция summarizer'а
--------------------------------------------------------------------
Bibliographic   Извлечение автора и заголовка
Binary          Извлечение смысловых строчек и резюме страниц руководства (manual page summary)
C, CHeader      Извлечение имен процедур, имен включенных файлов и комментариев
Dvi             Вызов summarizer'а текста на извлеченный ASCII текст
FAQ, FullText, README
                Извлечение всех слов в файле
Font            Извлечение комментариев
HTML            Извлечение выделений, гиперссылок и выбраных полей
LaTex           Разбор выбраных полей LaTex (автор, заголовок и т.д.)
Mail            Извлечение определенных полей заголовка
Makefile        Извлечение комментариев и имен целей
ManPage         Извлечение резюме, автора, заголовка и т.д. на основе макроса ``-man''
News            Извлечение определенных полей заголовка
Object          Извлечение таблицы символов
Patch           Извлечение имен ``пропаченых'' файлов
Perl            Извлечение имен процедур и комментариев
PostScript      Извлечение текста определенным обработчиком слов (word processor) и пропуск
                через summarizer текста.
RCS, SCCS       Извлечение revision control summary
RTF             Конвертирование в HTML и пропуск через HTML summarizer
SGML            Извлечение полей, названных в таблице извлечений
ShellScript     Извлечение комментариев
SourceDistribution
                Извлечение полного текста файла README и комментариев из Makefile
                и файлов исходного кода, и суммирование всех man-страниц
SymbolicLink    Извлечение имени файла, владельца и даты создания
TeX             Вызов summarizer'а текста на извлеченный ASCII текст
Text            Извлечение первых 100 строк и первых предложений всех оставшихся
                абзацев
Troff           Извлечение автора, заголовка и т.д. на основе макропакетов ``-man'', ``-ms'',
                ``-me'', или извлечение заголовков разделов и
                тем.
Unrecognized    Извлечение имени файла, владельца и даты создания.

Действия стандартных summarizer'ов по умолчанию

Таблица в разделе Извлечение данных для индексации: Подсистема суммирования Essence снабжает короткой справкой о том, как документы суммируются в зависимости от их типа. Эти действия могут быть настроены, как обсуждалось в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования. Некоторые summarizer'ы реализованы как программы UNIX, в то время как другие выражаются регулярными выражениями; обртитесь в раздел Настройка шага суммирования или раздел Пример 4 за информацией о том, как написать summarizer.

Суммирование данных SGML

Можно суммировать документы, которые удовлетворяют Стандартному обобщенному языку верстки (Standart Generalized Markup Language, SGML), для которого у вас есть Определение типа документа (Document Type Definition, DTD). HTML -- это на самом деле частное приложение SGML с соответствующим DTD. (HTML summarizer Harvest'а может использовать HTML DTD и наш механизм суммирования SGML, который предоставляет множество преимуществ; см. раздел HTML summarizer на основе SGML.) SGML используется во все более увеличивающемся широком разнообразии приложений, например как формат для хранения данных для большого числа физических наук. Так как SGML позволяет документам иметь хорошую структуру, Harvest может суммировать документы SGML очень эффективно.

Summarizer SGML (SGML.sum) использует программу sgmls Джеймса Кларка (James Clark) для разбора документов SGML. Парсеру нужен и DTD документа, и файл деклараций, который описывает допустимый набор символов. Программа SGML.sum использует таблицу, которая сопоставляет тэги SGML с атрибутами SOIF.

Размещение вспомогательных файлов

Вспомогательные файлы SGML можно найти в $HARVEST_HOME/lib/gatherer/sgmls-lib/. Например, вот пути по умолчанию для суммирования HTML, используя механизм суммирования SGML:

        $HARVEST_HOME/lib/gatherer/sgmls-lib/HTML/html.dtd
        $HARVEST_HOME/lib/gatherer/sgmls-lib/HTML/HTML.decl
        $HARVEST_HOME/lib/gatherer/sgmls-lib/HTML/HTML.sum.tbl

Размещение файла DTD должно быть указано в каталоге sgmls ($HARVEST_HOME/lib/gatherer/sgmls-lib/catalog). Например:

        DOCTYPE   HTML   HTML/html.dtd

Программа SGML.sum ищет файл .decl, используя путь по умолчанию. Другой путь может быть указан SGML.sum опцией -d.

Summarizer ищет файл .sum.tbl сначала в каталоге Gatherer'а lib, а потом по пути по умолчанию. Свой путь можно указать SGML.sum опцией -t.

Таблица соответствий SGML - SOIF

Таблица перевода снабжает простым, но мощным средством указания, как документ SGML должен быть суммирован. Есть четыре способа сопоставить данные SGML с SOIF. Первые два касаются помещения содержания (content) тэга SGML в атрибут SOIF.

Простое сопоставление SGML и SOIF выглядит примерно так:

        <TAG>              soif1,soif2,...

Оно помещает все, что находится между тэгами ``TAG'' в атрибуты SOIF ``soif1'' и ``soif2''. Можно выбрать различные атрибуты SOIF на основе значений атрибутов SGML. Например, если ``ATT'' - атрибут тэга ``TAG'', то надо написать так:

        <TAG,ATT=x>         x-stuff
        <TAG,ATT=y>         y-stuff
        <TAG>               stuff

Два других способа заключаются в помещении атрибутов SGML в атрибуты SOIF. Чтобы поместить значения атрибута ``ATT'' тэга ``TAG'' в атрибут SOIF ``att-stuff'' нужно написать:

        <TAG:ATT>           att-stuff

Также можно поместить значение атрибута SGML в атрибут SOIF, используя другой атрибут SOIF:

        <TAG:ATT1>          $ATT2

Когда summarizer встречает атрибут SGML, не занесенный в таблицу, содержимое отнесется к родительскому тэгу и станет частью содержимого родительского тэга. Чтобы не обрабатывать содержимое какого-то тэга, укажите атрибут SOIF как ``ignore''. Чтобы содержимое некоторого тэга было рассмотрено также и в родительском тэге в дополнение к помещению в свой атрибут SOIF, занесите в таблицу дополнительный атрибут SOIF под названием ``parent''.

Обратитесь в раздел HTML summarizer на основе SGML за примерами таких сопоставлений.

Ошибки и предупреждения парсера SGML

Парсер sgmls может генерировать большой объем сообщений об ошибках и предупреждениях. Это в особенности справедливо для документов HTML, находящихся в Internet, которые часто не соответствуют строгому DTD HTML. По умолчанию, ошибки и предупреждения направляются в /dev/null так что они не будут засорять логи Gatherer'а. Чтобы включить эти сообщения в логи, отредактируйте Perl скрипт SGML.sum и установите $syntax_check = 1.

Создание summarizer'а для новых типов данных SGML

Чтобы создать summarizer SGML для новых типов данных SGML с соответствующим DTD, вам нужно сделать следующее:

  1. Напишите скрипт оболочки shell под именем FOO.sum, который просто содержит
            #!/bin/sh
            exec SGML.sum FOO $*
          
    
  2. Модифицируйте конфигурационные файлы essence (как описано в разделе Настройка шага распознавания типов), чтобы ваш документ был понят как тип FOO.
  3. Создайте каталог $HARVEST_HOME/lib/gatherer/sgmls-lib/FOO/ и скопируйте туда DTD и файл деклараций как FOO.dtd и FOO.decl. Отредактируйте $HARVEST_HOME/lib/gatherer/sgmls-lib/catalog и добавьте туда FOO.dtd.
  4. Создайте таблицу переводов FOO.sum.tbl и поместите ее вместе с DTD в $HARVEST_HOME/lib/gatherer/sgmls-lib/FOO/.

Теперь можно протестировать все из командной строки:

        % FOO.sum myfile.foo

HTML summarizer на основе SGML

Harvest может суммировать HTML, используя свой SGML summarizer, описанный в разделе Суммирование данных SGML. Преимущество такого подхода заключается в том, что summarizer более просто настраивается, и удовлетворяет хорошо продуманной модели SGML (где вы можете определить DTD для отдельных типов документов и создать интерпретирующее для понимания DTD, а не отдельных типов документов). Минус в том, что теперь summarizer более придирчив к синтаксису, а большинство документов Web синтаксически не корректны. Из=за такой придирчивости, по умолчанию для HTML отключена выдача результатов проверки синтаксиса. Если ваши документы так плохо организованы, что запутывают парсер, это может означать, что процесс суммирования бесцеремонно умирает. Если вы обнаружите, что ваши документы HTML не суммировались или суммировались частично, вы можете включить выдачу результатов проверки синтаксиса, установив $syntax_check = 1 в $HARVEST_HOME/lib/gatherer/SGML.sum. Это позволит вам увидеть, какие документы неправильные и где-именно.

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

Ниже приведена таблица SGML-SOIF, используемая по умолчанию HTML summarizer'ом:

Элемент HTML    Атрибуты SOIF
------------   -----------------------
    <A>             keywords,parent
    <A:HREF>        url-references
    <ADDRESS>       address
    <B>             keywords,parent
    <BODY>          body
    <CITE>          references
    <CODE>          ignore
    <EM>            keywords,parent
    <H1>            headings
    <H2>            headings
    <H3>            headings
    <H4>            headings
    <H5>            headings
    <H6>            headings
    <HEAD>          head
    <I>             keywords,parent
    <IMG:SRC>       images
    <META:CONTENT>  $NAME
    <STRONG>        keywords,parent
    <TITLE>         title
    <TT>            keywords,parent
    <UL>            keywords,parent

Путь к этому файлу -- $HARVEST_HOME/lib/gatherer/sgmls-lib/HTML/HTML.sum.tbl.

Отдельные Gatherer'ы могут производить настроенное суммирование HTML, если поместить модифицированную версию этого файла в каталог Gatherer'а lib. Другой способ настройки -- модифицировать скрипт HTML.sum и добавить опцию -t команде SGML.sum. Например:

        SGML.sum -t $HARVEST_HOME/lib/my-HTML.table HTML $*

В HTML заголовок документа записывается так:

        <TITLE>My Home Page</TITLE>

Выше приведенная таблица переводов поместит резюме SOIF так:

        title{13}:  My Home Page

Отметим, что ``keywords,parent'' встречаются в таблице часто. Для любого выделенного текста (жирный, курсив, гиперссылки и т.д.), слова будут скопированы в атрибут keywords (ключевые слова) и также останутся в содержимом родительского элемента. Так сохраняется тело читаемого текста, и определенные слова не удаляются.

Любой текст, который появляется внутри пары тэгов CODE, не будет показан в резюме, так как мы указали ``ignore'' в качестве атрибута SOIF.

URL'ы в HTML записываются так:

        <A HREF="http://harvest.cs.colorado.edu/">

Указание <A:HREF> в таблице переводов занесет URL в атрибут SOIF как:

        url-references{32}: http://harvest.cs.colorado.edu/

Добавление META данных в ваш HTML

Один из наиболее полезных тэгов HTML- META. Он позволяет автору документа включить произвольные метаданные в документ HTML. Типичное применение элемента META:

        <META NAME="author" CONTENT="Joe T. Slacker">

Указав ``<META:CONTENT> $NAME'' в таблице переводов, вы получите:

        author{15}: Joe T. Slacker

Используя тэги META, авторы HTML могут легко добавть список ключевых слов в свои документы:

        <META NAME="keywords" CONTENT="word1 word2">
        <META NAME="keywords" CONTENT="word3 word4">

Другие примеры

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

Элемент HTML   Атрибуты SOIF
------------   -----------------------
    <A>             keywords
    <B>             keywords
    <EM>            keywords
    <H1>            keywords
    <H2>            keywords
    <H3>            keywords
    <I>             keywords
    <META:CONTENT>  $NAME
    <STRONG>        keywords
    <TITLE>         title,keywords
    <TT>            keywords

Наоборот, полнотекстовый summarizer можно легко сделать так:

Элемент HTML   Атрибуты SOIF
------------   -----------------------
    <HTML>          full-text
    <TITLE>         title,parent

Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования

Действия Gatherer'а определяются набором конфигурационных файлов, утилит и соответствующим набором исполняемых программ, на которые ссылаются конфигурационные файлы.

Если вы хотите настроить Gatherer, вам нужно создать подкаталоги bin и lib в каталоге, где вы запускаете Gatherer, а потом скопировать $HARVEST_HOME/lib/gatherer/*.cf и $HARVEST_HOME/lib/gatherer/magic в ваш каталог lib. Потом добавьте в конфигурационный файл вашего Gatherer'а:

        Lib-Directory:         lib

Ниже описаны детали о том, что делает каждый из этих файлов. Основное содержание типичного каталога Gatherer'а следующее (отметим: некоторые имена файлов ниже можно изменить, установив переменные в конфигурационнм файле Gatherer'а, как описано в разделе Задание значений переменных в конфигурационном файле Gatherer'а):

        RunGatherd*    bin/           GathName.cf    log.errors     tmp/
        RunGatherer*   data/          lib/           log.gatherer

        bin:
        MyNewType.sum*

        data:
        All-Templates.gz    INFO.soif    PRODUCTION.gdbm    gatherd.log
        INDEX.gdbm          MD5.gdbm     gatherd.cf

        lib:
        bycontent.cf   byurl.cf       quick-sum.cf
        byname.cf      magic          stoplist.cf

        tmp:

RunGatherd и RunGatherer используются, чтобы экспортировать базу данных Gatherer'а после перезапучка машины и запуска Gatherer'а,соответственно. Файлы log.errors и log.gatherer содержат сообщения об ошибках и вывод программы Essence, соответственно (Essence будет коротко описан). Файл GathName.cf - это конфигурационный файл Gatherer'а.

Каталог bin содержит все summarizer'ы и другие программы, которые нужны summarizer'ам. Если бы вам нужно было настроить Gatherer, добавив summarizer, вам нужно было бы поместить соответствующие программы в этот каталог bin; MyNewType.sum - пример.

Каталог data содержит базу данных Gatherer'а, которую экспортирует gatherd. База данных Gatherer'а состоит из файлов All-Templates.gz, INDEX.gdbm, INFO.soif, MD5.gdbm и PRODUCTION.gdbm. Файл gatherd.cf используется для поддержки контроля доступа, что описано в разделе Контроль доступа к базе данных Gatherer'а. В файл gatherd.log программа gatherd заносит свою информацию (логи).

Каталог lib содержит конфигурационные файлы, используемы подсистемами Gatherer'а, а именно Essence. Эти файлы коротко описаны в следующей таблице:

        bycontent.cf    Эвристика разбора содержания для распознавания типов
        byname.cf       содержит эвристики для распознавания типов по именам файлов
        byurl.cf        содержит эвристики для распознавания типов по URL
        magic           инструкции команды ``file'' UNIX (соотвествующие строкам
                        bycontent.cf)
        quick-sum.cf    Извлекает атрибуты на шаге суммирования
        stoplist.cf     содержит типы файлов, которые нужно отклонить на шаге выбора кандидатов

Настройка шага распознавания типов

Essence распознает типы тремя способами (в порядке приоритета): по названиям URL, по названиям файлов и определяя иденцифицирующие данные в файле, используя команду (file) UNIX.

Чтобы изменить шаг распознавания типов, отредактируйте lib/byname.cf для добавления эвристики по имени файла, или lib/byurl.cf для добавления эвристики по URL, или lib/bycontent.cf для добавления эвристики по содержимому. Эвристика по содержимому согласовывается с выходом комманды file, так что возможно также понадобится отредактировать файл lib/magic. Обратитесь в разделы Пример 3 и Пример 4 за подробными примерами, как настроить шаг распознавания типов.

Настройка шага выбора кандидатов

Конфигурационный файл lib/stoplist.cf содержит список типов, которые отклоняются Essence. Вы можете добавить или удалить некоторые типы из lib/stoplist.cf для контроля шага выбора кандидатов.

Чтобы направить Essence индексировать только определенные типы, вы можете составить список типов для индексирования в lib/allowlist.cf. Потом укажите Essence флаг --allowlist.

Эвристики по именам файлов и URL, используемые на шаге распознавания типов (описано в разделе Настройка шага распознавания типов), в особенности полезны для выбора кандидаьов при собирании удаленных данных. Они позволяют Gatherer'у избежать получение файлов, которые вы не хотите индексировать (в отличие от этого распознавание типов определением иденцифицирующих данных внутри фалйа требует сначала получение файла). Такой подход может сохранить достаточно много сетевого трафика, особенно при индексировании RootNode URL'ов. Например, много сайтов предлагают свои файлы как в сжатом, так и не в сжатом виде. Создав lib/allowlist.cf, содержащий только сжатые типы, вы сможете избежать получение несжатых версий файлов.

Настройка шага извлечения представлений

Некоторые типы объявлены как ``уплотненные'' (nested). Essence трактует их не так, как другие типы, он запускает алгоритм извлечения представлений или ``Exploder'' лдя этих данных, а не Summarizer. На данный момент Essence может работать с файлами, сжатыми в следующих форматах:

  1. binhex
  2. uuencode
  3. shell archive (``shar'')
  4. tape archive (``tar'')
  5. bzip2 compressed (``bzip2'')
  6. compressed
  7. GNU compressed (``gzip'')
  8. zip compressed archive

Чтобы настроить щаг извлечения представлений, вы можете модифицировать исходный файл Essence src/gatherer/essence/unnest.c. Этот файл выдает список доступных кодировок представления, а также указывает алгоритм расжатия. Обычно используется внешняя программа для раскрывания файла в один или более файлов-компонент (например bzip2, gunzip, uudecode, и tar).

Exploder также можно использовать для преобразования файла в поток объектов SOIF. Программа Exploder принимает URL как первый аргумент в командной строке и файл, содержащий данные, как второй аргумент, а потом генерирует один или более объектов SOIF на выходе. Для вашего удобства, тип Exploder уже определен как уплотненный тип (nested type). Для сохранения некоторго времени вы можете использовать этот тип и соответствующую программу Exploder.unnest, а не модифицировать код Essence.

Обратитесь в раздел Пример 2 за подробным примером по написанию Exploder'а. Файл unnest.c также содержит информацию по определению алгоритмов расжатия.

Настройка шага суммирования

Essence поддерживает два механизма для определения алгоритмов извлечения по типу (называемые Summarizer'ами), которые генерируют резюме содержимого (summaries): программа UNIX, которая принимает имя файла для суммированя в качестве одного аргумента в командной строке, и регулярные выражения, указанные в lib/quick-sum.cf. Обратитесь в раздел Пример 4 за подробными примерами, как определять оба типа Summarizer'ов.

Summarizer'ы UNIX принято называть TypeName.sum (например, PostScript.sum). Эти Summarizer'ы выдают на выходе резюме содержимого в виде списка атрибут SOIF - значение (см. раздел Формат взаимообмена краткими изложениями документов (SOIF)). Вы можете использовать команду wrapit для облечения сырой выход в формат SOIF (т.е., для расстановки разграничителей на отдельные пары атрибут-значение).

Есть summarizer, называемый FullText.sum, который вы можете использовать для представления полнотекстового индексирования выбранного типа файлов просто заставив конфигурационные файлы lib/bycontent.cf и lib/byname.cf распознавать желаемые типы файлов как FullText (т.е., напишите ``FullText'' напротив соответствующего регулярного выражения).

4.6 Пост-суммирование: настройка резюме объектов (object summaries) по правилам

Возможна ``тонкая настройка'' резюме, сгенерированных summarizer'ами Essence. Типичным приложением этого может быть изменение атрибута Time-to-Live (время жизни), основанного на некоторых сведениях о объекте. Так, администратор может использовать свойства пост-суммирования и дать быстро меняющимся объектам малый TTL, а очень стабильным документам - большой TTL.

Объекты выбираются для пост-суммирования, если они удовлетворяют указанным условиям. Условие состоит из трех частей: имя атрибута, оператор, и некоторая строка данных. Например: some string data. For example:

        city == 'New York'

В этом случае мы проверяем, равен ли атрибут city строке ``New York''. Для точного совпадения строк, строка должна быть заключена в одинарные кавычки. Также поддерживаются регулярные выражения:

        city ~ /New York/

Также поддерживаются отрицательные операторы:

        city != 'New York'
        city !~ /New York/

Условия могут быть объединены операторами `&&' (логическое ``И'') или `||' (логическое ``ИЛИ''):

        city == 'New York' && state != 'NY';

Если объект удовлетворяет всем условиям, над ним выполняется несколько инструкций. Можно указать четыре типа инструкций:

  1. Установить атрибуту точно заданное значение. Например:
            time-to-live = "86400"
          
    
  2. Отфильтровать атрибут какой-нибудь программой. Значение атрибута подается на вход фильтра. Фильтр выдает новое значение атрибута. Например:
            keywords | tr A-Z a-z
          
    
  3. Отфильтровать множественные атрибуты программой. В этом случае фильтр должен прочитать и записать атрибуты в формате SOIF. Например:
            address,city,state,zip ! cleanup-address.pl
          
    
  4. Особый случай инструкций - удалить объект. Чтобы сделать это, напишите просто:
            delete()
          
    

Файл правил

Условия и инструкции объединены вместе в файле правил (``rules'' file). Формат этого файла чем-то напоминает формат файла Makefile; условия начинаются в первой колонке, а инструкции отделяются табуляцией.

Например:

        type == 'HTML'
                partial-text | cleanup-html-text.pl

        URL ~ /users/
                time-to-live = "86400"
                partial-text ! extract-owner.sh

        type == 'SOIFStream'
                delete()

Файл правил указывается в файле gatherer.cf при помощи тэга Post-Summarizing, например:

        Post-Summarizing: lib/myrules

Rewriting URLs

До версии 1.4 невозможно было переписать часть резюме, содержащую URL. Сейчас это возможно, но только при помощи инструкции ``pipe''. Это может оказаться полезным для людей, желающих запустить Gatherer для URL'ов типа file://, но которые должны показываться как http://. Сделать это можно с таким правилом пост-суммирования как:

        url ~ 'file://localhost/web/htdocs/'
                url | fix-url.pl

А скрипт `fix-url.pl' может выглядеть так:

        #!/usr/local/bin/perl -p
        s'file://localhost/web/htdocs/'http://www.my.domain/';

4.7 Администрирование Gatherer'а

Задание значений переменных в конфигурационном файле Gatherer'а

Кроме настроек, описанных в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования, вы можете настроить Gatherer, установив переменные в конфигурационном файле Gatherer'а. Этот файл состоит из двух частей: список переменных, которые указывают информацию о Gatherer'е (такую как его имя, хост, и номер порта), и два списка URL (разделенных на RootNodes и LeafNodes), из которых нужно собирать индексируемую информацию. Раздел Начальная установка содержит пример конфигурационного файла Gatherer'а. В этом разделе мы сосредоточим внимание на переменных, которые может установить пользователь в первой части конфигурационного файла Gatherer'а.

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

        Access-Delay:           Задержка по умолчанию между доступами к URL.
        Data-Directory:         Каталог, куда записывается база данных GDBM.
        Debug-Options:          Опции отладчтка, передаваемые дочерним программам.
        Errorlog-File:          Файл для записи ошибок.
        Essence-Options:        Любые дополнительные опции для программы Essence.
        FTP-Auth:               Имя пользователя/пароль для защищенных документов FTP.
        Gatherd-Inetd:          Обознчает, что gatherd запущен из inetd.
        Gatherer-Host:          Полное имя хоста, на котором запущен Gatherer.
        Gatherer-Name:          Униакльное имя Gatherer'а.
        Gatherer-Options:       Дополнительные опции для Gatherer'а.
        Gatherer-Port:          Номер порта для демона gatherd.
        Gatherer-Version:       Версия Gatherer'а.
        HTTP-Basic-Auth:        Имя пользователя/пароль для защищенных документов HTTP.
        HTTP-Proxy:             хост:порт вашего HTTP прокси.
        Keep-Cache:             ``yes'', чтобы не удалять кэш на локальном диске.
        Lib-Directory:          Каталог, в котором "живут" конфигурационные файлы.
        Local-Mapping:          Преобразование информации для локального собирания.
        Log-File:               Файл для записи логов.
        Post-Summarizing:       Файл правил для пост-суммирования.
        Refresh-Rate:           Скорость обновления объектов в секундах, по умолчанию 1 неделя.
        Time-To-Live:           Время жизни объектов в секундах, по умолчанию 1 месяц.
        Top-Directory:          Каталог верхнего уровня для Gatherer'а.
        Working-Directory:      Каталог для временных файлов (tmp) и локального кэша.

Замечания:

Опции Essence:

Опция                   Значение
--------------------------------------------------------------------
--allowlist filename    Файл со списком допустимых типов
--fake-md5s             Генерирует MD5 для объектов SOIF из программы .unnest
--fast-summarizing      Увеличивает скорость за счет согласованности данных. Используйте только,
                        когда уверены, что внешний summarizer будет генерировать чистые,
                        уникальные атрибуты.
--full-text             Использует весь файл вместо резюме. Также вы
                        можете получить полный текст, индексируя отдельные типы
                        файлов, используя summarizer FullText.sum.
--max-deletions n       Число удалений GDBM перед реорганизацией
--minimal-bookkeeping   Генерирует минимальное число атрибутов учета системных ресурсов
--no-access             Не читать содержимое объектов
--no-keywords           Не генерировать ключевые слова автоматически
--stoplist filename     Файл со списком типов, которые подлежат удалению
--type-only             Только типы данных; не суммировать объекты

Особенное замечание о полнотекстовом суммировании: Использование опции Essence --full-text запрещает файлам проходить через механизм извлечения содержания Essence. Вместо этого, все содержимое файлов включается в поток резюме SOIF. В некоторых случаях это может привести к нежелательным результатам (например, программа сразу включит PostScript, а не пропустит сначала его через переводчик данных из PostScript в текст, предоставляя несколько терминов, поддающихся поиску, и большие объекты SOIF). Использование механизма суммирования отдельных типов файлов, описанное в разделе Настройка шага суммирования, будет лучше работать в этом случае, но потребует от вас указать, как должны извлекаться данные для каждого отдельного типа файлов. В следующих версиях Harvest мы заменим опцию Essence --full-text, чтобы выполнять извлечение содержимого перед включением полного текста документов.

Собирание на локальной файловой системе для сниженной загрузки процессора

Хотя рабочая нагрузка Gatherer'а определяется указываемыми URL'ами, часто собираемые файлы размещены в локальной файловой системе. В этом случае гораздо более эффективно собирать прямо с файловой системы, а не через FTP/Gopher/HTTP/News, в основном потому, что все требуемые порождаемые процессы UNIX должны собирать информацию через сетевые процессы. Например, наши измерения показывают, что процессор нагружен в 4-7 раз больше при собирании с FTP, чем прямо с локальной файловой системы. Для больших коллекций (например, архивные сайты, содержащие тысячи файлов), выигрыш процессорного времени может быть значительным.

Начиная с версии 1.1 Harvest'а стало возможным указать Gatherer'у, как транслировать URL'ы в имена локальной файловой системы, используя переменную Local-Mapping конфигурационного файла Gatherer'а (см. раздел Задание значений переменных в конфигурационном файле Gatherer'а. Синтаксис:

        Local-Mapping: URL_prefix local_path_prefix

Это заставит во время сбора транслироваться все URL'ы, начинающиеся с URL_prefix, в файлы, начинающиеся с local_path_prefix, но в результатах запросов будут оставаться URL'ы (поэтому объекты могут быть получены как обычно). Заметьте, что регулярные выражения здесь не поддерживаются. Например, указание

        Local-Mapping: http://harvest.cs.colorado.edu/~hardy/ /homes/hardy/public_html/
        Local-Mapping: ftp://ftp.cs.colorado.edu/pub/cs/ /cs/ftp/

заставит URL http://harvest.cs.colorado.edu/ hardy/Home.html транслироваться в локальное файловое имя /homes/hardy/public_html/Home.html, а URL ftp://ftp.cs.colorado.edu/pub/cs/techreports/schwartz/Harvest.Conf.ps.Z будет транслирован в имя /cs/ftp/techreports/schwartz/Harvest.Conf.ps.Z.

Локальное собирание будет работать с фаловой системой NFS. Локальное транслирование не удастся, если: локальные файлы не могут быть открыты для чтения; локальный файл - не регулярный файл (например, ссылка); у локального файла установлены биты на исполнение. Так, к каталогам, символическим ссылкам и сценариям CGI всегда обращается сервер, а не локальная файловая система. Наконец, Gatherer не предоставляет никаких преобразований синтаксиса URL для локального транслирования. Если ваш URL содержит управляющие символы (см. RFC1738), тогда локальное преобразование не удастся. Начиная с версии 1.4 (patchlevel 2) Essence печатает [L] после каждого URL, который был удачно обработан локально.

Заметье, что если ваша сеть сильно загружена, на самом деле может оказаться быстрее собрать через HTTP/FTP/Gopher, чем по NFS, так как NFS становится очень неэффективным в сильно нагруженных сетях. Гораздо лучше запускать свои Gatherer'ы на хостах на их собственных дисках и обращаться к ним прямо через локальную файловую систему.

Собирание с серверов, защищенных паролем

Вы можете собирать документы, защищенные паролем, с серверов HTTP и FTP. В обоих случаях, вы можете указать имя пользователя и пароль как часть URL. Формат следующий:

         ftp://user:password@host:port/url-path
        http://user:password@host:port/url-path

В таком формате, часть ``user:password'' хранится как часть строки URL во всем процессе обработки Harvest'ом. Это может позволить любому, кто имеет доступ у вашему брокеру, получить доступ к документам, защищенным паролем.

Вы можете хранить информацию с именем пользователя и паролем в ``спрятанном'' виде, указав индецифицирующую информацию в конфигурационном файле Gatherer'а. Для HTTP формат следующий:

        HTTP-Basic-Auth: realm username password

где realm - это то же самое, что и параметр AuthName в конфигурационном файле Apache httpd httpd.conf или файле .htaccess. В других конфигурациях сервера httpd значание realm иногда называется ServerId.

Для FTP формат в файле gatherer.cf следующий:

        FTP-Auth: hostname[:port] username password

Контроль доступа к базе данных Gatherer'а

Вы можете использовать файл gatherd.cf (помещенный в каталог Gatherer'а Data-Directory) для контроля доступа к базе данных Gatherer'а. В строке, начинающейся с Allow, соодержится произвольное число имен доменов или хостов, которым разрешено подключаться к Gatherer'у. Если используется слово all, тогда подходят все хосты. Deny имеет противоположное назначение к Allow. Следующий пример разрешит доступ к базе данных Gatherer'а только хостам из доменов cs.colorado.edu или usc.edu:

        Allow  cs.colorado.edu usc.edu
        Deny   all

Периодическое собирание и обновления в реальном времени

Программа Gatherer автоматически не совершает никаких периодических обновлений -- когда вы запустите ее, она обработает указанные URL'ы, запустит демон gatherd (если он уже не запущен), и затем прекратит работу. Если вы хотите периодически обновлять данные (например, чтобы получать новые файлы, как только они появлятся в FTP архиве), вам нужно использовать команду UNIX cron для запуска программы Gatherer с каким-то регулярным интервалом.

Чтобы установить периодическое собирание при помощи cron, используйте команду RunGatherer, которую создаст RunHarvest. Пример скрипта RunGatherer:

        #!/bin/sh
        #
        #  RunGatherer - Runs the ATT 800 Gatherer (from cron)
        #
        HARVEST_HOME=/usr/local/harvest; export HARVEST_HOME
        PATH=${HARVEST_HOME}/bin:${HARVEST_HOME}/lib/gatherer:${HARVEST_HOME}/lib:$PATH
        export PATH
        NNTPSERVER=localhost; export NNTPSERVER
        cd /usr/local/harvest/gatherers/att800
        exec Gatherer "att800.cf"

Вам следует запускать оманду RunGatherd из системного файла начальной загрузки (например, /etc/rc.local), чтобы база данных Gatherer'а экспортировалась всякий раз, когда машина перегружается. Пример скрипта RunGatherd:

        #!/bin/sh
        #
        #  RunGatherd - starts up the gatherd process (from /etc/rc.local)
        #
        HARVEST_HOME=/usr/local/harvest; export HARVEST_HOME
        PATH=${HARVEST_HOME}/lib/gatherer:${HARVEST_HOME}/bin:$PATH; export PATH
        exec gatherd -d /usr/local/harvest/gatherers/att800/data 8500

Дисковый кэш

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

По умолчанию, локальный кэш Gatherer'а удаляется после каждого удачного завершения. Чтобы сохранить кэш между сессиями Gatherer'а, определите переменную Keep-Cache: yes в конфигурационном файле Gatherer'а (раздел Задание значений переменных в конфигурационном файле Gatherer'а).

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

Если вы запускаете ваш Gatherer часто и используете Keep-Cache: yes в конфигурационном файле Gatherer'а, тогда локальный кэш Gatherer'а может перемешиваться с получаемыми обновлениями. По умолчанию объекты в локальном кэше устаревают через 7 дней; однако, вы можте заставить ``устаревать'' их быстрее, установив переменную окружения $GATHERER_CACHE_TTL, равную числу секунд для времени жизни (Time-To-Live, TTL) перед запуском Gatherer'а, или вы можете изменить RunGatherer, чтобы удалять каталог Gatherer'а tmp после каждого запуска Gatherer'а. Например, чтобы объекты устаревали в локальном кэше через один день:

        % setenv GATHERER_CACHE_TTL 86400       # one day
        % ./RunGatherer

Размер локального кэша Gatherer'а равен по умолчанию 32 MB, но вы можете изменить это значение, установив переменную окружения $HARVEST_MAX_LOCAL_CACHE равную числу MB перед запуском Gatherer'а. Например, для максимального размера кэша 10 MB вы можете проделать следующее:

        % setenv HARVEST_MAX_LOCAL_CACHE 10       # 10 MB
        % ./RunGatherer

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

Заметьте, что при использовании вместе с cron, Gatherer предоставляет мощную возможность ``зеркалирования'' данных (data ``mirroring''). Вы можете использовать Gatherer для дублирования содержимого одного или нескольких сайтов, получения данных в различных форматах по различным протоколам (FTP, HTTP, etc.), по желанию проделывать разнообразие преобразований данных в зависимости от их типа или сайта, и эффективно выдавать результаты в виде сжатых резюме объектов SOIF другим сайтам, которые хотят использовать данные для построения индексов или других целей.

Включение в Gatherer информации, сгенерированной вручную

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

Harvest имеет некоторые программы, которые автоматически вычищают базу данных Gatherer'а. Программа rmbinary удаляет любые двоичные данные из шаблонов объектов. Программа cleandb делает простое утверждение объектов SOIF, и если задан флаг -truncate, она обрежет поле данных Keywords до 8 килобайт. Чтобы помочь вручную управлять базами данных Gatherer'а, имеется средство управления базами данных GDBM gdbmutil в $HARVEST_HOME/lib/gatherer.

В будущих выпусках Harvest'а мы добавим механизм на основе форм, чтобы легко вручную вносить дополнения. А пока вы можете дополнять базу данных Gatherer'а информацией, написанной вручную, используя программы mktemplate, template2db, mergedb и mkindex. Сначала вам нужно создать файл (назовем его, скажем, annotations) в слеующем формате:

        @FILE { url1
        Attribute-Name-1:        DATA
        Attribute-Name-2:        DATA
        ...
        Attribute-Name-n:        DATA
        }

        @FILE { url2
        Attribute-Name-1:        DATA
        Attribute-Name-2:        DATA
        ...
        Attribute-Name-n:        DATA
        }

        ...

Заметьте, что атрибуты должны начинаться в нулевой колонке и должна быть одна табуляция после колонки, а данные (DATA) должны быть в пределах одной строчки.

Затем, запустите программы mktemplate и template2db, чтобы сгенерировать SOIF и потом версии GDBM этих данных (у вас может быть несколько файлов с дополнениями, и вы можете сгенерировать одну базу данных GDBM при помощи вышеуказанных команд):

        % set path = ($HARVEST_HOME/lib/gatherer $path)
        % mktemplate annotations [annotations2 ...] | template2db annotations.gdbm

Наконец, запустите mergedb, чтобы включить дополнения в автоматически сгенерированные данные, и mkindex, чтобы сгенерировать их индекс. Использование mergedb:

        mergedb production automatic manual [manual ...]

Идея заключается в том, что production - окончательная база данных GDBM database, которую будет обслуживать Gatherer. Это новая база данных, которая будет генерироваться из других баз в командной строке. automatic - это база данных GDBM, которую Gatherer сгенерировал в предыдущем запуске (наример, WORKING.gdbm или предыдущая PRODUCTION.gdbm). manual и т.д. - базы данных GDBM, которые вы создали вручную. Когда запускается mergedb, она строит базу данных production, сперва скопировав шаблоны из баз даных manual, а затем соединив с атрибутами атрибуты из базы данных automatic. В случае конфликта (одни и те же атрибуты имеют различные значения в базах manual и automatic), значения manual перевесят значения automatic.

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

Пример использования mergedb:

        % mergedb PRODUCTION.new PRODUCTION.gdbm annotations.gdbm
        % mv PRODUCTION.new PRODUCTION.gdbm
        % mkindex

Если база данных manual выглядит так:

        @FILE { url1
        my-manual-attribute:  this is a neat attribute
        }

а база данных automatic выглядит так:

        @FILE { url1
        keywords:   boulder colorado
        file-size:  1034
        md5:        c3d79dc037efd538ce50464089af2fb6
        }

то в конце база данных production будет выглядеть вот так:

        @FILE { url1
        my-manual-attribute:  this is a neat attribute
        keywords:   boulder colorado
        file-size:  1034
        md5:        c3d79dc037efd538ce50464089af2fb6
        }

4.8 Устранение неполадок

Отладка

Доплнительная информация от отдельных программ и библиотечных функций может записана, если установить отладочные флаги (debugging flags). Отладочный флаг имеет вид -Dsection,level. Section -- это целое число в пределах 1-255, а level -- целое число в пределах 1-9. Флаги могут быть заданы в командной строке, при помощи тэга Debug-Options: в конфигурационном файле Gatherer'а, или установлением переменной окружения $HARVEST_DEBUG.

Примеры:

        Debug-Options: -D68,5 -D44,1
        % httpenum -D20,1 -D21,1 -D42,1 http://harvest.cs.colorado.edu/
        % setenv HARVEST_DEBUG '-D20,1 -D23,1 -D63,1'

Разделы отладки (debugging sections) и уровни (levels) относятся к следующим разделам кода: of the code:

section  20, level 1, 5, 9          liburl обработка URL
section  21, level 1, 5, 9          Функции HTTP библиотеки liburl
section  22, level 1, 5             Функции дискового кэша библиотеки liburl
section  23, level 1                Функции FTP библиотеки liburl
section  24, level 1                Функции Gopher библиотеки liburl
section  25, level 1                urlget - отдельная программа liburl
section  26, level 1                ftpget - отдельная программа liburl
section  40, level 1, 5, 9          Нумерация URL Gatherer'ом
section  41, level 1                Нумерация Gatherer'а, подтверждение URL
section  42, level 1, 5, 9          Нумерация Gatherer'а для HTTP
section  43, level 1, 5, 9          Нумерация Gatherer'а для Gopher
section  44, level 1, 5             Нумерация Gatherer'а, функции фильтра
section  45, level 1                Нумерация Gatherer'а для FTP
section  46, level 1                Нумерация Gatherer'а для URL'ов типа file://
section  48, level 1, 5             Нумерация Gatherer'а, robots.txt
section  60, level 1                Gatherer essence, обработка объекта данных
section  61, level 1                Gatherer essence, функции базы данных
section  62, level 1                Gatherer essence, главная часть (main)
section  63, level 1                Gatherer essence, распознавания типов
section  64, level 1                Gatherer essence, суммирование объектов
section  65, level 1                Gatherer essence, извлечение объектов
section  66, level 1, 2, 5          Gatherer essence, пост-суммирование
section  67, level 1                Gatherer essence, код ID объекта
section  69, level 1, 5, 9          Обработка шаблонов SOIF
section  70, level 1, 5, 9          Broker, регистр
section  71, level 1                Broker, функции коллекций
section  72, level 1                Broker, функции разбора SOIF
section  73, level 1, 5, 9          Broker, хэш-таблицы регистра
section  74, level 1                Broker, функции управления хранением
section  75, level 1, 5             Broker, функции обработки запросов
section  75, level 4                Broker, отладка query_list
section  76, level 1                Broker, функции обработки событий
section  77, level 1                Broker, main
section  78, level 9                Broker, цикл select(2)
section  79, level 1, 5, 9          Broker, управление gatherer-id
section  80, level 1                Общие утилиты, управление памятью
section  81, level 1                Общие утилиты, функции буфера
section  82, level 1                Общие утилиты, системные(3) функции
section  83, level 1                Общие утилиты, функции путей (pathname)
section  84, level 1                Общие утилиты, обработка имени хоста
section  85, level 1                Общие утилиты, обработка строк
section  86, level 1                Общие утилиты, кэш хостов DNS
section 101, level 1                Broker, движок индекса PLWeb
section 102, level 1, 2, 5          Broker, движок индекса Glimpse
section 103, level 1                Broker, движок индекса Swish

Симптом

Gatherer не собирает все объекты, на которые указывают некоторые из моих RootNode'ов.

Решение

Gatherer делает различные ограничения на нумерацию, чтобы предостеречь плохо сконфигурированный Gatherer от неправильного обращения к серверам или от ``дикого'' запуска. Обратитесь в раздел Описание RootNode за деталями о том, как переделать эти ограничения.

Симптом

Не сработало локальное преобразование (Local-Mapping) - объекты получены по обычным протоколам удаленного доступа.

Решение

Локальное преобразование не удастся, если:

Так, к каталогам, символическим ссылкам и сценариям CGI всегда обращается сервер, а не локальная файловая система. Мы не предоставляем преобразование URL для локальных преобразований. Если ваш URL имеет специальные символы, от которых нужно избавиться, то локальное преобразование также не удастя. Добавьте опцию отладчика -D20,1, чтобы понять, как происходит локальное преобразование.

Симптом

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

Решение

На данный момент --full-text просто включает все данные из содержимого в резюме SOIF. Использование механизмов суммирования отдельных типов данных, описанных в разделе Настройка шага суммирования, будет лучше работать в этом случае, но потребует от вас указать, как нужно извлекать данные для отдельных типов файлов. В будущих версиях Harvest'а мы заменим опцию Essence --full-text, чтобы выполнять извлечение содержимого перед включением полного текста документов.

Симптом

Не сгенерировались индексирующие термины в резюме SOIF для тэгов META в моих документах HTML.

Решение

Вероятно, это показывает, что ваш HTML синтаксически неверно организован, и следовательно HTML summarizer на основе SGML не способен понять его. Обратитесь в раздел Суммирование данных SGML за деталями и опциями отладки.

Симптом

Собранные данные не обновляются.

Решение

Gatherer автоматически не производит периодических обновлений. Обратитесь в раздел Периодическое собирание и обновления в реальном времени за деталями.

Симптом

Gatherer записывает немного другие URL в резюме SOIF, а не те, что я указал в конфигурационном файле Gatherer'а.

Решение

Это происходит потому, что Gatherer пытается привести URL к каноническому формату. Он делает это, убирая номера портов по умолчанию и похожие ``косметические'' изменения. Также по умолчанию Essence (подсистема Gtherer'а извлечения содержимого) удаляет стандартные типы из stoplist.cf, который включает запросы HTTP (состав cgi-bin).

Симптом

Нет Last-Modification-Time (время последнего изменения) или атрибутов MD5 в моих данных SOIF, поэтому брокер не может делать повторного отсеивания.

Решение

Если вы собираете удаленно созданную вручную информацию, она добывается Harvest'ом, используя ``exploder'ы'', которые транслируют удаленный формат в SOIF. Это значит, что они не имеют прямого способа заполнить информацию Last-Modification-Time или MD5 за одну запись. Заметьте также, что это занчит, что после одного обновления удаленные записи будут выглядеть обновленными, что приведет к большей сетевой загрузке для брокера, который собирает данные с этого Gatherer'а. Как решение, вы можете вычислять MD5 для всех объектов и хранить их как часть записи. Потом, когда вы запустите exploder, вы сгенерируете только временные метки для тех объектов, у которых изменилось MD5 - это даст вам реальные времена последних изменений.

Симптом

Gatherer заменяет на ``%7e'' тильды `` '' во всех URL'ах каталогов пользователя. directory URLs.

Решение

Gatherer следует RFC1738, который говорит, что тильда внутри URL должна кодироваться как ``%7e'', так как она рассматривается как ``небезопасный'' символ.

Симптом

Когда я ищу, используя ключевые слова, которые точно есть в документе, который я проиндексировал Harvest'ом, документ не находится.

Решение

Harvest использует подсистему извлечения содержимого Essence, которая по умолчанию не извлекает каждое ключевое слово в документе. Вместо этого, она использует эвристику, чтобы попытаться выбрать наиболее нужные ключевые слова. Вы можете установить, какие ключевые слова выбирать настроив summarizer'ы для этих типов данных, что обсуждается в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования. Или вы можете сказать Essence, чтобы он использовал полнотекстовое суммирование, если чувствуете, что увелечение занимаего места на диске будет оправдано, это обсуждается в разделе Задание значений переменных в конфигурационном файле Gatherer'а.

Симптом

Я запускаю Harvest на HP-UX, но процесс essence Gatherer'а занимает слишком много памяти.

Решение

Имеющаяся библиотека регулярных выражений имеет утечки памяти на HP-UX, поэтому вам нужно использовать библиотеку регулярных выражений, поставляемую с HP-UX. Замените Makefile в src/gatherer/essence:

        REGEX_DEFINE    = -DUSE_POSIX_REGEX
        REGEX_INCLUDE   =
        REGEX_OBJ       =
        REGEX_TYPE      = posix

Симптом

Я создал конфигурационный файл, чтобы указать, как Essence должен извлекать данные types/content, но он использует все равно стандартные механизмы typing/extracting.

Решение

Убедитесь, что у вас Lib-Directory установлена в каталог lib/, в который вы положили ваш конфигурационный файл. Lib-Directory определяется в конфигурационном файле вашего Gatherer'а.

Симптом

У меня проблемы с разрешением имен хостов на SunOS.

Решение

Для того, чтобы собирать данные с хостов вне вашей организации, ваша система должна быть способна разрешать полностью правильные имена доменов в адреса IP. Если ваша система не может разрешить имена хостов, вы увидите сообщения об ошибках, как ``Unknown Host''. В этом случае, одно из двух:

Чтобы убедиться, что ваша система сконфигурирована для DNS, убедитесь, что файл /etc/resolv.conf существует и может быть прочитан. Прочитайте страницу man для resolv.conf(5) с информацией об этом файле. Вы можете убедиться, что DNS работает при помощи команды nslookup.

Некоторые сайты могут использовать Службу сетевой информации Sun Microsystem (Network Information Service, NIS) вместо или вместе с DNS. Мы считаем, что Harvest работает на системах, в которых NIS был правильно сконфигурирован. Сервера NIS (имена которых вы можете определить при помощи команды ypwhich) должны быть сконфигурированы, чтобы делать запросы к серверам DNS для имен хостов, о которых они ничего не знают. Попробуте опцию -b команды ypxfr.

Симптом

Я не могу заставить Gatherer работать через наш firewall gateway.

Решение

Harvest поддерживает только получение объектов HTTP через прокси. Пока еще невозможно запросить Gopher и FTP объекты через firewall. Для этих объектов, вам может понадобиться запустить Harvest внутренне (за firewall'ом) или на самом хосте с firewall'ом.

Если вы видите сообщение ``Host is unreachable'', вероятно, возникли эти проблемы:

Если вы видите сообщение ``Connection refused'', вероятно, проблема в том, что вы пытаетесь подсоединиться к неиспользуемому порту на машине назначения. Другими словами, нет программы, прослушивающей соединения на этом порту.

Gatherer Harvest'а - это, по существу, клиент WWW. Вы должны ожидать, что он будет работать так же как и любой Web броузер.


След Пред Содержание