Коллектив Авторов - Цифровой журнал «Компьютерра» № 29 Страница 22

* Обычные идентификаторы (например, естественного языка) используются для графических элементов, но неотделимы от самих элементов (т.е. недоступны для переиспользования).

* Элементы интерфейса, файла, документа, приложения и сайтов монолитны и неотделимы друг от друга, что затрудняет переиспользование.

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

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

* Гипертекстовая ссылка ссылает слово (абстрактное) на ресурс (конкретное).

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

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

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

* Практически отсутствует возможность сохранять «снимки» информации, с которой вы работали (например, последний запрос к базе данных или сайту), с возможностью обновить позднее

* Невозможно при поиске получить точный ответ (вместо этого вы получаете миллионы ссылок)

* Практически невозможно руководствоваться целями при работе с приложениями (хотя мы их представляем, когда работаем), а только инструкциями (например, вместо того, чтобы поставить цель «послать документы господину Х» мы должны разбивать нашу цель на команды, которые включают в себя выделение документов, нахождение господина Х в адресной книге, и отсылку при помощи какого-то приложения)

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

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

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

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

* Ассоциации (ключевые слова, теги и т.п.) часто заменяют абстракции (редуцированную или обобщенную информацию). Хотя, в общем случае, информация имеет множество ассоциаций, но одну абстракцию.

* Приложения детерминированы и не могут работать с непредусмотренными ситуациями

* Пока не существует способов фильтрации, способных значительно сужать область поиска

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

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

* Семантический Веб предлагает использовать URI для идентификации любых объектов, но не предлагается способа разделять идентификаторы обычных объектов от идентификаторов http объектов

* Семантический Веб предлагает определять семантику в виде онтологий, не связывая разные онтологии между собой

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

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

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

Нам нужен новый уровень абстракции, который скроет от нас детали компьютерной реализации обработки и представления информации. Разумеется, кое в чем, это уже сделано сейчас на пользовательском уровне. Но этого недостаточно, если учитывать реалии сегодняшнего дня. Что же данный новый уровень будет включать в себя?

* Общий подход: мягкая интеграция

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