🥇O que está acontecendo com os armazenamentos RDF agora?

A Web Semântica e o Linked Data são como o espaço sideral: não há vida lá. Ir lá por um período de tempo mais ou menos longo... Não sei o que te diziam quando criança em resposta a “Quero ser astronauta”. Mas você pode observar o que está acontecendo enquanto estiver na Terra; É muito mais fácil se tornar um astrônomo amador ou mesmo profissional.

O artigo se concentrará nas tendências recentes, com não mais de vários meses, do mundo do armazenamento RDF. A metáfora do primeiro parágrafo é inspirada na imagem publicitária de tamanho épico sob o corte.

Imagem épica

I. GraphQL para acesso RDF

Eles dizemque o GraphQL pretende se tornar uma linguagem universal de acesso a bancos de dados. E quanto à capacidade de acessar RDF usando GraphQL?

Fora da caixa, esta oportunidade é fornecida por:

Stardog (Blog, a documentação);
Produtos TopQuadrant (webinar, a documentação).

Se o repositório não oferecer essa oportunidade, ele poderá ser implementado de forma independente, escrevendo um “resolvedor” apropriado. Foi o que fizeram, por exemplo, no projecto francês DataTourism. Ou você não pode mais escrever nada, apenas pegue HiperGraphQL.

Do ponto de vista de um adepto ortodoxo da Web Semântica e do Linked Data, tudo isso, claro, é triste, pois parece projetado para integrações construídas em torno do próximo silo de dados, e não para plataformas adequadas (lojas RDF, é claro) .

As impressões da comparação do GraphQL com o SPARQL são duplas.

Por um lado, GraphQL parece um parente distante do SPARQL: resolve os problemas de reamostragem e multiplicidade de consultas típicos do REST - sem os quais, provavelmente, não seria possível considerar Linguagem de consulta, pelo menos para a web;
Por outro lado, o esquema rígido do GraphQL é decepcionante. Assim, a sua “introspectividade” parece muito limitada em comparação com a plena reflexividade do RDF. E não existe análogo de caminhos de propriedade, então nem está muito claro por que é “Graph-”.

II. Adaptadores para MongoDB

Uma tendência complementar à anterior.

No Stardog agora talvez - em particular, tudo no mesmo GraphQL - configure o mapeamento de dados MongoDB em gráficos RDF virtuais;
Ontotext GraphDB recentemente permite insira fragmentos no SPARQL na consulta MongoDB.

Se falarmos mais amplamente sobre adaptadores para fontes JSON, que permitem representar mais ou menos “on the fly” o JSON armazenado nessas fontes como RDF, podemos lembrar o já antigo Gerar SPARQL, que pode ser ajustado, por exemplo, para Apache Jena.

Resumindo as duas primeiras tendências, podemos dizer que os armazenamentos RDF demonstram total prontidão para integração e operação em condições de “persistência poliglota”. Sabe-se, porém, que este último está há muito fora de moda e está sendo substituído por está vindo multimodelo. E quanto à multimodelagem no mundo do armazenamento RDF?

Em suma, de jeito nenhum. Gostaria de dedicar um artigo separado ao tópico de SGBDs multimodelos, mas por enquanto pode-se notar que atualmente não existem SGBDs multimodelos “baseados” em um modelo gráfico (RDF pode ser considerado um tipo dele) . Algumas pequenas multimodelagens - suporte de armazenamento RDF para um modelo gráfico alternativo de GLP - serão discutidas em seção V.

III. OLTP vs. OLAP

No entanto, o mesmo Gartner escreveque o multimodelo é uma condição sine qua non principalmente para salas de cirurgia SGBD. Isto é compreensível: numa situação de “armazenamento multivariado”, os principais problemas surgem com a transacionalidade.

Mas onde estão localizados os armazenamentos RDF na escala OLTP-OLAP? Eu responderia assim: nem lá nem aqui. Para indicar a que se destinam, é necessária uma terceira abreviatura. Como opção eu sugeriria OLIP — Processamento Intelectual Online.

No entanto, ainda assim:

os mecanismos de integração com MongoDB implementados em GraphDB não são menos importantes pretendido para contornar problemas de desempenho de gravação;
Stardog vai ainda mais longe e completamente reescreve motor, novamente com o objetivo de melhorar o desempenho de gravação.

Agora deixe-me apresentar um novo player ao mercado. Dos criadores do IBM Netezza e do Amazon Redshift - AnzoGraph®. Uma foto de um anúncio de um produto baseado nele foi postada no início do artigo. O AnzoGraph se posiciona como uma solução GOLAP. O que você acha do SPARQL com funções de janela? -

SELECT ?month (COUNT(?event) OVER (PARTITION BY ?month) AS ?events) WHERE {  …  }

XNUMX. RochasDB

Já mais alto havia um link ao anúncio do Stardog 7 Beta, que dizia que o Stardog usaria o RocksDB como um sistema de armazenamento subjacente - um armazenamento de valor-chave, um fork do Facebook do LevelDB do Google. Por que vale a pena falar sobre uma determinada tendência?

Em primeiro lugar, a julgar por Artigo da Wikipédia, não apenas os armazenamentos RDF são “transplantados” para RocksDB. Existem projetos para usar RocksDB como mecanismo de armazenamento em ArangoDB, MongoDB, MySQL e MariaDB, Cassandra.

Em segundo lugar, projetos (ou seja, não produtos) sobre temas relevantes são criados no RocksDB.

Por exemplo, o eBay usa RocksDB em plataforma para o seu “gráfico de conhecimento”. Aliás, é engraçado ler: a linguagem de consulta começou como um formato desenvolvido internamente, mas mais recentemente está em transição para se parecer muito mais com SPARQL. Como na piada: não importa quanto gráfico de conhecimento façamos, ainda assim acabamos com RDF.

Outro exemplo – que apareceu há alguns meses Serviço de consulta de histórico do Wikidata. Antes de sua introdução, as informações históricas do Wikidata tinham que ser acessadas através de MWAPI para a API Mediawiki padrão. Agora muito é possível com SPARQL puro. “Sob o capô” também existe o RocksDB. A propósito, o WDHQS foi feito, ao que parece, pela pessoa que importou o Freebase para o Google Knowledge Graph.

V. Apoio ao GPL

Deixe-me lembrá-lo da principal diferença entre gráficos GLP e gráficos RDF.

No LPG, as propriedades escalares podem ser atribuídas a instâncias de aresta, enquanto no RDF elas só podem ser atribuídas a “tipos” de aresta (mas não apenas propriedades escalares, mas também conexões comuns). Esta limitação do RDF em comparação com o GLP superar uma ou outra técnica de modelagem. As limitações do GLP em comparação com o RDF são mais difíceis de superar, mas os gráficos do GLP são mais parecidos com imagens de um livro Harari do que com gráficos RDF, e é por isso que as pessoas os querem.

Obviamente, a tarefa de “apoio ao GPL” divide-se em duas partes:

fazer alterações no modelo RDF que possibilitem nele simular estruturas de GLP;
fazer alterações na linguagem de consulta RDF que tornem possível acessar dados neste modelo modificado ou implementar a capacidade de fazer consultas a este modelo em linguagens de consulta LPG populares.

V.1. Modelo de dados

Existem várias abordagens possíveis aqui.

V.1.1. Propriedade Singleton

A abordagem mais literal para harmonizar o CDR e o GPL é provavelmente propriedade singleton:

Em vez de, por exemplo, o predicado :isMarriedTo predicados são usados :isMarriedTo1, :isMarriedTo2 etc
Esses predicados tornam-se então sujeitos de novos trigêmeos: :isMarriedTo1 :since "2013-09-13"^^xsd:date etc
A conexão dessas instâncias de predicados com um predicado comum é estabelecida por trigêmeos da forma :isMarriedTo1 rdf:singletonPropertyOf :isMarriedTo.
Obviamente, o rdf:singletonPropertyOf rdfs:subPropertyOf rdf:type, mas pense por que você não deveria simplesmente escrever :isMarriedTo1 rdf:type :isMarriedTo.

O problema do “apoio ao GPL” é resolvido aqui ao nível do RDFS. Tal decisão requer inclusão no apropriado Стандарт. Algumas alterações podem ser necessárias para armazenamentos RDF que suportam a anexação de consequências, mas por enquanto, a propriedade Singleton pode ser considerada apenas mais uma técnica de modelagem.

V.1.2. Reificação bem feita

Abordagens menos ingênuas decorrem da constatação de que as instâncias de propriedade são totalmente instanciáveis por trigêmeos. Ao podermos dizer algo sobre trigêmeos, seremos capazes de falar sobre instâncias de propriedade.

A mais robusta dessas abordagens é RDF*, também conhecido como RDR, nascer nas profundezas do Blazegraph. É desde o início eleito para você e para o AnzoGraph. A solidez da abordagem é determinada pelo facto de, no seu âmbito, são oferecidos alterações correspondentes em Semântica RDF. A questão, porém, é extremamente simples. Na serialização Turtle do RDF agora você pode escrever algo assim:

<<:bob :isMarriedTo :alice>> :since "2013-09-13"^^xsd:date .

V.1.3. Outras abordagens

Você não pode se preocupar com a semântica formal, mas simplesmente assumir que os trigêmeos possuem determinados identificadores, que são, obviamente, URIs, e criar novos trigêmeos com esses URIs. Resta apenas dar acesso a esses URIs no SPARQL. Então chega Stardog.

Em Alegrógrafo vamos lá de forma intermediária. Sabe-se que os identificadores de trigêmeos no Allegrograph tem, mas ao implementar atributos triplos eles não se destacam. No entanto, ainda está muito longe da semântica formal. Vale ressaltar que os atributos trigêmeos não são URIs, e os valores desses atributos também podem ser apenas literais. Os adeptos do GLP conseguem exatamente o que queriam. No formato NQX especialmente inventado, um exemplo semelhante ao acima para RDF* se parece com este:

:bob :marriedTo :alice {"since" : "2013-09-13"}

V.2. Linguagens de consulta

Tendo suportado o GLP de uma forma ou de outra no nível do modelo, você precisa tornar possível fazer consultas nos dados desse modelo.

Blazegraph para consultas RDF* suporta SPARQL* и Gremlin. Uma consulta SPARQL* se parece com isto:

 SELECT * { <<:bob :isMarriedTo ?wife>> :since ?since }

Anzograph também suporta SPARQL* e vai apoiar Cypher, uma linguagem de consulta no Neo4j.
Stardog suporta o seu próprio extensão SPARQL e novamente Gremlin. Você pode obter o URI triplo e a “meta-informação” no SPARQL usando algo assim:

SELECT * {
    BIND (stardog:identifier(:bob, :isMarriedTo, ?wife) AS ?id)
    ?id :since ?since
}

Allegrograph também suporta seu próprio extensão SPARQL:

 SELECT * { ("since" ?since)  franz:attributesNameValue  ( :bob :marriedTo ?wife ) }

A propósito, o GraphDB já suportou Tinkerpop/Gremlin sem oferecer suporte a GLP, mas isso parou na versão 8.0 ou 8.1.

VI. Reforço das licenças

Não houve acréscimos recentes à interseção dos conjuntos “triplestore de escolha” e “triplestore de código aberto”. Os novos armazenamentos RDF de código aberto estão longe de ser uma boa escolha para o uso diário, e os novos armazenamentos triplos que eu gostaria de usar (como o AnzoGraph) são de código fechado. Em vez disso, podemos falar de diminuições...

É claro que o código aberto não foi encerrado no passado, mas alguns repositórios de código aberto aos poucos não são mais vistos como dignos de escolha. O Virtuoso, que tem uma edição opensource, está, na minha opinião, afogado em bugs. Blazegraph foi adquirido pela AWS e formou a base do Amazon Neptune; agora não está claro se haverá pelo menos mais um lançamento. Apenas Jena permanece...

Se o código aberto não é muito importante, mas você apenas quer experimentá-lo, então tudo também é menos otimista do que antes. Por exemplo:

Stardog pára distribuir a versão gratuita (no entanto, o período de teste da versão regular dobrou);
в Nuvem GraphDB, onde antes era possível escolher um plano básico gratuito, os registros de novos usuários foram suspensos.

Em geral, para o profissional médio de TI, o espaço está se tornando cada vez mais inacessível; seu desenvolvimento está se tornando o destino das corporações.

Fonte: habr.com

O que está acontecendo com o armazenamento RDF agora?