Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 29
Спасибо, за хорошую статью.
Да, концепция Linked Data прекрасна представлением объектов в виде SVO-троек и возможностью рисования запросов по коллекциям таких троек. Однако, на мой скромный взгляд, существует две системных проблемы технологий Linked Data и Semantic Web:
Когда информационная система изначально построена поверх Linked Data и эти форматы являются для неё родными, то всё чудесно. Практика оказывается, увы, несколько иной.
Да, концепция Linked Data прекрасна представлением объектов в виде SVO-троек и возможностью рисования запросов по коллекциям таких троек. Однако, на мой скромный взгляд, существует две системных проблемы технологий Linked Data и Semantic Web:
- Достаточно резкая кривая обучения. Допустим, программисты хотят просто получить данные. Вместо этого им предоставляется «какой-то SPARQL» и аппарат дескрипционной логики. Если по работе приходится «писать контроллеры», то на столь высокие вещи у людей времени обычно нет.
- Нетривиальный способ публикации данных. Хорошо, когда твоя информационная система общается сразу в RDF. А если нет? Обычно люди представляют данные в чём-то ещё: реляционные СУБД, файлы, модные NoSQL-решения. Выгрузка данных в форматах Linked Data вызывает дополнительные накладные расходы.
Когда информационная система изначально построена поверх Linked Data и эти форматы являются для неё родными, то всё чудесно. Практика оказывается, увы, несколько иной.
1. Да ладно вам, никто не пользуется этой дескрипционной логикой. А SPARQL — это еще один API, который осваивается за десять минут, что я постараюсь показать в будущих статьях
2. Да, согласен. Но если вы публикуете данные хоть в каком-то виде (например, в JSON, CSV), то они конвертируются в RDF довольно просто
2. Да, согласен. Но если вы публикуете данные хоть в каком-то виде (например, в JSON, CSV), то они конвертируются в RDF довольно просто
Проблема кривой обучения хорошо обозначена в самом начале статьи. Склад мышления наших людей таков, что они в большинстве своём не привыкли строить решения, основанные на данных. Тема с открытыми, например, государственными данными в России начинает подниматься только сейчас. Пройдёт несколько лет и станет легче (надеюсь).
Безусловно, нет никаких проблем отобразить CSV в RDF напрямую. Это не всегда правильно, так как наверняка найдётся словарь RDF, который уже описывает данную предметную область, и в нём придётся разбираться. В области XML существует аналогичная ситуация с XML Schema. Это вопрос интероперабельности.
Безусловно, нет никаких проблем отобразить CSV в RDF напрямую. Это не всегда правильно, так как наверняка найдётся словарь RDF, который уже описывает данную предметную область, и в нём придётся разбираться. В области XML существует аналогичная ситуация с XML Schema. Это вопрос интероперабельности.
1)
Вы преувеличиваете способности среднего программиста
Я как то писал на скорую руку сервис, в котором нужны синонимы, слов. Потратил с час на попытки разобраться с DBpedia. В результате написал html парсер. Я этим не горжусь, но для моей задачи этого было достаточно.
Большая часть времени ушла не на изучение синтаксиса SPARQL, а на то чтобы просто создать правильный коннект.
2) Мне кажется вы очень преувеличиваете качество данных в DBpedia
Например есть статья на вики Список профессий
Аналога этой статьи нет в англоязычной википедии. Хотя достаточно обыденная тема.
Это к тому, что формат данных, очень разный от языка к языку.
UPD.Цифра 2, скорее к статье, чем к комментарию
еще один API, который осваивается за десять минут
Вы преувеличиваете способности среднего программиста
Я как то писал на скорую руку сервис, в котором нужны синонимы, слов. Потратил с час на попытки разобраться с DBpedia. В результате написал html парсер. Я этим не горжусь, но для моей задачи этого было достаточно.
Большая часть времени ушла не на изучение синтаксиса SPARQL, а на то чтобы просто создать правильный коннект.
2) Мне кажется вы очень преувеличиваете качество данных в DBpedia
Например есть статья на вики Список профессий
Аналога этой статьи нет в англоязычной википедии. Хотя достаточно обыденная тема.
Это к тому, что формат данных, очень разный от языка к языку.
UPD.Цифра 2, скорее к статье, чем к комментарию
В английской Википедии есть список списков профессий.
Вся область слишком молодая, естественно, что она требует больше усилий для вхождения (без отсылок к Фрейду, пожалуйста).
Но подождите пару, максимум 5 лет и у вас будут под рукой необходимый набор инструментов, чтобы "просто получить данные.".
Нетривиальный способ не такой уж сложный, это цена ETL-процесса, который не должен пугать больших взрослых дядек.
Ну есть у нас вики текст, ну взяли библиотеки Protégé, ну накрутили поверх Gate для лексического анализа и text-mining-а, ну сложили все в RDF/Triple store на любой вкус…
Накладно? Да, как и любой ETL процесс.
Что до «просто использовать», те же модные NoSQL местами не что иное, как графовые СУБД, некоторые даже имеют нужные фичи из коробки.
На практике придется много возиться с конкретной реализацией — область и инструменты слишком молоды по сравнению с теми же решениями на реляционных БД.
И, замечу, делать что-то подобное LinkedData на базе только существующих решений есть костыль и репродукция велосипеда.
Только вперед!
Только к звездам через минные поля!
Но подождите пару, максимум 5 лет и у вас будут под рукой необходимый набор инструментов, чтобы "просто получить данные.".
Нетривиальный способ не такой уж сложный, это цена ETL-процесса, который не должен пугать больших взрослых дядек.
Ну есть у нас вики текст, ну взяли библиотеки Protégé, ну накрутили поверх Gate для лексического анализа и text-mining-а, ну сложили все в RDF/Triple store на любой вкус…
Накладно? Да, как и любой ETL процесс.
Что до «просто использовать», те же модные NoSQL местами не что иное, как графовые СУБД, некоторые даже имеют нужные фичи из коробки.
На практике придется много возиться с конкретной реализацией — область и инструменты слишком молоды по сравнению с теми же решениями на реляционных БД.
И, замечу, делать что-то подобное LinkedData на базе только существующих решений есть костыль и репродукция велосипеда.
Только вперед!
Только к звездам через минные поля!
>… информация об их местоположении (которую, если честно, лучше тащить из других источников),
Т.е. географические координаты населенных пунктов не всегда верно заданы? А где есть лучше?
Т.е. географические координаты населенных пунктов не всегда верно заданы? А где есть лучше?
Да, координаты лучше выверять и при необходимости исправлять маппинги. В www.geonames.org/ довольно качественные данные
В обозримом будущем с координатами должно стать лучше в Викиданных (за счёт исправления конфликтов между языковыми разделами), а соответственно и в Википедии, и во всех проектах, которые берут их неё информацию.
В свое время меня впечатлил www.visualdataweb.org/relfinder.php — позволяет искать всевозможные связи между двумя произвольными сущностями (которые, конечно же, должны быть в базе знаний). По-моему, это интересный и очень наглядный пример использования технологий SW на практике.
Да-да. Это действительно интересно;)
все равно пример довольно научный — мы экспериментировали, показывая людям от бизнеса это приложение и ни разу не встретили ответного интереса.
«люди от бизнеса» питаются только сильно упрощенными отбросами научной мысли. Желательно в виде продукта, которого нет на полках, который им по карману и который сделает профит за следующие пару кварталов сам по себе.
Те немногие, которые излучают интерес, сами организуют исследования и R&D в области Semantic Web/Linked Data.
я понимаю, что это офтопик, чувства вслух и все давно знают эту истину.
Просто у самого есть также.
Больше четырех лет работы в этой области заморожено на неопределенный срок.
Поэтому на любые умные графики можно сразу забить, если идет охота на инвестора.
Юзкейс должен быть проще кнопки Like (а десять лет назад написал бы — проще пареной репы).
Те немногие, которые излучают интерес, сами организуют исследования и R&D в области Semantic Web/Linked Data.
я понимаю, что это офтопик, чувства вслух и все давно знают эту истину.
Просто у самого есть также.
Больше четырех лет работы в этой области заморожено на неопределенный срок.
Поэтому на любые умные графики можно сразу забить, если идет охота на инвестора.
Юзкейс должен быть проще кнопки Like (а десять лет назад написал бы — проще пареной репы).
Вот, кстати, интересно — могу ли я как-то представить какой-то свой информационный сайт в виде источника знаний, при помощи средств Semantic Web?
Ну то есть, понятно, что я должен наверное сперва как-то составить структуру: базовые концепты, роли, отношения между ними и т.д. Здесь еще видимо стоит поискать уже какие-то готовые словари и максимально их переиспользовать. Затем я должен пройтись по всем страницам и как-то соотнести контент, представленный на них, с той структурой, что получилась, описать его в виде фактов.
Но ведь если сайт большой, информации много и контент достаточно разношерстный, то это просто адская ручная работа. Может быть, есть какие-то инструменты / подходы выполнить эту работу (полу-) автоматически и максимально эффективно?
Ну то есть, понятно, что я должен наверное сперва как-то составить структуру: базовые концепты, роли, отношения между ними и т.д. Здесь еще видимо стоит поискать уже какие-то готовые словари и максимально их переиспользовать. Затем я должен пройтись по всем страницам и как-то соотнести контент, представленный на них, с той структурой, что получилась, описать его в виде фактов.
Но ведь если сайт большой, информации много и контент достаточно разношерстный, то это просто адская ручная работа. Может быть, есть какие-то инструменты / подходы выполнить эту работу (полу-) автоматически и максимально эффективно?
Семантическая вики?
\o/ воистину семантическая вики! Причем, либо Semantic MediaWiki, либо OntoWiki, либо Callimachus.
Подождите, сем. вики не позволяет делать автоматическое аннотирование контента, о чем собственно спрашивает sainnr.
Все, что идет из коробки всего-лишь возможность установить значение проперти в вики тексте через UI.
Это все равно ручной, адский труд — текст надо читать и осмыслять.
Смотреть нужно в сторону анализатора текста, который по указанной онтологии/онтологиям проставит или предложит проставить те или иные обнаруженные свойства и значения. Помню несколько демок (пример) в инете, с разной степенью успешности.
Все, что идет из коробки всего-лишь возможность установить значение проперти в вики тексте через UI.
Это все равно ручной, адский труд — текст надо читать и осмыслять.
Смотреть нужно в сторону анализатора текста, который по указанной онтологии/онтологиям проставит или предложит проставить те или иные обнаруженные свойства и значения. Помню несколько демок (пример) в инете, с разной степенью успешности.
А-а-а, ну значит, я ошибся и протормозил. Я не верю в автоматическое аннотирование контента как источник структурированных данных. Скормить растэгированный DBPedia Spotlight'ом или OpenCalais'ом текст можно разве что какому-нибудь machine learning алгоритму, который будет выдавать неплохой результат даже при 40% лажи в исходном материале.
У вас на сайте какого рода сущности и какого рода отношения между ними? От этого, думаю, зависит очень многое. В частности, если информация — это данные из БД, аннотировать их в RDF будет осмысленно и не сильно сложно. А вот массивы неструктурированного текста подавать как граф сведений? Сомнительной пользы дело, и большой сложности.
Вроде ко всем публичным данным есть ограничения по количеству запросов/их сложности? Мы сейчас пишем своей проект который использует семантический веб в качестве основы для хранения и управления метаданными и нас очень сильно интересует процесс отображения онтологий (alignment), особенно учитывая их количество.
да, лучше всего рассматривать публичные SPARQL-точки просто как средство демонстрации данных, а в реальной работе использовать свои хранилища с данными, восстановленными из дампов. А можно поподробнее про проект?
Проект связан с хранением данных, в начале он разрабатывался как архивная система на основе эталонной модели OAIS, и одним из требований было то, что информация должна быть понятна целевой аудитории на протяжении сколько угодно длительного времени (при этом сама информация остается неизменной). Тут очень хорошо подошел именно semantic web, и концепт изменяемых метаданных. Например. У нас есть объект хранения — Анамнез пациента. Метаданными в данном случае может является информация о болезнях, родственниках, способ получения, врачи и т.п. Мы пытаемся покрыть основные онтологии, а именно (библиография, медиа, инженерная документация, медицина).
Проект является стартапом, над которым мы работаем уже почти 2 года, рекламировать я его не буду, но если Хабрахабр примет нас как стартап по своей новой программе (ну или мы наконец найдем деньги и оплатим подписку), то я расскажу более детально, там довольно много интересных моментов как с семантикой, так и с OAIS.
Проект является стартапом, над которым мы работаем уже почти 2 года, рекламировать я его не буду, но если Хабрахабр примет нас как стартап по своей новой программе (ну или мы наконец найдем деньги и оплатим подписку), то я расскажу более детально, там довольно много интересных моментов как с семантикой, так и с OAIS.
Откуда данные кто на кого влиял, в музыке и в кино?
Хочу добавить сайт-коллекцию APIs, end-points и других интерфейсов для доступа к данным: datahub.io
Например, тут есть данные от РИА Новости, a так же упомянутые Freebase и dbpedia. Wikidata нету.
Например, тут есть данные от РИА Новости, a так же упомянутые Freebase и dbpedia. Wikidata нету.
мы не привыкли придумывать юзкейсы, видя перед собой только данные
Я не понимаю такой подход. Юзкейсы пишутся как описание решения какой-либо проблемы. Да, их в том числе используют для описания какой-либо идеи — именно это мне не нравится.
На самом деле искать пути применения данных очень просто.
Алгоритм:
— взять 1 существующий кейс
— выделить все затронутые домены
— описать «человеческую» сторону кейса
— определить контекст выполнения кейса
— отыскать подходящих провайдеров с данными
— mix & match — на этом этапе уже появится идея кейс
— готовим POC
— ???
— profit
На мой взгляд проблема не в подходе, а в зрелости рынка.
Имхо супер-дупер-умный софт нахер не сдался рядовому потребителю или частному бизнесу. Его совершенно другие проблемы волнуют — как выжить, например.
Разработка приложений для Big/Linked/SemanticData в данный момент стоит на порядок больше, а ожидаемый профит гораздо меньше.
Поясню примером. Жили-были данные о состоянии зданий. И тут внезапно они стали открытыми. На них посмотрел один разработчик и подумал — гм, а почему бы не сделать приложение, которое я продам пожарным на основе этих данных? Вот примерно так я вижу придумывание кейса по данным
Идею понимаю, но я скептик:
— сторонний разработчик разве что может угадать с приложением, если он, конечно, не спец в пожарном деле или есть хорошие друзья.
— под описание попадает куча существующих кейсов: мониторинг, оповещение, предупреждение
— валидность, качество и постоянство данных
Но это все детали, я буду только рад системам/решениям способным решать такие важные задачи.
— сторонний разработчик разве что может угадать с приложением, если он, конечно, не спец в пожарном деле или есть хорошие друзья.
— под описание попадает куча существующих кейсов: мониторинг, оповещение, предупреждение
— валидность, качество и постоянство данных
Но это все детали, я буду только рад системам/решениям способным решать такие важные задачи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Базы знаний. Часть 1 — введение