Шлюзы каталогов и развитие интерфейса доступа

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

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

Клиент A получает доступ к пользовательскому интерфейсу, который загружается в виде формы или Java-апплета с Интернет-сервера, управляющий подключениями к другим серверам. Клиент B обращается к пользовательскому интерфейсу из места, отличного от того, где расположен шлюз, который обеспечивает настроенные интерфейсы для посетителей. Клиент C – это клиентское «настольное» приложение, которое является совершенно самостоятельным, имеет свой пользовательский интерфейс и возможности выполнения распределенных запросов для прямого подключения к удаленными серверам. Но на этой схеме неясна зависимость от реестра или директории серверов. Она обсуждается в следующем разделе. Все три типа взаимодействия уже применяются в различных SDI. Поскольку все они зависят от распределенных серверов каталога, обеспечена и полная совместимость этих трех вариантов.

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

Для опытных пользователей запросы по распределенным каталогам может дать более высокую точность отбора необходимых пространственных данных. Часто этот процесс носит итеративный характер, то есть проверяется, какое влияние оказывает конкретная часть запроса на результат поиска. Второй подход больше подходит неопытным пользователям, которым проще просматривать получаемые ссылки, не задумываясь о точном выборе ключевых слов. Главной задачей создания и поддержки браузеров для работы с глобальным множеством коллекции серверов является формирование и ведение универсального словаря для классификации понятий, иерархии или словесного пространства, известного как онтология. Поскольку это требует междисциплинарной кооперации, то создание единой системы классификации представляется невероятно сложной задачей. Однако, появление в ближайшие годы интеллектуальных систем классификации, способных работать с внешними хранилищами информации, используя нейронные сети, Байесовские вероятности и другие «контекстные» оценки, может существенно облегчить навигацию пользователей по гетерогенным источникам геопространственной информации.

Сценарий выполнения пользовательского запроса может выглядеть так:

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

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

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

4. Результаты с каждого сервера объединяются и представляются пользователю. Типы ответов могут включать: список совпадений (hits) по заголовку и формату связи?, кратко оформленную информацию или полное представление метаданных. Визуализация нескольких результатов может также представляться в виде расположения наборов данных на карте, тематических групп или с временными характеристиками.

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

6. После этого пользователь, проанализировав метаданные, решает, стоит ли приобрести набор данных. Щелкнув на соответствующем URL, он может либо интерактивно заказать нужные данные, либо воспользоваться для этого другими предлагаемыми способами.

Сценарий работы пользователя может быть следующим:

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

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

3. Запросы передаются на каждый сервер через механизм распределенных запросов.

4. Результаты с каждого сервера сопоставляются и представляются пользователю. Стиль представления результаты управляется интерфейсом пользователя и шлюзом.

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Живите по правилу: МАЛО ЛИ ЧТО НА СВЕТЕ СУЩЕСТВУЕТ? Я неслучайно подчеркиваю, что место в голове ограничено, а информации вокруг много, и что ваше право...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: