Немного о Семантических Сетях

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

В этом посте я хочу коротко описать концепцию семантической сети и поговорить о некоторых методах ее реализации. Этот пост коротко резюмирует результаты моих исследований за последние несколько недель.

Нехватка данных

Когда я говорю что компьютеру не распознать что значит информация у меня на сайте – я лукавлю. Если вы—Яндекс, вы можете просто нанять толпу С++ программистов которые понапишут вам массу алгоритмов, которые научат систему разпознавать тип данных прямо по его содержимому. На сегодняшний день, этот подход неизбежен, но нельзя сказать что этому нет альтернатив.

Одна вполне вменяемая альтернатива – это когда автор сайта сам “подсказывает” системе какие данные как воспринимать. Например, Google любит данные в форматах Google Rich Snippets. Наличие данных в этих форматах позволяет Гуглу, например, показывать на поисковой странице рейтинг товара или его цену.

А зачем?

Ну вот представьте: у нас есть в интернете куча магазинов, торгующих оргтехникой, например компьютерами. Я знаю что самые хорошие цены в Штатах, и готов воеватьдружить с таможней, но мне нужно для начала найти все магазины с определенным товаром, а потом выбрать тот, который является самым “приемлимым” с точки зрения, например, цены.

И тут возникает проблема: магазины эти не публикуют свои прайс-листы в каком-то универсальном формате. Порой, цены вообще вывешены в табличках, а скачивать все это дело через WebRequest, парсить и интегрировать в BizTalk мне лень – нет, я могу это сделать, и это кстати является моей “продуктовой специализацией”, если так можно выразиться, но это болезненно.

Поэтому, я предпочитаю данные которые реализуют известную онтологию (т.е. схему описания данных), такую например как Good Relations. Эта онтология позволяет продавцам публиковать универсальный набор данных по своим продуктам. Данные, которые потом распарсит Google а я, как пользователь, смогу получить из них выписку.

Что интересней, так это то, что при таком раскладе дел, мне Google вообще-то не нужен – мне нужен свой “паук” или агент который сам будет шастать по интернету в поисках магазинов с нужной продукцией.

Механизмы

Для описания “дополнительных” данных в структуре сайта есть много вариантов, один из которых называется RDFa или RDF для аттрибутов. Идея тут примерно такая: вместо того, чтобы в сайте создавать отдельные страницы с метаданными, мы добавляем эти данные в уже существующие страницы как атрибуты. Например:

<div xmlns:dc="http://purl.org/dc/elements/1.1/">
   <h2 property="dc:title">The trouble with Bob</h2>
   <h3 property="dc:creator">Alice</h3>
   ...
</div>

Для тех, кому RDFa в новость, у W3C есть неплохой вводный документ, описывающий технологию более детально. Хотя сама по себе идея, конечно же, примитивна.

На этом этапе вам уже должно быть понятно, что нам просто нужен удобный инструмент, который позволит людям вносить в существующие структуры данных семантическую информацию (semantic annotation). Один из инструментов, который позволит делать это на клиентской стороне – это редактор Aloha. Проект сам по себе интересный, но возможность семантических аннотаций – это очень полезно для встраивания в CMS которую можно например поставлять бизнесу для самостоятельного введения данных по продуктам.

Счастье на сервере

Что касается клиенской части все понятно – нам нужно аннотировать XHTML. А что насчет серверной? Тут опять же есть варианты, один из которых предоставят (я надеюсь) авторы WebSharper. Для тех кто не знает, поясню что WebSharper – это аналог GWT на F#. Иначе говоря, идея в том что F# транслируется в HTML+JavaScript+CSS+сторонние библиотеки вроде JQuery. Сейчас WebSharper еще не достиг коммерческого состояния, но у него уже есть две плюшки, которые хочется получить “чем скорее тем лучше”. Во-первых, это возможность полной отвязки от серверной части, т.е. перевод сайта в чистый JS-driven клиент который может работать на Mono и тем самым освободить нас от обслуживания IIS. Вторая интересная фича – это возможность создания “плагинов”, т.е. встраивания кастомных компонент которые изменяют процесс трансформации F# в JavaScript.

Почему это актуально? Элементарно, Ватсон — нам нужен этот механизм чтобы мы могли создавать решения, которые позволяли бы делать семантические аннотации путем описания всего этого счастья в F#, с дальнейшей эмиссией “кошерного” HTML. Ведь это всяко лучше чем копаться прямо в HTML, не так ли?

Заключение

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

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

Ждите скорых обновлений!