Пошук інформації в Інтернеті

Пошук інформації в інтернет

Загальні відомості.
В даний час Інтернет об'єднує сотні мільйонів серверів, на яких розміщені мільярди різних сайтів і окремих файлів, що містять різного роду інформацію. Це гігантське сховище інформації. Існують різні прийоми пошуку інформації в Інтернет.
Пошук за відомою адресою. Необхідні адреси беруть із довідників. Знаючи адресу, досить ввести його в адресний рядок Браузера.
Приклад 1.
www.gov.ru - сервер органів державної влади Росії.
Конструювання адреси користувачем. Знаючи систему формування адреси в Інтернет, можна при поіскеWeb-сайтів конструювати адреси.
До ключовим словом (назвою фірми, підприємства, організації або простому англійському іменнику) необхідно додати домен тематичний або географічний, при цьому необхідно підключати інтуїцію.
Приклад 2.
Адреси комерційних Web-сторінок:
www.cnn.com (всесвітні новини CNN),
www.sony.com (фірма SONY),
www.mtv.com (музичні новини MTV).
Приклад 3.
Адреси навчальних закладів:
www.ntu.edu (Національний університет США).
Приклад 4.
Адреси регіональних серверів:
www.poland.net (Польща),
www.israil.net (Ізраїль).

Пошукові системи Інтернет

Для пошуку інформації в Інтернет розроблені спеціальні інформаційно-пошукові системи. Пошукові системи мають звичайний адресу і відображаються у вигляді Web-сторінки, яка містить спеціальні засоби для організації пошуку (рядок для пошуку, тематичний каталог, посилання). Для виклику пошукової системи досить ввести її адресу в адресний рядок Браузера.
За способом організації інформації інформаційно-пошукові системи діляться на два види: класифікаційні (рубрикатори) та словникові.
Рубрикатори (класифікатори) - пошукові системи, в яких використовується ієрархічна (деревоподібна) організація інформації. При пошуку інформації користувач переглядає тематичні рубрики, поступово звужуючи поле пошуку (наприклад, якщо необхідно знайти значення якогось слова, то спочатку у класифікаторі потрібно знайти словник, а потім вже в ньому знайти потрібне слово).
Словникові пошукові системи - це потужні автоматичні програмно-апаратні комплекси. З їх допомогою проглядається (сканується) інформація в Інтернет. У спеціальні довідники-індекси заносяться дані про місцезнаходження тієї чи іншої інформації. У відповідь на запит здійснюється пошук у відповідності з рядком запиту. У результаті користувачеві пропонуються ті адреси (URL), на яких у момент сканування знайдені шукані слово чи група слів. Обравши будь-який із запропонованих адрес-посилань, можна перейти до знайденого документа. Більшість сучасних пошукових систем є змішаними.
Найбільш відомі і популярні пошукові системи:
www.aport.ru www.yahoo.com www.rambler.ru www.yandex.ru www.altavista.com www.google.com
Існують системи, що спеціалізуються на пошуку інформаційних ресурсів за різними напрямками.
Пошук людей в Інтернет:
www.whowhere.ru ww. bigfoot.com
Пошук по телеконференцій (Usenet):
www.dejanews.com
Предметні пошукові системи:
www.webring.org
Пошук програмного забезпечення:
www.files.com
www.files.ru
Пошук по файлових архівів:
http://ftpseach. city.ru, http://ftpsearch. licos.com
Каталоги (тематичні добірки посилань з анотаціями):
http://www.atrus.ru
www.aup.ru
Часто ефективний пошук інформації можна провести за допомогою регіональних каталогів - спеціалізованих серверів, що містять дані про підприємства або Web-ресурсах якогось міста або регіону. Наприклад, для Санкт-Петербурга такий каталог розташовується за адресою http://www.spb.ru.
Список ІПС можна знайти на сайті www.monk. newmail.ru
Більш докладний перелік пошукових систем і каталогів представлений в табл. 3.2.

Правила виконання запитів

У кожній пошуковій системі в розділі Допомога (Help) можна отримати відомості про те, як шукати, як скласти рядок запиту. Нижче наведена інформація про типове, "усереднений" мовою запитів.
Простий запит.
Ввести одне слово, яке визначає тему пошуку. Наприклад, в пошуковій системі Rambler.ru досить ввести: автоматика.
Знаходяться документи, в яких зустрічаються слова, зазначені у запиті. Розпізнаються всі форми слів російської мови, як правило, регістр букв ігнорується.
У запиті можна використовувати символ "*" або "?". Знаком "?" в ключовому слові замінюється один символ, на місце якого може бути підставлена ​​будь-яка буква, а знаком "*" - послідовність символів.
Наприклад, запит автомат * дозволить знайти документи, які включають слова автоматичний, автоматика і т.д.
Складний запит.
Часто виникає необхідність комбінування ключових слів для отримання більш певної інформації. У цьому випадку використовуються додаткові слова-зв'язки, функції, оператори, символи, комбінації операторів, розділені дужками.
Наприклад, запит музика & (beatles | бітлз) означає, що користувач шукає документи, що містять слова музика і beatles або мов та бітлз.
У табл.3.1 наведено правила формування запитів, прийняті в системі Апорт (http://www.aport.ru).
Таблиця 3.1
Оператори для формування запитів
Таблиця 3.2
Список пошукових серверів і каталогів

Пошук інформації в Інтернеті: підводні камені

Проблеми, що не лежать на поверхні, нерідко дають про себе знати лише "заднім числом", після того як певний етап пошукових робіт завершено і, можливо, виходячи з його результатів уже прийняте будь-яке рішення. Що ж заважає зробити ситуацію прозорішою з самого початку експлуатації тієї чи іншої інформаційно-пошукової системи (ІПС)? Відповідь досить проста: відсутність вичерпної інформації подібного роду з боку розробника. Прямим наслідком цього стають недостовірність даних, що отримуються та їх неконтрольована втрата. Рідко вдається зустріти в Мережі пошукову систему, яка не володіла б деякими "недокументовані" особливостями. Здавалося б - користувачеві необхідно не так вже багато відомостей, а саме:
як відбувається наповнення бази даних ІПС і який її обсяг;
повний спектр можливостей пошукової мови системи;
основні особливості представлення результатів пошуку, перш за все алгоритму ранжирування записів зі списку відгуку на пошуковий запит.
На жаль, джерелом такої інформації звичайно є не документ, доступний з головної сторінки пошукового сервера, а розкидані по Мережі, книг та комп'ютерних журналів публікації окремих авторів. До причин такого стану справ, мабуть, можна віднести не тільки недбалість розробника, але і фактор, іменований маркетинговою політикою. Простіше кажучи, надання пошуковою системою найбільш повної інформації про саму себе не завжди позитивно позначається на її рейтингу. Тим не менше, взяти ситуацію під контроль у ряді випадків користувачеві виявляється цілком по силам. З'ясувати особливості роботи обраного пошукового сервісу часто вдається за допомогою тестування. Побудова спеціальних тестових запитів, швидко прояснюють саме той аспект роботи системи, який найбільш важливий для поточного завдання, у багатьох випадках виявляється нетривіальним. Тому, як уникнути деяких неприємностей під час роботи з ІПС, ми і присвятимо наше обговорення. В якості прикладів, що ілюструють виклад, будуть розглянуті широко відомі пошукові системи Інтернету.
Будь-яка пошукова машина чи каталог регламентує свою роботу по збору даних з Мережі. Очевидно, що формування пошукового образу інформаційного об'єкта, або, іншими словами, його "відображення" в "дзеркалі" пошукової системи, неминуче пов'язано з деякими спотвореннями. По суті, головним при цьому стає питання про те алгоритмі, на основі якого створюється пошуковий образ. Об'єктом-оригіналом при цьому може стати як Web-сторінка, так і файл "закритого" формату, який не доступний для проникнення скануючих програм ІПС, наприклад відео - або аудіозапис. Певний шаблон зазвичай використовується і при побудові пошукового образу для фізичної або юридичної особи в момент його реєстрації в пошуковій службі. Відсікання, фільтрація інформації від оригіналу властиві всім без винятку ІПС, в тому числі і повнотекстових систем глобального охоплення і самого загального призначення.
Фільтрація може регламентуватися як на технічному, так і на лінгвістичному рівні, проте завдання у неї одна - при мінімальних матеріальних витратах домогтися реальної ефективності пошуку.
У зв'язку з цим на практиці часто виникає питання - що стає причиною невдалого пошуку: висока ймовірність відсутності в Мережі на даний момент часу інформації, релевантної запиту, або те, що ця інформація потенційно не доступна для розглянутої пошукової системи. "Підводним каменем" цей аспект стає, коли отримано ненульовий відгук на пошуковий запит, а частка недоотриманих даних виявляється неконтрольованою. Деяке світло на особливості роботи глобальних ІПС проливає порівняльний аналіз їх можливостей, який був приведений в минулій публікації. Однак, якщо деталі алгоритму фільтрації не відомі, найбільш чутливі втрати даних виникають саме при використанні спеціалізованих пошукових служб.
Розглянемо кілька прикладів. Чимало спеціалізованих систем має власний інтерфейс для введення пошукових запитів. Тим не менше можна вважати віянням часу ситуацію, коли багато подібних сервіси інтегруються в шаблони глобальних ІПС у вигляді фільтрів. Такими можливостями завжди відрізнявся HotBot; нещодавно відповідні елементи були впроваджені на AltaVista; є вони і на Еxcite. Постійно розширюється набір фільтрів пошукової системи Lycos (див. рис.1), на якій ми зупинимося докладніше.
Уявіть себе на місці користувача, що вперше відвідав таку відому глобальну пошукову систему, як Lycos, з метою знайти в Мережі дані про якийсь книжковому виданні. Запровадивши відповідні ключові слова і вибравши фільтр Books, він одержує відгук, який, за відсутності додаткової інформації, не можна розцінити інакше, як отримання даних про книжки, зібраних по всьому Інтернету. Цікаво було б задати питання, а чи може в масштабі Мережі автоматично вестися відбір подібних відомостей? Якщо говорити тільки про простір WWW, то в більшості випадків програми-павуки, скануючі Мережа, використовують для розпізнавання типу даних спеціальні елементи мови HTML, за допомогою яких в Web-сторінку запроваджуються певні інформаційні блоки. Назва елемента може нести смислове навантаження і ототожнюватися з типом інформації. Так, якщо б гіпотетично існував елемент HTML book, що містить у собі відомості про книгу та її автора, він міг би розміщуватися на сторінці і в найпростішому випадку мати наступний вигляд:
<book> Назва книги і автор </ book>
(Самі елементи <book> у вікні браузера не повинні відображатися) При цьому вся інформація про книги, яку публікує в WWW подібним чином, могла б благополучно і без участі людини накопичуватися в базі даних ІПС. Але елемента book в стандарті HTML поки не існує. Отже, доводиться вдаватися або до "ручного" відбору, або до автоматичного перегляду деяких, заданих наперед каталогів окремих вузлів, можливо, мають відношення до продажу книжкової продукції або до бібліотек.
У разі Lycos все набагато простіше. Пошук відбувається всього-на-всього по одному-єдиному вузла компанії (http://www.barnesandnoble.com), зацікавленої в реалізації свого товару. До честі розробника слід сказати, що після декількох років мовчання з приводу фільтра "books" в надрах пропонованої документації сьогодні можна знайти скромне згадка про орендаря фільтра. Раніше його власника просто не можна було ідентифікувати, і лише через деякий час стало зрозуміло, що система працює з досить незначною за обсягом і специфічно поповнюваною базою даних.
Не менш серйозно звучать побоювання у разі, коли пошук пов'язаний з інформацією, прив'язаною до певного формату її зберігання, наприклад до звукових файлів. Протягом кількох місяців пошук "звуків в Інтернеті" на Lycos залишався чимось таємничим, що нагадує роботу з невеликою, але зі смаком зібраної колекцією. Тестування системи за допомогою простих запитів показувало, що в основному в ній представлені формати WAV і AU. Нещодавно стало відомо, що тепер підтримуються також і MP3, MID, RA, RAM і AIF. При цьому обсяг накопичених записів, доступних через більшість фільтрів, продовжує зберігатися в таємниці.
Ясно, що, якщо вас зацікавив формат не входить в підтримуваний на даний момент системою перелік, ви отримаєте нульової відгук, причину якого слід було б чітко уявляти з самого початку.
Походження супровідних записів до звукових файлів на Lycos, які відображаються в результатах пошуку, як і раніше не регламентовано розробником.
Аналогічні проблеми існують і на інших ІПС. Хотілося б відзначити типовий в цьому відношенні прийом: використання шаблону глобальної ІПС як для пошуку інформації, що відноситься до всього Інтернет-простору, так і для пошуку по деяким обраним баз даних або колекціях. На жаль, реальне поле пошуку обмовляється далеко не завжди, і часто його доводиться з'ясовувати самостійно, щоб уникнути невірних висновків надалі
Ситуація може ускладнитися тим, що на пошуковому сервері ви не знайдете вичерпного опису того, як працюють оператори мови запитів.
C цим можна зіткнутися навіть на "зрілих", не перший рік працюють ІПС. Розглянемо на прикладі AltaVista, яким чином це може стати джерелом певних проблем.
Незважаючи на нещодавню появу графічного фільтра (рис.2), багато користувачів системи продовжують експлуатувати прозорий за своєю природою оператор image, що дозволяє знаходити в індексі графічні файли. На цей рахунок довідка AltaVista вичерпується тим, що рекомендує ввести в шаблон запит, в якому услід за вказаним оператором має слідувати ім'я або частину імені шуканого файлу. Таким чином, для пошуку файлу з зображенням акрополя слід задати запит у вигляді image: acropolis.
Чи збільшить наші шанси на успіх знання того, як реально відпрацьовує оператор image? Якщо подивитися на відгукнулися документи, а потім на їх HTML-джерело, то легко переконатися, що в кожному з них у місці вставки графічного образу присутній елемент <IMG>. Всередині нього в якості обов'язкового атрибуту варто URL, з якого, власне, і витягає сам файл:
<IMG SRC="http://citforum.ru/buildings/acropolis. gif">
Фактично ж Web-сторінка дає відгук, якщо ключове слово входить не тільки в ім'я файлу, але і в назву будь-якого каталогу та в доменне ім'я сервера, що містяться в URL елемента <IMG>, тобто документ, що включає в себе наведену вище рядок, відгукнувся б і на запит image: buildings. Отже, пошук по імені каталогу, яке так само, як і ім'я файлу, несе смислове навантаження, дозволяє отримати графічні дані, які не можна витягнути в першому випадку. Припустимо, що Web-майстер необережно назвав шуканий файл ACR1. GIF, але розумно поклав його в каталог buildings. Тоді за запитом image: buildings можуть відгукнутися релевантні документи з зображенням акрополя, вставленим в Web-сторінку за допомогою рядки:
<IMG SRC="http://www.citforum.ru/buildings/acr1. gif">
У розширеному пошуку AltaVista використовуються логічні оператори і дужки. Однак на сервері нічого не говориться про те, чи припустимо застосовувати їх усередині спеціальних полів пошуку, таких як поле image. Вже завідомо зареєстрований в індексі графічний файл, знайдений раніше, можна використовувати для перевірки працездатності окремих пошукових запитів. Так, якщо припустити, що файл з URL з останнього прикладу існує, то тестовий запит у вигляді image: (buildings AND acr1) повинен дати коректну ненульовий відгук і таким чином підтвердити, що комбінування операторів допустимо. На практиці це дійсно можливо.
Хотілося б ще раз підкреслити, що мова тут йде не про недосконалість окремих пошукових систем, а про конструктивний підхід до вирішення виникаючих питань. При цьому нерідкі і ситуації, передбачити які вкрай складно.
Якщо, скажімо, на тій же AltaVista організувати пошук за ключовим словом "президент" (воно спеціально вибрано в якості тестового як досить поширене), легко переконатися, що відгук залежить від двох чинників: яку мову вибрано в меню шаблону (див. рис.2 , справа вгорі) - російська (Russian) або будь-який (any language), а також яка російське кодування встановлена ​​в меню браузера. Результати пошуку приведені в табл.1. Аналіз переліку відгуку показує, що, по-перше, при введенні запиту тільки в одному кодуванні неминуче втрачаються дані. По-друге, стає ясно, як система ідентифікує ту чи іншу мову документа. Виявляється, якщо деяка початкова частина документа написана мовою, відмінному від російської, то цей документ вже не описується ІПС як російськомовний. Результат цієї недокументованих особливостей - максимальний відгук індексу при пошуку по російськомовному терміну досягається при установці пункту меню "any language", а не "Russian".
У шаблоні розширеного пошуку популярної бізнес-орієнтованої системи Open Text Livelink Pinstripe (OTLP) (рис.3) також приховані деякі проблеми, ніяк не висвітлені в довідковому матеріалі ІПС.
Як видно з малюнка, шаблон дозволяє задати своє поле пошуку для кожного терміна, а потім зв'язати терміни за допомогою логічних операторів. Однак як тільки термінів стає більше двох - виникає питання: у якій послідовності будуть відпрацьовувати оператори і, відповідно, що буде являти собою результат. Навіть для такого простого запиту, як term1 AND term2 OR term3, розумно припустити двояку інтерпретацію, яку можна проілюструвати за допомогою виділення в дужки логічних одиниць (в самому шаблоні дужки не застосовуються). І варіант (term1 AND term2) OR term3, і варіант term1 AND (term2 OR term3) здаються прийнятними, даючи при цьому абсолютно різний відгук. Тестовий запит і подальший аналіз відгукнулися документів показують справедливість першого варіанту, тобто те, що оператори виконуються в міру їх появи в шаблоні і в документі будуть присутні або term1 і term2 одночасно, або тільки term3. Як у такому шаблоні вводити запити за участю фраз (а це можливо) - автор пропонує з'ясувати читачам самостійно. У даному випадку доводиться констатувати очевидну недбалість розробника по відношенню до користувачів системи.
Переважна більшість ІПС Інтернету сьогодні активно працює з так званими стоп-словами (stop-words). До останніх відносять службові частини мови, які не несуть смислове навантаження, а також деякі найбільш загальновживані в Мережі слова, такі як information, Internet, Web, business, та інші. Відомо, що AltaVista, Excite, HotBot і Lycos застосовують у роботі техніку стоп-слів, а Infoseek і NorthernLight її не практикують.
При появі стоп-слів в пошуковому запиті, не містить спеціальних хитрувань, ІПС може не враховувати їх при пошуку та ранжуванні результатів, при цьому іноді інформуючи про це користувача, а іноді - ні. У цілому неврахування стоп-слів під час обробки запиту скорочує час пошуку та підвищує релевантність відгуку. Однак варто вам спробувати відшукати що-небудь на зразок класичної фрази Шекспіра "to be or not to be", що складається тільки з стоп-слів, - і ви вже не володієте ситуацією.
Хоча стоп-слова і можуть ігноруватися в простих запитах, в індексі повнотекстової ІПС вони присутні поряд з іншими. Такою системою є, наприклад, AltaVista (індексуються всі слова документа). HotBot, навпаки - індексує всі, крім стоп-слів.
Тим не менш і HotBot виконує повнотекстове індексування окремих значущих полів документа, так що запити зі стоп-словами, оформлені у вигляді фрази, дають і на цій ІПС результативний відгук.
Перелік стоп-слів не стандартизований, так що він може бути оригінальним для кожного сервісу. Розробники рідко наводять відомості про цей аспект роботи ІПС, проте при необхідності пошук за ключовими словами stop, words плюс назва цікавить вас пошукової машини дозволяє виявити в Мережі версії відповідних переліків.
Найбільш загальні принципи виходу з проблемної ситуації такі: по можливості уникати вживання стоп-слів у запитах, виключити застосування логічних операторів типу and, or, not та інших у тих шаблонах, в яких вони не підтримуються і будуть сприйняті як стоп-слова.
Якщо ж без стоп-слів у запиті обійтися не можна, то слід включити їх у фразу, що в багатьох системах означає укладення в лапки. В окремих випадках корисно протестувати роботу шаблонів простого і розширеного пошуку ІПС, в яких техніка підтримки стоп-слів може бути різною
Сама захоплююча інтрига Мережі, яку породжують ІПС, пов'язана з особливостями роботи алгоритму, ранжирує результати в списку відгуку. Ці відомості зазвичай не вдаються до широкого розголосу, але вони вкрай необхідні Web-майстрам, що просуває в суворій конкурентній боротьбі свої вузли через пошукові системи Інтернету. Потрапити в перші кілька десятків записів зі списку відгуку на ІПС по часто повторюється в Мережі запитах - значить забезпечити свою доступність для потенційних клієнтів (див. КомпьютерПресс № 5'99, с.114).
Тим не менше, і при вирішенні пошукових завдань під час роботи зі списком відгуку через нестачу інформації також можуть виникати деякі проблеми.
У попередньому випуску ми говорили про те, що прості тестові запити дозволяють з самого початку роботи з ІПС зрозуміти, наскільки широко в індексі представлена ​​шукана інформація. Проте не всяка ІПС дає повне число документів, що містяться у відгуку на запит (наприклад, Lycos, не дає). У якійсь мірі це дозволяє системі зберегти своє обличчя, уникнувши порівняння з гігантами - Northern Light, AltaVista або HotBot. При вирішенні професійних пошукових завдань до таких сервісів слід звертатися в останню чергу.
Зазвичай у списку відгуку з'являється інформація, яка включає в себе заголовок сторінки, адресу і анотацію. Анотація береться або зі спеціального META-елемента, що задається автором документа, або у цій якості виступають декілька перших нередактіруемих рядків тексту, взятих зі сторінки. У деяких випадках вказується мову документа. Вище ми вже звертали увагу на проколи алгоритму AltaVista, пов'язані з ідентифікацією мови, і подібні випадки - не рідкість і на інших ІПС.
Інша обескураживающие неприємність - це можлива відсутність у знайдених документах тих самих ключових слів, за якими проводився пошук. Причиною подібного явища, якщо не вважати незареєстрованого оновлення сторінки без зміни адреси, стає той факт, що ключові слова були задані автором у спеціальному полі - елементі META. Він доступний для сканування роботом ІПС, але не відображається на сторінці. У цьому випадку шляхом перегляду метаелементов HTML-джерела у вас є можливість переконатися в несумлінності автора: невідповідність ключових слів змісту документа - це пряма дезінформація.
Ще одна проблема взагалі не очевидна для одиничного користувача. Мова йде про те, як пошуковий сервер обробляє запити у разі, коли їх надходить надто багато, тобто в режимі переповнення. Так, автору статті не раз доводилося стикатися з тим, що, наприклад, на AltaVista при однаковому і практично одночасний тестовому запиті з 10-15 комп'ютерів кількість результатів, що з'являються у відгуку для кожного користувача системи, іноді може розрізнятися на десятки тисяч. У дійсності, потрапляючи в режим перевантаження, пошукова система не має великого вибору, а саме: він або відхиляє запит, або обслуговує його по "скороченим" варіанту. Останній цілком може припускати надання лише частини відповідають запиту даних. Вихід очевидний: перевіряти достовірність відгуку ІПС багато разів і в різний час доби.
Нам хотілося б зупинитися на деяких більш ніж реальних небезпеки, які підстерігають користувача, довірила маловідомому пошукового сервера. Написати про це автора змусив такий випадок. Людині була терміново необхідна інформація про наявність прямих електропоїздів між двома містами СНД. Скориставшись каталогом Rambler, він швидко зумів локалізувати сервер, що пропонує необхідні відомості (рис.4).
http://pavel. physics. sunysb.edu: 8080 /
Після введення станцій відправлення та призначення система відповіла негативно (див. рис.4, рядок внизу). Такий категоричний відповідь сервера змусив людини припинити подальші пошуки і прийняти рішення, про яке йому скоро довелося пошкодувати. Висунути претензії до розробника системи також виявилося неможливим. Справа в тому, що трохи нижче під результатом пошуку користувачем не була замічена одна важлива деталь, а саме напис "Розклад рекламний, можливі зміни, за які не несуть відповідальності ні розповсюджувач, ні МПС". При цьому якщо б фраза про відмову була сформульована трохи м'якше, користувач, імовірно, зміг би продовжити пошук у Мережі і досягти позитивного результату.
У деяких випадках маркетингова агресивність розробника починає носити викликає характер. Ось уже не один місяць на серверах HotBot і AltaVista знаходиться рекламне оголошення найбільшої книготорговельної компанії Amazon (http://www.amazon.com), а також ряду інших. При цьому на будь-який запит в ІПС поруч з результатами пошуку з'являється банер, натякає на те, що якраз за тематикою виконаного пошуку і можна знайти інформацію на Amazon, навіть якщо в запиті фігурував містичний "пан Іванов" (див. рис.5).
Підстановка термінів з шаблонами в банер проводиться шляхом їх механічного перенесення і без жодного контролю на предмет дійсного наявності книг з даної тематики на сервері компанії. До того ж знайти "Іванова" на Amazon не можна в принципі, оскільки аж до останнього часу російськомовна література там не продавалася. У даному випадку плата за довірливість - це кілька хвилин марно витраченого часу.
Таким чином, від звичного поваги до друкованого слова в Мережі краще відмовитися, особливо якщо сервер генерує репліки автоматично.