Semantic Web и Linked Data подобны ближнему космосу: жизни там нет. Чтобы отправиться туда на более-менее длительный срок… ну, не знаю, что говорили вам в детстве в ответ на «хочу стать космонавтом». Но понаблюдать за происходящим можно и находясь на Земле; стать астрономом-любителем или даже профессионалом гораздо проще. В статье речь пойдет о свежих, не старее нескольких месяцев, трендах из мира RDF-хранилищ. Метафора в первом абзаце была навеяна вот этой эпических размеров рекламной картинкой. I. GraphQL для доступа к RDF
II. Адаптеры к MongoDB
III. OLTP vs. OLAP
IV. RocksDB
V. Поддержка LPG
     V.1. Модели данных
           V.1.1. Singleton Property
           V.1.2. Reification Done Right
           V.1.3. Прочие подходы
     V.2. Языки запросов
VI. Ужесточение лицензий Говорят, что GraphQL претендует стать универсальным языком доступа к базам данных. Как обстоят дела с возможностью использовать GraphQL для доступа к RDF? «Из коробки» такую возможность предоставляют: Если же хранилище такой возможности не предоставляет, её реализуют самостоятельно, написав соответствующий «распознаватель» (resolver). Так поступили, например, во французском проекте DataTourisme. Или уже можно ничего не писать, а просто взять HyperGraphQL. С точки зрения ортодоксального приверженца Semantic Web и Linked Data всё это, конечно, печально, поскольку кажется предназначенным для интеграций, выстраиваемых вокруг очередных data silos, а не подходящих для того платформ (разумеется, RDF-хранилищ). Впечатления от сравнения GraphQL со SPARQL двоякие. Тренд, комплементарный предыдущему. Если же говорить шире, об адаптерах к JSON-источникам, позволяющих более-менее «на лету» представлять JSON как RDF, то стоит вспомнить и довольно давно существующий SPARQL Generate, который можно приладить, например, к Apache Jena. Резюмируя первые два тренда, можно сказать, что RDF-хранилища демонстрируют полную готовность к интеграциям и функционированию в условиях «многовариантного хранения» (polyglot persistence). Известно, впрочем, что это последнее уже давно не в моде, и на смену ему грядет мультимодельность. А как обстоят дела с мультимодельностью в мире RDF-хранилищ? Если вкратце, то никак. Теме мультимодельных СУБД хочется посвятить отдельную статью. Пока же можно заметить, что мультимодельных СУБД, в которых основной моделью была бы графовая (разновидностью её можно считать RDF), сейчас нет. О некоей малой мультимодельности — поддержке RDF-хранилищами альтернативной графовой модели LPG — будет рассказано в разделе V. Впрочем, тот же Gartner пишет, что мультимодельность — условие sine qua non в первую очередь для операционных СУБД. Оно и понятно: в ситуации «многовариантного хранения» главные проблемы возникают с транзакционностью. Вот только где на шкале OLTP—OLAP находятся RDF-хранилища? Я бы ответил так: ни там, ни тут. Для обозначения того, к чему они предназначены, нужна какая-то третья аббревиатура. Как вариант предложил бы OLIP — Online Intellectual Processing. Однако все же: А теперь разрешите представить нового игрока на рынке. От создателей IBM Netezza и Amazon Redshift — AnzoGraph. Картинка из рекламы продукта на его основе была размещена в начале статьи. AnzoGraph позиционирует себя как GOLAP-решение. Как вам SPARQL c оконными функциями? — Выше уже была ссылка на анонс Stardog 7 Beta, где говорилось, что Stardog собирается использовать в качестве нижележащей системы хранения RocksDB — хранилище «ключ-значение», фейсбуковский форк гугловской LevelDB. Почему уже стоит говорить о некоем тренде? Во-первых, cудя по статье в Википедии, на RocksDB пересаживаются не только RDF-хранилища. Есть проекты по использованию RocksDB как движка хранения в ArangoDB, MongoDB, MySQL и MariaDB, Cassandra. Во-вторых, на RocksDB делаются проекты (т. е. не продукты) соответствующей тематики. Например, eBay использует RocksDB в платформе для своего «графа знаний». Между прочим, забавно читать: the query language started as a home grown format, but more recently it has been transitioning to be much more like SPARQL. Как в анекдоте: сколько knowledge graph ни делаем, все равно получается RDF. Другой пример — появившийся несколько месяцев назад Wikidata History Query Service. До его появления за историческими сведениями Викиданных приходилось обращаться через MWAPI к стандартному Mediawiki API. Теперь многое возможно на чистом SPARQL. «Под капотом» там тоже RocksDB. Кстати, сделал WDHQS, похоже, человек, занимавшийся импортом Freebase в Google Knowledge Graph. Напомню основное отличие LPG-графов от RDF-графов. В LPG на экземпляры ребер могут навешиваться скалярные свойства, в то время как в RDF они могут навешиваться лишь на «типы» ребер (зато не только скалярные свойства, но и обычные связи). Эта ограниченность RDF по сравнению с LPG преодолевается теми или иными техниками моделирования. Ограниченность же LPG по сравнению с RDF преодолевается сложнее, но LPG-графы больше, чем RDF-графы, похожи на картинки из учебника Харари, поэтому люди их хотят. Очевидно, задача поддержки LPG распадается на две части: Здесь имеется несколько возможных подходов. Самый буквальный подход к гармонизации RDF и LPG — это, наверное, singleton property: Задача поддержки LPG решается здесь на уровне RDFS. Такое решение требует внесения в соответствующий стандарт. Какие-то изменения могут потребоваться от RDF-хранилищ, поддерживающих присоединение следствий, а пока Singleton Property можно воспринимать просто как еще одну технику моделирования. Менее наивные подходы проистекают из осознания того, что экземпляры свойств вполне инстанциируются триплетами. Имея возможность говорить что-то о триплетах, мы получим возможность говорить и об экземплярах свойств. Самый солидный из этих подходов — RDF*, он же RDR, родившийся в недрах Blazegraph. Его с самого начала избрал для себя и AnzoGraph. Солидность подхода определяется тем, что в его рамках предлагаются соответствующие изменения в RDF Semantics. Суть, однако, чрезвычайно проста. В Turtle-сериализации RDF можно теперь будет писать примерно так: Можно не заморачиваться формальной семантикой, а просто считать, что у триплетов есть некие идентификаторы, являющиеся, естественно, URI, и составлять новые триплеты с этими URI. Останется лишь дать доступ к этим URI в SPARQL. Так поступает Stardog.  В Allegrograph пошли промежуточным путем. Известно, что идентификаторы триплетов в Allegrograph есть, но при реализации triple attributes наружу они не торчат. Однако и до формальной семантики очень далеко. Примечательно, что атрибуты триплетов — не URI, и значения этих атрибутов тоже могут быть только литералами. Адепты LPG получают ровно то, что хотели. В специально изобретенном формате NQX пример, аналогичный приведенному выше для RDF*, выглядит так: Поддержав тем или иным способом LPG на уровне модели, нужно дать возможность делать запросы к данным в такой модели. Кстати, GraphDB одно время поддерживала Tinkerpop/Gremlin, не поддерживая при этом LPG, но в версии 8.0 или 8.1 это прекратилось. Никаких прибавлений в пересечении множеств «triplestore of choice» и «open source triplestore» в последнее время не случалось. Новым RDF-хранилищам с открытым исходным кодом далеко до того, чтобы стать хорошим выбором для повседневного использования, а исходный код новых триплсторов, которые хотелось бы поиспользовать (того же AnzoGraph), закрыт. Скорее, можно говорить об убавлениях… Конечно, прежде открытый исходный код не закрывается, но некоторые хранилища c открытым исходным кодом постепенно перестают рассматриваться как достойные выбора. Virtuoso, имеющий opensource-редакцию, на мой взгляд, тонет в багах. Blazegraph куплен AWS и лег в основу Amazon Neptune; теперь непонятно, будет ли еще хоть один релиз. Остается лишь Jena… Если же открытый исходный код не очень важен, а хочется просто попробовать, то всё тоже менее радужно, чем раньше. Например: В общем, для рядового ИТ-обывателя космос становится все более и более недоступным, освоение его становится уделом корпораций.