Интегрирую данные
0,1
рейтинг
16 октября 2013 в 13:31

Разработка → Базы знаний. Часть 1 — введение

Одной из причин слабого использования Linked Data-баз знаний в обычных, ненаучных приложениях является то, что мы не привыкли придумывать юзкейсы, видя перед собой только данные. Трудно спорить с тем, что сейчас в России производится крайне мало взаимосвязанных данных. Однако это не значит, что разработчик, создающий приложение для русскоязычной аудитории совсем уж отрезан от мира семантического веба: кое-что всё-таки у нас есть.
image
Основными источниками данных для нас являются международные базы знаний, включающие русскоязычный контент: DBpedia, Freebase и Wikidata. В первую очередь это справочные, лингвистические и энциклопедические данные. Каждый раз когда вам в голову приходит мысль распарсить кусочек википедии или викисловаря — ущипните себя как следует и вспомните о том, что всё, что хранится в категориях, инфобоксах или таблицах, уже распарсено и доступно через API с помощью SPARQL или MQL-интерфейса.

Я попробую привести несколько примеров полезных энциклопедических данных, которые вы не найдете нигде, кроме Linked Data.

Эта статья — первая из цикла Базы знаний. Следите за обновлениями.


Городах, страны, исторические данные


imageЕсли вас интересуют города и страны, то в Linked Data вы найдете не только информация об их местоположении (которую, если честно, лучше тащить из других источников), но также:
  • достопримечательности вроде дворцов и памятников
  • родившихся и умерших известных людей
  • метеостатистику вроде месячного количества осадков и времени восхода солнца
  • гербы, флаги
  • демографию
  • связанные исторические события

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

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

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

SELECT DISTINCT ?strength, ?result, ?longitute, ?latitude, ?commander WHERE {
dbpedia:Battle_of_Kulikovo dbpprop:strength ?strength;
                           dbpprop:result ?result;
                           geo:long ?longitute;
                           geo:lat ?latitude;
                           dbpedia-owl:commander ?commander
}
LIMIT 1000


Данные об институтах, организациях, госструктурах


Такого рода даты часто нужны в аналитике. Например для того, чтобы подсчитывать, какой вуз выпускает больше всего олигархов/ученых/писателей, достойных упоминания в Википедии.
  • численность персонала/студентов/профессоров, для студентов — количество баков, магистров, иностранных студентов
  • годовая выручка
  • место в рейтингах
  • даты основания
  • дочерние и материнские компании
  • информация о руководителях

Композиторы, музыканты, фильмы


Насчет фильмов все выглядит более чем крепко: Freebase, Dbpedia и Linkedmdb располагают очень и очень неплохими массивами данных на тему кинематографии.
ileriseviye.wordpress.com/2012/07/11/is-semantic-web-and-linked-data-good-enough-sparql-dbpedia-vs-python-imdbpy
Мы не только легко можем посмотреть, какой актер где снимался, в каком году вышел фильм и кто его выпустил, но еще и узнать, кто повлиял на актёра, когда он родился, что у него с семейным положением и занимается ли он чем-либо, кроме съемок.
image

Например, вот этот запрос к Dbpedia выведет всех актеров, которые снимались и в фильме The Shining, и в фильме Hoffa:

image

Самым замечательным источником данных в области музыки, пожалуй, является MusicBrainz. Конечно же, он есть и в RDF, и конечно же, вы будете использовать традиционные API чтобы получить к ним доступ. Однако Freebase и Dbpedia могут пригодиться и тут — в последней есть, например, информация о гастролях музыкальных групп. Ну и даты рождения, влияние, стили и жанры — энциклопедические данные для музыки тоже присутствуют. Собственно в обучающих материалах Freebase используется как раз музыкальный пример: доставание данных о группе The Police:
{
  "type" : "/music/album",
  "name" : "Synchronicity",
  "artist" : "The Police",
  "track" : [{
     "name":null,
     "length":null
  }]
}

Наверное, интересно было бы использовать это в связке с API Last.fm

Персоналии: политики, спортсмены, исторические фигуры


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

Лингвистические приложения. Иерархия категорий



Для нужд классификации и кластеризации, а также задач математической лингвистики часто нужны иерархии понятий. Например, что палец является разновидностью части тела. Semantic Web спешит на помощь и позволяет вам не парсить категории википедии, а доставать их готовыми из Dbpedia или www.mpi-inf.mpg.de/yago-naga YAGO. Если же размер иерархии для вас менее важен, чем её качество, вы можете поглядеть на созданные вручную онтологии Dbpedia, Cyc, Umbel.

Лингвистические приложения. Викисловарь и переводы


В конце 2012 года команда Dbpedia запустила проект Wiktionary — доступ к Викисловарю как к базе данных. Сейчас можно делать запросы к английскому, немецкому, французскому, русскому, греческому и вьетнамскому языкам. Давайте попробуем вытащить переводы для какого-нибудь хорошего русского слова через SPARQL-точку Wiktionary:

image

Среди Semantic Web энтузиастов немало лингвистов, а потому лингвистический мир имеет своё собственное облако взаимосвязанных данных.
image

Много полезной информации по Linked и не-Linked данным можно получить c порталов Open Knowledge Foundation и нашего русского NLPub.

Как находить хорошие данные


Для Freebase на главной странице есть визуализация того, какие категории содержат наибольшее количество объектов.
image
Для DBPedia простой способ понять, где скрываются качественные данные тоже есть. Надо обратиться к приложению Mappings.DBpedia и его статистической сводке.
Маппинги — это отличный инструмент, позволяющий пользователям DBpedia влиять на то, как работают парсеры. Я обязательно расскажу про них подробнеев последующих статьях, а пока ограничимся вот этой страницей:
image

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

Ну а что тут сказать, поиск он и есть поиск. Мы используем движки Sig.ma, Sindice и Swoogle. Все они позволяют искать внутри одного датасета или же по всему множеству LInked Data.

В следующий раз я постараюсь описать то, как научиться строить SPARQL-запросы к базе знаний Dbpedia.
Юрий Катков @ganqqwerty
карма
100,2
рейтинг 0,1
Интегрирую данные
Реклама помогает поддерживать и развивать наши сервисы

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

Самое читаемое Разработка

Комментарии (29)

  • 0
    Спасибо, за хорошую статью.

    Да, концепция Linked Data прекрасна представлением объектов в виде SVO-троек и возможностью рисования запросов по коллекциям таких троек. Однако, на мой скромный взгляд, существует две системных проблемы технологий Linked Data и Semantic Web:

    1. Достаточно резкая кривая обучения. Допустим, программисты хотят просто получить данные. Вместо этого им предоставляется «какой-то SPARQL» и аппарат дескрипционной логики. Если по работе приходится «писать контроллеры», то на столь высокие вещи у людей времени обычно нет.
    2. Нетривиальный способ публикации данных. Хорошо, когда твоя информационная система общается сразу в RDF. А если нет? Обычно люди представляют данные в чём-то ещё: реляционные СУБД, файлы, модные NoSQL-решения. Выгрузка данных в форматах Linked Data вызывает дополнительные накладные расходы.

    Когда информационная система изначально построена поверх Linked Data и эти форматы являются для неё родными, то всё чудесно. Практика оказывается, увы, несколько иной.
    • +1
      1. Да ладно вам, никто не пользуется этой дескрипционной логикой. А SPARQL — это еще один API, который осваивается за десять минут, что я постараюсь показать в будущих статьях
      2. Да, согласен. Но если вы публикуете данные хоть в каком-то виде (например, в JSON, CSV), то они конвертируются в RDF довольно просто
      • 0
        Проблема кривой обучения хорошо обозначена в самом начале статьи. Склад мышления наших людей таков, что они в большинстве своём не привыкли строить решения, основанные на данных. Тема с открытыми, например, государственными данными в России начинает подниматься только сейчас. Пройдёт несколько лет и станет легче (надеюсь).

        Безусловно, нет никаких проблем отобразить CSV в RDF напрямую. Это не всегда правильно, так как наверняка найдётся словарь RDF, который уже описывает данную предметную область, и в нём придётся разбираться. В области XML существует аналогичная ситуация с XML Schema. Это вопрос интероперабельности.
      • +1
        1)
        еще один API, который осваивается за десять минут

        Вы преувеличиваете способности среднего программиста
        Я как то писал на скорую руку сервис, в котором нужны синонимы, слов. Потратил с час на попытки разобраться с DBpedia. В результате написал html парсер. Я этим не горжусь, но для моей задачи этого было достаточно.
        Большая часть времени ушла не на изучение синтаксиса SPARQL, а на то чтобы просто создать правильный коннект.

        2) Мне кажется вы очень преувеличиваете качество данных в DBpedia
        Например есть статья на вики Список профессий
        Аналога этой статьи нет в англоязычной википедии. Хотя достаточно обыденная тема.
        Это к тому, что формат данных, очень разный от языка к языку.

        UPD.Цифра 2, скорее к статье, чем к комментарию
    • 0
      Вся область слишком молодая, естественно, что она требует больше усилий для вхождения (без отсылок к Фрейду, пожалуйста).
      Но подождите пару, максимум 5 лет и у вас будут под рукой необходимый набор инструментов, чтобы "просто получить данные.".

      Нетривиальный способ не такой уж сложный, это цена ETL-процесса, который не должен пугать больших взрослых дядек.
      Ну есть у нас вики текст, ну взяли библиотеки Protégé, ну накрутили поверх Gate для лексического анализа и text-mining-а, ну сложили все в RDF/Triple store на любой вкус
      Накладно? Да, как и любой ETL процесс.
      Что до «просто использовать», те же модные NoSQL местами не что иное, как графовые СУБД, некоторые даже имеют нужные фичи из коробки.

      На практике придется много возиться с конкретной реализацией — область и инструменты слишком молоды по сравнению с теми же решениями на реляционных БД.

      И, замечу, делать что-то подобное LinkedData на базе только существующих решений есть костыль и репродукция велосипеда.

      Только вперед!
      Только к звездам через минные поля!
  • 0
    >… информация об их местоположении (которую, если честно, лучше тащить из других источников),

    Т.е. географические координаты населенных пунктов не всегда верно заданы? А где есть лучше?
    • +1
      Да, координаты лучше выверять и при необходимости исправлять маппинги. В www.geonames.org/ довольно качественные данные
    • 0
      В обозримом будущем с координатами должно стать лучше в Викиданных (за счёт исправления конфликтов между языковыми разделами), а соответственно и в Википедии, и во всех проектах, которые берут их неё информацию.
  • 0
    В свое время меня впечатлил www.visualdataweb.org/relfinder.php — позволяет искать всевозможные связи между двумя произвольными сущностями (которые, конечно же, должны быть в базе знаний). По-моему, это интересный и очень наглядный пример использования технологий SW на практике.
    • +1
      Да-да. Это действительно интересно;)
    • 0
      все равно пример довольно научный — мы экспериментировали, показывая людям от бизнеса это приложение и ни разу не встретили ответного интереса.
      • 0
        «люди от бизнеса» питаются только сильно упрощенными отбросами научной мысли. Желательно в виде продукта, которого нет на полках, который им по карману и который сделает профит за следующие пару кварталов сам по себе.
        Те немногие, которые излучают интерес, сами организуют исследования и R&D в области Semantic Web/Linked Data.

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

        Поэтому на любые умные графики можно сразу забить, если идет охота на инвестора.
        Юзкейс должен быть проще кнопки Like (а десять лет назад написал бы — проще пареной репы).
  • +1
    Вот, кстати, интересно — могу ли я как-то представить какой-то свой информационный сайт в виде источника знаний, при помощи средств Semantic Web?

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

    Но ведь если сайт большой, информации много и контент достаточно разношерстный, то это просто адская ручная работа. Может быть, есть какие-то инструменты / подходы выполнить эту работу (полу-) автоматически и максимально эффективно?
    • +1
      Семантическая вики?
      • 0
        \o/ воистину семантическая вики! Причем, либо Semantic MediaWiki, либо OntoWiki, либо Callimachus.
        • 0
          Подождите, сем. вики не позволяет делать автоматическое аннотирование контента, о чем собственно спрашивает sainnr.
          Все, что идет из коробки всего-лишь возможность установить значение проперти в вики тексте через UI.
          Это все равно ручной, адский труд — текст надо читать и осмыслять.

          Смотреть нужно в сторону анализатора текста, который по указанной онтологии/онтологиям проставит или предложит проставить те или иные обнаруженные свойства и значения. Помню несколько демок (пример) в инете, с разной степенью успешности.
          • 0
            А-а-а, ну значит, я ошибся и протормозил. Я не верю в автоматическое аннотирование контента как источник структурированных данных. Скормить растэгированный DBPedia Spotlight'ом или OpenCalais'ом текст можно разве что какому-нибудь machine learning алгоритму, который будет выдавать неплохой результат даже при 40% лажи в исходном материале.
    • 0
      У вас на сайте какого рода сущности и какого рода отношения между ними? От этого, думаю, зависит очень многое. В частности, если информация — это данные из БД, аннотировать их в RDF будет осмысленно и не сильно сложно. А вот массивы неструктурированного текста подавать как граф сведений? Сомнительной пользы дело, и большой сложности.
  • +1
    Вроде ко всем публичным данным есть ограничения по количеству запросов/их сложности? Мы сейчас пишем своей проект который использует семантический веб в качестве основы для хранения и управления метаданными и нас очень сильно интересует процесс отображения онтологий (alignment), особенно учитывая их количество.
    • 0
      да, лучше всего рассматривать публичные SPARQL-точки просто как средство демонстрации данных, а в реальной работе использовать свои хранилища с данными, восстановленными из дампов. А можно поподробнее про проект?
      • 0
        Проект связан с хранением данных, в начале он разрабатывался как архивная система на основе эталонной модели OAIS, и одним из требований было то, что информация должна быть понятна целевой аудитории на протяжении сколько угодно длительного времени (при этом сама информация остается неизменной). Тут очень хорошо подошел именно semantic web, и концепт изменяемых метаданных. Например. У нас есть объект хранения — Анамнез пациента. Метаданными в данном случае может является информация о болезнях, родственниках, способ получения, врачи и т.п. Мы пытаемся покрыть основные онтологии, а именно (библиография, медиа, инженерная документация, медицина).

        Проект является стартапом, над которым мы работаем уже почти 2 года, рекламировать я его не буду, но если Хабрахабр примет нас как стартап по своей новой программе (ну или мы наконец найдем деньги и оплатим подписку), то я расскажу более детально, там довольно много интересных моментов как с семантикой, так и с OAIS.
        • 0
          ух ты, звучит отлично! Жду обновлений от вас
        • 0
          Очень интересно! Особенно, мне, в плане GUI ко всему этому.
  • 0
    Откуда данные кто на кого влиял, в музыке и в кино?
  • 0
    Хочу добавить сайт-коллекцию APIs, end-points и других интерфейсов для доступа к данным: datahub.io
    Например, тут есть данные от РИА Новости, a так же упомянутые Freebase и dbpedia. Wikidata нету.
  • 0
    мы не привыкли придумывать юзкейсы, видя перед собой только данные


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

    На самом деле искать пути применения данных очень просто.
    Алгоритм:
    — взять 1 существующий кейс
    — выделить все затронутые домены
    — описать «человеческую» сторону кейса
    — определить контекст выполнения кейса
    — отыскать подходящих провайдеров с данными
    — mix & match — на этом этапе уже появится идея кейс
    — готовим POC
    — ???
    — profit

    На мой взгляд проблема не в подходе, а в зрелости рынка.
    Имхо супер-дупер-умный софт нахер не сдался рядовому потребителю или частному бизнесу. Его совершенно другие проблемы волнуют — как выжить, например.
    Разработка приложений для Big/Linked/SemanticData в данный момент стоит на порядок больше, а ожидаемый профит гораздо меньше.

    • 0
      Поясню примером. Жили-были данные о состоянии зданий. И тут внезапно они стали открытыми. На них посмотрел один разработчик и подумал — гм, а почему бы не сделать приложение, которое я продам пожарным на основе этих данных? Вот примерно так я вижу придумывание кейса по данным
      • 0
        Идею понимаю, но я скептик:
        — сторонний разработчик разве что может угадать с приложением, если он, конечно, не спец в пожарном деле или есть хорошие друзья.
        — под описание попадает куча существующих кейсов: мониторинг, оповещение, предупреждение
        — валидность, качество и постоянство данных

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

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