Страница:
Однако основным идеям Семантического Веба уже немало лет, а не то чтобы "экстремума", но даже стремительного роста не видать (сравните хотя бы с куда более молодым термином-вирусом "Web 2.0", знакомым любой домохозяйке). В чем же дело?
Вот вопрос: а где же, собственно, во всем этом благолепии деньги (которые, как известно, правят миром), — то есть что может завлечь сильных мира сего в Сети Семантики? Ответы есть и у W3C, и лично у сэра Тимоти, но, в общем-то, не слишком убедительные: дескать, информационные потоки любой корпорации могут быть организованы существенно эффективнее (читай — выгоднее), если будут основываться на семантически описанных данных. Но вопрос-то не в том, что Семантический Веб намного проще, а в том, где деньги для поставщиков контента? С какой стати мой непосильнымтрудом-нажитый контент должен участвовать в сети-без-сайтов, где потребитель информации не"зайдет ко мне" (и посмотрит Рек ламу!), а получит от меня лишь нужный ему кусочек данных посредством своего интеллектуального агента?
Существует интересный прагматический ответ на этот непростой вопрос, известный под названием MashupAds. Идея в том, что пользовательским "интеллектуальным агентом", интерфейсом к миру семантических данных, должен являться обычный сайт, аггрегирующий информацию с семантических сервисов и предоставляющий пользователю дружественный интерфейс для навигации по этой информации и выполнения сложнейших запросов. Именно этот сайт (точнее — множество сайтов, для каждой отрасли — свой интеллектуальный агент) и будет показывать пользователю рекламу — да не свою, а полученную из "семантической базы рекламы" и семантически же привязанную к текущему контенту. При этом деньги из кармана рекламодателя (минус процент "интеллектуального агента") будут переходить в карман поставщиков того контента, к которому семантически привязалась реклама. Не правда ли, похоже на модель Гугла с его AdWords и AdSense?
В таком разрезе Семантическая Паутина простому пользователю представляется немногочисленным набором сайтов-аггрегаторов специализированных поисковиков, выполняющих посредническую роль не только между пользователем и информацией, но и между поставщиком контента и рекламодателем. Условный пример: на сайте-"интеллектуальном агенте" географической направленности пользователь может максимально быстрым и удобным путем найти любую информацию об интересующей его местности — от туристической до краеведческой; и при этом он увидит максимально релевантную своим поискам рекламу: человеку, просматривающему информацию об отелях, будет предложено несколько соблазнительных туров, а взыскующему исторических сведений скорее выпадет реклама книжных магазинов и обучающих фильмов. При этом, напомним, сам сайтсервис является просто универсальным интерфейсом к туче баз данных (находящихся на других серверах, принадлежащих другим хозяевам).
Выводы о преимуществах и недостатках описанного подхода, а равно и перспективах его внедрения, оставим читателю в качестве домашнего задания.
(Редактор попытался начать выполнять "домашнее задание" и сразу столкнулся с вопросом: с чего бы агенту что-то отстегивать поставщику контента, если только мы не планируем вступать на шаткую землю "технологий защиты от копирования"?)
Если попытаться дать простой ответ на прямой вопрос — побеждают ли идеи Семантического Веба? — то мы окажемся перед серьезным затруднением.
С одной стороны, разработанные инструменты — RDF как универсальный способ машиночитаемого описания данных, OWL как способ построения онтологий, SPARQL как способ запроса к этим данным и онтологиям — вполне себе заняли место в научных и смежных областях и стали стандартом де-факто. С другой стороны, в "мэйнстрим" эти технологии не спешат — а когда и прорываются, редко обходится без конфуза. Например, всем известный RSS — формат для описания обновлений сайтов и блогов, вполне себе семантическая штука, — изначально расшифровывался именно как RDF SiteSummary; завоевание им всеобщего признания казалось началом триумфального шествия Semantic Web по планете. Однако в результате некоторых противоречий и недопониманий на данный момент существует несколько разных RSS’ов (0.90, 0.91, 1.0,2.0), которые, даром что отличаются только номерами версий, имеют совершенно разную внутреннюю структуру и даже разную расшифровку аббревиатуры. Из этих форматов только 0.90 и 1.0 по-прежнему основаны на RDF. А RSS 0.91 (Rich Site Summary) и RSS 2.0 (Really Simple Syndication) — более простые форматы, не связанные с ключевыми технологиями Semantic Web. (Вдобавок существует еще и альтернативный и популярный формат Atom, тоже не имеющий с RDF ничего общего.)
Вообще говоря, превалирующим "сторонним взглядом" на перспективы идей Семантического Веба долгое время был абсолютный пессимизм и неприятие[Еще полтора года назад автор писал колонки на тему "почему Семан- тического Веба нет, не было, и не надо" — см.]. Причины, в общем, можно легко предпо ложить: среди всего разнообразия сайтов, созданных разнообразнейшими методами, руками авторов с разнообразнейшей квалификацией, трудно ожидать вспышки интереса к "правильной", осмысленной выдаче данных — тем более что выгоды каждого конкретного сайта/сервиса от собственной семантичности малоочевидны, а квалификации создателей не всегда хватает на семантически правильное использование элементов простого HTML, вроде заголовков и списков. Да и сама идея полной (или, по крайней мере, существенной) замены современного Веба Новым Вебом казалась утопией — при полном отсутствии так называемого killer app, привлекательного и общеполезного приложения (не гипотетического, а работающего "здесь и сейчас"), которое делало бы преимущества Нового Веба очевидными любому.
Но в новейшее время в семантичности Веба определенно происходят положительные сдвиги — хотя "семантические" технологии W3C играют в этих сдвигах далеко не первую роль. Killer app’ом, чья популярность только зарождается, оказались, вопервых, поиск, а во-вторых — переносимость данных.
Средством и основной технологией — микроформаты и простые API популярных сервисов. Средством структурирования — (контролируемые) фолксономии.
Результатом — не новая "сеть данных", но и не старая "сеть страниц", а гибридная "сеть страниц с (мета) данными".
Итак, семантическая информация в сегодняшнем Вебе-не-только-для-ученых преимущественно записывается в виде микроформатов — стандартов, позволяющих к существующей HTML-странице добавить информацию о смысле данных. Например, ‹a href=''http://vasya.com''› — это "какая-то ссылка"; а ‹a href=''http://vasya.com'' rel=''colleague''› [Помните "малоиспользуемый и забытый атрибут rel" из первого раздела? ] это та же ссылка, но семантически описывающая мои отношения с блогом-по-ссылке в формате XFN (XHTML Friends Network — натурально, формат задания информации о френдах), — при этом, с точки зрения простого браузера, страница выглядит все так же, но "понимающие" XFN боты[Или браузеры со специальным плагином, например Operator для Firefox.]"увидят" дополнительную информацию и смогут ее использовать. Существуют микроформаты для описания, например, контактной информации (hCard), календарной (hCalendar), информации о "Creative Commons"-лицензировании данного контента и множество других.
Смежный способ "придания дополнительной информации" обычной странице — задание "альтернативных представлений этой страницы" в ее заголовке.
Именно так в блогах указывают их RSS-потоки (тоже ведь — ссылка на "семантическое изложение" того же, что мы видим в HTML); именно так на страницах профилей в разно образных социальных сетях (в том же ЖЖ, например) указывают ссылки на FOAF документы[ FOAF (Friend of a Friend) — схема RDFдокументов, указывающих, опять же, информацию о френдах и ссылки на них. То есть FOAF и XFN — это конкурирующие технологии.].
Хорошо, допустим, кто-то решил описать таким образом часть контента на странице. Возникает закономерный вопрос (точнее — даже два): какая обычному инфопутешественнику [Это автор так предпочитает называть веб-серферов. И красивше, и семантичнее] польза и радость с этой семантики? и даже если она есть, много ли страниц, в которых заложена такая информация?
Действительно, даже Firefox+Operator, честно показывающий "в этой странице заложена контактная информация, хотите ее экспортировать?" или "здесь используются такие-то теги", кажется скорее "вспомогательной фенькой для гика", нежели "признаком качественно другого веба"[Впрочем, есть мнение, что скрытый потенциал семантических микроформатов еще раскроет себя в интеграции виртуальной и физической реальности на мобильных устройствах. Самыми простыми и очевидными примерами представляются мобильник, умеющий одним кликом позвонить по записанному на веб-странице телефону, или КПК, по геоинформации описания достопримечательности в путеводителе немедленно запускающий навигатор.]. Но — вспомним, что было сказано выше о killer app’ах Настоящего Семантического Веба["Настоящего" — не в смысле "истинного", а в смысле существующего здесь и сейчас (в отличие от утопического Полностью Семантического Веба).]: поиск и перенос данных.
Семантическим поиском (то есть поиском, учитывающим свойства данных, а не только встречаемость слов в документе) многие из нас пользуются ежедневно. Это, например, Яндекс-поиск по блогам, индексирующий RSS-потоки блогов и форумов и позволяющий находить отдельные посты (независимо от того, как они сгруппированы в HTML-страницы), причем вести поиск можно не только по встречающимся словам, но и по "семантическим" (смысловым) атрибутам записи — заголовку, имени автора, тегам и пр. Другой пример — множество сторонних сервисов для "сложного" поиска по Flickr или del. icio.us: здесь играет большую роль открытый и простой API, ставший одним из почти обязательных признаков Web2.0-сервиса. И породивший новую разновидность сервисов: машапы (mash-ups, помеси сервисов), извлекающие семантически описанную информацию из нескольких популярных сервисов и объединяющие ее по этим самым семантическим признакам[Навязший в зубах пример — показать чтонибудь, снабженное геоинформацией (например, записи-статусы Twitter), на картах Гугла.], — при этом, заметим, смешиваемым сервисам достаточно описать свою информацию в рамках своей области и вовсе не нужно договариваться об общем языке данных и общей онтологии допустимых значений.
Вот, кстати, и слово сказано — ответ на вопрос "кто вообще будет этим заниматься?" (в смысле — добавлением/экспортом семантической информации). Отдельный пользователь-автор — вряд ли (точнее — не стоит рассчитывать на всех и каждого). Но если наш пользователь-автор — участник крупной Web2.0-системы — будь то блог-хостинг, фотохостинг, голая "социальная сеть", энциклопедия, — создатель сервиса может озаботиться тем, чтобы ПО самой системы экспортировало метаинформацию (описание блоговых записей, фотографий на хостинге и т. п.).
Зачем? Чтобы потрафить семантическим поисковым системам, настоящим и будущим, и в конечном счете увеличить посещаемость и прибыли (чувствуете разницу с целями Идеального Семантического Веба — изничтожить само понятие "посещаемости отдельного сайта"?). Завтра создавать новый блог-хостинг/социальную сеть (или автономный движок для личного блога, например), не представляющую информацию о френдах в общеизвестном формате (FOAF или XFN), будет такой же глупостью, как сегодня — блог-хостинг без RSS-лент.
К вопросу "экспорта ради поиска" примыкает вопрос "экспорта ради миграции и интеграции", все больше волнующий пользователей — они жаждут возможности единожды записанные данные переносить между разными сервисами — для чего, опять-таки, все эти сервисы должны поддерживать общепонятные стандарты "описания данных по смыслу". Наиболее объемлющая инициатива такого рода — проект DataPortability, ставящий своей целью описать, какие открытые стандарты, микроформаты и протоколы (hCard, FOAF, OpenID, RSS, RDF…) должен "понимать" уважающий себя современный сервис, чтобы пользователю легко было "прийти" и "уйти" со своими данными. Учитывая, что этот молодой (основан в ноябре 2007-го) проект уже получил широчайшую поддержку рынка (по крайней мере, на словах) — от Google и Microsoft до Facebook и Twitter, — можно ожидать постепенного нарастания массы семантической информации, экспортируемой и импортируемой популярными сервисами. А вслед за "грандами" подтянутся и стандарты "хорошего тона" индустрии. Так победим!
Наконец, нельзя не упомянуть о двух последних громких проектах Настоящего Семантического Веба: 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, да зачастую еще и плохо отформатированный (вместо заголовков — просто строкиполужирным шрифтом, вместо списков — просто звездочка в начале строки). Возможно, ситуацию когда-нибудь исправят специальные "семантические" редакторы, мощные, удобные и требовательные (в смысле, вообще не позволяющие "просто изменить шрифт" без указания семантики форматируемой области). Но даже и в этом случае мало надежды, что каждый блоггер, журналист или автор Википедии станет заморачиваться "семантическим" указанием: например, "вот эти слова в кавычках — название книги, которую я цитирую" (хотя если это добавит записям "красивости" — вроде вставления обложки книги и ссылки на ее описание…). И в этом смысле идеи Семантического Веба (который, напомню, в первую очередь требует семантичности внутри контента, а не "вокруг" него, в метаданных) — скорее всего утопия
Касание сетки
Где деньги, Зин?
Вот вопрос: а где же, собственно, во всем этом благолепии деньги (которые, как известно, правят миром), — то есть что может завлечь сильных мира сего в Сети Семантики? Ответы есть и у W3C, и лично у сэра Тимоти, но, в общем-то, не слишком убедительные: дескать, информационные потоки любой корпорации могут быть организованы существенно эффективнее (читай — выгоднее), если будут основываться на семантически описанных данных. Но вопрос-то не в том, что Семантический Веб намного проще, а в том, где деньги для поставщиков контента? С какой стати мой непосильнымтрудом-нажитый контент должен участвовать в сети-без-сайтов, где потребитель информации не"зайдет ко мне" (и посмотрит Рек ламу!), а получит от меня лишь нужный ему кусочек данных посредством своего интеллектуального агента?
Существует интересный прагматический ответ на этот непростой вопрос, известный под названием MashupAds. Идея в том, что пользовательским "интеллектуальным агентом", интерфейсом к миру семантических данных, должен являться обычный сайт, аггрегирующий информацию с семантических сервисов и предоставляющий пользователю дружественный интерфейс для навигации по этой информации и выполнения сложнейших запросов. Именно этот сайт (точнее — множество сайтов, для каждой отрасли — свой интеллектуальный агент) и будет показывать пользователю рекламу — да не свою, а полученную из "семантической базы рекламы" и семантически же привязанную к текущему контенту. При этом деньги из кармана рекламодателя (минус процент "интеллектуального агента") будут переходить в карман поставщиков того контента, к которому семантически привязалась реклама. Не правда ли, похоже на модель Гугла с его AdWords и AdSense?
В таком разрезе Семантическая Паутина простому пользователю представляется немногочисленным набором сайтов-аггрегаторов специализированных поисковиков, выполняющих посредническую роль не только между пользователем и информацией, но и между поставщиком контента и рекламодателем. Условный пример: на сайте-"интеллектуальном агенте" географической направленности пользователь может максимально быстрым и удобным путем найти любую информацию об интересующей его местности — от туристической до краеведческой; и при этом он увидит максимально релевантную своим поискам рекламу: человеку, просматривающему информацию об отелях, будет предложено несколько соблазнительных туров, а взыскующему исторических сведений скорее выпадет реклама книжных магазинов и обучающих фильмов. При этом, напомним, сам сайтсервис является просто универсальным интерфейсом к туче баз данных (находящихся на других серверах, принадлежащих другим хозяевам).
Выводы о преимуществах и недостатках описанного подхода, а равно и перспективах его внедрения, оставим читателю в качестве домашнего задания.
(Редактор попытался начать выполнять "домашнее задание" и сразу столкнулся с вопросом: с чего бы агенту что-то отстегивать поставщику контента, если только мы не планируем вступать на шаткую землю "технологий защиты от копирования"?)
Подача в прыжке
Если попытаться дать простой ответ на прямой вопрос — побеждают ли идеи Семантического Веба? — то мы окажемся перед серьезным затруднением.
С одной стороны, разработанные инструменты — RDF как универсальный способ машиночитаемого описания данных, OWL как способ построения онтологий, SPARQL как способ запроса к этим данным и онтологиям — вполне себе заняли место в научных и смежных областях и стали стандартом де-факто. С другой стороны, в "мэйнстрим" эти технологии не спешат — а когда и прорываются, редко обходится без конфуза. Например, всем известный RSS — формат для описания обновлений сайтов и блогов, вполне себе семантическая штука, — изначально расшифровывался именно как RDF SiteSummary; завоевание им всеобщего признания казалось началом триумфального шествия Semantic Web по планете. Однако в результате некоторых противоречий и недопониманий на данный момент существует несколько разных RSS’ов (0.90, 0.91, 1.0,2.0), которые, даром что отличаются только номерами версий, имеют совершенно разную внутреннюю структуру и даже разную расшифровку аббревиатуры. Из этих форматов только 0.90 и 1.0 по-прежнему основаны на RDF. А RSS 0.91 (Rich Site Summary) и RSS 2.0 (Really Simple Syndication) — более простые форматы, не связанные с ключевыми технологиями Semantic Web. (Вдобавок существует еще и альтернативный и популярный формат Atom, тоже не имеющий с RDF ничего общего.)
Вообще говоря, превалирующим "сторонним взглядом" на перспективы идей Семантического Веба долгое время был абсолютный пессимизм и неприятие[Еще полтора года назад автор писал колонки на тему "почему Семан- тического Веба нет, не было, и не надо" — см.]. Причины, в общем, можно легко предпо ложить: среди всего разнообразия сайтов, созданных разнообразнейшими методами, руками авторов с разнообразнейшей квалификацией, трудно ожидать вспышки интереса к "правильной", осмысленной выдаче данных — тем более что выгоды каждого конкретного сайта/сервиса от собственной семантичности малоочевидны, а квалификации создателей не всегда хватает на семантически правильное использование элементов простого HTML, вроде заголовков и списков. Да и сама идея полной (или, по крайней мере, существенной) замены современного Веба Новым Вебом казалась утопией — при полном отсутствии так называемого killer app, привлекательного и общеполезного приложения (не гипотетического, а работающего "здесь и сейчас"), которое делало бы преимущества Нового Веба очевидными любому.
Но в новейшее время в семантичности Веба определенно происходят положительные сдвиги — хотя "семантические" технологии W3C играют в этих сдвигах далеко не первую роль. Killer app’ом, чья популярность только зарождается, оказались, вопервых, поиск, а во-вторых — переносимость данных.
Средством и основной технологией — микроформаты и простые API популярных сервисов. Средством структурирования — (контролируемые) фолксономии.
Результатом — не новая "сеть данных", но и не старая "сеть страниц", а гибридная "сеть страниц с (мета) данными".
Итак, семантическая информация в сегодняшнем Вебе-не-только-для-ученых преимущественно записывается в виде микроформатов — стандартов, позволяющих к существующей HTML-странице добавить информацию о смысле данных. Например, ‹a href=''http://vasya.com''› — это "какая-то ссылка"; а ‹a href=''http://vasya.com'' rel=''colleague''› [Помните "малоиспользуемый и забытый атрибут rel" из первого раздела? ] это та же ссылка, но семантически описывающая мои отношения с блогом-по-ссылке в формате XFN (XHTML Friends Network — натурально, формат задания информации о френдах), — при этом, с точки зрения простого браузера, страница выглядит все так же, но "понимающие" XFN боты[Или браузеры со специальным плагином, например Operator для Firefox.]"увидят" дополнительную информацию и смогут ее использовать. Существуют микроформаты для описания, например, контактной информации (hCard), календарной (hCalendar), информации о "Creative Commons"-лицензировании данного контента и множество других.
Смежный способ "придания дополнительной информации" обычной странице — задание "альтернативных представлений этой страницы" в ее заголовке.
Именно так в блогах указывают их RSS-потоки (тоже ведь — ссылка на "семантическое изложение" того же, что мы видим в HTML); именно так на страницах профилей в разно образных социальных сетях (в том же ЖЖ, например) указывают ссылки на FOAF документы[ FOAF (Friend of a Friend) — схема RDFдокументов, указывающих, опять же, информацию о френдах и ссылки на них. То есть FOAF и XFN — это конкурирующие технологии.].
Хорошо, допустим, кто-то решил описать таким образом часть контента на странице. Возникает закономерный вопрос (точнее — даже два): какая обычному инфопутешественнику [Это автор так предпочитает называть веб-серферов. И красивше, и семантичнее] польза и радость с этой семантики? и даже если она есть, много ли страниц, в которых заложена такая информация?
Действительно, даже Firefox+Operator, честно показывающий "в этой странице заложена контактная информация, хотите ее экспортировать?" или "здесь используются такие-то теги", кажется скорее "вспомогательной фенькой для гика", нежели "признаком качественно другого веба"[Впрочем, есть мнение, что скрытый потенциал семантических микроформатов еще раскроет себя в интеграции виртуальной и физической реальности на мобильных устройствах. Самыми простыми и очевидными примерами представляются мобильник, умеющий одним кликом позвонить по записанному на веб-странице телефону, или КПК, по геоинформации описания достопримечательности в путеводителе немедленно запускающий навигатор.]. Но — вспомним, что было сказано выше о killer app’ах Настоящего Семантического Веба["Настоящего" — не в смысле "истинного", а в смысле существующего здесь и сейчас (в отличие от утопического Полностью Семантического Веба).]: поиск и перенос данных.
Семантическим поиском (то есть поиском, учитывающим свойства данных, а не только встречаемость слов в документе) многие из нас пользуются ежедневно. Это, например, Яндекс-поиск по блогам, индексирующий RSS-потоки блогов и форумов и позволяющий находить отдельные посты (независимо от того, как они сгруппированы в HTML-страницы), причем вести поиск можно не только по встречающимся словам, но и по "семантическим" (смысловым) атрибутам записи — заголовку, имени автора, тегам и пр. Другой пример — множество сторонних сервисов для "сложного" поиска по Flickr или del. icio.us: здесь играет большую роль открытый и простой API, ставший одним из почти обязательных признаков Web2.0-сервиса. И породивший новую разновидность сервисов: машапы (mash-ups, помеси сервисов), извлекающие семантически описанную информацию из нескольких популярных сервисов и объединяющие ее по этим самым семантическим признакам[Навязший в зубах пример — показать чтонибудь, снабженное геоинформацией (например, записи-статусы Twitter), на картах Гугла.], — при этом, заметим, смешиваемым сервисам достаточно описать свою информацию в рамках своей области и вовсе не нужно договариваться об общем языке данных и общей онтологии допустимых значений.
Вот, кстати, и слово сказано — ответ на вопрос "кто вообще будет этим заниматься?" (в смысле — добавлением/экспортом семантической информации). Отдельный пользователь-автор — вряд ли (точнее — не стоит рассчитывать на всех и каждого). Но если наш пользователь-автор — участник крупной Web2.0-системы — будь то блог-хостинг, фотохостинг, голая "социальная сеть", энциклопедия, — создатель сервиса может озаботиться тем, чтобы ПО самой системы экспортировало метаинформацию (описание блоговых записей, фотографий на хостинге и т. п.).
Зачем? Чтобы потрафить семантическим поисковым системам, настоящим и будущим, и в конечном счете увеличить посещаемость и прибыли (чувствуете разницу с целями Идеального Семантического Веба — изничтожить само понятие "посещаемости отдельного сайта"?). Завтра создавать новый блог-хостинг/социальную сеть (или автономный движок для личного блога, например), не представляющую информацию о френдах в общеизвестном формате (FOAF или XFN), будет такой же глупостью, как сегодня — блог-хостинг без RSS-лент.
К вопросу "экспорта ради поиска" примыкает вопрос "экспорта ради миграции и интеграции", все больше волнующий пользователей — они жаждут возможности единожды записанные данные переносить между разными сервисами — для чего, опять-таки, все эти сервисы должны поддерживать общепонятные стандарты "описания данных по смыслу". Наиболее объемлющая инициатива такого рода — проект DataPortability, ставящий своей целью описать, какие открытые стандарты, микроформаты и протоколы (hCard, FOAF, OpenID, RSS, RDF…) должен "понимать" уважающий себя современный сервис, чтобы пользователю легко было "прийти" и "уйти" со своими данными. Учитывая, что этот молодой (основан в ноябре 2007-го) проект уже получил широчайшую поддержку рынка (по крайней мере, на словах) — от Google и Microsoft до Facebook и Twitter, — можно ожидать постепенного нарастания массы семантической информации, экспортируемой и импортируемой популярными сервисами. А вслед за "грандами" подтянутся и стандарты "хорошего тона" индустрии. Так победим!
Наконец, нельзя не упомянуть о двух последних громких проектах Настоящего Семантического Веба: 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’ем.].
К этим главным требованиям добавляются и веяния времени — пользовательский интерфейс должен быть "богатым" не только с точки зрения эффективного представления информации и удобного управления, но и в самом приземленном смысле: переливающиеся кнопочки, плавно выплывающие менюшечки — то есть динамические графические эффекты.
Личное мнение: вообще говоря, тот факт, что мощнейшие наработки современной графики — возможности железа и библиотек — используются в основном для украшения кнопок, а не для более эффективного представления информации, автор склонен считать признаком упадка нравов и победы потребительской цивилизации.
И что, есть решения, удовлетворяющие этим требованиям?
Полноценного и стопроцентного — кажется, еще нет ["Кажется" — потому что в этой горячей области все меняется чуть ли не ежедневно. Например, Adobe AIR уже существует, но возможности его полностью еще не распробованы.].
Но шаги в нужном направлении — и какие шаги! — делают многие, от гранд-монстров до еще вчера никомуне ведомых героев open source. Если разобраться в этих шагах и аккуратно их разложить, то и в фейерверке технологий, заявленном в первом абзаце, разобраться немудрено.
Рассказ об интерфейсах "богатых интернет-при ложений" (Rich Internet Applications) нельзя не начать с Gmail: роль этого сервиса в мэйнстримовом понимании "как можно делать веб-приложения" переоценить трудно. При этом, заметим, технологии использовались "старые": HTML/CSS/JavaScript. "Весь секрет" был лишь в довольно большом объеме кода на JavaScript (некогда созданного для простых однострочных инструкций типа "показать это окошко, когда нажмут ту кнопку") и использовании недооцененной возможности JavaScript по отправке запросов на удаленный сервер и получению ответов. Свершение Gmail было идеологическим, а не технологическим: он как бы сказал всем "вот эти (давно существующие) технологии можно использовать и так". Надо заметить, что у новаторского подхода были довольно существенные недостатки: во-первых, проблема переносимости по операционным системам сменилась проблемой переносимости по браузерам (очень немногие из которых оказались готовы к использованию возможностей JavaScript "на пределе", да и готовые исполняли его по-разному); вовторых, программирование сложных элементов интерфейса и аккуратного обновления их с сервера — работа довольно-таки нетривиальная.
Проблема адаптации к разным браузерам хоть и не решена полностью по сию пору, но стала в некоторой степени проблемой производителей браузеров, а не разработчиков веб-приложений. Здесь тоже большую роль сыграл масштаб шума вокруг гугловских сервисов, поставив вопрос ребром: "А в вашем браузере Google Maps работает?".
А вот для того, чтобы справиться со сложностью самой разработки, за истекшие годы было создано несколько решений разного толка. Одни из них — удобные библиотеки для эффективного изменения содержимого веб-страницы (например, jQuery, Prototype) — своим существованием обязаны гибкости и изяществу самого языка JavaScript, ранее недооцененного. Другие — Dojo, mooTools, Yahoo! UI Library или приложения к тем же jQuery и Prototype — это большие подборки готовых, профессионально разработанных и отлаженных элементов пользовательского интерфейса и вспомогательных объектов. Третьи, например Google Web Toolkit[Занятно, что для создания Gmail и Google Maps эта библиотека не использовалась. ], вообще предпочитают использовать веб-технологии как "высокоуровневый ассемблер" — приложения при помощи GWT пишутся на Java, а потом пользовательский интерфейс "компилируется" в HTML/JavaScript. Перечисленные средства, как правило, берут на себя не только построение динамичного интерфейса и обновление его с сервера, но и "красивости" (плавное выпадение меню, полупрозрачные окошки и пр.) и некоторую часть несовместимостей между браузерами.
Опубликовано в журнале "Компьютерра" 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’ем.].
К этим главным требованиям добавляются и веяния времени — пользовательский интерфейс должен быть "богатым" не только с точки зрения эффективного представления информации и удобного управления, но и в самом приземленном смысле: переливающиеся кнопочки, плавно выплывающие менюшечки — то есть динамические графические эффекты.
Личное мнение: вообще говоря, тот факт, что мощнейшие наработки современной графики — возможности железа и библиотек — используются в основном для украшения кнопок, а не для более эффективного представления информации, автор склонен считать признаком упадка нравов и победы потребительской цивилизации.
И что, есть решения, удовлетворяющие этим требованиям?
Полноценного и стопроцентного — кажется, еще нет ["Кажется" — потому что в этой горячей области все меняется чуть ли не ежедневно. Например, Adobe AIR уже существует, но возможности его полностью еще не распробованы.].
Но шаги в нужном направлении — и какие шаги! — делают многие, от гранд-монстров до еще вчера никомуне ведомых героев open source. Если разобраться в этих шагах и аккуратно их разложить, то и в фейерверке технологий, заявленном в первом абзаце, разобраться немудрено.
Внешнее: пользовательский интерфейс
Рассказ об интерфейсах "богатых интернет-при ложений" (Rich Internet Applications) нельзя не начать с Gmail: роль этого сервиса в мэйнстримовом понимании "как можно делать веб-приложения" переоценить трудно. При этом, заметим, технологии использовались "старые": HTML/CSS/JavaScript. "Весь секрет" был лишь в довольно большом объеме кода на JavaScript (некогда созданного для простых однострочных инструкций типа "показать это окошко, когда нажмут ту кнопку") и использовании недооцененной возможности JavaScript по отправке запросов на удаленный сервер и получению ответов. Свершение Gmail было идеологическим, а не технологическим: он как бы сказал всем "вот эти (давно существующие) технологии можно использовать и так". Надо заметить, что у новаторского подхода были довольно существенные недостатки: во-первых, проблема переносимости по операционным системам сменилась проблемой переносимости по браузерам (очень немногие из которых оказались готовы к использованию возможностей JavaScript "на пределе", да и готовые исполняли его по-разному); вовторых, программирование сложных элементов интерфейса и аккуратного обновления их с сервера — работа довольно-таки нетривиальная.
Проблема адаптации к разным браузерам хоть и не решена полностью по сию пору, но стала в некоторой степени проблемой производителей браузеров, а не разработчиков веб-приложений. Здесь тоже большую роль сыграл масштаб шума вокруг гугловских сервисов, поставив вопрос ребром: "А в вашем браузере Google Maps работает?".
А вот для того, чтобы справиться со сложностью самой разработки, за истекшие годы было создано несколько решений разного толка. Одни из них — удобные библиотеки для эффективного изменения содержимого веб-страницы (например, jQuery, Prototype) — своим существованием обязаны гибкости и изяществу самого языка JavaScript, ранее недооцененного. Другие — Dojo, mooTools, Yahoo! UI Library или приложения к тем же jQuery и Prototype — это большие подборки готовых, профессионально разработанных и отлаженных элементов пользовательского интерфейса и вспомогательных объектов. Третьи, например Google Web Toolkit[Занятно, что для создания Gmail и Google Maps эта библиотека не использовалась. ], вообще предпочитают использовать веб-технологии как "высокоуровневый ассемблер" — приложения при помощи GWT пишутся на Java, а потом пользовательский интерфейс "компилируется" в HTML/JavaScript. Перечисленные средства, как правило, берут на себя не только построение динамичного интерфейса и обновление его с сервера, но и "красивости" (плавное выпадение меню, полупрозрачные окошки и пр.) и некоторую часть несовместимостей между браузерами.