Как решить проблемы современного поиска

Сегодня поиск может найти миллионы страниц контента, однако вместе с правильными результатами мы можем получить и ненужную информацию. На запрос «Столица Франции» можно получить 35 миллионов страниц вместо всего одного слова. Пользователи пока мирятся с таким положением дел, но всё больше и больше зреет необходимость в чём-то более искушённом, чем просто догадка, основанная на сложных математических и статистических методах для поиска слов в базе данных, состоящей из миллиардов страниц. Но проблема не только в поиске, но и в том, как информация организована, что видно из следующих примеров:

1. Поиск

Запрос «опера» даёт ссылки на (а) браузер, (б) статьи об опере как виде искусства, (в) оперные театры, (г) отель «Опера».
Запросы «Европейский Союз» и «ЕС» дают разные результаты и включают информацию не только о самом ЕС, но и близких по значению темах, таких как делегация ЕС или поездки в ЕС.
Запрос «Германия Испания» даёт ссылки в основном на матч чемпионата мира 2010, однако не все интересуются футболом (а отношения между Испанией и Германией не ограничиваются только этим матчем, даже внутри футбольной темы).
Запрос «Германия Испания 2010 футбол» даёт ссылки на чемпионат мира 2010 года в общем.
Запрос «Как проехать в Арагон», по сути, не даёт результатов вообще (хотя он даёт множество ссылок, которые не имеют отношения к запросу).
Запрос «Арагон» неоднозначен, поскольку мы можем хотеть или (а) идентифицировать слово, так как не знаем, что такое Арагон вообще, или (б) детализировать слово; нам же поиск даёт множество неотсортированных ссылок, которые пытаются покрыть все возможные цели запроса.
Запрос «Арагон Наварра» неоднозначен, так как мы можем хотеть узнать (а), как слова обобщаются, например, что они являются частью современной Испании, (б) как слова связаны, например, какие отношения между Арагоном и Наваррой существуют сейчас или в прошлом или как проехать из Арагона в Наварру и т.п.
Запросы «Арагон Испания» и «Арагон Сарагоса» неоднозначны, так как включают в себя понятие, который является частью другого понятия.

2. Помощь к поиску

Давайте посмотрим на советы, которые поисковики предлагают пользователям:

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

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

3. Обобщения, ключевые слова

http://gazeta.ru/science/2010/10/12_a_3427805.shtml
Страница озаглавлена как «Есть ли жизнь под Марсом», подзаголовок гласит «Жизнь на Марсе может существовать на глубине нескольких километров», другой подзаголовок раскрывает тему еще больше: «Жизнь на Марсе может существовать на глубине нескольких километров. Такое предположение сделали учёные, ознакомившись с новыми данными, полученными станцией Mars Reconnaissance Orbiter (MRO)». Какой из заголовков правильный? Какой наиболее точно передаёт содержание страницы? Теги содержат следующие слова: Жизнь на Марсе, Mars Reconnaissance Orbiter, карбонаты, гидротермальные ископаемые. Почему «Жизнь на Марсе» и почему не просто «Марс»? Почему «карбонаты»? Относится ли эта страница к теме карбонатов или же к теме карбонатов на внеземных объектах? Сама статья в соответствии с URL классифицирована как относящаяся к «Науке», внутри страницы мы ещё находим ссылку на тему «Космический обзор». Почему «Космический обзор», а не «Космос»?

Если мы посмотрим на html, то увидим ещё множество параллельных определений (которые включают заголовки разных типов и стандартов):
<link rel=»alternate» type=»application/rss+xml» title=»Газета.Ru — двадцать строк о науке» href=»http://www.gazeta.ru/export/rss/science_20.xml»>
<link rel=»alternate» type=»application/rss+xml» title=»Газета.Ru — Наука. Новости» href=»http://www.gazeta.ru/export/rss/science_more.xml»>
<meta name=»keywords» content=»Жизнь на Марсе, Mars Reconnaissance Orbiter, карбонаты, гидротермальные ископаемые»>
<meta name=»description» content=»Жизнь на Марсе может существовать на глубине нескольких километров. Такое предположение сделали учёные, ознакомившись с новыми данными, полученными станцией Mars Reconnaissance Orbiter (MRO).»>
Так какой из заголовков правильный?

4. Классификации

Как размещается информация на порталах, можно увидеть на примере одной утилиты, которая оказалась в следующих категориях на разных сайтах:

Система
Системная информация
Софт / Сетевые утилиты / Мониторинг сети
Home > Windows > Network Tools > Network Information
Home > Windows Software > Utilities & Operating Systems > System Utilities
System > Power Tools

http://www.bbc.co.uk/nature/species/Common_Goldeneye
Страница использует множество произвольных, по сути, классификаций (можно представить ещё пару подобных: Nature -> Birds -> Goldeneye или Birds -> Goldeneye):
1. Внутри URL: Nature -> Species -> Common Goldeneye
2. На странице: Wildlife Finder -> Animals -> Goldeneye
3. Animals -> Vertebrates -> Birds -> Anseriformes -> Ducks, geese and swans -> Bucephala -> Goldeneye

5. Локальная информация

Страницу из предыдущего примера мы можем положить в C:DownloadsAnimalsGoldeneye.html (хотя браузеры предлагают даже более интересное имя файла: «BBC — Wildlife Finder — Goldeneye facts, pictures & stunning videos»). Если после этого вы нашли ещё и видеофайл, но на диске C нет места, то вы сохраните его как D:VideoAnimalsDuck_geye.avi. Как позже найти оба файла? Запустить локальный поиск? Один раз это имеет смысл, но если вы будете работать с ними несколько раз, то желательно иметь их под рукой всегда. Библиотеки файлов? У них свои ограничения: вы должны вручную их создавать, а если их станет совсем много, то вам опять придётся использовать поиск уже внутри этих библиотек. В реальности же получается так, что мы многократно проделываем одну и ту же операцию (поиск ли это или следование пути, с использованием каталогов или библиотеки).

6. XML, Семантический Веб, микроформаты

Семантический Веб уходит от акцента на представлении информации (что делает гипертекст) и обращается к смыслу (семантике) информации. Например, данные о конкретном человеке в нём представляются так:

<?xml version="1.0"?>
<rdf:RDF 
             >

	<contact:Person rdf_about="http://www.w3.org/People/EM/contact#me">
		<contact:fullName>Eric Miller</contact:fullName>
		<contact:mailbox rdf_resource="mailto:em@w3.org"/>
		<contact:personalTitle>Dr.</contact:personalTitle> 
	</contact:Person>

</rdf:RDF>

Конечно, едва ли мы сможем пользоваться таким представлением, которое, очевидно, ориентировано на машинную обработку данных. Микроформаты реализуют ту же идею (работы со смыслом), используя гипертекстовые элементы. Пример данных о домашнем телефоне:

<span class="tel">
	<span class="type">home</span>:
	<span class="value">+1.415.555.1212</span>
</span>

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

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

Как вы можете видеть, мы сталкиваемся с множеством проблем, так как поисковые системы:

ищут слова, а не смысл (запрос «ЕС» именно о ЕС, а не обо всём, что относится к ЕС)
не понимают всех синонимов («ЕС» и «Европейский Союз»)
не пытаются уточнить, что вы имели ввиду («опера» — браузер или музыкальное произведение)
не пытаются понять цель запроса (идентифицируем мы слово или детализируем и т.п.)
информация не всегда упорядочивается (например, группировка схожей информации)
предоставляют слишком избыточные ответы (миллион страниц вместо одного слова)
не понимают сложных отношений между словами
последние события имеют большую релевантность (только потому, что они чаще упоминаются в новостях и дискуссиях), но это не всегда так для того, кто ищет
требуют дополнительного времени для уточнения запроса (что часто нарушает одно из правил GUI о том, что любая цель должна быть достигаема за 3 клика)
удовлетворительный результат обычно получается, если мы ищем либо определения термина (тогда здесь нет сложных отношений и слово запроса обычно совпадает с заголовком страницы в словаре), либо типичную информацию (которая представлена на множестве страниц, которые используют разные синонимы, что увеличивает шансы угадать их в запросе)

Советы для поиска только подтверждают наличие этих проблем:

запросы должны быть простыми, так как поисковые системы не справляются со сложными отношениями
вы должны предугадать, какие слова будут в ответе, так как поиск не может использовать похожие термины
требование использовать как можно меньше слов иногда имеет смысл и в реальной жизни (краткость ведь — сестра таланта), но с другой стороны абсурдно: ведь чем больше слов вы используете, тем более вы детализируете объект: например, «машина» хуже описывает предмет, чем «красная спортивная машина»
совет подбирать более информативные слова (то есть слова, которые добавляют что-то новое к содержанию и не пересекаются по смыслу с другими словами) имеет смысл, если вы хорошо понимаете, что же это такое; однако что мешает поисковым системам исключать их?

Но ведь существуют ещё и проблемы упорядочивания и использования информации:

идентификация предметов реального мира недоступна (поэтому смысл слов доступен только людям)
классификации произвольны (относится ли статья к «животным» или «хордовым»?)
некоторые классификации (как каталоги файлов) позволяют упорядочивать информацию, но не запрещают неправильно отклассифицированную информацию (например, вы можете положить файл музыки в каталог с фильмами и т.п.), так как не делают явными критерии классификации (например, если вы не знаете, кто такой Верди, то вы не сможете понять, что означает путь «Музыка/Опера/Верди»)
зафиксированные критерии классификации ухудшают вероятность повторного нахождения информации (вы можете поместить фильм в каталог «Фильмы/2010», но впоследствии забыть, в каком году фильм был выпущен) и разделяемость информации (копирование части дерева каталогов может быть весьма трудоёмко, так как оно охватывает вовлечённые ветви дерева полностью, а нам нужны только их части, например, если вам нужно скопировать три файла из разных подкаталогов, с сохранением имён каталогов)
существующие классификации (включая разнообразные таксономии и онтологии) используют множество отношений для определения своих элементов, что затрудняет их использование (и часто понятно только экспертам в семантике)
обобщение или абстрагирование (которое обычно представлена заголовком, то есть кратким содержанием статьи) тоже произвольно: заголовки часто состоят из метафор или других элементов, которые засоряют понимание того, какой контент скрывается за ним (например, заголовок может включать название сайта, но вы даже можете не подозревать, что это название сайта), иногда они заменяются ассоциациями, ключевыми словами и тегами (например, «Жизнь на Марсе может существовать на глубине нескольких километров» раскрывает смысл статьи, а ассоциации «карбонаты» или «гидротермальные ископаемые» понятны только специалисту)
обобщение дублируется (и частично становится противоречивым) внутри заголовка ссылки, внутри заголовка страницы, в дополнительных тегах, ключевых словах, в заголовках ссылок, которая указывает на эту страницу, и т.п.
URL трудно запомнить (так как используются аббревиатуры, а разделители естественного языка не используются по назначению)
ссылка указывает на один ресурс, тогда как в естественном языке ссылка (слово) является обобщающей ссылкой (слово «фильм» может указывать на любой фильм)
не у каждого предмета или явления есть соответствующий компьютерный ресурс, а если и есть, то он может устареть или быть удалённым
гипертекст жёстко интегрирует разнородную информацию, что приводит в результате к «контентовому кошмару» (невозможно понять, где граница между разным контентом, между контентом и не-контентом)
во многих случаях мы работаем с простым текстом потому, что существующие приложения работают либо с заранее структурированной информацией, либо с неструктурированной информацией вообще
интеграция информации во многих случаях практически отсутствует, так как мы используем текстовые идентификаторы без привязки к смыслу (то есть если даже файл назван «Храброе сердце», то это не означает, что файл связан с фильмом или с каким-то другим содержанием, которое вы решили так назвать)
обмен информацией затруднен вследствие необходимости явного использования определённых средств (электронной почты, сайтов и т.п.)
использование информации затруднено,так как не существует простых способов совместного использования классифицирующей информации (то есть каждый пользователь должен классифицировать информацию заново) и фильтрации информации (то есть пользователь должен заново фильтровать информацию практически при каждом обращении к ней)
проблема доступа к информации не решена прозрачно, поэтому её либо игнорируют вообще, либо ставят столько барьеров, что использование информации становится проблематичным

У Семантического Веба (его создатели ещё называют его «Вебом данных») свои недостатки и проблемы репрезентации знаний вообще:

ориентирован на обработку машинами
рассматривает упорядоченные данные и приложения и представляет собой универсальный формат данных для интеграции больших массивов данных и приложений, но пока нет общепринятого представления для людей
работать с ним могут эксперты (которые могут иметь дело с его стандартами)
проблема идентификация предметов и событий реального мира не раскрывается полностью (иначе бы мы уже бы пользовались ею)
в нём отсутствует механизм поддержки детализации/обобщения (который является одним из важнейших механизмов интеллекта)
семантика представляется в виде триплетов «подлежащее-сказуемое-дополнение» (subject-predicate-object), игнорируя всё богатство естественного языка
для него актуальна квалификационная проблема (для любого обобщающего определения существует множество исключений) и проблема большого количества взаимосвязанных фактов

Откуда берутся эти проблемы?

Данные недостатки появляются постольку, поскольку поиск рассматривает тексты как набор символов (подобно тому, как мы видим текст на неизвестном нам языке). Естественно, что, не понимая смысла текста, можно только угадывать, что ищут пользователи благодаря совпадению слов. Советы для поиска, более изощрённые математические методы могут помочь увеличить вероятность успешного совпадения, но не более того. И только понимание текста может вывести поиск на качественно новый уровень, что означает, что поиск должен рассматривать не текст, а смысл.

Например, в чём смысл фильма «Храброе сердце»?

фильм как (1) последовательность кадров, (2) видеокассета, диск или файл, (3) актёры, декорации, сцены
в самих исторических событиях, которые имели место несколько веков подряд
(1) в описании этих событий, (2) интерпретации этого описания в фильме, (3) описании того, как снимался фильм
идеи, мысли, чувства и эмоции, которые (1) вложены в эту интерпретацию, (2) испытывали реальные актёры при съёмке, (3) испытывает конкретный зритель

Этому смыслу соответствует следующие идентификаторы:

название «Храброе сердце», которое уникально идентифицирует этот фильм (хотя это название не уникально, т.к. в 1925 году уже выходил такой фильм, поэтому более точное название будет «Храброе сердце (1995)»)
слова «фильм» или «исторический фильм», которыми мы подчеркиваем сходство с другими фильмами, обобщая его свойства и игнорируя детали
слова, которые описывают сюжет фильма
слова, которые описывают наши чувства и впечатления от фильма
кадры, которые и есть фильм, тоже могут считаться описанием (изображение — это тоже язык, визуальный)

Давайте попробуем разобраться по порядку, что же мы здесь видим (и что, собственно говоря, и составляет понятие смысла):

предметы и явления реального мира (здесь это исторические события)
чтобы уменьшить сложность предметов и явлений до уровня, достаточного для восприятия, субъект познания трансформирует их в символы и идентификаторы (визуальные и другие представления, буквы и слова естественного языка, цифры и т.п.)
идентификаторы, отделённые от реального мира (так как они остаются внутри субъекта познания), начинают жить своей собственной жизнью, образуя систему идентификаторов / абстрактный мир со своими предметами и явлениями (здесь это описание исторических событий и их интерпретация в фильме, а также идеи, мысли, чувства как самого фильма, так и зрителей)
идентификаторы используются для ссылки на объекты («Уильям Уоллес»), на действия («битва на Стерлингском мосту»), на отношения, то есть объекты абстрактного мира («отец Уильяма Уоллеса», где «отец» — это отношение, которое обозначает факт родства, но которое не может быть воспринято в реальности напрямую, так как факт родства может быть только зарегистрированным или подтверждённым анализом ДНК), на временные отношения, то есть абстрактные действия (сам фильм и фраза «если бы Уильяма Уоллеса не казнили», где действия не являются частью реальности), и на смешанные структуры («я смотрел Храброе сердце», где «я» и «смотрел» являются частью реальности, тогда как сам фильм — смесью реляционных объектных и временных структур)
в общем случае чем больше идентификаторов мы используем для описания, тем более конкретным (детальным) оно является и более абстрактным (обобщённым) в обратном случае (например, «Храброе сердце, кинотеатр М города Н, 20:00 26 октября 2010 года» указывает на сеанс конкретного фильма, фраза «фильм в октябре 2010 года» указывает на все фильмы, которые где-либо проходили в октябре 2010 года, а слово «фильм» указывает на любой фильм вообще, хотя во фразе «я смотрел вчера фильм» оно указывает и на конкретный сеанс)
чтобы уменьшить количество идентификаторов («человек, который боролся за независимость Шотландии в XIII веке»), мы можем использовать уникальный идентификатор (например, «Уильям Уоллес»), который может образовывать собственные системы идентификаторов (система личных имён, названия стран, база данных и т.п.)
так как система идентификаторов независима от реального мира (мы должны, но не всегда поддерживаем верифицируемость), то смысл идентификатора может зависеть как от обстоятельств, предметов и явлений (смысл фразы «я был в кино» зависит от того, где и когда была сказана эта фраза), так и от субъекта и его представлений («я был в кино» зависит ещё и от того, зачем и почему фраза была сказана), так и от самой системы идентификаторов (не понимая русского языка, нельзя понять, что означает слово «фильм»)
перевод идентификаторов из одной системы в другую (из представления в язык, из языка в язык, между идентификаторами одного языка) может быть основан на идентичности (если существует однозначное соответствие идентификаторов, как между «Уильям Уоллес» и «William Wallace») или же на схожести, то есть частичной идентичности (как между «Уильям Уоллес» и «герой Шотландии», где сходство между идентификаторами достигается за счёт идентичности только части из критериев, входящих в описание этих идентификаторов)

Но причины существующих проблем ещё и в том, что смысл должен рассматриваться шире:
1. Чтобы рассматривать смысл как можно точнее, мы должны брать во внимание все системы идентификаторов, которые при этом используются. А они включают в себя как сам текст (как результат поиска), так и запрос (которому уделяется недостаточно внимания, даже учитывая советы по поиску). Сейчас поисковая система пытается удовлетворить сразу все направления поиска, которые возможны теоретически, оставляя выбор на усмотрение человека. Однако такой подход будет проблемой, если мы будем использовать сложные запросы, которые будут включать подзапросы (то есть те, для которых выбор будет предоставляться не человеку, а машине).
2. Интерфейс тоже должен рассматриваться как часть семантики. Что по меньшей мере подразумевает некоторую синхронизацию между интерфейсом и семантикой (например, если вы в данный момент оказались в окне программы регистрации фильмов, то все запросы, сделанные из этого окна, должны оказаться фильмами и т.п). То есть результат работы интерфейса или поиска должен являться контекстом (основой) для дальнейшей работы с информацией.
3. Проблема идентификации сильно недооценена: например, вместо определения всех деталей информации (определения её связей, отношений и т.п.) часто достаточно уточнить ответ на вопрос «что это такое?». Так, даже простой пользователь может идентифицировать, какое вино он купил, по этикетке, но только эксперт может сказать, к каким классам оно принадлежит, как связано с другими объектами и т.п. Детальная же информация является уже производной от идентификации: если вы знаете, что смотрите именно «Храброе сердце» 1995 года, то этого достаточно, чтобы найти, на какой студии фильм выпущен, кто в нём играет и т.п.
4. Локальный поиск рассматривают как аналог поиска в Интернете, хотя его задача звучит скорее как вопрос «где оно находится?», а не «что это такое?»; поэтому просто неэффективно запускать каждый раз полнотекстовый поиск для нахождения потерявшегося файла (содержание которого вы даже можете помнить лучше, чем его месторасположение на диске).

Вообще говоря, человек всегда пытается передавать обобщённый и не до конца определённый смысл, стараясь сократить объём информации, так как он не обладает необходимыми ресурсами и временем, чтобы полностью описать вещь или явление, а как читатель не всегда имеет желание читать слишком уж детализированное описание. Опущенную же информацию мы часто можем восстановить, только задав вопросы самому носителю информацию (например, из фразы «я вчера был в опере» нельзя извлечь, кто такой я, когда было вчера и в какой опере он был). Следовательно, поиск заведомо обречён на неудачу, покуда он не может восстановить всю информацию.

Как решить проблемы поиска и организации информации?

Можно ли разрешить противоречие между стремлением обобщить информацию и необходимостью предоставлять точную информацию? Противопоставление детализации и обобщения вытекает из самой природы интеллектуальной активности в общем и абстрагирования, в частности: чем больше информации у нас имеется в распоряжении, тем более точно мы можем описать явление, но и тем больше ресурсов и времени нам требуется для этого. Для описания мы можем использовать как одну фразу, так и целую книгу, так как краткость (обобщение) будет эффективной в одной ситуации, а точность (детализирование) в другой. Мы вынуждены всегда балансировать между размером информации и скоростью на её обработку (типичный дуализм для программирования, аналогичный принципу непротиворечивости Гёделя). Нельзя отдавать предпочтение одной или другой стороне, поэтому разрешение противоречия состоит в том, что мы должны иметь возможность для детализации, обобщения, идентификации и связанности.

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

необходимость предоставить интерфейс людям, которые предпочитают гибкость и обобщения. Этот дуализм проявляется и в двух Вебах: обычном и Семантическом («Веб данных»). Изначально обычный Веб был создан именно для людей, что хорошо проявляется в его особенностях:
гипертекст связывает разнородный контент, используя достаточно простой язык (до этого для этих целей использовались технологии и форматы, которыми можно было пользоваться, только используя сложный инструментарий, тогда как гипертекст можно редактировать в любом текстовом редакторе)
гипертекст обладает хорошей выживаемостью (он функционирует даже при неполных данных, то есть не полностью загруженный или неправильный гипертекст во многих случаях не утрачивает информативности)
гипертекст допускает неопределённость (слова) и определённость (конкретные ссылки) одновременно
В то время Семантический Веб (и отчасти XML) ориентированы прежде всего на машины:
они представляют собой набор форматов для универсального представления данных, что в общем-то недалеко от бинарных форматов, которые существовали и десятилетия до этого (сама универсализация данных стала более насущной в силу существования Интернета и необходимости совместимости между данными из различных источников)
как и любой машинный формат, он должен быть точным и подчиняться определённым правилам, что не всегда приемлемо для людей

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

точно идентифицировать информацию
обобщать/детализировать информацию и контекст работы с ней
связывать информацию в пространственно-временные-реляционные комплексы

Кроме того, он подразумевает, что:

противоречия в идентификаторах должны разрешаться как можно раньше (то есть если мы вводим в строке поиска «опера», то мы должны решить, какую оперу мы ищем, ещё до того, как запустить поиск)
использование идентификаторов должно быть ненавязчивым (например, пользователь должен иметь возможность использовать естественный язык для обобщенного описания, как он это и делает всегда, но также и иметь возможность уточнять смысл, если он того хочет)
семантическая ссылка, в общем случае, должна указывать не на информационный ресурс (который является частным случаем абстрактного понятия, которое описывает что-то), а на смысл (то есть на то, что описывается и при помощи чего мы описываем и который включает в себя и информационные ресурсы)
дополнительная упорядочивающая информация (как классификация, ассоциация и т.п.) должна быть подразумеваемой, так как она может быть легко извлечена из самого идентификатора
идентификаторы должны быть транслируемы, так как люди используют разные системы идентификаторов (языки), а также так как существуют синонимы
идентификаторы должны быть делегируемы, так как идентификаторы могут менять смысл в зависимости от субъекта, который их употребляет, и так как таким образом мы можем улучшить масшатабируемость (делегировав нагрузку) и распределённость (разделив запрос на специализированные подзапросы)
обобщающая информация должна иметь приоритет над детализированной (например, статья с заголовком «Арагон» имеет больший приоритет над информацией, в которой упоминается Арагон)
смысл должен быть интегрирован с любой информацией (файлы, текст и т.п.) и совместно использоваться
использование смысла, а также обмен им должны быть упрощены (интеграция в интерфейс, фильтрация)

Компромисс между точностью и гибкостью может быть достигнут только на стыке технологий, которые их предоставляют. В отношении смысла такими технологиями выступают машинно-ориентированный XML (стандарты Семантического Веба отчасти являются продолжением идей XML) и человечески-ориентированный HTML. Микроформаты уже используют эту идею, с несколькими «но»: (а) это опять же «форматы», т.е. опять же ориентированы на машины (люди способны работать с форматами тоже, но только до определённой степени сложности), (б) это именно микроформаты, то есть возникает проблема их фрагментированности, (в) они используют теги class, rel, rev и title, которые уже имеют другой смысл и которые не могут обеспечить всех возможностей, но об этом ниже. Так как же сделать решение дружественным и для людей и для машин, но чтобы в то же время присутствовали все необходимые возможности?

Идентификация

Прежде чем манипулировать чем-то, мы должны узнать, что это. А для этого нам нужна идентификация. И идентифицирующий протокол. Почему именно протокол? Естественного языка (который выступает таким идентифицирующим протоколом в реальной жизни) нам недостаточно, в силу его двусмысленности. Зачем нужен протокол, можно видеть на примере гипертекстового протокола: он нужен, чтобы установить соответствие между URL и информационными ресурсами. Точно так же идентифицирующий протокол нужен, чтобы установить соответствие между идентификаторами и между любым идентификатором и предметами и действиями реального мира, понятиями и т.п. Для этого, собственно говоря, уже существует URN, но он не нашёл своего развития в силу ограничений:

говоря о различиях между URN и URL, первый сравнивают с «именем адресата», а URL с «адресом», утверждая, что они дополняют друг друга
URN включает в себя NID (идентификатор пространства имён), которые должны регистрироваться (подобно именам доменам)
URN включает в себя NSS (строка пространства имён), который не учитывает особенностей построения идентификаторов в естественном языке
Эти ограничения существенно сдерживают применения URN, так как:
на самом деле URL — частный случай URN, так как представляет собой частный случай идентификатора, который указывает на информационный ресурс в Интернете
существующая вялотекущая регистрация NID-ов потенциально грозит той же коррупцией, которая сложилась с доменами и коллизиями вокруг имён; разумеется, что регистрация сама по себе необходима, чтобы исключать конфликты между пространствами имён, но она должна быть децентрализированной и распределённой
NSS представляют собой труднозапоминаемые идентификаторы (например, urn:isbn:0451450523 для книги или urn:isan:0000-0000-9E59-0000-O-0000-0000-2 для фильма); вместо них желательно использовать сложные идентификаторы на естественном языке (но и транслируя их за сценой в более точные идентификаторы, если это неоходимо)

Например, возьмём наш случай со словом «опера». При помощи URN мы можем представить отдельные значения как:

urn:browser:Opera
urn:art:opera
urn:hotel:Opera (Madrid)
urn:English:opera
urn:Russian:опера

Вообще говоря, существует бесконечное количество NID-ов (включая личные, например urn:PetrovVasiliy:я, который укажет, что идентификатор «я» связан с конкретной личностью, или для организаций: urn:Моя компания:Здание 1, Офис 220, или urn:Моя компания:Проект 1, Приложение, Окно настроек), которые относятся либо к различным системам идентификаторов (языки, протоколы и т.п.), либо к субъектам, в рамках которых складывается своя система идентификации (личности, организации, науки и т.п.). Отдельного упоминания заслуживают цифры, которые представляют собой бесконечный ряд идентификаторов, изменяющихся по определённым правилам. Они тоже нуждаются в субъекте (который меняет их смысл), который должен представлять (1) систему исчисления, (2) формат разделителей, (3) единицу измерения.

По сути же NID представляет собой субъект, в рамках которого идентификатор получает субъективную ассоциацию с предметом или понятием. Но идентификаторы могут менять смысл не только из-за субъекта, но и в силу следующих факторов:

предыдущего контекста (например, «Я видел сегодня фильм А и фильм Б. Этот фильм — лучший», где слово «фильм» в последнем предложении может принимать два значения)
времени высказывания («Я видел фильм», сказанное вчера и сегодня, может указывать на разные фильмы)
субъекта высказывания («Я видел фильм», сказанное разными людьми, может указывать на разные фильмы)
субъективного времени (выражающиеся в модальных глаголах и различных временах: «Я мог видеть этот фильм» или «Я посмотрел бы этот фильм»)
Больше того, эти факторы могут пересекаться (субъект может предоставлять смысл для идентификаторов внутри какой-либо темы: urn:Моя Компания:Предметная Область:термин) и отсутствовать вообще (если вы знаете термин, но не знаете, к какой категории он принадлежит).

Смысл (абстрагирование, связывание)

Главная цель идентифицирования — сделать сравнение точным. В простейшем случае это сравнение двух идентификаторов: т.е. если у нас есть запрос «Смотрел ли ты Храброе сердце?» и текст «Я смотрел Храброе сердце», где обе фразы «Храброе сердце» указывают на «urn:movie:Braveheart(1995)», то мы сможем сравнить их более точно, чем это возможно сейчас. Но ведь запрос и текст не ограничивается только простыми идентификаторами. Система URN может дать базу для элементарных идентификаторов, но она не может охватить все возможные их сочетания и то, как эти сочетания образуют все более сложные структуры, балансируя между краткостью и точностью. Для этого нам и нужен гипертекст.

Представьте, что у нас есть следующий XML (на его месте может быть любой другой формат), который соответствует стране и её характеристикам:

<Country>  <!-- Страна -->
	<Name>Бутан</Name> <!-- Название -->
	<Area>38,8 кв. км.</Area> <!-- Площадь -->
</Country>

Вроде бы эта структура довольно понятна для человека (знакомого с английским языком), но с ростом количества полей и информации вам трудно будет разобрать эту информацию даже в иерархии. А названия полей? Во-первых, предпочтительно использовать не только латиницу; во-вторых, даже если название состоит из двух слов, мы вынуждены их соединять в один идентификатор (например, «LastName») или заменять пробел другим разделителем, а иногда они вообще представляют собой аббревиатуры (например, «LName»). А можно ли представить ту же самую структуру внутри HTML?

<span s-id="urn:Страна"> <!-- urn:* задаёт префикс по умолчанию для данного субъекта -->
	<span s-id="Название" s-id="urn:country:Bhutan">Бутан</span> 
	<span s-id="Площадь">38,8 кв. км.</span>
</span>

Тоже самое мы можем сделать и с любой другой структурой, например таблицей:

<table s-id="urn:Страна"> 
	<th s-id>Флаг</th>
	<th s-id>Название</th>
	<th s-id="urn:Площадь:кв.км">Площадь</th> <!-- у единиц измерения площади собственное подпространство имён -->
	<tr s-id="urn:country:Bhutan" s-id="#bh"> <!-- #bh - локальный идентификатор -->
		<td><img src="bhutan.jpg" /></td>
		<td>Бутан</td>
		<td>38,8</td>
	</tr>
</table>

<p>Королевство <span s-ref=»#bh»>Бутан</span> — государство в Азии в Гималаях, расположенное между Индией и Китаем.</p>

где:
— s-ref=»#bh» связывает второе упоминание Бутана с локальным идентификатором
— вложенность тегов является естественной возможностью для выражения обобщения/детализации (Страна -> Название -> Бутан)
— логика соответствия полей и значений может отличаться в разных тегах («Название» может быть атрибутом тега, а может быть и отдельным тегом)
— пустой атрибут необходим для исключения избыточности (в примере это означает, что значение внутри тега используется как s-id)

Или же, не используя вложенные теги:
<s-of=»#3″ s-id=»#1″>Площадь</s-of> <s-id=»#2″>страны</s-id> <s-id=»urn:country:Bhutan» s-id=»#3″ s-is=»#2″>Бутан</s-id> — <s-of=»#1″>38,8 кв. км</s-of>.

где:
s-of=#3 связывает «площадь» и «Бутан»
s-is=»#2″ связывает «Бутан» и «страна»
s-of=»#1″ связывает «38,8 кв. км» и «площадь»

или
<s-id=»#1″ s-has=»#4″>Площадь</s-id> <s-id=»#2″>страны</s-id> <s-id=»urn:country:Bhutan» s-id=»#3″ s-is=»#2″ s-has=»#1″>Бутан</s-id> — <s-id=»#4″>38,8 кв. км</s-id>.

где:
s-has=#4 связывает «площадь» и «38,8 кв. км»
s-has=»#1″ связывает «Бутан» и «площадь»

Итак, зачем нам нужны вышеупомянутые теги?
— s-id: связывание идентификаторов естественного языка и элементов гипертекста с другими идентификаторами
— s-is: абстрагирование (в нашем случае это «Бутан», абстрагируемый в «страна», но это может быть и краткое содержание статьи или книги)
— s-of: обобщение в виде части общего (например, «площадь Бутана»)
— s-has: детализирование
— s-ref: связывание

Будет ли весь гипертекст использовать идентификацию и семантические теги? Нужно ли это? Использование уже существующего html позволяет производить разметку по мере необходимости (в первую очередь, она может затронуть краткое содержание страниц как наиболее важную часть контента).

Достаточно ли этих тегов? Здесь предлагается упрощённый набор тегов, использования которых будет достаточно для простейшего абстрагирования и связывания. Аналогично этому, в естественном языке, нам достаточно одних лишь пробелов и знаков пунктуации (набор которых ограничен), чтобы выразить все связи между словами. Но ведь есть же ещё глаголы, прилагательные, наречия. Как быть с ними? На самом деле, мы можем использовать естественный язык и без того, чтобы знать, является ли слово глаголом или нет. В конце концов, если мы точно идентифицируем слово, то компьютер и сам может точно сказать, глагол это или нет (а чаще и без этой подсказки). Но возможно, что нам нужно очевидно сказать, что глагол является глаголом. Освещение данной темы выходит далеко за пределы этой статьи.

Поиск

Итак, что же меняется с точки зрения поиска информации? Например, что найдет запрос «Какова площадь Бутана?»? Любой вопрос имеет дело с неизвестным, для чего нам нужен свой идентификатор: urn:_. Таким образом, вопрос «Какова площадь Бутана?» должен представляться как (впрочем, явное использование идентификатора для неизвестного может быть излишним, т.к. список вопросительных слов довольно ограничен, а следовательно, может использоваться автоматически)
<s-id=»urn:_» s-of=»#1″>Какова</s-id> <s-id=»#1″ s-of=»#2″>площадь</s-id> <s-id=»urn:country:Bhutan» s-id=»#2″>Бутана</s-id>

тогда как искомая фраза как
<s-of=»#3″ s-id=»#1″>Площадь</s-of> <s-id=»#2″>страны</s-id> <s-id=»urn:country:Bhutan» s-id=»#3″ s-is=»#2″>Бутан</s-id> — <s-of=»#1″>38,8 кв. км</s-of>

Таким образом, запрос сводится к нахождению одинаковых связей (между «площадью» и «Бутаном»), игнорированию нерелевантных (связь между «страной» и «Бутаном»), а также к сравнению искомого в запросе (между «площадью» и неизвестным) и тексте (между «площадью» и «38,8 кв. км»).

Но использование urn:_ не ограничивается одними только запросами. Так, например, сервис, предоставляющий географические данные о странах, может не индексировать все свои запросы, а предоставлять данные в виде связанности с неизвестным, например: <s-id=»#1″ s-of=»#2″>Площадь</s-id> <s-id=»#2″ s-id=»urn:country»>стран</s-id> <s-id=»urn:_» s-of=»#1″>. Тогда при поиске «Какова площадь Бутана?» мы можем воспользоваться данным сервисом, если мы используем абстракцию Бутана как страны.

Но, конечно же, поиск не будет ограничиваться только простейшими запросами. А более сложные запросы могут включать (а) похожую, (б) подразумеваемую информацию. Например, запрос «Бутан — большая страна?» подразумевает, что запрос должен найти значение площади Бутана и сравнить её с понятием «большая страна», что возможно только примерно, так как не существует общепризнанной классификации площадей государств. Или возьмём ещё более неоднозначный вопрос: «Тепло ли в Бутане?» Попробуем его соотнести с фразой «На севере Бутана — круглогодичный снег, на западе — сильные муссонные дожди, в восточной и центральной части — сухой климат, на юге — влажный субтропический климат». Здесь нельзя найти точного соответствия между отношениями «тепло» и словами для описания климата. Однако можно заметить, что «тепло» и «субтропический климат» схожи; в таком случае, если точное соответствие не найдено, мы можем использовать похожие идентификаторы, явно указав критерий схожести: «Тепло на юге Бутана, где субтропический климат» (естественно, что мы взяли только одну фразу как ответ, но в реальной жизни ответ должен быть расширен при помощи дополнительных фактов).

Если же запрос («Что такое Бутан?») даёт нам больше, чем один ответ, то к ответам необходимо применить рекурсивно основные операции:

идентификации («Бутан» как страна, «бутан» как газ)
детализации (сведения о Бутане, карты и т.п.)
обобщения («Бутан и туризм», «Бутан и горы» и т.п.)
связи («Как проехать в Бутан», «Как получить визу в Бутан» и т.п.)

В свете вышесказанного то, как находится информация, должно ещё больше волновать создателей информации. Ведь теперь успешность нахождения созданной информации будет зависеть не только от алгоритма поискового сервиса, а и от более точных и универсальных правил, которые должны быть эквивалентными для любого приложения. Задача создателя информации должна состоять не только в точной идентификации содержимого и установлении связей внутри информации, но и в последующем тестировании, находится ли ваша информация соответствующими запросами. Напротив, задача классификации информации должна стать менее значимой: ведь классификация представляет собой набор обобщений, относящихся к информации. Но при наличии идентификации они не нужны, так как один и тот же идентификатор доступен как для создателя, так и для потребителя информации, а все возможные обобщения могут быть выведены из самого идентификатора (о них создатель информации может даже не подозревать). Например, если вы определили Бутан как страну, то из этого можно легко вывести, что это слово имеет отношение к географии, Земле, горам, и т.п.

Организация информации

Проблемы организации информации не менее важны, чем проблемы поиска и смысла. По сути же они взаимосвязаны друг с другом, и их нужно решать в комплексе. Ведь эти проблемы затрагивают информацию, которая не может быть структурирована в виде гипертекста, а также способы, с помощью которых информация и субъекты (которые её хранят и ищут) взаимодействуют между собой.

* Как искать информацию в бинарных файлах?
У бинарных файлов есть только имя (в которое можно добавить не так уж и много структурированной информации, а если и добавите, то только в неизвестном для других формате, как «Bravehear_1995_Gibson») и так называемая метаинформация (которая, впрочем, существует не для всех видов информации, а формат метаинформации ограничен). В силу этого нам нужно другое решение: гипертекст должен описывать информацию и иметь возможность быть присоединённым к файлу. Таким образом, каждое копирование файла должно подразумевать, что получатель получит также и присоединённую обёртку файла, которая его описывает и (возможно) идентифицирует.

Но для этого нам необходим ещё один маленький шаг — семантическая форма гипертекста. На самом деле она, возможно, не так уж необходима, но это делает цель использования гипертекста более очевидной: то ли мы используем его для представления информации и тогда используем тег body, то ли он используется только для семантики и тогда мы используем тег semantics. Например, видеопоток может быть описан так:

<semantics>
	<s-id="urn:movie:Braveheart(1995)" s-has="urn:movies:trailer" />
</semantics>

Список файлов (URL) может быть описан так:

<semantics>
	<s-id="urn:file://c:/movies/braveheart.html" />
	<s-id="http://youtube.com/watch?v=vBXBtORI7pE" />
</semantics>

Подобное представление также может использоваться для цитирования (которое может являться внешней разметкой информации, т.е. которая сделана не создателем информации):

<semantics>
	<s-id="http://mysite.com/blog/braveheart.html">
		Мое мнение.
	</s-id>
</semantics>

То есть, работая с уже описанными файлами, вам не нужно будет заново идентифицировать их, что упрощает дальнейшее использование: вам не нужно думать, куда его сохранять и как его найти в будущем (так как он будет встроен в вашу локальную систему на основе идентифицирующей и классифицирующей информации в описании). Например, вместо «c:/movies/braveheart.html» (путь и имя файла гарантируют уникальность этого идентификатора внутри вашей системы, но он будет отличаться на других системах) вы сможете использовать «urn:movie:Braveheart(1995)» как глобально уникальный идентификатор (которые мы и так используем в реальной жизни) и как классифицирующую информацию, которая ассоциируется с этим идентификатором (а не фиксированную классификацию в виде иерархии каталогов).

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

* Как взаимодействуют информация и субъекты?
Наши современные возможности для запроса, передачи и доставки информации искуственно сдерживаются существующим программным обеспечением. Например, представьте, что вы не можете найти необходимую информацию и проделываете следующие действия: (1) вы запрашиваете это, например, при помощи электронной почты; (2) друг ищет файл; (2а) прикрепляет его к письму и посылает вам ответ или, как вариант, (2б) шарит файл и посылает вам ссылку; (3) если файл был обновлён, то процедура повторяется. Мы вынуждены совершать подобные действия, так как: (1) мы не можем запросить информацию напрямую; (2) мы должны знать, где информация должна быть найдена; (3) работа с версиями и обновлениями информации доступна только в специализированных программах; (4) способ обмена информацией отделён от самой информации.

Чтобы решить проблему взаимодействия информации и субъектов, участвующих в её круговороте, мы должны:

представлять компьютерные ресурсы (сети компьютеров, сами компьютеры, приложения и даже отдельно взятые файлы) как провайдеров информации
провайдеры могут использовать маршрутизацию запросов
провайдеры могут сравнивать версии информации, имеющиеся у другого провайдера, а также обновлять её и уведомлять об изменении
субъект коммуникации тоже представляет собой провайдера информации (где настройки протокола указывают ссылку на источник информации)

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

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

трансляция идентификаторов из одной системы в другую (перевод слов, соответствие синонимов и т.п.)
делегация сложных идентификаторов, когда часть идентификатора указывает на другую систему идентификаторов (например, идентификатор отеля может включать в себя и идентификатор города, так как одно название не обеспечивает уникальности)
делегация подзапросов (например, запрос о фильме о средневековой Шотландии может быть разделён на подзапросы о географии Земли, историческом делении эпох и о видах искусства)
делегация соответствия идентификаторов и ресурсов, так как на каждом уровне (работник — отдел — компания — мир) могут быть разные соответствия (т.е. для работника «Проект 1» может означать один набор документов, а для внешнего мира — совсем другой)
делегация вычислений, когда запросы могут распределяться между ресурсами
делегация неполных идентификаторов (вы можете использовать идентификатор без указания NID-а — особенно это актуально для запросов, которые сами должны найти соответствующий NID).

То есть провайдеры информации могут использовать довольно сложную маршрутизацию запросов (например, вы можете использовать компьютеры А и Б как провайдеры информации по проекту 1, а компьютеры А и В по проекту 2), которая должна быть скрыта от пользователя. А например, если вы ищете «Спецификацию проекта 1», то запрос за кулисами может пройти по следующему маршруту:
1. Искать документ в данном приложении (если не найден, то перенаправить запрос на уровень выше).
2. Искать документ в данном компьютере.
3. Искать документ в данном домене сети (если не найден, то перенаправить запрос на провайдера внутри домена).
4. Искать документ в компьютере А.
5. Искать документ в приложении 1 компьютера А.
В итоге вы можете получить документ по пути \computerAapp1doc1.doc, даже не подозревая о том, где находится документ.

Заключение

Крестьянину нужно перевезти через реку волка, козу и капусту. Но лодка такова, что в ней может поместиться крестьянин, а с ним или только волк, или только коза, или только капуста. Но если оставить волка с козой, то волк съест козу, а если оставить козу с капустой, то коза съест капусту. Как перевёз свой груз крестьянин?

Что у нас есть:
1. Крестьянин, волк, коза, капуста, река, лодка.
2. Лодка перевозит крестьянина и волка, или козу, или капусту.
3. Волк ест козу, коза ест капусту.
4. Вопрос: как перевёз свой груз крестьянин?

Что подразумевается:
1. У реки два берега.
2. «Перевозить» подразумевает перемещение предмета (при помощи лодки) с одного берега на другой.
3. «Груз» подразумевает волка, козу и капусту.
4. «Перевезти груз» подразумевает, что если в начале волк, коза и капуста были на одном берегу, то в конце они будут на другом.
5. «Перевезти лодкой» означает, что крестьянин и один предмет помещается в лодку на одном берегу, а потом этот предмет извлекается на другом берегу.
6. «Оставить» подразумевает, что крестьянин находится в лодке с одним предметом, а слова, связанные с «оставить», находятся на одном из берегов.
8. «Ест» подразумевает, что второй предмет уничтожается.

Возможно ли решить данную задачу, разметив данный текст при помощи семантических тегов? Задача включает как начальные условия (то есть то, что мы можем идентифицировать непосредственно), так и подразумевающиеся условия (выводимые при помощи детализации и обобщения), причём каждое из условий представляет собой идентификаторы, связанные между собой. То есть все необходимые операции вполне покрываются описываемым выше решением. Но возможно ли создать решение на основании полученного гипертекста? Пусть этот вопрос остаётся открытым, как и другие проблемы и их решения, которые просто невозможно осветить в одной статье.