Журнал Компьютерра - Журнал "Компьютерра" N741-742

Наконец, нельзя не упомянуть о двух последних громких проектах Настоящего Семантического Веба: OpenSocial от Google (стандарт интеграции социальных сетей — как раз через экспорт социальной информации в общепонятных форматах) и недавно анонсированном будущем семантическом поиске от Yahoo (поисковик, понимающий и индексирующий микроформаты и другую семантическую информацию, который наконец-то обобщит проблему поиска "контактов человека по имени Вася Пупкин и людей, его знающих"). Так, пока автор идеи Семантического Веба рассуждает о том, как он (Semantic Web, а не автор) убьет современные поисковики, эти самые поисковики находятся впереди планеты всей в задаче введения семантических элементов в Веб обыкновенный. Такие вот дела.

У читателя могло сложиться превратное впечатление о том, что идеологии и технологии, которые W3C и лично Бернерс-Ли понимают под Semantic Web, не имеют ничего общего с Настоящим Семантическим Вебом. Вообще говоря, это не совсем так. Во-первых, восемь лет разработок дали как минимум общую терминологию и "повестку дня". Во-вторых, сами технологии — RDF, OWL и иже с ними — вполне используются где-то напрямую (FOAF, как уже было сказано, — это таки RDF, точнее — OWLонтология, которую можно использовать в RDF, описывающем френдов).

В-третьих, в "семантических" комитетах W3C тоже стараются не отставать от веяний времени (не идиоты же и там): и приложения к RDF существуют [Например — eRDF, то есть embedded (встроенный) RDF], позволяющие вставлять его элементы как микроформат (то есть дополнительными свойствами к тегам существующей HTML-странички), да и все цели Веба Семантического переформулированы нынче как "семантическое приложение к некоторым частям Веба".

Кроме того, процесс "наведения мостов" между двумя мирами зачастую дает крайне интересные и общественно полезные результаты, вроде проекта SIMILE [Semantic Interoperability of Metadata and Information in unLike En vi ronments — семантическое взаимодействие метаданных в разнообразных (непохожих) окружениях], в рамках которого создан,к примеру, Piggy Bank — расширение для Firefox, позволяющее создавать (и использовать созданные другими) "превращалки" страниц некоторых сервисов в RDF — с получением всех "плюшек" семантического веба — просмотра, фильтрации и сортировки данных по смыслу, а не "по дизайну". Кстати, именно этот метод — Screen scrapping или Web scrapping, сайтоспецифичные алгоритмы "насильственного вытаскивания важной информации из страниц", — является одним из значимых звеньев нарастания семантичности веба.

Но вот чем Настоящий Семантический Веб радикально отличается от идей W3C — это способами структурирования данных и границами объектов, к которым прилагается "семантичность". Что до способов структурирования — тщательно разработанным, разветвленным и детальным онтологиям Web 2.0 противопоставил "фолксономии" — классификации на тегах, составляемые пользователями на лету (то есть если какой-то пользователь к своим данным добавил какой-то новый тег — сразу же пополнилась и "общественная" копилка тегов).

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

Касание сетки

Касание сеткиАвтор: Виктор Шепелев

Опубликовано в журнале "Компьютерра" N25-26 от 08 июля 2008 годаОсенью прошлого года Adobe выпустила технологию Adobe AIR, связанную с ее (точнее, купленными у Macromedia) технологиями Flash и Flex. Примерно тогда же в свет вышла Silverlight — прямой конкурент Flash/Flex. Flex, AIR, Silverlight, Google Gears, GWT, Mozilla Prizm, Sun JavaFX — все это технологии, созданные для того, чтобы навсегда изменить привычный нам Интернет, из "Сети документов" превратить его в "Сеть приложений", могучей волной смыть различие между десктопом и Интернетом, веб-сервисом и отдельной программой.

Эти гибриды обозначаются термином RIA (Rich Internet Applications, "богатые" интернетприложения; а раньше Smart Client, "умный клиент"). Так уже много лет называют гипотетические приложения, более удобные, чем обычные сайты-сервисы, и более Интернето-центричные, чем обычные приложения. Неизвестно, что тому виной — рост ли пропускной способности сетей, приход ли "нового веба", или что иное, но лишь в последние года полтора-два эти гипотетические приложения стали стремительно становиться реальностью. Как и почему — выясним?

Введение в ria в вопросах и ответах

Чем плох браузер?

Да всем хорош. В своей роли: программыпросмотрщика гипертекстовых документов. Равно как язык разметки HTML — отличный язык для разметки гипертекстовых документов[Ну, про его "отличность" есть и альтернативные мнения — как у практиков (разработчиков браузеров и веб-дизайнеров), так и у теоретиков (радетелей Семантической Сети). Но все же.]. Да вот беда: ни то ни другое к созданию приложений не имеет ни малейшего отношения — by design, то есть по определению. И сам HTML как язык разметки, базовыми элементами которого являются абзацы, списки, таблицы, предполагает "поток текста с форматированием", а вовсе не пользовательский интерфейс произвольной формы. И динамическое взаимодействие с HTML-приложениями ограничено "переходом на другую страницу" (ссылка) да "отправлением заполненной анкеты на сервер" (форма). И ограниченность (точнее, отсутствие) связи с пользовательским окружением мешает развернуться — ни иконку информационную в трей не запихнуть, ни вложение в письмо в подходящей программе сходу не открыть. И необходимость для обработки каждого малейшего действия пользователя связываться с сервером мешает в средах с нестабильным подключением (например, мобильных).

А чем тогда плохи обычные приложения?

Здесь достаточно сказать одно слово: платформа.

При всех своих недостатках (см. выше) приложение-вбраузере или его аналоги имеют и массу достоинств: простота доставки пользователю, установки и обновления (в том смысле, что никого не приходится просить "пожалуйста, скачайте новую версию Gmail" — она просто есть), естественность взаимодействия с сервером, лучшее обеспечение безопасности пользователя (неизвестное приложение имеет немного возможностей проникнуть в его систему), работа приложения под всеми распространенными настольными ОС — был бы браузер современный. Да и сами веб-технологии (клиентская часть — HTML/CSS/JavaScript), с технической точки зрения, — штука простая, высокоуровневая и работающая: с сервера по простому протоколу передаются простые текстовые описания пользовательского интерфейса (которые могут быть сгенерированы мириадами способов и технологий), а умный и эффективный клиент-браузер их отображает.

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

Ну, допустим. А что нужно-то? В какую сторону должен происходить "сдвиг"?

Ответ на этот вопрос органически вытекает из ответа на предыдущие. Нужно средство создания богатых, нетривиальных, динамичных интерфейсов — но позволяющее описывать их на достаточно лаконичном языке (который можно было бы передавать с сервера на клиент как простой текст). Нужна возможность интеграции с пользовательской операционной средой (каждое веб-приложение имеет отдельное окно без "стандартных элементов браузера", может встраиваться в трей, вешать панели на рабочий стол и т. п.) — но контролируемая, с не слишком большими уступами со стороны безопасности. Нужна возможность хранения на клиентском компьютере рабочих данных (актуальных настроек, уже полученных писем и т. п.) и самого интерфейса приложения — чтобы иметь возожность работать в среде с нестабильным интернетподключением и минимизировать трафик — забирать с сервера только обновившуюся информацию[Еще раз подчеркнем — это требование обосновано скорее не потребностями "бедных домашних" пользователей с dial-up’ом, а "богатых мобильных" пользователей с WiFi’ем.].