Настоящее семантической паутины

[kal1sha]

Крутил связку RDF+SPARQL вроде всё работает, но скорость не радует. В проекте есть готовые модули, но пока ждём пока «созреет» sw.

[kal1sha]

Делали поисковик основе sw. Пришли к выводу, что лучше sphinx использовать.

[GMint]

А что использовали в качестве БД?

[kal1sha]

mysql

[dmitriid]

RDF — это все же графы. Может, имело смысл смотреть в стороно граф-баз данных и набора технологий от tinkerpop: www.tinkerpop.com/ (а именно свзяка Blueprints/Pipes/Gremlin)

[GMint]

Очень интересная ссылка, приходилось уже использовать в проектах?

[dmitriid]

Увы, пока только на уровне «поиграться»

[yamalight]

а где у них там базы данных? только пачку фреймворков вижу.
из баз под RDF/OWL самое удобное, чем пользовался, пока что Virtuoso

[dmitriid]

Эти фреймворки базаданнонезависимые. Поддерживают на данный момент Neo4j, OrientDB, интерфейс Sail: github.com/tinkerpop/blueprints/wiki

[yamalight]

ах, вот оно как. понятно, спасибо :(

[yamalight]

зараза! смайлик, конечно, такой :)

[dmitriid]

Смайлик неправильный :)

Они позволяют интересную работу с графами. Для затравки презентации:

www.slideshare.net/slidarko/computing-with-directed-labeled-graphs-3879998
www.slideshare.net/slidarko/graph-windycitydb2010
www.slideshare.net/slidarko/problemsolving-using-graph-traversals-searching-scoring-ranking-and-recommendation

Да и в доках на Pipes и gremlin есть много интересного

[yamalight]

Занятные презентации. Было бы круто послушать выступление по ним :)

[dmitriid]

О да.

У slidarko там еще есть толпа презентаций, в основном на темы графов

[mr_fresh]

Так-то оно так. Но когда я присматривался к NoSQL'ю, я так и не нашел приемлемый БД на графах.
Neo4j не распределенный, и что еще хуже — AGPL. OrientDB — пока без распределенности, планируется репликация — говорят как в Монго — один мастер много слейвов (то есть и не распределенность вовсе). А ведь в Монго на самом деле честно автошардится?
FlockDB — хорошая, но очень простая, не представляю как сделать на ней range search какой-нибудь.
InfoGrid — нераспределенный + AGPL. AllegroGraph — туда же.
Это всё может показаться ворчанием, однако я хотел бы найти именно распределенный вариант =)

[GMint]

Вам нужна noSQL бд или бд под SPARQL/RDF?
MongoDB — документо-ориентированная БД — не пробовал там делать масштабируемое решение, но вроде как интересная. Если вам из такого рода БД — то советую посмотреть Cassandra.
Из БД которые работают именно по графам — HyperGraphDB
А если SPARQL, то есть вы планируете работать с RDF — то я пока лишь CORESE могу порекомендовать — с использованием KGRAM она стала масштабируемой.

[mr_fresh]

Спасибо за ответ! По идее под проект подойдет и то и то, но чисто графовый вариант лучше ;-)
MongoDB — хорошо, но у Couch'а мне больше нравится решение по целостности базы + понадежнее вроде. А в HyperGraphDB я просто не нашел информации по распределенности — вроде она есть, но в каком виде и как это работает — негласная информация.

Если ничего не найду — останется действительно только
Cassandr'а. Но с этим семейством проблемы в том, что моделирование идет от запросов и для поиска по многим атрибутам придется делать кучу индексов и искать их пересечение (при этом для обычной БД — это тривиальная задача с одним индексом). + Проблемы с интервальными запросами.

Очень благодарен за CORESE, пошел изучать.

[dmitriid]

> хотел бы найти именно распределенный вариант

ой, вот с этим пока все плохо, насколько я понимаю :) имхо пока никто не знает, как нрамотно распределять граф при изменении его структуры :)

[mr_fresh]

Да, это я и имел ввиду. И меня терзают сильные сомнения, что сделают качественный автоматический шардинг графов.
Основа для распределения — информация о связанности элементов в запросе. Грубо говоря при какой группировке запросов второго и большего уровней будет меньше всего. Задачу облегчает то, что можно (и нужно) хранить несколько копий каждой вершины — соответственно и группировать их можно по разному.

Как я вижу на данный момент, можно решить эту задачу используя предварительно составленные схемы распределения (ручками), а затем корректировать их на основе статистики запросов.

[GMint]

Кстати, а как дела обстоят у Виртуозо с апдейтом?
Мне пока приходилось работать лишь с CORESE.

[yamalight]

Я про такую штуку даже и не слышал о.О У нас основная масса используют либо виртуозо либо jena и производные )
У виртуозо почти со всем (по крайней мере в последней версии) почти все хорошо. По крайней мере гораздо лучше, чем у большинства других бекэндов 8]

[GMint]

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

[yamalight]

а в чем ключевые отличия от монстров вроде Jena и Virtuoso?

[GMint]

Надо как раз мне это и изучить, потому как с Jena и Virtuoso я не работал — лишь читал по ним доки. Думаю надо пару тестов прогнать — производительность померить, удобство работы сравнить.

[sashaeve]

>> Кто-нибудь использует технологии семантического веба в своих разработках?
Использую. Думаю, что вскоре выкачу статейку на эту тему. Сейчас доклад готовлю.

[yamalight]

Команда DBpedia из соседней комнаты передает привет :D
Что до проектов, то являюсь участником проекта OntoWiki, направленного на создание инструментов для визуального редактирования семантических баз данных (отсюда и wiki, хотя это уже давно не только вики :) ).

[GMint]

Спасибо :-)
Да, насчет вики — пошла путаница, я сам совсем недавно был участником проекта SweetWiki. И даже делал свое в время анализ вашей вики, кстати говоря, очень было бы интересно актуализировать информацию по Wiki Semantic — что существует и развивается, а так же направление.

[edhell]

Но «взрыва» нет, как было с html. Простым смертным не понять даже базового rdf, а без sw-контента и от инструментов толку нет, даже если их сделать. Пока можно что-то внедрять только в узких гругах (интранет, кольца сайтов и т.д.).

[yamalight]

так ведь rdf «простым смертным» и не нужен совсем, они про него даже знать не должны. он же не для этого вообще.

[edhell]

Под «простыми смертными» я имел ввиду людей, которые разрабатывают и/или сопровождают веб-ресурсы. Это могут быть как и технари, так и гуманитарии (редакторы). Они могут быть и не глупыми, но осилить rdf им тяжело, тем более когда непонятен выхлоп.

[yamalight]

вот поэтому семантика пока и является совершенно отдельною вещью, которой занимаются отдельные люди. а на вопрос «зачем» по-моему уже столько раз отвечали, что понять сможет кто угодно)

[edhell]

А для серьёзного выхлопа — нужна серьёзная аудитория «понимающих», в этом и противоречие и затык с SW.

зы: баян пошёл)

[dmitriid]

Зачем отдельные? :) Отдельных людей нет. Есть все те же веб-программисты. И просто программисты.

[yamalight]

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

[dmitriid]

> слишком много все тут есть и слишком оно все непросто пока что.

вот это — ключевой момент :) потому что разбираться во всем этом будут точно не отдельные люди :)

[edhell]

Когда-то пытался экспериметально переделывать сайт с sql-базы на rdf (Jena+MySQL). Если данных мало — всё более-менее работает, если отключить reasoner (лог. вывод), то тоже всё терпимо, если контент статичен — тоже всё путём… Если объекты начинаются исчисляться тысячами и включить лог.вывод уровня owl lite, то изменения в базу вносятся по несколько минут и яве не хватало памяти в 1 гиг. В итоге тупо не смог реализовать простейший сайт по такой схеме: статический контент + гостевая книга)

[GMint]

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

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

[dmitriid]

Данную задачу скорее всего не надо решать с помощью MySQL. RDF — это все же графы, со всеми вытекающими

[GMint]

Здесь Jena для RDF/SPARQL, MySQL лишь для хранения информации использовался, я так предполагаю, хотя лучше услышать от автора.

[dmitriid]

Ааа. Сорри. Я просто на MySQL, как на красную тряпку накинулся :)

[edhell]

Jena хранит rdf в mysql в виде троек.

[tree]

Никак не закрою летнюю практику — использование семантической паутины в вики. Расширение SemanticWiki. Довольно сильно упрощает жизнь, но честно скажу — сильно не копал, скорость работы не мерял. Однако радует возможность «реюзать» уже введенную информацию для составления тех же списков. Интересная вещь, но пока что, увы, не более того =(

[kit]

Использую Dublin Core Metadata на progopedia.ru

[Aquary]

Могу ошибаться, но по-моему многое из их онтологии взято из MPEG-7, а именно то, что качсается класификаций контента и хронометража.
И это хорошо, никаких велосипедов.

[Busin]

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