Комментарии 45
Крутил связку RDF+SPARQL вроде всё работает, но скорость не радует. В проекте есть готовые модули, но пока ждём пока «созреет» sw.
Делали поисковик основе sw. Пришли к выводу, что лучше sphinx использовать.
А что использовали в качестве БД?
mysql
RDF — это все же графы. Может, имело смысл смотреть в стороно граф-баз данных и набора технологий от tinkerpop: www.tinkerpop.com/ (а именно свзяка Blueprints/Pipes/Gremlin)
Очень интересная ссылка, приходилось уже использовать в проектах?
а где у них там базы данных? только пачку фреймворков вижу.
из баз под RDF/OWL самое удобное, чем пользовался, пока что Virtuoso
из баз под RDF/OWL самое удобное, чем пользовался, пока что Virtuoso
Эти фреймворки базаданнонезависимые. Поддерживают на данный момент Neo4j, OrientDB, интерфейс Sail: github.com/tinkerpop/blueprints/wiki
ах, вот оно как. понятно, спасибо :(
зараза! смайлик, конечно, такой :)
Смайлик неправильный :)
Они позволяют интересную работу с графами. Для затравки презентации:
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 есть много интересного
Они позволяют интересную работу с графами. Для затравки презентации:
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 есть много интересного
Занятные презентации. Было бы круто послушать выступление по ним :)
Так-то оно так. Но когда я присматривался к NoSQL'ю, я так и не нашел приемлемый БД на графах.
Neo4j не распределенный, и что еще хуже — AGPL. OrientDB — пока без распределенности, планируется репликация — говорят как в Монго — один мастер много слейвов (то есть и не распределенность вовсе). А ведь в Монго на самом деле честно автошардится?
FlockDB — хорошая, но очень простая, не представляю как сделать на ней range search какой-нибудь.
InfoGrid — нераспределенный + AGPL. AllegroGraph — туда же.
Это всё может показаться ворчанием, однако я хотел бы найти именно распределенный вариант =)
Neo4j не распределенный, и что еще хуже — AGPL. OrientDB — пока без распределенности, планируется репликация — говорят как в Монго — один мастер много слейвов (то есть и не распределенность вовсе). А ведь в Монго на самом деле честно автошардится?
FlockDB — хорошая, но очень простая, не представляю как сделать на ней range search какой-нибудь.
InfoGrid — нераспределенный + AGPL. AllegroGraph — туда же.
Это всё может показаться ворчанием, однако я хотел бы найти именно распределенный вариант =)
Вам нужна noSQL бд или бд под SPARQL/RDF?
MongoDB — документо-ориентированная БД — не пробовал там делать масштабируемое решение, но вроде как интересная. Если вам из такого рода БД — то советую посмотреть Cassandra.
Из БД которые работают именно по графам — HyperGraphDB
А если SPARQL, то есть вы планируете работать с RDF — то я пока лишь CORESE могу порекомендовать — с использованием KGRAM она стала масштабируемой.
MongoDB — документо-ориентированная БД — не пробовал там делать масштабируемое решение, но вроде как интересная. Если вам из такого рода БД — то советую посмотреть Cassandra.
Из БД которые работают именно по графам — HyperGraphDB
А если SPARQL, то есть вы планируете работать с RDF — то я пока лишь CORESE могу порекомендовать — с использованием KGRAM она стала масштабируемой.
Спасибо за ответ! По идее под проект подойдет и то и то, но чисто графовый вариант лучше ;-)
MongoDB — хорошо, но у Couch'а мне больше нравится решение по целостности базы + понадежнее вроде. А в HyperGraphDB я просто не нашел информации по распределенности — вроде она есть, но в каком виде и как это работает — негласная информация.
Если ничего не найду — останется действительно только
Cassandr'а. Но с этим семейством проблемы в том, что моделирование идет от запросов и для поиска по многим атрибутам придется делать кучу индексов и искать их пересечение (при этом для обычной БД — это тривиальная задача с одним индексом). + Проблемы с интервальными запросами.
Очень благодарен за CORESE, пошел изучать.
MongoDB — хорошо, но у Couch'а мне больше нравится решение по целостности базы + понадежнее вроде. А в HyperGraphDB я просто не нашел информации по распределенности — вроде она есть, но в каком виде и как это работает — негласная информация.
Если ничего не найду — останется действительно только
Cassandr'а. Но с этим семейством проблемы в том, что моделирование идет от запросов и для поиска по многим атрибутам придется делать кучу индексов и искать их пересечение (при этом для обычной БД — это тривиальная задача с одним индексом). + Проблемы с интервальными запросами.
Очень благодарен за CORESE, пошел изучать.
> хотел бы найти именно распределенный вариант
ой, вот с этим пока все плохо, насколько я понимаю :) имхо пока никто не знает, как нрамотно распределять граф при изменении его структуры :)
ой, вот с этим пока все плохо, насколько я понимаю :) имхо пока никто не знает, как нрамотно распределять граф при изменении его структуры :)
Да, это я и имел ввиду. И меня терзают сильные сомнения, что сделают качественный автоматический шардинг графов.
Основа для распределения — информация о связанности элементов в запросе. Грубо говоря при какой группировке запросов второго и большего уровней будет меньше всего. Задачу облегчает то, что можно (и нужно) хранить несколько копий каждой вершины — соответственно и группировать их можно по разному.
Как я вижу на данный момент, можно решить эту задачу используя предварительно составленные схемы распределения (ручками), а затем корректировать их на основе статистики запросов.
Основа для распределения — информация о связанности элементов в запросе. Грубо говоря при какой группировке запросов второго и большего уровней будет меньше всего. Задачу облегчает то, что можно (и нужно) хранить несколько копий каждой вершины — соответственно и группировать их можно по разному.
Как я вижу на данный момент, можно решить эту задачу используя предварительно составленные схемы распределения (ручками), а затем корректировать их на основе статистики запросов.
Кстати, а как дела обстоят у Виртуозо с апдейтом?
Мне пока приходилось работать лишь с CORESE.
Мне пока приходилось работать лишь с CORESE.
Я про такую штуку даже и не слышал о.О У нас основная масса используют либо виртуозо либо jena и производные )
У виртуозо почти со всем (по крайней мере в последней версии) почти все хорошо. По крайней мере гораздо лучше, чем у большинства других бекэндов 8]
У виртуозо почти со всем (по крайней мере в последней версии) почти все хорошо. По крайней мере гораздо лучше, чем у большинства других бекэндов 8]
>> Кто-нибудь использует технологии семантического веба в своих разработках?
Использую. Думаю, что вскоре выкачу статейку на эту тему. Сейчас доклад готовлю.
Использую. Думаю, что вскоре выкачу статейку на эту тему. Сейчас доклад готовлю.
Команда DBpedia из соседней комнаты передает привет :D
Что до проектов, то являюсь участником проекта OntoWiki, направленного на создание инструментов для визуального редактирования семантических баз данных (отсюда и wiki, хотя это уже давно не только вики :) ).
Что до проектов, то являюсь участником проекта OntoWiki, направленного на создание инструментов для визуального редактирования семантических баз данных (отсюда и wiki, хотя это уже давно не только вики :) ).
Но «взрыва» нет, как было с html. Простым смертным не понять даже базового rdf, а без sw-контента и от инструментов толку нет, даже если их сделать. Пока можно что-то внедрять только в узких гругах (интранет, кольца сайтов и т.д.).
так ведь rdf «простым смертным» и не нужен совсем, они про него даже знать не должны. он же не для этого вообще.
Под «простыми смертными» я имел ввиду людей, которые разрабатывают и/или сопровождают веб-ресурсы. Это могут быть как и технари, так и гуманитарии (редакторы). Они могут быть и не глупыми, но осилить rdf им тяжело, тем более когда непонятен выхлоп.
вот поэтому семантика пока и является совершенно отдельною вещью, которой занимаются отдельные люди. а на вопрос «зачем» по-моему уже столько раз отвечали, что понять сможет кто угодно)
А для серьёзного выхлопа — нужна серьёзная аудитория «понимающих», в этом и противоречие и затык с SW.
зы: баян пошёл)
зы: баян пошёл)
Зачем отдельные? :) Отдельных людей нет. Есть все те же веб-программисты. И просто программисты.
я начал изучать семантический веб в конце прошлого года и, в общем, до сих пор не скажу, что знаю хотя бы 10% от того, что надо знать. слишком много все тут есть и слишком оно все непросто пока что.
поэтому нужны отдельные люди, «все те же веб-программисты» не смогут составлять хорошие словари и прочие нужные в семантике вещи, которые по сути к программированию не сильно относятся.
поэтому нужны отдельные люди, «все те же веб-программисты» не смогут составлять хорошие словари и прочие нужные в семантике вещи, которые по сути к программированию не сильно относятся.
Когда-то пытался экспериметально переделывать сайт с sql-базы на rdf (Jena+MySQL). Если данных мало — всё более-менее работает, если отключить reasoner (лог. вывод), то тоже всё терпимо, если контент статичен — тоже всё путём… Если объекты начинаются исчисляться тысячами и включить лог.вывод уровня owl lite, то изменения в базу вносятся по несколько минут и яве не хватало памяти в 1 гиг. В итоге тупо не смог реализовать простейший сайт по такой схеме: статический контент + гостевая книга)
Возможно, просто данную задачу не стоит решать с использованием семантики?
Мне кажется основная проблема семантических технологий, что задачи надо ими решать, где стандартный подход либо сильно ограничивает, либо совсем невозможен.
А где же тогда это может быть полезно?
Например, мы можем унифицировать данные сразу многих ресурсов(блоги, например, с помощью SIOC и FAOF), если они будут использовать одни и те же онтологии, мы легко можем организовать по ним поиск и при этом можно будет давать качественный ответ на запрос.
Мне кажется основная проблема семантических технологий, что задачи надо ими решать, где стандартный подход либо сильно ограничивает, либо совсем невозможен.
А где же тогда это может быть полезно?
Например, мы можем унифицировать данные сразу многих ресурсов(блоги, например, с помощью SIOC и FAOF), если они будут использовать одни и те же онтологии, мы легко можем организовать по ним поиск и при этом можно будет давать качественный ответ на запрос.
Никак не закрою летнюю практику — использование семантической паутины в вики. Расширение SemanticWiki. Довольно сильно упрощает жизнь, но честно скажу — сильно не копал, скорость работы не мерял. Однако радует возможность «реюзать» уже введенную информацию для составления тех же списков. Интересная вещь, но пока что, увы, не более того =(
Использую Dublin Core Metadata на progopedia.ru
Могу ошибаться, но по-моему многое из их онтологии взято из MPEG-7, а именно то, что качсается класификаций контента и хронометража.
И это хорошо, никаких велосипедов.
И это хорошо, никаких велосипедов.
Всё это, к сожалению, на сегодняшнем уровне реализации предлагает производительность велосипеда в век космических кораблей, бороздящих просторы октрытого космоса. Причём за последние 3 года очень мало что изменилось, т.е. теория есть, на практике работает, но ооочень медленно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Настоящее семантической паутины