Pull to refresh

Comments 19

4 года назад RDF казался космосом и пришлось относительно долго в него вникать, когда я пришел на проект, но сейчас его мощь более чем очевидна. Однако технические моменты и производительность хранилища — в самом деле боль. Оно у нас свое, на базе обычный sql-БД (поддерживается как mysql, так и postgres).
Классы сущностей тут github.com/oat-sa/generis/tree/master/core/kernel/classes
Реализация хранилища тут github.com/oat-sa/generis/tree/master/core/kernel/persistence/smoothsql

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

А какая стратегия укладки триплетов в таблицы у вас, если словами? Просто EAV, одна таблица с тремя столбцами?

Да, именно так. Плоская таблица и поля subject, predicate, object + вспомогательные, вроде пользователя, что сделал запись и даты создания/обновления.
Должно работать небыстро по сравнению с purpose-built RDF-хранилищами… Хотя вот в Virtuoso подход практически такой же. Но там «под капотом» своя собственная, а не сторонняя, реляционная СУБД.

Быть может, в зависимости от типов запросов, помогли бы составные индексы наподобие [таких](http://docs.openlinksw.com/virtuoso/rdfperfrdfscheme/). А SPARQL-то у вас нет, да?

[Вот](https://www.springer.com/gp/book/9783642193569) не совсем ещё старая книжка, рассказывающая, как все устроено под капотом у purpose-built RDF-хранилищ (надеюсь, найдете, где скачать). Было ещё что-то хорошее и объемное, напишу, если вспомню.

Спасибо за ссылки, всегда приятно покопаться в чужой БД СУБД.
из других подходов есть еще ArangoDB + AQL. RDF там конечно тоже можно хранить, но более интересен комплексный подход — Document store + Graph DBMS + Key-value store
Каноничный RDF, к сожалению, в ArangoDB сохранить не получится; что-то более-менее RDF-подобное — наверное, да. Под «комплексным подходом» вы имеете в виду мультимодельные возможности ArangoDB? И подход, опять же, к чему? Если, например, говорить о подходах к интеграции гетерогенных данных, то да, мультимодельные СУБД и триплсторы немного конкурируют. Постараюсь в ближайшее время написать о мультимодельных СУБД отдельную статью, буду рад получить там ваши комментарии.
RDF слишком примитивен и если мы говорим о поиске/хранении знаний, а не о перетягивании старой парадигмы в сегодняшний день, то multi-model хранилище более эффективно. намного удобнее работать со связанными обьектами (документами), особенно при их создании/редактировании. да и мапится это все out of the box в JSON и далее в C++/Javascript. я собственно и написал «про другие подходы» так как задачи иногда не стоят с нуля, порой получаешь нафталиновое RDF/XML наследие как данность в начале проекта
Я с симпатией отношусь к ArangoDB (и к OrientDB тоже с симпатией отношусь). Если не вступать в теоретические дискуссии, а просто прицепиться к словам «знание» и «сегодняшний день», то на прошедшей на днях Knowledge Graph Conference, если судить по аннотациям докладов, ArangoDB никто не упоминал.
Blazegraph куплен AWS и лег в основу Amazon Neptune; теперь непонятно, будет ли еще хоть один релиз.
Blazegraph 2.1.5 все-таки вышел, но теперь, скорее всего, точно всё.
I. GraphQL для доступа к RDF

Этот тренд усиливается с каждым месяцем. Как минимум, два спеца и целая DBMS выразили поддержку только с конца года...



Кажется утверждается MultiAPI для MultiDBMS. GraphQL так хорош?
Это очень похоже на ситуацию с аналитикой семилетней давности. Отрасль радостно приняла колончатые базы как практичную вещь, при этом понимая, что кубы все равно лучше. Любим одних, женимся на других?

Спасибо за ссылки! Автор первой статьи писал мне как-то в LinkedIn: generally speaking, most people don't actually want to use SPARQL, and I think that's more important than any of the technology. Собственно, и всё.


Я рассматриваю поддержку RDF-хранилищами GraphQL как очередную попытку понравиться и стать понятными конвенциональным разработчикам. Предыдущей был JSON-LD. В дополнение к тому, что говорил в статье, могу добавить, что GraphQL сильно похож на MQL, язык запросов к Freebase, который особой популярности в LD-сообществе не приобрел.


Если интересует тема LD, есть Telegram-группа «Linked Data Russia»: https://t.me/linkeddatarussia, я больше там по этой теме пишу.

Да, не вооруженным глазом видно, SemanticWeb ищет спасительные соломинки — то JSON-LD, то теперь GraphQL. И напрашивается реакция: чем смотреть по сторонам, не лучше ли разобраться в себе, хорошенько покопаться в модели. Возможно пора уже заменить RDF на что-то более практичное ради успеха триплсторов.

Спасибо за ссылку на группу. Давно искал более-менее живое общение на тему SW.

Не все так плохо. Как обстоят дела, я писал в двух заключительных разделах другой статьи. Конечно, хочется увеличения рынка раз в несколько. Большие ожидания связываются с гартнеровскими «knowledge graphs». Но в той же статье отмечается, что все это вряд ли про российский рынок.


Некая ревизия модели сейчас в повестке есть — это RDF*, см. о ней раздел V.1.2 этой (под которой комментарий). Впрочем, можно сказать, что тут тоже «спасительная соломинка» — LPG.


Кстати, если совсем интересно, JSON-LD тоже вносит изменения в модель. Предикаты в нем могут быть пустыми узлами (другой вопрос, что за этим не стоит формальной семантики). Никто такого специально не хотел, так получилось. В принципе, это может быть использовано как один из способов поддержки LPG (см. раздел V.1 этой статьи), только ни одно RDF-хранилище такого не сохранит.

Насчет «отказаться от RDF» я конечно поспешил (спасибо группе — посвятили). Но, что важнее, присутствует прогресс.
Можно, наверное, выделить две серии корневых изменений:

1) Named graph + LinkedData (2014-2015)

2) RDF* + Knowledge graphs (2018-2019)

Так вот, думаю, накатывает новая (Бог любит троицу?). Об этом могут свидетельствовать подвижки внутри гигантов: построение экосистемы данных (Сбербанк). И мне еще кажется недооцененной идея прикреплять к триплам id (как это вроде есть в Stardog). RDF* — хорошо, но не достаточно.

А почему в разделе VI не упомянута реификация через rdf:Statement, rdf:subject, predicate and object? Это совсем не "Reification Done Right"? Из-за объёма?

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


Но главная проблема неприминимости реификации в чистм виде — что, что реифицируемые суждения не утверждаются. Ну т.е Фреге перед rdf:Statement знак штопора не поставил бы. В то время как в LPG ребро между узлами графа обычно все-таки что-то утверждает. Хотя, конечно, если строго, то семантики в двух узлах LPG-графа и ребре между ними столько же, сколько в бельевой веревке на двух гвоздях :-).


См. еще https://www.w3.org/TR/swbp-n-aryRelations/#RDFReification.

У GraphDB есть сравнение времени загрузки и занимаемого места на диске. GraphDB придерживается SA-интерпретации RDR.


К слову, у упоминаемой вами статьи было продолжение. Рисунок 7 показательный. Почему выбрали всё-таки Blazegraph, см. тут.

Sign up to leave a comment.

Articles