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