Проблемы при каталогизации информации

Одной из мер эффективности подхода к поиску информации является “отзыв” (recall), содержащий информацию о всех релевантных документах, которые были найдены. Брайен Пинкертон утверждает, что отзыв в индексирующих системах Интернет является вполне приемлемым подходом, так как обнаружение достаточно релевантных документов не проблема. Однако, если сравнивать все множенство информации, доступной в Интернет, с информацией в базе данных, созданной роботом, то отзыв не может быть слишком точным, поскольку количество информации огромно и она очень часто изменяется. Так что практически база данных может не содержать специфического ресурса, который доступен в Интернет в данный момент, и таких документов будет множество, поскольку Сеть непрерывно растет.

4.1. Определение роботом, какую информацию включать / исключать

Робот не может автоматически определить, была ли данная страница в Сети включена в его индекс. К тому же веб-сервера в Интернет могут содержать документы, которые являются релевантными только для локального контекста, документы, которые существуют временно, и т.д. На практике роботы сохраняют почти всю информацию о том, где они побывали. Заметьте, что, даже если робот смог определить, должна ли указанная страница быть исключена из его базы данных, он уже понес накладные расходы на запрос самого файла, а робот, который решает игнорировать большой процент документов, очень расточителен. Пытаясь исправить эту ситуацию, Интернет-сообщество приняло ” Стандарт исключений для роботов”. Этот стандарт описывает использование простого структурированного текстового файла, доступного в известном месте на сервере (“/robots.txt”) и используемого для того, чтобы определить, какая из частей их ссылок должна игнорироваться роботами. Это средство может быть также использовано для того, чтобы предупредить роботов о черных дырах. Каждому типу роботов можно передавать определенные команды, если известно, что данный робот специализируется в конкретной области. Этот стандарт является свободным, но его очень просто осуществить и в нем имеется значительное давление на роботов с попыткой их подчинения.

4.2. Формат файла /robots.txt.

Файл /robots.txt предназначен для указания всем поисковым роботам индексировать информационные сервера так, как определено в этом файле, т.е. только те директории и файлы сервера, которые НЕ описаны в /robots.txt. Это файл должен содержать 0 или более записей, которые связаны с тем или иным роботом (что определяется значением поля agent_id), и указывают для каждого робота или для всех сразу что именно им НЕ НАДО индексировать. Тот, кто пишет файл /robots.txt, должен указать подстроку Product Token поля User-Agent, которую каждый робот выдает на HTTP-запрос индексируемого сервера. Например, нынешний робот Lycos на такой запрос выдает в качестве поля User-Agent:

Lycos_Spider_(Rex)/1.0 libwww/3.1

Если робот Lycos не нашел своего описания в /robots.txt - он поступает так, как считает нужным. При создании файла /robots.txt следует учитывать еще один фактор - размер файла. Поскольку описывается каждый файл, который не следует индексировать, да еще для многих типов роботов отдельно, при большом количестве не подлежащих индексированию файлов размер /robots.txt становится слишком большим. В этом случае следует применять один или несколько следующих способов сокращения размера /robots.txt:

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




4.3. Записи (records) файла /robots.txt


Общее описание формата записи.


[ # comment string NL ]*

User-Agent: [ [ WS ]+ agent_id ]+ [ [ WS ]* # comment string ]? NL

[ # comment string NL ]*

Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL

[

# comment string NL

|

Disallow: [ [ WS ]+ path_root ]* [ [ WS ]* # comment string ]? NL

]*

[ NL ]+




Параметры


Описание параметров, применяемых в записях /robots.txt



[…]+ Квадратные скобки со следующим за ними знаком + означают, что в качестве параметров должны быть указаны один или несколько терминов. Например, после “User-Agent:” через пробел могут быть указаны один или несколько agent_id.
[…]* Квадратные скобки со следующим за ними знаком * означают, что в качестве параметров могут быть указаны ноль или несколько терминов. Например, Вы можете писать или не писать комментарии.
[…]? Квадратные скобки со следующим за ними знаком ? означают, что в качестве параметров могут быть указаны ноль или один термин. Например, после “User-Agent: agent_id” может быть написан комментарий.
..|.. означает или то, что до черты, или то, что после.
WS один из символов - пробел (011) или табуляция (040)
NL один из символов - конец строки (015) , возврат каретки (012) или оба этих символа (Enter)
User-Agent: ключевое слово (заглавные и прописные буквы роли не играют). Параметрами являются agent_id поисковых роботов.
Disallow: ключевое слово (заглавные и прописные буквы роли не играют). Параметрами являются полные пути к неиндексируемым файлам или директориям.
# начало строки комментариев, comment string - собственно тело комментария.
agent_id любое количество символов, не включающих WS и NL, которые определяют agent_id различных поисковых роботов. Знак * определяет всех роботов сразу.
path_root любое количество символов, не включающих WS и NL, которые определяют файлы и директории, не подлежащие индексации.



4.4. Расширенные комментарии формата.


Каждая запись начинается со строки User-Agent, в которой описывается каким или какому поисковому роботу эта запись предназначается. Следующая строка: Disallow. Здесь описываются не подлежащие индексации пути и файлы. КАЖДАЯ запись ДОЛЖНА иметь как минимум эти две строки (lines). Все остальные строки являются опциями. Запись может содержать любое количество строк комментариев. Каждая строка комментария должна начинаться с символа # . Строки комментариев могут быть помещены в конец строк User-Agent и Disallow. Символ # в конце этих строк иногда добавляется для того, чтобы указать поисковому роботу, что длинная строка agent_id или path_root закончена. Если в строке User-Agent указано несколько agent_id, то условие path_root в строке Disallow будет выполнено для всех одинаково. Ограничений на длину строк User-Agent и Disallow нет. Если поисковый робот не обнаружил в файле /robots.txt своего agent_id, то он игнорирует /robots.txt.


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


User-Agent: *




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


Каждый поисковый робот будет определять абсолютный URL для чтения с сервера с использованием записей /robots.txt. Заглавные и строчные символы в path_root ИМЕЮТ значение.


Пример 1:


User-Agent: *

Disallow: /

User-Agent: Lycos

Disallow: /cgi-bin/ /tmp/




В примере 1 файл /robots.txt содержит две записи. Первая относится ко всем поисковым роботам и запрещает индексировать все файлы. Вторая относится к поисковому роботу Lycos и при индексировании им сервера запрещает директории /cgi-bin/ и /tmp/, а остальные - разрешает. Таким образом сервер будет проиндексирован только системой Lycos.



4.5. Определение порядка перемещения по Сети


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



4.6. Подведение итоговых данных


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


Эти методы являются хорошими общими мерами и могут автоматически применяться для всех страниц, но, к сожалению, не могут быть столь же эффективны, как индексация страницы самим ее автором. Язык HTML обеспечивает автора документа средством для того, чтобы присоединить к нему общую информацию. Это средство заключается в определении элемента , например ” Вячеслав Тихонов, Ноябрь 2000

www.metaping.com


Случайные статьи

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


Танцы Google по-флоридски
Если вы хоть немного интересуетесь оптимизацией для поисковых систем, причем не только для русскоязычных - вы уже слышали зловещий термин Florida Update, без упоминания которого нынче не обходится ни ...


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


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


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


 




1,8589911460876