Архивы: по дате | по разделам | по авторам

Идентификация, абстрагирование, смысл

АрхивReaditorial
автор: Юрий Гуськов   12.08.2010

Интернет - это большая свалка информации. Впрочем, не без попыток отсортировать и упорядочить. Даже лучшие сортировочные машины выдают миллион ссылок на простейшие запросы.

Орфография и пунктуация автора сохранены.

Интернет - это большая свалка информации. Впрочем, не без попыток отсортировать и упорядочить. Но даже самые успешные сортироворочные машины на простейшие запросы вываливают на вас миллион ссылок (что, по видимому, должно считаться символом успешности сортировки, как если бы вы попали в библиотеку, а вам сказали: "да, у нас есть миллион книжек на эту тему, поищите там..."). Что ж, приходится полагаться на собственные умения и досортировывать то, что уже предложено. Вполне естественно, что обычно мы ограничиваемся сортировкой десятка, максимум, сотни ссылок, если ничего не находим - поиск можно считать провалившимся. Конечно, сортировочные машины проделывают огромную работу: по расчетам, на данный момент, в Интернете существует около 1 триллиона (10 в 16 степени) уникальных страниц, запросы на общие слова обычно дают около сотни миллионов страниц (10 в 8 степени), на менее общие мы уже получаем десятки миллионов, и так далее. Но ведь, в реальной жизни, поиск должен давать от десятка-сотни до одной ссылки. Например, на запрос "чемпион мира по футболу 2010 года" существует ровно один ответ, на запрос "кошки", наверное, все же ожидается ответ с сайтами и страницами, посвященным только им, а не все ссылки, где они так или иначе упоминаются. Поэтому неудивительно, что современные поисковики пытаются угадать то, что вам нужно, предложить лучшую фильтрацию, полагаются на человеческую досортировку, логично полагая, что уж люди лучше разберутся в информационном хламе.

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

Можно ли решить проблему больших объемов информации? Кое-кто полагает, что решение в коллаборации и разного рода социальных сетях, а также Семантическом Вебе (который, хотя и акцентируется на интеллектуальных агентах и приложениях, но тоже подразумевает своего рода социальную сеть). Однако существует, по крайней мере, две проблемы. (1) Информация, когда создается и публикуется, уже должна быть упорядочена. Возникает вопрос, есть ли гарантия, что сторонние люди упорядочат ее лучше, чем ее создатели? (2) Порой коллаборация вместо упорядочивания информации создает еще больший объем информации, которую в свою очередь, тоже надо упорядочивать. (3) Часто упорядочивание требует эксперта, что порой просто невозможно. Другие перспективные направления включают (но не ограничены только этими): виртуальная реальность, дополненная реальность, 3-мерный интерфейс, распознавание образов и языка. Некоторые из них еще недостаточно развиты, другие же весьма эффектны эстетически, но не так полезны практически. Раз так, то давайте попробуем взглянуть на проблему с другой стороны: а можно ли вообще понять, что хотя бы теоретически могло бы решить эту проблему? Для начала можно посмотреть на революции прошлого и попробовать понять, почему то или иное изобретение оказалось прорывом.

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

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

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

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

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

* Графический интерфейс. Его преимущества связаны не только с тем, что человек лучше воспринимают информацию визуально (человек быстрее обрабатывает пространственные абстракции, чем логические или языковые, к тому же само абстрагирование возможно является порождением именно визуального восприятия информации). Не менее важно и то, что он явно предоставляет и ограничивает информацию (т.е. вы видите все команды сразу, а не вспоминаете их, а их возможные значения ограничены в списке и т.п.) и связывает ее (одному элементу соответствуют другие элементы информации или действия, например, связь между объектом и действиями, предоставляемыми в меню). Однако, при большом количестве элементов мы опять возвращаемся к необходимости использования поддержки естественного языка (в виде руководств и т.п.). К тому же, что часть элементов приходится скрывать, упорядочивая их в иерархии (меню, деревья, вложенные окна и т.п.), при этом мы ограничиваем контекст, что хорошо для понимания отдельной области, но при этом же, многие уровни вложенности так хорошо скрывают возможности приложения, что ими редко, кто пользуется, а иногда и с трудом находит. Наконец, еще одна проблема заключается в том, что элементы графического интерфейса и данные связаны неявно (для пользователя), что не позволяет переиспользовать подобный интерфейс (т.е. ссылаться на элементы GUI). При всех преимуществах, графический интерфейс всегда поддерживается натуральным языком: в корне проблемы лежит тот факт, что визуальные элементы программы не всегда интуитивно понятны, в то время как естественному языку люди обучаются в течении десятилетий. Собственно говоря, иконки ничем не отличаются от букв (которые тоже являются иконками), но при необходимости компоновки сложных действий - это проще будет сделать при помощи естественного языка (в виде инструкции), либо при помощи абстрактного языка скриптов, а не переиспользуя графический интерфейс. В целом, хотя графический интерфейс и очень эффективен, но он не может представить любую информацию (например, звук), поэтому универсальным может быть только символьный интерфейс.

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

* Гипертекст, Веб, Веб 2.0, доменная система. В свою очередь, представляет собой симбиоз трех факторов: связывания ресурсов (различных репрезентаций информации), форматирования данных и разного рода динамика: клиентская (ДжаваСкрипт, плагины) и серверная (формы, элементы графического интерфейса) ресурсов. Впоследствии, серьезное внимание было уделено форматированию и динамическим возможностя, поэтому были упущены недостатки связывания. А именно, гипертекстовое связывание позволяет реализовать ссылку только один-к-одному, и наибольший смысл имеет только тогда, когда мы ссылаемся на уникальный ресурс (или оригинал) или же ссылаемся на часть общего целого (как, например, один сайт). Если же мы ссылаемся на произвольный ресурс произвольного сайта (например, новость на определенном новостном ресурсе, хотя она продублирована на множестве других), то такая ссылка становится ограниченной и субъективной. Веб 2.0 представляет собой развитие динамической составляющей ресурсов, добавляя больше возможностей графического интерфейса со стороны клиента. Доменная система является аналогом "файловой системы" Интернета, где домен и его компоненты должны (теоретически) идентифицировать провайдера информации. Практически же, домены в виде идентификаторов часто неправильно (намеренно или нет) используются (как и имена файлов), что поощряет коррупцию вокруг доменных имен.

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

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

* XML, Семантический Веб. Идея связывания всего и представления в одном универсальном формате лежала еще в основе HTML, а если копнуть еще глубже, то и в SGML (если уж копать дальше и дальше - идея-то прорабатывалась еще философами за много столетий до того как). XML подошел к проблеме ближе, так как, по крайней мере, был достигнут консенсус по поводу универсального формата. Однако, не хватало смысла. Семантический Веб добавил немного смысла, и стал потенциальным кандидатом на новую революцию, но он обладает и определенными недостатками. Главное - это то, что он ориентирован на обработку "интеллектуальными агентами", а не простыми пользователями. И обработку, в основном, данных, причем, данных упорядоченных. К тому же, формат тройки "субъект-предикат-объект" заставляет сомневаться в целесообразности абстрагирования всего при его помощи. Никто не подвергает сомнению факт, что всё можно втиснуть в подобный формат, но будет ли являтся это целесообразным? Этот принцип аналогичен конструкциям естественного языка, где подобные тройки выступают как символ дуальности пространства-времени и выражение факта, что любое действие происходит между двумя предметами. Но, в естественном языке формат тройки не является обязательным, к тому же часто расширяется обстоятельствами. Разумеется, что и дополнения, и обстоятельства можно представить тройками тоже, но это может быть целесообразным только, когда субъект, предикат и объект - это роли, а не смысл. Например, в таком случае в роли предиката может выступать как глагол-действие, так и глагол-отношение, а в роли объекта как существительное (объект), так и прилагательное (которое редко бывает объектом, а обычно выступает атрибутом объекта). Любимый пример в Семантическом Вебе: "небо голубое", где субъектом выступает "небо", предикатом "иметь цвет", а объектом "голубое". Как мы видим, здесь не совершается никакого действия по смыслу, а выражается только отношение (или же атрибутивность). Данный пример показывает, что изначальный смысл дуальности пространства и времени (например, в "я иду"), представляется в абстрактной форме, где вся предикат и объект являются ролями. И, конечно, очевидный недостаток в обязательности тернарного представления, хотя большинство данных организовано в Н-арном виде, в общем случае (особенно это очевидно в мире компьютеров, где данные могут быть связаны множеством произвольных ссылок, но это истинно и для естественного языка). Онтологии Семантического Веба вводят новый уровень сложности, но не являются ли они логическим продолжением XML схем, на которые мечтали перевести целые индустрии несколько лет тому назад (и на которые все так и не перешли)? В целом, мы видим картину, что с Семантическим Вебом могут работать (по крайней мере, на данный момент), в основном, эксперты, что очень сужает возможности коллаборации на его основе.

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

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

Проблема идентификации идеально решается в программировании. Что неудивительно - ведь там это необходимое условие самого процесса (т.к. всё должно быть идентифицировано, чтобы использовать его в дальнейшем). Для всего остального мира, проблема идентификации как стояла, так и стоит, как никогда остро (впрочем, проблема существует даже в программировании на месте его стыка с миром не-программирования, например, идентификации предметов, не включенных в программу напрямую). Текстовый интерфейс усугубил проблему идентификации тысячей аббревиатур, которые необходимо запомнить (или найти). Графический интерфейс облегчил проблему тем, что показывает идентификаторы явно, однако проблема его заключается в том, что эти идентификаторы не доступны для переиспользования (например, чтобы сослаться на какой-либо элемент и изменить его значение/состояние). Файловая система вводит еще один уровень сложности идентифицирования, т.к. необходимо запоминание имен файлов и путей. Доменная система заставляет запоминать имена доменов и URL-ы. В целом, конечно, любое запоминание полезно для тренировки памяти, но на выходе мы также видим свалку из миллионов идентификаторов. И ладно, когда чужие идентификаторы нам ничего не говорят о содержимом, так даже те идентификаторы, которые мы используем для собственных файлов, со временем тоже могут потерять смысл.

* Абстракция

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

* Смысл

Проблема смысла лучше всего решается в программировании. Что такое смысл? Простейшее определение может звучать так: комплекс идентификаторов сходны по смыслу, если стоящие за ними объекты, действия, отношения тоже сходны. Например, комплекс идентификаторов может включать: (1) фотографию части реальности, где травка зеленеет и солнышко блестит, (2) сочинение, описывающее эту часть реальности, (3) предложение "травка зеленеет, солнышко блестит", (4) предложение "весна пришла, ожили растения, стало тепло и сухо". Разумеется, что полной эквивалентности между этими комплексами достичь практически невозможно, так (2) абстрагирована при помощи фотоаппарата (а если это картинка в памяти, то абстрагирована человеческим глазом), (2), (3) и (4) являются результатом абстрагирования человеческого ума, причем (3) и (4) также могут выступать в качестве абстракции по отношению к (2). Все эти случаи не могут быть полностью эквивалентными, так как полностью идентичное абстрагирование двух инструментов абстракции (человеческий ум, глаз, фотоаппарат, и т.п.) достижимо только в идеальных условиях. Поэтому нам приходится устанавливать допустимые границы, в пределах которого мы считаем комплексы сходными. Так, в нашем случае, смысл абстрагируется в объекты травы и солнца, которые соответственно зеленеют и блестят (действия, отношения). Абстрагируясь, мы можем отбросить факты, что трава не полностью зеленеет, и не всегда солнышко блестит. Обозначив допущения, мы можем прийти к ситуации, в которой все комплексы могут считаться сходными. В программировании каждому объекту реального мира соответствуют либо переменная, либо объект, либо комплекс объектов и т.д. Чего нет или частично нет в программировании: (а) категоризации элементов смысла (объекты, действия, отношения, временные отношения, и т.п.), (б) связи с объектами реального мира. Тоже самое касается и Семантического Веба, который пытается упорядочить информацию при помощи новых стандартов, но не решает полностью ни проблему категоризации (хотя пытается при помощи онтологий), ни проблему связи с реальным миром (хотя пытается при помощи URI/URN).

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

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

* Компьютерные идентификаторы неестественны (слова естественного языка часто представляются в виде не всегда понятных аббревиатур, разделители либо пропускаются, либо заменяются другими разделителями) и сложны для запоминания (URL). Например, equalsIgnoreCase - идентификатор используемый для сравнения игнорируя регистр букв, он эквивалентен идентификатору естественного языка "equals ignoring case" или же другому компьютерному идентификатору equals(boolean ignoreCase). Как мы видим компьютерные идентификаторы приводятся к неестественному виду главным образом, т.к. игнорируются разделители естественного языка (которые используются для других целей) и т.к. часть смысла становится статической, а не динамической (параметром).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Трансляция идентификаторов может производиться и в вызовы действий/сервисов/методов (с параметрами), что аналогично предложениям естественного языка (например, "я написал письмо другу ручкой" подразумевает либо вызов "написал" с параметрами "письмо", "друг", "ручка", либо "написатьПисьмо" с двумя параметрами, либо "написатьРучкой"). Данный тип трансляции позволит: (1) ссылаться на разные идентификаторы, ресурсы, в зависимости от параметров, (2) более гибко связывать действия (например, страница может иметь идентификатор "написать письмо" без привязки к сервису или приложению), (3) использовать идентификаторы для помощи пользователю (например, инструкция вида "зайти в меню, выбрать в диалоге чекбокс, нажать ОК" может быть представлена в виде исполняемых идентификаторов) и т.п.

- Трансляция идентификаторов должна явно или неявно делегироваться (например, сначала к компьютеру пользователя, затем к более высоким уровням сетевой принадлежности: например, проект, отдел, компания, город, страна, глобальная сеть; как вариант делегация может идти по цепочке пакет приложений, приложение, библиотеки; или же используя контексты; т.е. от низкого к высшим уровням абстрагирования). Таким образом, (1) трансляция будет произведена на уровне, который способен обработать запрос, (2) трансляция может предоставлять разное понимание идентификатора из разных уровней, (3) возможно создание сетей серверов, которые будут отвечать за определенный набор идентификаторов (например, идентификаторы, относящиеся только к биологии и т.д.), (4) упростить обмен информацией (например, вы посылаете идентификатор "документ проекта" коллеге, он пытается его открыть, но операционная система сообщает, что данный документ доступен только на другой машине и предоставляет возможность сохранить его локально).

* Абстрагирование

- Явное представление результатов абстрагирования (например, статья о выпуске модели А машины марки Б должна абстрагироваться в условную фразу "выпуск модели А марки Б", которая состоит из идентификаторов "выпуск", "модель А", "марка Б", связанных между собой, где "модель А" включается в "марку Б", т.к. не может существовать независимо от нее, а "выпуск модели А марки Б" включает в себя все идентификаторы, т.к. является результатом их связывания). Типичным примером представления "идентификатор + абстрагирование" в современном мире является связка "ID + Имя", которая часто используется в приложениях, где первый элемент является компьютерным идентификатором, и второй - обычным.

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

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

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

- Критерии важности, основаны на способе абстрагирования и фильтрации информации (что в современном интерфейсе выражается сортировкой и фильтрацией).

* Смысл

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

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

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

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

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

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

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

* Интерфейс

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

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

- Информация должна быть доступна при помощи смысловых идентификаторов (например, вместо файла 1234.sub, информация будет видна как "субтитры фильма А"; причем, "субтитры" и "фильм А" - это два связанных идентификатора, которые возможно будет переиспользовать для дальнейшего поиска/фильтрации).

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

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

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

- Любой элемент интерфейса должен быть представлен в следующих аспектах: (1) декларативном (объявление и/или идентификатор), (2) императивном (связанный с действием или же с изменениями, например, для текстового поля), (3) ссылочном, (4) вопросительном. Данные аспекты помогают понять, как данный элемент можно (1) использовать и переиспользовать, (2) менять и изменять при его помощи другие элементы, (3) связан с другими элементами, (4) может быть связан с другими элементами, вследствие недостаточных сведениях о связях или необходимости уточнения.

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

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

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

Итак, как это будет работать всё вместе?

Пример 1. В отпуске вы сняли фотографии и привезли их домой.

1. Открываете контекст фотографий (в котором доступны только графические приложения и/или только файлы с фотографиями).

2. Загружаете фотографии из фотоаппарата, при этом вам сразу предлагают классифицировать их внутри данного контекста. Вы набираете "отпуск", но у вас уже есть идентификатор "отпуск 2009 дача", поэтому вам предлагают добавить новый идентификатор (т.к. атрибуты файлов фотографий 2010 года и геотаг не находится близко от дачи), например "отпуск 2010 Париж" (т.к. для обозначения времени вы используете только год, а геотаги, абстрагируются в самую крупную географическую структуру, в районе Парижа, если же например, геотаги захватывают и Версаль, то они могут быть абстрагированы как Иль-де-Франс). При дальнейшей классификации, вы можете отобрать наиболее используемые идентификаторы: "я" и "жена" (которые имеют особые значения в пределах данного компьютера), "Лувр", "лучший", выделять фотографии, и перетаскивать идентификаторы на них, таким образом связывая их с фотографиями.

3. Ваша классификация готова к использованию. "лучшие фотографии из Парижа" теперь вернет только лучшие фотографии, а не все документы, в которых встречается эти слова. "я на фотографиях" вернет в том числе и мои фотографии из Парижа.

4. Если, вам нужно отправить лучшие фотографии из Парижа другу, то для этого достаточно только применить действие "отправить" к выделенным лучшим фотографиям, при этом вы можете выбрать (а можете и нет) способ передачи. Дальше возможны варианты: (а) друг доступен за компьютером, тогда он подтверждает передачу (если она не разрешена всегда), ваши компьютеры устанавливают доступное соединение (имейл, http, ftp, IM, p2p, и т.п.) и копируют фотографии, (б) друг не доступен, ему отправляется только сообщение о намерении передать файлы, он подтверждает, когда он включает компьютер, вы получаете подтверждение и ваш компьютер начинает передачу (без вашего вмешательства) на один из промежуточных серверов, далее, когда ваш друг включит компьютер - он получит ваши фотографии с промежуточного сервера. Причем, фотографии попадают в тот же контекст, что и у вас (хотя он, при желании, может быть изменен).

В чем отличие от современного положения вещей? (1) Идентификаторы значат ровно то, что они должны значить, т.е. дача - не просто слово, а может включать географические координаты, 2009 - это не число, а год, и т.п. (2) Идентификаторы доступны не только для приложения, в котором они могут быть созданы, но для всей системы и глобально (например, для той же передачи файлов) (3) Вам не нужно помнить их месторасположение на диске, использование контекста, классификация и абстракция гарантируют, что вы сможете их найти. (4) Вы работаете с компьютером при помощи целей (отправить), а не инструкций (открыть приложение, найти фотографии, приаттачить, отправить).

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

Использование блокирования может быть описано следующими пунктами: (1) необходимо, чтобы предотвратить доступ к компьютеру, когда пользователь отсутствует, (2) включается после периода неактивности, (3) может быть включен вручную, (4) может также использоваться, чтобы установить статус отсутствия в приложении обмена сообщениями. Для описания данных фактов с точки зрения смысла, нам необходимы следующие отношения: (1) цель (чтобы предотвратить доступ..., чтобы установить статус...), (2) возможности (может быть включен после периода неактивности, либо вручную; может быть запрещена вообще), (3) причина-следствие (включается после периода неактивности), (4) после (в данном случае "после" совпадает с "причиной-следствие", но в общем случае, "после" не означает "вследствие").

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

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

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

Поделиться
Поделиться
Tweet
Google
 
© ООО "Компьютерра-Онлайн", 1997-2017
При цитировании и использовании любых материалов ссылка на "Компьютерру" обязательна.