Внедрение семантических данных в HTML

    Тоже хочу принять участие в размышлениях на тему семантического веба, начатого здесь и здесь.

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


    Зачем мне это нужно?


    Ответ очень простой — необходимость отделять зерна от плевел, т.е. «информацию» от «информационного шума».

    Как это может качественно повлиять на веб:
    • если ввести в поисковую систему запрос, содержащий название некого топика или новости, то можно заметить, что 80% результатов — это один и тот же текст, «внедренный» в графический интерфейс того или иного ресурса
    • концентрация на информации, а не на баннерах, списков ссылок, друзей друзей и т.д.
    • более точный поиск за счет учета лишь релевантного контента
    • ваш вариант?

    Что мы имеем на данный момент?


    Если необходимость и преимущества «семантического веба» более и менее понятны, то вот варианты реализации вызывают некоторые опасения.

    На данный момент мы оперируем такими понятиями как URI (Uniform Resource Identifier), онтологии, которые описываются такими языками как RDF и OWL и др.

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

    Также мы имеем такое понятие, как микроформаты, которые, как мне кажется, дальше по своей сути продвинулись в идейном развитии, но, к сожалению, не достаточно далеко.

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

    Ручной труд или автоматизация?


    Второй стоп-фактор — это то, что семантические данные необходимо вводить самостоятельно, в связи с чем возникает вопросы о том, кто это будет делать и кто за это будет платить.

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

    Постановка задач и варианты их решения


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

    С точки зрения автора сайта нет смысла заниматься семантикой, потому что:
    • это требует дополнительных трудозатрат (это еще полбеды)
    • это требует обучения новым стандартам и языкам (тот же RDF и OWL)
    • отсутствие или слабая поддержка семантики поисковыми системами
    Если первый пункт — это больше вопрос денежный и часто вполне решаемый, третий — зависит от поисковых лидеров, то со вторым пунктом попробуем что-то сделать.

    Интеграция семантических данных


    Проанализировав (и немного пофантазировав) сложные и не очень возможные методы интеграции семантических данных, я остановился на простом и очевидном способе: интеграция в виде тегов и (или) в нотации CSS.

    Пример:

    <div id=”content” xml:semantic=”keywords: mathcad; contentType: content; category: math;”> Mathcad is desktop software for performing and documenting engineering and scientific calculations.

    Для того, чтобы код был валидный, дописываем схему:

    <!DOCTYPE html PUBLIC
    "-//W3C//DTD XHTML 1.0 Transitional//EN"
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"
    [
    <!ATTLIST div keywords CDATA #IMPLIED>
    <!ATTLIST div contentType (copyright|content|definition|links|references| bibliographic|related|image) CDATA #IMPLIED>
    <!ATTLIST div category (Business_Finance|Entertainment_Culture| Environment|Health_Medical_Pharma|Hospitality_Recreation|Law_Crime| Politics|Sports|Technology_Internet|Weather|Other) CDATA #IMPLIED>
    ...
    <!ATTLIST div progLang CDATA #IMPLIED>
    ]>


    В нотации CSS:

    <div id=”content” xml:semanticClass=”mySemanticClass”> Mathcad is desktop software for performing and documenting engineering and scientific calculations.

    .mySemanticClass {
    keywords: mathcad;
    contentType: content;
    category: math;
    }

    В наш HTML файл семантический файл подключаем как и простой CSS файл.

    Атрибуты и категории


    В своей работе я выделил основные атрибуты, которые хотелось бы иметь уже сейчас. Вот их список:
    • contentType defines content type (top, bottom, advertisement, content, links, references, bibliographic, related, image, video etc.);
    • keywords defines the relevant keywords or phrases for block content; synonyms defines related terms and synonyms (e.g. «Obama» and «president»;
    • category defines content category (Business_Finance, Entertainment_Culture, Environment, Health_Medical_Pharma, Hospitality_Recreation, Law_Crime, Politics, Sports, Technology_Internet, Weather, Other) [6].
    • importance defines content importance and can be a float value from 0 to 1;
    • ref attribute defines additional reference related with block content;
    • parent is a identifier of parent block which says that it must be considered with parent block;
    • author defines copyrights and can be used for citations, proverbs, programming code;
    • progLang defines a programming language.
    Рассмотрим преимущества такого подхода:
    • интегрировать семантические данные можно сразу на этапе создания HTML
    • это может делать и верстальщик и программист, который знаком с CSS (а таких гораздо больше чем знатоков RDF)
    Ну да, мечты, мечты…

    Но ведь будущее уже здесь!


    У данного подхода один явный недостаток — необходимость заручиться поддержкой поисковых гигантов, которые будут использовать данный подход при индексации страниц. Но данную идею уже можно внедрять в CMS, блогодвижках — для этого нужно внедрить соответствующий код в движок и некоторые дополнительные поля для ввода и использовать эту информацию в собственной логике поиска и фильтрации данных.

    P.S. Как кто-то хорошо подметил, за идею не бьют. Поэтому было бы интересно обсудить и такой вариант развития semantic web. Спасибо за внимание!
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 18

      +1
      Я думаю, что заручиться поддержкой поисковых гигантов гораздо проще, чем кажется. В конце концов мы все здесь делаем веб таким, какой он будет завтра. И «большие компании» идут нам на встречу. Взять хотя-бы Mozilla Drumbeat. Ведь в конечном счете идея создания единого информационного пространства, и привела к Web2.0
      Мы стоим на пороге новой эры взаимодействия человека и машин с информацией. Наша задача в создании и популяризации инструментов анализа и обработки семантической информации. Как только такие инструменты станут достаточно функциональны, мы получим необходимую критическую массу и выдвинем веб на новый уровень…
        0
        Заметил, что мы каждый день стоим на каком-то пороге… И не на одном)
        +1
        Уйдите уже наконец от интерфейсноцентрических систем и наделите сами данные смыслом, сделайте доступ к данным через апи (SOAP, xml-rpc...) и свяжите их на уровне моделей данных. Уже изобретены нейронные сети, семантические сети, ассоциативные… сложность в том, что нормальной доступной субд нету для не реляционных структур.
          –1
          Гиганты тоже коммерческие организации. Они тоже хотят внедрить технологию семантического поиска как только это позволит избежать выдачи одного и тогоже текста в выдаче. Другое дело, что в выиграше останутся только сайты с высоким процентом создаваемой информации. Поэтому, мне кажется, что в ближайшее время нас ждут только микроформаты, которые гораздо выгоднее.
            0
            Вообщем-то, микроформаты это тоже большой шаг вперед по сравнению с текущим состоянием дел.

            Мне кажется, что поисковые гиганты могли бы значительно стимулировать использование тех или иных технологий (например, микроформатов) за счет добавления дополнительных очков при ранжирование.

            Например, мне кажется вполне реализуемой следующая схема работы:

            1. Юзер вводит в поиск «Вася Пупкин»
            2. Поисковик определяет, что в запросе имя собственное и отдает некоторое предпочтение при ранжировании тем страницам, которые содержат контакты Васи не просто в текста, а внутри hCard, например.
            3. Кроме этого, для таких страниц помимо снипета выводится ссылка «Контакты Васи Пупкина», при наведении на которую показывается аккуратно отформатированный контент из hCard.

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

            Абсолютно аналогично решается с другими микроформатами… И через некоторое время мы уже получаем чуть более упорядоченный веб.

            Однако, описанного почему-то пока не наблюдается…
              0
              Собственно, когда писал комент — в голове крутилась мысль, что совершенно не затронута область микроформата сайтов-визиток (ну и сайтов-прайсов как отдел визитки). Хотя как говорит опыт RSS это позволит не создавать дизаин вобще, так как по данным из тэгов будет проходить форматирование информации (а на сайтах визитках даже комменты негде). Получается что можно положить на файловый сервер некий отформатированный документ (robots.txt) и успокоиться. Но опять таки это выгодно только некомерческим сайтам, которых единицы.
                0
                Ну, я думаю, владельцам сайтов не всегда выгодно класть только robots.txt — в той же hCard содержатся только контактные данные, а на сайте-визитке может быть некоторая дополнительная информация — например, портфолио разработчика. И люди будут заходить ее смотреть время от времени… Я бы, например, заходил посмотреть, даже если я искал только телефон человека — там же может быть какая-та информация от человека, которая может пригодится позже в разговоре.

                Я немного не понял про опыт RSS — все RSS-потоки, которые я встречал, параллельно представлены набором страниц с дизайном, почти у всех там еще форма для комментов есть как минимум. Если у Вас есть другие примеры, было бы интересно посмотреть, я таких просто не встречал пока.

                И почему только некоммерческим? Если говорить о сайтах-прайсах (ваш пример), то это весьма коммерческие сайты.
                  0
                  Про RSS:
                  Единственное, что заставляет заходить на блоггерский сайт — это либо коммент (которых нет у визиток), либо неполный пост в RSS. У меня есть несколько блогов в агрегаторах, которые я читаю регулярно, но дизаин сайтов уже забыл. Тоже самое будет и hCard's. Я не говорю что это плохо или хорошо. Просто это другой веб с другой идеей.
                  Про прайс:
                  Идея отличная, однако пока все её реализовывают, насколько я понимаю, с помощью API (Яндекс.Маркет).
                    +1
                    Я думаю, тут все сильно зависит от личных предпочтений человека. Я обычно открываю текст в браузере (если, конечно, он как-то мне интересен). Может быть это обусловлено просто привычкой, я не могу сказать. Но я могу предположить, что я не один такой в мире, и поэтому пока многим авторам придется какой-то дизайн поддерживать =)

                    Хотя с другой стороны — я кажется видел парочку сайтов (сейчас, к сожалению, не могу вспомнить адреса), где для отображения в браузере ленты использовалось форматирование RSS с помощью XSLT — это достаточно близко к отсутствуию дизайна. Кроме того, Firefox, например, предоставляет некоторый дефолтный стиль для отображения RSS.

                    Так что, если дефолтные стили браузеров будут немного доработаны — то действительно, многие авторы смогут не создавать дизайна — и при этом позволять читать ленту из браузера. Тогда ситуация безусловно приблизится к той, которую Вы описываете =)

                    По поводу прайсов — видимо это описывается микроформатом hProduct. Причем судя по списку примеров его потихоньку начинают использовать.
            +3
            Насчет «кто и зачем будет делать онтологическое описание» есть следующая идея: сейчас все находятся в плену стереотипа, что это описание добавляют где-то в конце, на готовый контент. Моя мысль: это чушь бред сивой кобылы в безлунную ночь, настолько же «простой» как дизассемблирование толстой программы (или, еще «круче» — попытка налету заменить классический процедурный код на объектно-ориентированный) Онтологическое описание должно идти _до_ работы над «шумом». Это должна быть технология разработки.
            Например, заказывая написание статьи неизбежно требуется договориться, что будет в этой статье. Основное сообщение и некоторые важные детали. Вот это — и есть тот материал, из которого можно очень легко и просто сделать описание всего прочего. Более того, в таком виде онтологическое описание будет помогать работе — фиксируя однозначным образом наиболее важные отношения. Частный случай — исследование. В нем онтология является продуктом — формализованным выводом.
              –1
              Грамотно! При возникновении идеи введения онтологий, первая возникающая мысль — «надо всё переделать». Напротив, нужно просто изменить подход к написанию :)
              –1
              > Как это может качественно повлиять на веб: ваш вариант?
              Легко можно отображать не только релевантные результаты но и связанные с ними: не всегда человек точно знает как называется то что он ищет :) даже я бы сказал обычно люди вообще не умеют правильно искать :) Семантическая разметка сильно бы помогла
                0
                Я бы ещё добавил что могут появиться «дорвеи» из RDFных схем для увеличения вероятности отклика страницы на некоторый смысловой запрос. Ничто ведь не удержит спамеров и прочую *****братию от создания заведомо ложных онтологий :) А вот это уже, увы, наверняка быстренько сведёт на нет всю красоту идеи, неважно в какой реализации. В жёстко структурированных схемах сложнее отличить лажу так как сейчас поисковики выкидывают дорвеи: суть онтологии как раз в машинном представлении информации с изначально подразумевающейся истинностью
                  +1
                  В принципе вечная борьба меча и щита: уже есть технологии и/или методики придания веса различным сайтам с одной и той же информацией (те же PR и ТИЦ), ничто не мешает применять их и к онтологиям — истинность утверждений при наличии различных вариантов зависит от «авторитетности» источников.
                    +2
                    Правильно. Были ведь уже meta content и meta keywords дискредитировавшие себя в глазах поисковиков.
                      0
                      хм, ну как сказать, боты поисковиков первым делом заглядывают в мета-тэги.
                        0
                        не заглядывают
                    0
                    глупость какая-то.

                    en.wikipedia.org/wiki/Notation3

                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                    Самое читаемое