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'ов).
Чтобы запустить основной 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 отличаются от других протоколов доступа, потому что
URL в основном не содержит имени хоста. Gatherer получает новостные URL'ы от
сервера NNTP. Имя сервера должно быть помещено в переменную окружения
$NNTPSERVER. Возможно, хорошая идея - добавить ее в ваш скрипт
RunGatherer. Если переменная окружения не установлена,
Gatherer попытается подсоединиться к хосту с именем news на вашем сайте.
Помните, что базы данных Gatherer'а продолжают существовать между запусками. Объекты остаются в в базе данных, пока не устареют. Эксперементируя с Gatherer'ом, всегда является хорошей идеей ``очистка'' базы данных между запусками. Проще всего это осуществить, выполнив команду из каталога Gatherer'а:
% rm -rf data tmp log.*
Средства описания 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='' показывает максимальное число URL'ов LeafNode URLs, которые нужно сгенерировать на всех уровнях глубины индексации, начиная от текущего URL. Заметьте, что URL-Max - это максимальное число URL'ов которые генерируются во время нумерации, а не ограничение на то, сколько URL'ов может пройти через фазу выбора кандидата (смотрите раздел Настройка шага выбора кандидата).
Это имя файла, содержащего набор фильтров из регулярных выражений (смотрите раздел Фильтры RootNode) для разрешения или запрета отдельных LeafNode при нумерации. По умолчанию используется фильтр $HARVEST_HOME/lib/gatherer/URL-filter-default, который исключает много изображений и звуковых файлов.
Число, указанное справа в выражении ``Host='' показывает максимальное число хостов, которое может быть использовано для нумерации RootNode. Хосты обычно подсчитываются по своим IP-адресам, таким образом хосты, имеющие несколько алиасов учитываются один раз. Но это не работает для хостов, имеющих несколько IP-адресов или хостов, DNS именами которых управляет какая-нибудь программа (например, для уравновешивания загрузки серверов).
Замечание: До версии Harvest 1.2 строка ``Host=...'' называлась ``Site=...''. Мы изменили имя на ``Host='', потому что оно интуитивно более понятно (ограничение на число хостов, а не сайтов). Для совместимости с конфигурационными файлами старых Gatherer'ов мы будем продолжать использовать ``Site='' как алиас для ``Host=''.
Это имя файла, содержащего набор регулярных выражений - фильтров для разрешения или запрещения определенных хостов в нумерации. Каждое выражение может определять как имя хоста (или IP-адрес), так и номер порта (в случае, если у вас есть несколько серверов на различных портах одной машины, а вы хотите проиндексировать только один из них). Синтаксис - ``hostname:port''.
Если 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=3 позволит Gatherer'у ждать 3 секунды между контактами.
Это максимальное число уровней нумерации (глубина) во время собирания информации. Depth=0 означает, что нет ограничений на глубину нумерации. Depth=1 означает, что будет получен указанный URL, а также все URL'ы, на которые есть ссылки в указанном URL'е; и так далее для более больших значений Depth. Другими словами, Gatherer будет следовать по ссылкам вплоть до Depth шагов от указанного URL'а.
Этот модификатор добавляет очень удобный способ контролирования Gatherer'а. Enumeration-Program - это фильтр, который считываетs URL'ы, как входные параметры, и записывает новые параметры нумерации на выходе. Обратитесь к разделу Описание настраиваемой программы нумерации за отдельными деталями.
По умолчанию, URL-Max равно 250, URL-Filter не делает ограничений, Host-Max равно 1, Host-Filter не делает ограничений, Access равен HTTP, Delay равен 1 секунде, а Depth равно нулю. Нет способа указать неограниченное значение для URL-Max или Host-Max.
Файлы-фильтры используют стандартный синтаксис регулярных выражений 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:
<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 содержит различную конфигурации нумерации:
Кроме использования файлов 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'' (если есть изменения с такого-то времени). Кэш на локальном диске описан в разделе Дисковый кэш.
Можно генерировать 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>
После того, как 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 Извлечение имени файла, владельца и даты создания.
Таблица в разделе Извлечение данных для индексации: Подсистема суммирования Essence снабжает короткой справкой о том, как документы суммируются в зависимости от их типа. Эти действия могут быть настроены, как обсуждалось в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования. Некоторые summarizer'ы реализованы как программы UNIX, в то время как другие выражаются регулярными выражениями; обртитесь в раздел Настройка шага суммирования или раздел Пример 4 за информацией о том, как написать summarizer.
Можно суммировать документы, которые удовлетворяют Стандартному обобщенному языку верстки (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 должен быть суммирован. Есть четыре способа сопоставить данные 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 за примерами таких сопоставлений.
Парсер sgmls может генерировать большой объем сообщений об ошибках
и предупреждениях. Это в особенности справедливо для документов HTML, находящихся в
Internet, которые часто не соответствуют строгому DTD HTML. По умолчанию,
ошибки и предупреждения направляются в /dev/null так что они не будут засорять
логи Gatherer'а. Чтобы включить эти сообщения в логи, отредактируйте
Perl скрипт SGML.sum и установите $syntax_check = 1.
Чтобы создать summarizer SGML для новых типов данных SGML с соответствующим DTD, вам нужно сделать следующее:
#!/bin/sh
exec SGML.sum FOO $*
Теперь можно протестировать все из командной строки:
% FOO.sum myfile.foo
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/
Один из наиболее полезных тэгов 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 может работать с файлами, сжатыми в следующих форматах:
Чтобы настроить щаг извлечения представлений, вы можете модифицировать
исходный файл 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'' напротив соответствующего регулярного выражения).
Возможна ``тонкая настройка'' резюме, сгенерированных 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';
Если объект удовлетворяет всем условиям, над ним выполняется несколько инструкций. Можно указать четыре типа инструкций:
time-to-live = "86400"
keywords | tr A-Z a-z
address,city,state,zip ! cleanup-address.pl
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
До версии 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/';
Кроме настроек, описанных в разделе Настройка шагов распознавания типов, выбора кандидатов, извлечения прдставлений и суммирования, вы можете настроить 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) и локального кэша.
Замечания:
Gatherer примет флаг -background, который
заставит Gatherer запуститься в фоновом режиме.Опции 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
Вы можете использовать файл 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 другим сайтам, которые хотят
использовать данные для построения индексов или других целей.
Возможно вы захотите проверить качество автоматически сгенерированных шаблонов 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
}
Доплнительная информация от отдельных программ и библиотечных функций может записана, если установить отладочные флаги (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 броузер.